Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| report:prm [2026/04/08 17:38] – [Risk] team3 | report: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, | + | 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, |
| **Project Start: 6 of March 2026** | **Project Start: 6 of March 2026** | ||
| - | **Team Preparedness: | + | **Team Preparedness: |
| **Stakeholder Communication: | **Stakeholder Communication: | ||
| 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 | + | **Test |
| <WRAP centeralign> | <WRAP centeralign> | ||
| <figure fig:lca> | <figure fig:lca> | ||
| - | {{: | + | {{ : |
| < | < | ||
| </ | </ | ||
| </ | </ | ||
| - | /* | ||
| - | Table {{ref> | ||
| - | <WRAP centeralign> | ||
| - | <table tlabel10> | ||
| - | < | ||
| - | <WRAP box 400px center> | ||
| - | ^Abbreviation ^Description ^ | ||
| - | |EPS |European Project Semester | ||
| - | |ISEP|Instituto Superior de Engenharia do Porto | | ||
| - | |USB |Universal Serial Bus | | ||
| - | </ | ||
| - | </ | ||
| - | </ | ||
| - | |||
| - | <WRAP centeralign> | ||
| - | <table tlabel1x> | ||
| - | < | ||
| - | <WRAP box 500px center> | ||
| - | ^ <WRAP column 100px> | ||
| - | |EPS |European Project Semester | ||
| - | |ISEP|Instituto Superior de Engenharia do Porto | | ||
| - | |USB |Universal Serial Bus | | ||
| - | </ | ||
| - | </ | ||
| - | </ | ||
| - | |||
| - | Table {{ref> | ||
| - | <table tlabel11> | ||
| - | < | ||
| - | <WRAP 120px> | ||
| - | ^ API ^ Time (s) ^ | ||
| - | | EJML | ||
| - | | JAMA | ||
| - | | JBLAS | 29 | ||
| - | | MTJ | 18 | ||
| - | | WEKA | ||
| - | </ | ||
| - | </ | ||
| - | |||
| - | <WRAP centeralign> | ||
| - | <table tlabel12> | ||
| - | < | ||
| - | ^Fruit | ||
| - | |Pears | ||
| - | |Apples | ||
| - | |Oranges | ||
| - | </ | ||
| - | </ | ||
| - | |||
| - | Figure {{ref> | ||
| - | <WRAP centeralign> | ||
| - | <figure flabel10> | ||
| - | {{ : | ||
| - | < | ||
| - | </ | ||
| - | </ | ||
| - | |||
| - | Figure {{ref> | ||
| - | <WRAP centeralign> | ||
| - | <figure flabel20> | ||
| - | <WRAP group> | ||
| - | <WRAP half column> | ||
| - | <WRAP half column> | ||
| - | </ | ||
| - | < | ||
| - | </ | ||
| - | </ | ||
| - | |||
| - | Figure {{ref> | ||
| - | <WRAP centeralign> | ||
| - | <figure flabel30> | ||
| - | {{ : | ||
| - | < | ||
| - | </ | ||
| - | </ | ||
| - | */ | ||
| ==== Time ==== | ==== Time ==== | ||
| - | This subchapter underlines the deadlines that must be met. Documenting key milestones and linking them to deadlines is crucial for clarity, accountability, | + | This subchapter underlines the deadlines that must be met. Documenting key milestones and linking them to specific |
| - | + | ||
| - | **2026-02-28: | + | |
| - | + | ||
| - | + | ||
| - | **2026-03-11: | + | |
| - | + | ||
| - | + | ||
| - | **2026-03-18: | + | |
| - | + | ||
| - | **2026-03-21: | + | |
| + | **Project Duration:** 2026-02-23 → 2026-06-25 (123 days / ~17.5 weeks) | ||
| - | **2026-03-25:** Upload System Schematics & Structural Drawings + cardboard scale model | + | | # | Date | Milestone | Days from start | Risk | |
| + | |---|------|-----------|-----------------|------| | ||
| + | | — | **2026-02-23** | **Project start** | 0 | — | | ||
| + | | 1 | 2026-02-28 | Choose top 3 projects | 5 | Low | | ||
| + | | 2 | 2026-03-11 | Upload black box diagram and Structural Draft | 16 | Medium | | ||
| + | | 3 | 2026-03-18 | Upload the List of Components and Materials | 23 | High | | ||
| + | | 4 | 2026-03-21 | Define Project Backlog, Global Sprint Plan, Initial Sprint Plan and Release Gantt Chart | 26 | Medium | | ||
| + | | 5 | 2026-03-25 | Upload System Schematics & Structural Drawings + cardboard scale model | 30 | High | | ||
| + | | 6 | 2026-04-12 | Upload Interim Report and Presentation | 48 | Medium | | ||
| + | | 7 | 2026-04-16 | Interim Presentation + feedback | 52 | Low | | ||
| + | | 8 | 2026-04-22 | Upload 3D model video | 58 | Medium | | ||
| + | | 9 | 2026-04-29 | Upload final List of Materials (local providers, price, VAT, transportation) | 65 | High | | ||
| + | | 10 | 2026-05-02 | Upload refined Interim Report (after feedback) | 68 | Low | | ||
| + | | 11 | 2026-05-13 | Upload packaging solution | 79 | Medium | | ||
| + | | 12 | 2026-05-27 | Upload Functional Tests results | 93 | High | | ||
| + | | 13 | 2026-06-13 | Upload Final Report, Presentation, | ||
| + | | 14 | 2026-06-18 | Final Presentation + Individual Discussion + Assessment | 115 | Medium | | ||
| + | | 15 | 2026-06-23 | Wiki/ | ||
| + | | 16 | **2026-06-25** | **Prototype demonstration, | ||
| - | **2026-04-12: | ||
| + | **Risk legend:** | ||
| - | **2026-04-16:** Interim Presentation + feedback | + | - **Low** — Well-defined task, short turnaround, low dependency on external factors. |
| - | **2026-04-22:** Upload 3D model video | + | - **Medium** — Moderate complexity or dependency on prior deliverables; |
| - | **2026-04-29:** Upload final List of Materials | + | - **High** — Blocks downstream work, depends on external factors |
| - | **2026-05-02: | ||
| - | **2026-05-13: | ||
| - | **2026-05-27:** Upload Functional Tests results | + | **High-risk rationale:** |
| - | **2026-06-13:** Upload Final Report, Presentation, | + | - **List of Components (2026-03-18)** — drives all sourcing |
| - | **2026-06-18:** Final Presentation + Individual Discussion + Assessment | + | - **System Schematics + scale model (2026-03-25)** — physical deliverable, |
| - | **2026-06-23:** | + | - **Final Materials List (2026-04-29)** — depends on supplier responses, pricing, VAT, shipping lead times. |
| - | Update wiki, report and paper (corrections), | + | |
| - | Upload refined deliverables (source + PDF + code + drawings), | + | |
| - | Submit printed poster, brochure and leaflet | + | |
| - | **2026-06-25:**Prototype demonstration, | + | - **Functional Tests (2026-05-27)** — prototype |
| + | - **Final deliverables bundle (2026-06-13)** — largest single upload (report, presentation, | ||
| + | - **Prototype demonstration (2026-06-25)** — final, non-recoverable; | ||
| ==== Costs ==== | ==== Costs ==== | ||
| Line 150: | 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, | + | 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, |
| 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 157: | Line 87: | ||
| == Budget Management == | == Budget Management == | ||
| - | The budget was carefully managed throughout the project lifecycle. Multiple Portuguese suppliers were evaluated to achieve a balance between cost, quality, and delivery time. Where possible, components were sourced from a single supplier to minimise | + | The budget was carefully managed throughout the project lifecycle. Multiple Portuguese suppliers were evaluated to achieve a balance between cost, quality, and delivery time. Where possible, components were sourced from a single supplier to minimize |
| - | In some cases, sourcing from multiple suppliers resulted in increased shipping expenses. Although lower-cost alternatives were available, the team prioritised | + | In some cases, sourcing from multiple suppliers resulted in increased shipping expenses. Although lower-cost alternatives were available, the team prioritized |
| == Cost Analysis == | == Cost Analysis == | ||
| - | The final prototype cost reached | + | The final prototype cost reached |
| == Conclusion == | == Conclusion == | ||
| - | Overall, the budget was effectively controlled, with only a modest increase from the original | + | 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, |
| ---- | ---- | ||
| Line 183: | Line 113: | ||
| == Electrical Components (Per Bottle) == | == Electrical Components (Per Bottle) == | ||
| + | |||
| | Name | Description | Link | Quantity | Unit Price (€) | | | Name | Description | Link | Quantity | Unit Price (€) | | ||
| | TDS sensor | Measures conductivity in the water | [Mauser.pt](https:// | | TDS sensor | Measures conductivity in the water | [Mauser.pt](https:// | ||
| | MOSFET | Works as a switch for the voltage booster | [Mauser.pt](https:// | | MOSFET | Works as a switch for the voltage booster | [Mauser.pt](https:// | ||
| - | | Interface | + | | Battery |
| - | | Battery | 3.7V 3400mAh power supply | + | | BMS | Protects, balances and manages charging of the batteries | [Mauser.pt](https:// |
| - | | Accelerometer | Senses movement, bottle upright | [Kiwi-electronics.com](https:// | + | | Battery |
| - | | UV-C LED module | Sterilizes the water | [Fruugo.pt](https:// | + | | Charging port | DC port that connects to the BMS module |
| + | | Buck converter | Step-down for microcontroller (12 V → 5 V) | [Mauser.pt](https:// | ||
| + | | Magnetic reed switch | Switch for the base of the bottle | [Mauser.pt](https:// | ||
| + | | Fuse | Glass fuse 1 A, 5x20 slow blow | [Mauser.pt](https:// | ||
| + | | Fuse holder | Cylindrical fuse holder with threads | [Mauser.pt](https:// | ||
| + | | Breadboard | Protoboard 50x70 for the prototype circuit | [Mauser.pt](https:// | ||
| + | | 1.1 mm wire | Wiring for UV-C light (AWG26) | [Mauser.pt](https:// | ||
| + | | Accelerometer | Senses movement | ||
| + | | UV-C LED module | Sterilizes the water | [Fruugo.pt](https:// | ||
| | Pressure sensor | Tracks the water amount | [Fruugo.pt](https:// | | Pressure sensor | Tracks the water amount | [Fruugo.pt](https:// | ||
| - | | Temperature sensor | Measures temperature | + | | Temperature sensor | Measures temperature |
| - | | Microcontroller | + | | Breadboard kit | Includes wires, resistors, LEDs, etc. | [Joom.pt](https:// |
| - | | Charger module | + | | Microcontroller |
| - | | Voltage booster | + | | Charger |
| ---- | ---- | ||
| - | == Total Estimated Cost per Prototyp | + | == Estimated Cost per Prototype |
| | Category | Estimated Cost (€) | | | Category | Estimated Cost (€) | | ||
| - | | Mechanical Components | 19.15 | | + | | Mechanical Components | 6.75 | |
| - | | Electrical Components | 89.04 | | + | | Electrical Components | 148.50 | |
| - | | Total Estimated Cost per Bottle | 108.19 | | + | | Total Estimated Cost per Bottle | 155.25 | |
| | Initial Budget | 100.00 | | | Initial Budget | 100.00 | | ||
| - | | Budget Difference | -8.19 | | + | | 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, | + | 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, |
| + | |||
| + | ---- | ||
| + | |||
| + | == Total Estimated Cost == | ||
| + | |||
| + | | 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 | + | == Quality Metrics |
| - | To ensure the smart water bottle | + | To ensure the smart water bottle |
| - | == Sensors | + | ^ Metric ^ Description ^ Threshold ^ Review Method ^ |
| + | | Physical Dimensions | Bottle size must remain practical | ||
| + | | 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 | | ||
| + | | Water Quality Monitoring | TDS sensor should provide useful and stable water quality readings | Within ±10 % of calibrated reference values | Sensor calibration and comparison testing | | ||
| + | | Temperature Monitoring | Temperature sensor should provide reliable readings | Within ±2 °C of reference values | Reference thermometer comparison | | ||
| + | | Water Level Detection | Pressure sensor should correctly identify fill level states | Empty, half-full, full states detected correctly | Controlled fill testing | | ||
| + | | Motion & Orientation | Accelerometer should detect movement and bottle position | Correct detection of movement and upright state | Functional testing | | ||
| + | | 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 | | ||
| - | All sensors are tested for accuracy | + | == Review |
| - | The pressure sensor (FSR406) | + | As the final prototype |
| - | h = F / (A · ρ · g) | + | Any requirement that does not meet its defined threshold will be addressed through design improvements, |
| - | Where: | + | == Acceptance Criteria |
| - | * h = water height (m) | + | |
| - | * F = force measured by the sensor (N) | + | |
| - | * 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, | + | The smart water bottle prototype will be considered acceptable when all defined quality thresholds are achieved and no functional |
| + | ==== People & Stakeholder Management ==== | ||
| + | The stakeholder analysis | ||
| - | == Power and Battery Performance == | + | Stakeholders will be split into four separate groups: Key Figure, Influencer, Interested |
| - | 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. Battery life is verified to provide at least six hours of normal use, with charging completed within four hours, while ensuring no overheating occurs. | + | **Mendelow Matrix** |
| + | - **Key Figures** (High Interest, High Influence): Clients, Lecturers / Coordinator, | ||
| + | - **Influencers** (Low Interest, High Influence): ISEP Board, Competitors | ||
| + | - **Interested** (High Interest, Low Influence): Material Providers, Future Investors | ||
| + | - **Spectators** (Low Interest, Low Influence): Logistic Partners | ||
| - | == System Reliability and User Interface == | + | Figure {{ref> |
| - | The system is expected to operate reliably, with uptime of at least 95 %, no unexpected resets, and consistent sensor readings over time. The OLED display is tested for quick updates (less than one second) and clear readability in normal lighting conditions. | + | <WRAP centeralign> |
| + | <figure fig: | ||
| + | {{ : | ||
| + | < | ||
| + | </ | ||
| + | </ | ||
| - | == Electrical Safety == | + | __Analysis of Stakeholders__ |
| - | All electrical components are designed and tested for safe operation. A fuse protects the system | + | **Spectators — Logistics Partners:** While not directly involved, they may eventually experience benefits from an improved inspection |
| - | During assembly of the prototype, careful safety measures will be taken to minimize exposure to UV-C light, including proper handling, protective gear, and avoiding powering | + | **Interested: |
| + | - **Material Providers: | ||
| + | - **Future Investors: | ||
| - | == Review | + | **Influencers: |
| + | - **ISEP Board:** Though not actively participating, | ||
| + | - **Competitors: | ||
| - | Quality is verified through functional testing, calibration, | + | **Key Figures: |
| + | - **Clients: | ||
| + | - **Lecturers / Coordinator: | ||
| + | - **Project Group:** The student developers have the most motivation to succeed | ||
| - | == Acceptance Criteria == | + | __Communication Strategy__ |
| - | A deliverable is considered acceptable when all defined thresholds are met, the system operates reliably, | + | 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. |
| - | ==== People & Stakeholder | + | | Stakeholder |
| - | 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 | + | | **Clients** | Manage Closely | Progress updates, prototype demos, design decisions, clarification requests | Requirements, |
| - | them throughout the project. | + | | **Lecturers / Coordinator** | Manage Closely | Deliverables, |
| - | Stakeholders will be split into four separate groups: Key Figure, Influencer, Interested and lastly, | + | | **Project Group** | Manage Closely | Task status, blockers, decisions, shared documents | Same — bidirectional | Daily standups, Discord/ |
| - | Spectator. All the stakeholders would be placed against 2 axes, representing their interests and | + | | **ISEP Board** | Keep Satisfied | Final deliverables, compliance with academic standards | Academic framework, regulations, |
| - | influence. | + | | **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, | ||
| + | | **Future Investors** | Keep Informed | Pitch, final presentation, | ||
| + | | **Logistic Partners** | Monitor (minimal effort) | No active communication | Passive — potential future end-users | N/A (indirect) | None during project | | ||
| + | **Communication principles: | ||
| + | - **Single point of contact:** each external stakeholder is handled by one designated team member to avoid mixed messages. | ||
| + | - **Documentation: | ||
| + | - **Escalation: | ||
| + | - **Feedback loop:** after each milestone, feedback received is reviewed in the following sprint planning. | ||
| + | ==== Communication ==== | ||
| - | **Mendelow Matrix** | + | TRAQUA uses a structured set of communication channels, each chosen for a specific purpose: fast internal coordination, |
| - | Key Figures: Clients, Lecturers / Coordinator and the Project Group | + | **Internal Team Communication** |
| - | Influencers | + | - **WhatsApp** — primary channel for day-to-day coordination, |
| + | - **Microsoft Teams** — used to store documents, organize files, and hold formal online meetings when in-person is not possible. Channels are structured by workstream | ||
| + | - **Jira** — sprint backlog, task assignment, sprint retrospectives, | ||
| + | - **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. | ||
| - | Interested (High Interest, Low Influence): Material Providers | + | **Communication with Lecturers / Coordinators** |
| - | Spectators (Low interest, Low influence): Logistic Parteners | + | 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. |
| - | Figure {{ref> | + | After each teacher meeting, the team gathers to hold a **retrospective** and discuss the upcoming sprint. Outcomes are logged in Jira and the wiki. |
| + | | 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 | | ||
| - | <WRAP centeralign> | + | **Communication with Clients** |
| - | <figure fig: | + | |
| - | {{ : | + | |
| - | < | + | |
| - | </ | + | |
| - | </ | + | |
| + | Clients define the problem and validate the solution, so regular structured contact is essential. | ||
| + | - **Bi-weekly progress meetings** — demo current state, gather feedback, confirm direction. | ||
| + | - **Milestone demos** — aligned with major deliverables (interim presentation, | ||
| + | - **Email** — for formal questions, requirement clarifications, | ||
| + | - **Meeting minutes** shared within 24h of each meeting to confirm understanding. | ||
| - | __Analysis of Stakholders | + | **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. | ||
| - | Spectator: Logistics Partners: While not directly involved, they may eventually experience benefits from | + | - **Primary channel:** email for quotes, orders, and specifications. |
| - | an improved inspection system. However, their role is passive, and they will not influence or | + | - **Backup channel:** phone for urgent availability or lead-time issues. |
| - | interact with the project. | + | - **Single point of contact:** one team member owns each supplier relationship to avoid mixed messages. |
| + | - **Documentation: | ||
| - | Interested: | + | **Communication with Customers** |
| - | Project Group: The student developers have the most motivation to succeed and interest in | + | |
| - | creating a functional system but have limited influence over scope once defined by | + | |
| - | stakeholders. | + | |
| - | Future investors: They will invest money into a product so a close look on them must be keept | + | |
| + | Customers will have the opportunity to subscribe to a **free newsletter** that will update them on the company' | ||
| - | Influencer: | + | - **Newsletter** — monthly, opt-in, covering company updates |
| - | ISEP Board: though not actively participating | + | - **In-app support** — chat / contact form for direct questions. |
| - | academic frameworks | + | - **Social media** — for announcements, |
| - | Competiros: TRAQUA must keep an sharp eye on what the competitors develop | + | - **Response SLA** — customer support queries answered within 48h. |
| - | Key figures: Clients are central to the project' | + | **Communication with Charities / Partners** |
| + | To keep charities involved, the company will organize regular meetings with them to discuss relevant topics. This helps maintain strong and high-quality partnerships. | ||
| - | Lecturers: Advise the group and evaluate project quality. Offers ongoing feedback | + | - **Frequency:** quarterly alignment meetings. |
| - | determines part of the final grade. | + | - **Purpose: |
| - | ==== Communications ==== | + | - **Channel: |
| - | 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. | + | |
| - | 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 Tools Summary** |
| - | These sprint retrospectives and all sprint-related activities are documented and kept in Jira. | + | | Tool | Purpose | Audience | |
| + | |---|---|---| | ||
| + | | WhatsApp | Fast internal chat | Project Group | | ||
| + | | 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, | ||
| + | | Email | Formal external communication | Lecturers, Clients, Suppliers | | ||
| + | | Newsletter | Customer engagement | Customers | | ||
| + | | In-app support | Customer service | Customers | | ||
| - | 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 Principles** |
| - | Customers will have the opportunity | + | - **Right channel for the right message:** urgent = WhatsApp; formal = email; technical = Jira/Git; knowledge = wiki. |
| + | - **Asynchronous by default:** written communication preferred | ||
| + | - **Document everything: | ||
| + | - **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 keep charities involved, the company will also organize meetings with them to discuss relevant topics. This helps maintain strong and high-quality partnerships. | + | **Communication Risks & 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> | + | | Risk | Impact |
| - | <table tab: | + | |---|---|---| |
| - | ^ Risk ^ Possibility ^ Outcome ^ Prevention ^ Measure taken ^ | + | | Message overload |
| - | | Common illness | + | | Supplier delays in response |
| - | |Tasks not completed | + | | Client unavailable for feedback |
| - | | Lack of technical knowledge | + | | Missed lecturer agenda deadline |
| - | | The departure of a project member | + | | Meeting minutes not documented |
| - | | Loss of data | Unlikely | + | | Single point of failure on a channel |
| - | | Insufficient testing | + | ==== Risk Management ==== |
| - | | Lack of money to scale the project | + | |
| - | </ | + | |
| + | 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 analaysis** | + | === Risk Classification === |
| - | <WRAP centeralign> | + | Risks are categorized by type to make it easier to assign ownership and response strategy: |
| - | <figure fig:rismatrix> | + | |
| - | {{ : | + | |
| - | < | + | |
| - | </ | + | |
| - | </ | + | |
| + | * **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, | ||
| + | === Likelihood and Severity Scales === | ||
| - | Data leaks (12) | + | <table tab: |
| - | 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. | + | ^ Level ^ Likelihood ^ Severity ^ |
| + | | 1 | Improbable | Negligible | | ||
| + | | 2 | Remote | Marginal | | ||
| + | | 3 | Possible | Moderate | | ||
| + | | 4 | Likely | Critical | | ||
| + | | 5 | Frequent | Catastrophic | | ||
| + | </ | ||
| + | **Risk score** = Likelihood × Severity. Scores are interpreted as: | ||
| - | Battery exploding (8) | + | * **1–4 Low** — accept and monitor |
| - | 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 | + | * **5–9 Medium** — actively mitigate |
| + | * **10–15 High** — mitigate before development milestones | ||
| + | * **16–25 Critical** — must be addressed before | ||
| + | === Risk Register === | ||
| - | Application downtime (4) | + | The table below lists all identified risks, their assessment, the prevention strategy (applied before |
| - | 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, | + | |
| + | <table tab: | ||
| + | ^ 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; | ||
| + | | 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/ | ||
| + | | R04 | Team member departure | Project | Possible (3) | Critical (4) | 12 | Strong communication; | ||
| + | | 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; | ||
| + | | 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; | ||
| + | | 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; | ||
| + | | 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; | ||
| + | | R17 | Sensor calibration drift | Technical | Possible (3) | Moderate (3) | 9 | Use calibrated reference solutions; periodic recalibration; | ||
| + | | R18 | Poor team communication | Project | Possible (3) | Moderate (3) | 9 | Weekly standup; shared tools (Slack/ | ||
| + | </ | ||
| + | |||
| + | === Risk Matrix === | ||
| + | |||
| + | 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: | ||
| + | {{ : | ||
| + | < | ||
| + | </ | ||
| + | </ | ||
| - | API downtime (4) | + | === Risk Monitoring |
| - | 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, | + | |
| + | 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 |
| - | This risk concerns | + | * **Milestone reassessment**: |
| + | * **New risk intake**: any team member | ||
| + | * **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 | + | == 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 | + | 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 |
| + | == 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, | ||
| - | Short circuit | + | == R03 — Lack of technical knowledge |
| - | 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 | + | 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 |
| + | == 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, | ||
| ==== Procurement ==== | ==== Procurement ==== | ||
| Line 417: | Line 479: | ||
| == Procurement Table == | == Procurement Table == | ||
| - | ^ Item ^ Supplier ^ Manufacturer ^ Quantity ^ Lead Time (Days) ^ Notes ^ | + | ^ Item ^ Supplier ^ Backup |
| - | | TDS Sensor (SEN0244) | Mauser | TPXCKZ | 1 | 2–4 | Water quality measurement | | + | | TDS Sensor (SEN0244) | Mauser |
| - | | MOSFET (IRLZ44N) | Mauser | YOINNOVATI | + | | MOSFET (IRLZ44N) | Mauser | DigiKey | Infineon |
| - | | OLED Display | + | | Battery |
| - | | Battery (NCR18650) | Mauser | Panasonic | + | | BMS (3S) | Mauser | DigiKey | Generic |
| - | | Accelerometer (LIS3DHTR) | Kiwi Electronics | Seeed Studio | + | | Battery |
| - | | UV-C LED Module | Fruugo | - | 1 | 5–8 | Water sterilization | + | | Charging Port (DC connector) | Mauser | DigiKey | Generic |
| - | | Pressure Sensor (FSR406) | Fruugo | JETTING | 1 | 5–8 | Water level measurement | | + | | Buck Converter (LM2596) | Mauser | Grandado | Generic | 1 | 2–4 | 12 V → 5 V regulation | |
| - | | Temperature Sensor (KY-015 DHT) | Fruugo | AOKIN | 1 | 5–8 | Temperature sensing | | + | | Magnetic Reed Switch (SPST-NO) | Mauser | Farnell | Generic | 1 | 2–4 | Circuit-killer at bottle base | |
| - | | Activated Carbon Filter | Joom | - | 1 | 5–10 | Improves taste | | + | | Fuse (1 A, 5×20 slow blow) | Mauser | DigiKey | Eska | 1 | 1–3 | Overcurrent protection | |
| - | | Microcontroller (ESP32 DevKit V1) | Joom | ALLOYSEED | + | | Fuse Holder (5×20) | Mauser | Farnell | Generic | 1 | 1–3 | Fuse mounting | |
| - | | Charger | + | | Breadboard (Protoboard 50×70) | Mauser | DigiKey | Generic | 1 | 1–3 | Prototype circuit board | |
| - | | Voltage Booster (MT3608) | Joom | ALLOET | 2 | 5–10 | Voltage regulation | | + | | 1.1 mm Wire (AWG26) | Mauser | DigiKey | Goobay | 1 | 1–3 | UV-C light wiring |
| - | | Plastic Bottle | IKEA | IKEA | 1 | 1–2 | Prototype housing | | + | | Accelerometer (LIS3DHTR) | Kiwi Electronics | Farnell | STMicroelectronics |
| - | | Aluminium Foil | Continente | Continente | 1 | 0–1 | UV-C light reflection | | + | | UV-C LED Module | Fruugo | DigiKey | Generic |
| - | | Plastic Separator | Amazon | + | | Pressure Sensor (FSR406) |
| - | | **Total Components** | + | | Temperature Sensor (KY-015 DHT) | Fruugo |
| + | | Breadboard Kit | Joom | Fruugo | Generic | 1 | 5–10 | Wires, resistors, LEDs, etc. | | ||
| + | | Activated Carbon Filter | Joom | Fruugo | Generic | ||
| + | | Microcontroller (ESP32 DevKit V1) | Joom | Fruugo | Espressif | ||
| + | | Charger (3S 12.6 V / 2 A) | Joom | Worten | Generic | ||
| + | | Total Components | ||
| ==== 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 |
| - | The project | + | |
| - | The pre-work phase covered foundational scrum activities such as stand-ups, retrospectives, | + | |
| - | This iterative approach allowed the team to review progress regularly through retrospectives and adapt the backlog accordingly, | + | |
| - | Figure {{ref> | + | The pre-work phase covered foundational Scrum activities — stand-ups, retrospectives, |
| + | |||
| + | Figure {{ref> | ||
| Line 452: | Line 517: | ||
| </ | </ | ||
| - | Figure | + | Figures |
| Line 471: | Line 536: | ||
| </ | </ | ||
| - | //Document the project schedule, | + | === Gantt Chart and Key Project Phases === |
| + | |||
| + | The project | ||
| - | Gantt Chart and Key Project 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, | ||
| + | - **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, | ||
| - | - 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 | + | The project |
| - | The project | + | The product backlog |
| - | 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 | + | The backlog was managed |
| - | The backlog was managed using Jira only. At the beginning of each sprint, | + | During |
| - | 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 == |
| - | //Describe how prioritization | + | Prioritization |
| - | //Document how the estimation process was implemented, | + | * **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' | ||
| + | External dependencies (component delivery times, supplier responses, lecturer feedback) were also considered, with dependent tasks scheduled only after their inputs were confirmed available. | ||
| - | ===== Sprint Overviews ===== | + | == Estimation |
| - | * **Sprint 1: Foundation & Research ** | + | |
| + | 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 === | ||
| + | |||
| + | 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. | ||
| + | |||
| + | 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 1: Foundation & Research === | ||
| Period: March 5, 2026 – March 12, 2026 | Period: March 5, 2026 – March 12, 2026 | ||
| Line 520: | Line 604: | ||
| - | - **Sprint 2 Cor Development and Reporting** | + | === Sprint 2 Cor Development and Reporting |
| Line 537: | Line 621: | ||
| - | - **Sprint 3 Strategic Completiong & Prototyping** | + | === Sprint 3 Strategic Completiong & Prototyping |
| Period: March 19th, 2026 – March 26th, 2026 | Period: March 19th, 2026 – March 26th, 2026 | ||
| Line 550: | Line 634: | ||
| <WRAP centeralign> | <WRAP centeralign> | ||
| <figure fig: | <figure fig: | ||
| - | {{: | + | {{ : |
| < | < | ||
| </ | </ | ||
| Line 556: | Line 640: | ||
| - | - **Sprint 4: Interim Presentation and Interim Report** | + | |
| + | === Sprint 4: Interim Presentation and Interim Report | ||
| Period: **March 26th, 2026 – April 1st, 2026** | Period: **March 26th, 2026 – April 1st, 2026** | ||
| - | **Sprint Goal:** Finish up the Interim Report. | + | Sprint Goal: Finish up the Interim Report. |
| Sprint {{ref> | Sprint {{ref> | ||
| Line 566: | Line 651: | ||
| <WRAP centeralign> | <WRAP centeralign> | ||
| <figure fig: | <figure fig: | ||
| - | {{: | + | {{ : |
| < | < | ||
| </ | </ | ||
| </ | </ | ||
| ==== Sprint Outcomes ==== | ==== Sprint Outcomes ==== | ||
| + | /* | ||
| //Include the outcomes of all sprint reviews (what was the sprint backlog, completion status, planned capacity vs. achieved velocity).// | //Include the outcomes of all sprint reviews (what was the sprint backlog, completion status, planned capacity vs. achieved velocity).// | ||
| + | */ | ||
| + | |||
| ==== Sprint Evaluations ==== | ==== Sprint Evaluations ==== | ||
| + | /* | ||
| //Include the summary of all the sprint retrospectives, | //Include the summary of all the sprint retrospectives, | ||
| + | */ | ||
| + | |||
| This section evaluates the effectiveness of each sprint by reflecting on what went well and what could be improved. It includes insights into challenges faced, team performance, | This section evaluates the effectiveness of each sprint by reflecting on what went well and what could be improved. It includes insights into challenges faced, team performance, | ||
| + | The teams' first retrospective {{ref> | ||
| - | + | < | |
| - | + | ||
| - | The teams' first retrospective {{ref> | + | |
| - | < | + | |
| <figure fig: | <figure fig: | ||
| - | {{: | + | {{ : |
| < | < | ||
| </ | </ | ||
| Line 591: | Line 680: | ||
| The teams' second retrospective {{ref> | The teams' second retrospective {{ref> | ||
| - | < | + | < |
| <figure fig: | <figure fig: | ||
| - | {{: | + | {{ : |
| < | < | ||
| </ | </ | ||
| </ | </ | ||
| - | |||
| - | |||
| Retrospective {{ref> | Retrospective {{ref> | ||
| - | < | + | < |
| <figure fig: | <figure fig: | ||
| - | {{: | + | {{ : |
| < | < | ||
| </ | </ | ||
| </ | </ | ||
| + | |||
| Retrospective | Retrospective | ||
| - | < | + | |
| + | |||
| + | < | ||
| <figure fig: | <figure fig: | ||
| - | {{: | + | {{ : |
| < | < | ||
| </ | </ | ||
| </ | </ | ||
| + | ==== Summary ==== | ||
| - | |||
| - | |||
| - | ==== Summary ==== | ||
| - | //Provide here the conclusions of this chapter and make the bridge to the next chapter.// | ||