Differences

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

--- report:prm [2026/06/11 10:48] – [Communications] team6
+++ report:prm [2026/06/14 00:05] (current) – [Summary] team6
@@ Line 244: / Line 244: @@
 ==== Procurement ====
-//Document your procurement management strategy including make vs buy decisions, materials/services to be acquired, sources, costs, timings, etc.//
+Our procurement management strategy is designed to balance technical performance, strict budgetary limits, and the use of local, sustainable resources. The goal is to maximize the quality of our proof-of-concept prototype while remaining within the €100 project budget.
+. Make vs. Buy Strategy
+- Buy: We adopted a "Buy" strategy for essential electronic and structural components that require professional-grade manufacturing or certification. This includes the ESP32-WROOM-32 microcontroller, high-precision sensors (BH1750, MQ-135, DHT22), the short-throw projector, and raw metal stocks (aluminum and brass). Purchasing these ensures that the core technical functionality is reliable and meets initial safety standards.
+- Make: We adopted a "Make" strategy for all software logic, user interface development, detailed electronic schematics, and structural assembly. By building the backend with FastAPI and the frontend using HTML/CSS/JavaScript, we avoid costly outsourcing fees and retain full control over the user experience. The structural assembly—including the bent-metal frame and acoustic panel fitting—is performed in-house to reduce labor costs.
+. Materials, Sources, and Acquisition
+Our procurement strategy prioritizes reliability and local availability to shorten lead times and reduce environmental impact:
+- Electronics: Components were sourced through reputable distributors including Farnell (for the ESP32), Botnroll (for sensors and atomizers), and Aquario (for audio components and the projector). These sources were chosen for their technical documentation availability.
+- Structural & Acoustic: We sourced brass and aluminum from F. Marques da Silva S.A. and acoustic materials from Artnovion. These partnerships ensure that materials meet the performance requirements for clinical environments.
+- Antimicrobial Textiles: We identified the MEDIFLEX collection from Monteiro Fabrics to ensure our textiles are medical-grade and hygienic.
+. Budgeting and Timings
+All acquisitions were managed in strict alignment with our sprint schedule:
+- Initial Procurement: Electronic components were acquired during the first sprints to allow for early testing and code integration.
+- Structural Procurement: Raw materials were purchased following the finalization of the structural drawings and SolidWorks modeling.
+- Cost Monitoring: Procurement costs are strictly monitored using a Bill of Materials (BOM). Currently, our identified costs total approximately €53.91, providing a buffer against unforeseen technical needs or final prototype refinements.
 ==== Project Plan ====
@@ Line 362: / Line 393: @@
 Our team took some time to get to grips with Jira properly (especially launching sprints to record them, assigning story points and managing priorities, retrospectives and dailies), so we are detailing the 3 most recent sprints here (8, 9 and 10) since they best correspond to the requests.\\
-\\
 === Sprint 8:  May 21st - 28th 2026 ===
@@ Line 395: / Line 424: @@
 During this sprint, the team focused on continuing the prototype with the 3D piece to do as well. Improving the Wik, finishing the functional tests (Hardware), and finishing to detail the quality control part on Wiki.
-Looking at Figure {{ref>fig:Sprint10}}, the diagram's appearance is not really satisfactory as it shows the fairly regular completion of tasks; however, we were unable to complete all the story points: our estimate was too high relative to our workload capacity. Having completed all the tasks and story points of the last sprint 8, we wanted to increase the number of committed story points. Having completed 25 out of 55 story points (which is more than in the last sprint, as shown in Figure {{ref>fig:VelocityReport}}), we now need to try to determine our story point velocity to better plan future sprints.
+Looking at Figure {{ref>fig:Sprint10}}, the diagram's appearance is not really satisfactory as it shows, first of all, that we added story points after the sprint had already started, and that we didn't even complete half of the planned story points. This week was packed with tasks and story points. We still managed to complete the most important tasks, although only 13 out of the 31 (as shown in Figure {{ref>fig:VelocityReport}}).
 <WRAP centeralign>
@@ Line 405: / Line 434: @@
 \\
-Looking at Figure {{ref>fig:VelocityReport}}, the
+The velocity report in Figure {{ref>fig:VelocityReport}} shows the number of story points planned and completed for each sprint. It indicates an average of 8.38 completed story points, but this doesn't truly represent our actual story point completion rate. We need to average the last three sprints completed successfully. Our average story points completed is then 18 for the last three sprints. We would need to complete more sprints to obtain an average that accurately reflects our true capacity, and thus be able to properly plan task completion during sprints.
 <WRAP centeralign>
 <figure fig:VelocityReport>
-{{ :report:velocity_report.png?direct& |}}
+{{ :report:velocity_reporttttt.png?direct& |}}
 <caption>Velocity Report and Sprint details</caption>
 </figure>
@@ Line 419: / Line 448: @@
 ==== Sprint Evaluations ====
-//Include the summary of all the sprint retrospectives, including any actions implemented as part of the team’s continuous improvement strategy.//
 This section provides a retrospective analysis of each sprint, highlighting successes, challenges, and opportunities for improvement. It examines team performance, project progress, and lessons learned, with the objective of continuously improving future sprint planning and execution.
@@ Line 427: / Line 455: @@
 <WRAP centeralign>
 <figure fig:Sprint5retro>
-{{ :report:sprint_5_retro.png?direct&600 |}}
+{{ :report:sprint_5_retro.png?direct& |}}
 <caption>Sprint 5 retrospective</caption>
 </figure>
@@ Line 438: / Line 466: @@
 <WRAP centeralign>
 <figure fig:Sprint6retro>
-{{ :report:sprint_6_retro.png?direct&600 |}}
+{{ :report:sprint_6_retro.png?direct& |}}
 <caption>Sprint 6 retrospective</caption>
 </figure>
@@ Line 449: / Line 477: @@
 <WRAP centeralign>
 <figure fig:Sprint7retro>
-{{ :report:sprint_7_retro.png?direct&600 |}}
+{{ :report:sprint_7_retro.png?direct& |}}
 <caption>Sprint 7 retrospective</caption>
 </figure>
@@ Line 460: / Line 488: @@
 <WRAP centeralign>
 <figure fig:Sprint8retro>
-{{ :report:sprint_8_retro.png?direct&600 |}}
+{{ :report:sprint_8_retro.png?direct& |}}
 <caption>Sprint 8 retrospective</caption>
 </figure>
@@ Line 472: / Line 500: @@
 <WRAP centeralign>
 <figure fig:Sprint9retro>
+{{ :report:sprint_9_retro.png?direct& |}}
 <caption>Sprint 9 retrospective</caption>
 </figure>
 </WRAP>
 \\
+=== Sprint 10 ===
+Looking at Figure {{ref>fig:Sprint10retro}} the team successfully completed several planned tasks, including designing the 3D part in SolidWorks, improving the quality control section of the Wiki, and finalizing the project video. However, the prototype assembly was delayed because we were waiting for validation of the 3D-printed component. We also observed that adding story points after the sprint had started negatively impacted the burndown chart. For future sprints, we aim to improve our planning by using previous sprint velocity to estimate workloads more accurately while continuing to make progress despite technical constraints.
+<WRAP centeralign>
+<figure fig:Sprint10retro>
+{{ :report:sprint_10_retro.png?direct& |}}
+<caption>Sprint 10 retrospective</caption>
+</figure>
+</WRAP>
+\\
 === Retrospective Summary ===
 Throughout the project, the team demonstrated a strong ability to achieve sprint objectives and continuously improve both technical deliverables and project documentation. Significant progress was made in prototype development, testing, reporting, and communication materials, while the team also showed resilience in overcoming technical challenges and external constraints.
@@ Line 484: / Line 525: @@
 ==== Summary ====
-//Provide here the conclusions of this chapter and make the bridge to the next chapter.//
+This chapter summarised the project management approach used for developing the Healing Cocoon prototype, a proof-of-concept designed to reduce anxiety in children in clinical waiting environments. The project scope focused on research, design, and development, organised using a Work Breakdown Structure (WBS) to structure tasks and responsibilities.
+The project was managed through short, structured development cycles with weekly planning sessions and Jira task tracking, enabling steady progress and flexibility over the 15-week timeline. The project was completed within a €100 budget by prioritising low-cost materials and components while maintaining core functionality.
+Quality was ensured through iterative testing, supervisor feedback, and a focus on safety, hygiene, accessibility, and reliability. Key stakeholders, including healthcare professionals, patients, supervisors, and suppliers, were considered throughout development.
+Communication was maintained using WhatsApp, Microsoft Teams, Outlook, and Jira to support effective collaboration. Risks were continuously identified and mitigated, while procurement decisions balanced cost, performance, and availability.
+Overall, this structured and iterative development process, supported by continuous feedback, allowed the team to deliver a functional prototype within the defined constraints of scope, time, cost, and quality.