Differences

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

--- report:prm [2026/04/12 21:42] – [3.2.1. Ideal Product Cost] epsatisep
+++ report:prm [2026/04/30 17:44] (current) – [3.10. Sprint Outcomes] team5
@@ Line 111: / Line 111: @@
 The EPS teams have to complete a list of milestones to ensure project succes. The following Table {{ref>tab:milestones}} defines the project timeline, acting as the baseline to monitor the project's performance.
-<WRAP center round box 900px>
 <table tab:milestones>
 <caption>Project Milestones</caption>
+<WRAP center round box 900px>
 ^ Date ^ Description ^
 | 2026/02/28 | Choose and share the team's top 3 preferred project proposals |
@@ Line 134: / Line 132: @@
 | 2026/06/23 | Update the wiki, report, paper with all suggested corrections. Hand in to the EPS coordinator a printed copy of the poster, brochure and leaflet |
 | 2026/06/25 | Demonstration of the operation of the prototype and hand in the prototype and user manual to the client |
-</table>
 </WRAP>
+</table>
 The timeline reveals a strong concentration of deliverables in April and May, particularly around the interim report and prototype development phases. This required careful sprint planning to balance documentation and technical implementation tasks.
@@ Line 145: / Line 143: @@
 and demonstrate fiscal responsibility within the constraints set by the project brief.
-=== 3.2.1. Ideal Product Cost ===
+=== 3.3.1. Ideal Product Cost ===
 This section outlines the projected costs for a full-scale, production-ready deployment
@@ Line 153: / Line 151: @@
 Table {{ref>tlabelIdealHardware}} presents the planned ideal product hardware costs.
-<WRAP center round box 800px>
 <table tlabelIdealHardware>
 <caption>Ideal product component costs (full carriage deployment).</caption>
-^ Component ^ Type / Model ^ Qty ^ Unit Price (€) ^ Total (€) ^
+<WRAP center round box 700px>
+^ Component ^ Type / Model ^  Qty  ^  Unit Price (€) ^  Total (€) ^
 | Microcontroller | Wemos C3 mini (ESP32-C3) |  11  |  6.20 |  68.20 |
 | Enclosure | PA Rail (fire-resistant, 3D printed) |  2  |  69.30 |  138.60 |
@@ Line 165: / Line 163: @@
 | Power supply | DC Step-Down 36–72 V to 12 V, 10 A, 120 W |  6  |  24.67 |  148.02 |
 | Wiring, resistors | Miscellaneous passive components |  1 |  10.00 |  10.00 |
-| Power supply | (5V) |  1  |  37.15 |  37.15 |
+| Power supply | (5 V) |  1  |  37.15 |  37.15 |
 | Delivery | — |  —  |  — |  TBC |
-| **Total hardware cost** | | | |  **764.74** |
+| **Total** | | | |  **764.74** |
-</table>
 </WRAP>
+</table>
-Hardware costs per carriage total 727.59 €, with the PA Rail enclosure being the single most expensive line item at 138.60 € for two units, specified due to its fire-resistance properties required for compliance with metro safety standards. No equivalent Portuguese-based supplier was identified at the time of writing, with the current source located in France. At scale, per-unit hardware costs could be reduced through bulk procurement across multiple carriage deployments.
+Hardware costs per carriage total 727.59 €, with the Polyamide (PA) Rail enclosure being the single most expensive line item at 138.60 € for two units, specified due to its fire-resistance properties required for compliance with metro safety standards. No equivalent Portuguese-based supplier was identified at the time of writing, with the current source located in France. At scale, per-unit hardware costs could be reduced through bulk procurement across multiple carriage deployments.
 === 3.3.2. Prototype Cost ===
@@ Line 180: / Line 178: @@
 with no associated purchase cost. Table {{ref>tlabelPlannedCosts}} presents total list and pricing of components for the prototype. Planned cost is 3.55 € below budget ceiling (100 €).
-<WRAP center round box 600px>
 <table tlabelPlannedCosts>
 <caption>Planned prototype component costs.</caption>
+<WRAP center round box 800px>
 ^ Component ^ Type / Model ^ Qty ^ Unit Price (€) ^ Total (€) ^
-| Microcontroller | Wemos C3 mini (ESP32-C3) |  2 |  6.20 |  12.40 |
+| Microcontroller | Wemos C3 mini (ESP32-C3) | 2 | 6.20 | 12.40 |
-| Enclosure | PLA biodegradable (3D printed) |  1 |  13.99 |  13.99 |
+| Enclosure | PLA biodegradable (3D printed) | 1 | 13.99 | 13.99 |
-| Copper tape | Conductive adhesive, 20 mm × 20 m |  1 |  8.86 |  8.86 |
+| CAN bus cable | 2×1.0mm CCA speaker wire, 10m | 1 | 2.20 | 2.20 |
-| Velostat | Piezoresistive sheet (pressure sensor) |  1 |  7.90 |  7.90 |
+| LED strip diffuser | Opaque sliding diffuser for aluminium profile, 2m | 1 | 3.27 | 3.27 |
-| CAN Transceiver | MCP2551-I/P |  2 |  1.99 |  3.98 |
+| Potentiometer | 10 kΩ linear mono | 1 | 0.49 | 0.49 |
-| LED strip (addressable RGB) | WS2813 IP65, 60 LEDs/m, 1m |  1 |  11.27 |  11.27 |
+| Copper tape | Conductive adhesive, 50 mm × 20 m | 1 | 17.60 | 17.60 |
-| Barrel jack converter | DC female 2.5×0.6 mm, 1.5 m |  1 |  2.96 |  2.96 |
+| Velostat | Piezoresistive sheet (pressure sensor) | 2 | 7.90 | 15.80 |
-| Power supply | Universal regulated 3–12 V DC, 5 A |  1 |  26.49 |  26.49 |
+| CAN Transceiver | MCP2551-I/P | 2 | 1.99 | 3.98 |
-| Buck Converter | JOY-IT SBC-Buck02 - Conversor step down 9..35V para 5V 5A 25W | 1 | 4,60 | 4,60 |
+| LED strip (addressable RGB) | WS2813 IP65, 60 LEDs/m, 1m | 1 | 11.27 | 11.27 |
-| Wiring, resistors | Miscellaneous passive components |  1 |  4.00 |  4.00 |
+| Barrel jack adapter | DC female 5.5×2.1mm screw terminal | 1 | 0.92 | 0.92 |
-| **Total** | | | |  **96.45** |
+| Power supply | 5 VDC 4 A 20 W, 5.5×2.1mm | 1 | 11.75 | 11.75 |
-</table>
+| Jumper cables | 120-piece Dupont set M-M/M-F/F-F, 200mm | 1 | 3.20 | 3.20 |
+| Resistors | Metal film 1 kΩ 0.6 W | 10 | 0.05 | 0.50 |
+| **Total** | | | | **97.37** |
 </WRAP>
+</table>
 ==== 3.4. Quality ====
-Quality management is needed to ensure that every deliverable meets the technical requirements and the expectations of our primary stakeholders: Porto Metro passengers and EPS coordination. Following the PMBOK standards, quality is managed as a continuous process rather than a final check. By defining clear metrics and verification protocols, we minimize risks and guarantee that the final prototype is safe, functional and socially impactful.
+Quality management is needed to ensure that every deliverable meets the technical requirements and the expectations of our primary stakeholders: Porto Metro passengers and EPS coordination. Following the Project Management Body of Knowledge (PMBOK) standards, quality is managed as a continuous process rather than a final check. By defining clear metrics and verification protocols, we minimize risks and guarantee that the final prototype is safe, functional and socially impactful.
 === 3.4.1 Quality Requirements and Metrics ===
@@ Line 207: / Line 208: @@
 To quantify the success of our work, we have established specific metrics and acceptance thresholds. As seen in Table {{ref>tab:quality}} each deliverable is associated with a measurable requirement.
 The selected quality metrics focus on three dimensions: technical functionality, user experience, and project completeness. This ensures that Connect is not only operational, but also meaningful and usable in its intended social context.
-<WRAP center round 100%>
 <table tab:quality>
 <caption>Quality Requirements and Metrics</caption>
+<WRAP center round box 1200px>
 ^ WP ^ Deliverable (WBS) ^ Requirement ^ Quality Metric ^ Threshold (Acceptance) ^
-| **1. Management** | 1.1 WBS | Organize tasks | Complete list of deliverables | 100% of the WBS included |
+| **1. Management** | 1.1 WBS | Organize tasks | Complete list of deliverables | All mandatory deliverables included |
 | | 1.2 Gantt Chart | Control deadlines | Approved schedule | Finalized timeline |
 | | 1.3 Global Sprint Plan | Plan sprints | Sprint dates | Approved sprint plan |
 | | 1.4 Weekly Sprint Plan | Weekly tracking | Weekly version | Updated weekly plan |
-| | 1.5 Product Backlog | Distribute workload | Jira | 100% of tasks assigned |
+| | 1.5 Product Backlog | Distribute workload | Jira | All active sprint tasks assigned |
 | | 1.6 Stakeholder Management | Identify key people | Stakeholder map | Closed list of stakeholders |
 | | 1.7 Risk Managemet Plan | Prevent issues | Response plan | Critical risks under control |
@@ Line 225: / Line 226: @@
 | | 3.3 Detailed Schematics | Circuit design | Electronic schematic | Finished and reviewed drawing |
 | | 3.4 Prototype (CAD) | 3D Design | Final digital model | Components fit correctly |
-| | 3.5 Packaging | Casing protection | Casing material | 100% recyclable material |
+| | 3.5 Packaging | Casing protection | Casing material | > 95% recyclable material |
 | | 3.6 Cardboard Model | Physical 3D "twin" | Real-scale model | Design matches 3D model |
 | **4. Development** | 4.1 List of Materials | Control spending | Final budget | Max. 100 € total cost |
@@ Line 242: / Line 243: @@
 | **7. Reporting** | 7.1 Interim Report | Mid-term report | Wiki chapters | Approved draft |
 | | 7.2 Interim Pres. | Present progress | PowerPoint presentation | Presentation performed |
-| | 7.3 Final Report | Final report | Final Wiki document | 100% of chapters closed |
+| | 7.3 Final Report | Final report | Final Wiki document | All required chapters finalized |
 | | 7.4 Final Pres. | Final defense | Project defense | Final presentation performed |
 | | 7.5 Paper | Write article | Paper format | Finished article |
 | | 7.6 Manual | User guide | Instructions for use | Easy-to-follow guide |
+</WRAP>
 </table>
-</WRAP>
 === 3.4.2 Verification Sheets ===
 While metrics define "what" we want to achieve, our verification system ensures "how" we check it. Table {{ref>tab:verification}} presents a series of Yes/No questions for every deliverable. These sheets act as a final quality gate: if the answer to the question is "Yes", the deliverable is accepted.
-<WRAP center round 100%>
 <table tab:verification>
 <caption>Verification Sheets for Deliverables</caption>
+<WRAP center round box 1200px>
 ^ WP ^ Deliverable (WBS) ^ Necessary Steps (Checklist) ^
 | **1. Management** | 1.1 WBS | Are all 35 deliverables included in the structure? |
@@ Line 271: / Line 270: @@
 | | 3.3 Schematics | Has the circuit schematic been verified to avoid short circuits? |
 | | 3.4 Prototype (CAD) | Has it been verified that all parts fit correctly in the 3D model? |
-| | 3.5 Packaging | Is the material 100% recyclable and does it protect the product? |
+| | 3.5 Packaging | Is the material > 95% recyclable and does it protect the product? |
 | | 3.6 Cardboard | Is the real-scale model finished and approved by the team? |
 | **4. Development** | 4.1 List Materials | Is the total budget under 100 €? |
@@ Line 292: / Line 291: @@
 | | 7.5 Paper | Does the article comply with the scientific paper format? |
 | | 7.6 Manual | Are the instructions easy to follow for any user? |
-</table>
 </WRAP>
+</table>
 ==== 3.5. People & Stakeholder Management ====
-//Enumerate all people relevant to your project, including the project team and key stakeholders. Document their roles and responsibilities. Document your stakeholder management plan and strategy.//
+/* //Enumerate all people relevant to your project, including the project team and key stakeholders. Document their roles and responsibilities. Document your stakeholder management plan and strategy.// */
 To make CONNECT a success, it is necessary to strategically manage all parties affected by the project. Following the PMBOK standards, this section identifies the key individuals and groups, defines their roles and outlines the management strategy.
@@ Line 310: / Line 309: @@
 Apart from the main teams, several external entities are involved in the project. In the Table {{ref>tab:stakeholders}} below, we identified them, their roles and their responsibilities.
-<WRAP center round 100%>
 <table tab:stakeholders>
 <caption>Stakeholders, Roles, and Responsibilities</caption>
+<WRAP center round box 1200px>
 ^ Entity / Name ^ Project Role ^ Primary Responsibility ^
 | **Team Members** | Project owners | Responsible for the full development cycle and all mandatory deliverables. |
@@ Line 325: / Line 324: @@
 | **Maintenance Team (Metro)** | Operational stakeholder | Evaluates ease of installation, durability, and maintenance of the smart handle. |
 | **Cleaning Staff (Metro)** | Operational support | Provides hygiene, accessibility, and resistance of the materials. |
-</table>
 </WRAP>
+</table>
 Among all stakeholders, Metro do Porto, the Security Department (Metro), and end users are considered critical, as they directly influence feasibility, approval, and user acceptance.
@@ Line 349: / Line 348: @@
 While the matrix identifies the "where", the following Table {{ref>tab:engagement}} defines the "how". It establishes the specific strategy for each group and assigns a point person from the internal team to manage the relationship.
-<WRAP center round box 100%>
+<WRAP center round box 900px>
 <table tab:engagement>
 <caption>Stakeholder Engagement Plan</caption>
@@ Line 390: / Line 389: @@
 === 3.6.2. Communication Matrix ===
+Table {{ref>tab:communication}} presents our activities and the way of realization, covering the frequency, medium, and participants involved in each communication event throughout the project.
-<WRAP center round 100%>
 <table tab:communication>
 <caption>Communication Matrix</caption>
+<WRAP center round box 800px>
 |**Activity**|**Objective**|**Frequency**|**Medium**|**Participants**|
 |Daily Stand-up|Daily tasks and identify blockers.|Daily|WhatsApp / Face-to-Face|Team Members|
@@ Line 400: / Line 399: @@
 |Retrospective|Evaluate team performance and workflow.|Weekly|Face-to-Face|Team Members|
 |Interim Demo|Present project status to coordinators.|Milestone-based|Presentation|Team & Supervisors|
-</table>
 </WRAP>
+</table>
 === 3.6.3. Stakeholder Management ===
@@ Line 410: / Line 409: @@
   * **Target Users:** Feedback gathered through surveys and testing sessions.
-===== 3.7. Risk =====
+==== 3.7. Risk ====
 /*Identify key risks (product and project level), evaluate them and define how they should be handled (responses) and monitored. Perform quantitative and qualitative risk analysis and use the results to define the appropriate risk responses.*/
@@ Line 445: / Line 444: @@
 <figure fig:risk_matrix>
 {{ :report:risk_matrix.png?direct&600 |}}
-<caption>Risk Matriz</caption>
+<caption>Risk Matrix</caption>
 </figure>
 </WRAP>
@@ Line 458: / Line 457: @@
 The risk analysis highlights that logistical and physical risks (delivery and vandalism) pose the greatest threat to project success, like it is shown in Figure {{ref>risk_analysis_final}}.
-<WRAP center round 100%>
 <table risk_analysis_final>
 <caption>Risk Analysis</caption>
+<WRAP center round box 1200px>
 ^ ID ^ Risk Description ^ Probability ^ Impact ^ Score ^ Response ^ Management (Action) ^ Follow-up ^
 | R1 | Delivery (Component delays) | 4 | 4 | 16 | Avoid | Purchase from local suppliers as soon as possible. | Weekly tracking of shipment ID. |
@@ Line 474: / Line 472: @@
 | R9 | Ergonomic Strain | 2 | 3 | 6 | Reduce | Create several 3D-printed prototypes for testing. | User feedback surveys. |
 | R10 | Privacy Breach | 1 | 5 | 5 | Avoid | No personal data is collected via the application. | Legal checklist verification. |
-</table>
 </WRAP>
+</table>
 === 3.7.3. Definition of Appropriate Risk Responses ===
@@ Line 485: / Line 483: @@
 All secondary risks are monitored through iterative testing to detect any score escalation.
-===== 3.8. Procurement =====
+==== 3.8. Procurement ====
@@ Line 502: / Line 500: @@
 The following Table {{ref>tab:makebuy}} summarizes the strategic choices for key project elements.
-<WRAP center round box 100%>
 <table tab:makebuy>
 <caption>Make vs. Buy Decision Summary</caption>
+<WRAP center round box 600px>
 ^ Item ^ Decision ^ Rationale ^
 | Electronic Nodes | Buy | Wemos C3 Mini boards offer greater reliability and lower cost than custom PCBs at prototype stage. |
@@ Line 510: / Line 508: @@
 | Sensing Material | Buy | Velostat is a specialized piezoresistive material with no viable in-house alternative. |
 | Web Platform | Make | Custom React/Supabase implementation ensures delayed-gratification logic and anonymization requirements are precisely met. |
+</WRAP>
 </table>
-</WRAP>
 === 3.8.3. Cost and Schedule Control ===
@@ Line 517: / Line 515: @@
 Expenditure is tracked against a detailed bill of materials within program budget constraints. Component procurement is milestone-gated to ensure availability before prototype assembly. Miscellaneous parts are sourced locally where possible to reduce lead times.
-===== 3.9. Project Plan =====
+==== 3.9. Project Plan ====
 As detailed in the Global Sprint Plan (see {{ref>sprint_plan}}), the project is divided into 15 distinct sprints.
-<WRAP center round box 600px>
 <table sprint_plan>
 <caption>Global sprint plan</caption>
+<WRAP center round box 600px>
 ^  Sprint  ^  Start  ^  Finish  ^  Working days  ^
 |  1  |  5 march  |  12 march  |  4 days of availability  |
@@ Line 527: / Line 525: @@
 |  3  |  19 march  |  26 march  |  5 days of availability  |
 |  4  |  26 march  |  2 april  |  5 days of availability  |
-|  5  |  2 april  |  9 april  |  2 days of availability  |
+|  5  |  2 april  |  16 april  |  2 days of availability  |
-|  6  |  9 april  |  16 april  |  3 days of availability  |
+|  6  |  16 april  |  23 april  |  5 days of availability  |
-|  7  |  16 april  |  23 april  |  5 days of availability  |
+|  7  |  23 april  |  30 april  |  5 days of availability  |
-|  8  |  23 april  |  30 april  |  5 days of availability  |
+|  8  |  30 april  |  14 may  |  4 day of availability  |
-|  9  |  30 april  |  7 may  |  1 day of availability  |
+|  9  |  14 may  |  21 may  |  5 days of availability  |
-|  10  |  7 may  |  14 may  |  3 days of availability  |
+|  10  |  21 may  |  28 may  |  5 days of availability  |
-|  11  |  14 may  |  21 may  |  5 days of availability  |
+|  11  |  28 may  |  4 june  |  5 days of availability  |
-|  12  |  21 may  |  28 may  |  5 days of availability  |
+|  12  |  4 june  |  11 june  |  5 days of availability  |
-|  13  |  28 may  |  4 june  |  5 days of availability  |
+|  13  |  11 june  |  18 june  |  5 days of availability  |
-|  14  |  4 june  |  11 june  |  5 days of availability  |
-|  15  |  11 june  |  18 june  |  5 days of availability  |
-</table>
 </WRAP>
+</table>
 The specific tasks and deliverables assigned to these periods are managed in the Project Backlog (see Table {{ref>project_backlog}}).
-<WRAP center round box 900px>
 <table project_backlog>
 <caption>Project backlog</caption>
+<WRAP center round box 900px>
 ^ Timeline ^ Epic ^ Ticket code ^ Ticket title ^ Status ^
 | Sprint 1 (5 Mar - 12 Mar) | General / No Epic | SCRUM-3 | Communication presentation | Done |
@@ Line 599: / Line 595: @@
 | Backlog | TESTING | SCRUM-67 | Non-functional testing | To Do |
 | Backlog | TESTING | SCRUM-68 | User-acceptance testing | To Do |
-</table>
 </WRAP>
+</table>
 The high-level distribution of Epic responsibilities across the timeline is summarized in the Initial Sprint Plan (see Table{{ref>initial_sprint}}).
-<WRAP center round box 900px>
 <table initial_sprint>
 <caption>Initial sprint plan</caption>
+<WRAP center round box 900px>
 ^ Sprint ^ Start ^ Finish ^ Epics ^ Responsible ^
 | 1 | 5 march | 12 march | INITIATION & PLANNING | All |
-| 2 | 12 march | 19 march | INITIATION & PLANNING ; SYSTEM DESIGN & DRAWINGS ; FINAL DELIVERABLES | All |
+| 2 | 12 march | 19 march | INITIATION & PLANNING; SYSTEM DESIGN & DRAWINGS; FINAL DELIVERABLES | All |
-| 3 | 19 march | 26 march | INITIATION & PLANNING ; SYSTEM DESIGN & DRAWINGS | All |
+| 3 | 19 march | 26 march | INITIATION & PLANNING; SYSTEM DESIGN & DRAWINGS | All |
-| 4 | 26 march | 2 april | SYSTEM DESIGN & DRAWINGS ; INTERIM REPORT & PRESENTATION | All |
+| 4 | 26 march | 2 april | SYSTEM DESIGN & DRAWINGS; INTERIM REPORT & PRESENTATION | All |
 | 5 | 2 april | 9 april | INTERIM REPORT & PRESENTATION | All |
-| 6 | 9 april | 16 april | PROTOTYPE CONSTRUCTION ; FINAL DELIVERABLES | All |
+| 6 | 9 april | 16 april | PROTOTYPE CONSTRUCTION; FINAL DELIVERABLES | All |
-| 7 | 16 april | 23 april | PROTOTYPE CONSTRUCTION ; FINAL DELIVERABLES | All |
+| 7 | 16 april | 23 april | PROTOTYPE CONSTRUCTION; FINAL DELIVERABLES | All |
-| 8 | 23 april | 30 april | PROTOTYPE CONSTRUCTION ; FINAL DELIVERABLES | All |
+| 8 | 23 april | 30 april | PROTOTYPE CONSTRUCTION; FINAL DELIVERABLES | All |
-| 9 | 30 april | 7 may | PROTOTYPE CONSTRUCTION ; FINAL DELIVERABLES | All |
+| 9 | 30 april | 7 may | PROTOTYPE CONSTRUCTION; FINAL DELIVERABLES | All |
-| 10 | 7 may | 14 may | PROTOTYPE CONSTRUCTION ; FINAL DELIVERABLES | All |
+| 10 | 7 may | 14 may | PROTOTYPE CONSTRUCTION; FINAL DELIVERABLES | All |
-| 11 | 14 may | 21 may | PROTOTYPE CONSTRUCTION ; FINAL DELIVERABLES | All |
+| 11 | 14 may | 21 may | PROTOTYPE CONSTRUCTION; FINAL DELIVERABLES | All |
-| 12 | 21 may | 28 may | PROTOTYPE CONSTRUCTION ; FINAL DELIVERABLES | All |
+| 12 | 21 may | 28 may | PROTOTYPE CONSTRUCTION; FINAL DELIVERABLES | All |
 | 13 | 28 may | 4 june | FINAL REPORT, PRESENTATION & VIDEO | All |
 | 14 | 4 june | 11 june | FINAL REPORT, PRESENTATION & VIDEO | All |
 | 15 | 11 june | 18 june | FINAL REPORT, PRESENTATION & VIDEO ; FINAL DELIVERABLES | All |
-</table>
 </WRAP>
+</table>
 Lastly, the visual dependencies and duration of these tasks are illustrated in the Gantt Chart (see Figure {{ref>fig:gantt_chart}}).
@@ Line 646: / Line 642: @@
 Bellow, we can see Table {{ref>sprint_reports}}, where we can find all Burn Down Chart from Sprint 3, with the which was first sprint managed in Jira.
-<WRAP center round box 600px>
 <table sprint_reports>
 <caption>Reports of sprint exported from Jira</caption>
+<WRAP center round box 600px>
 ^ Sprint ^ Report Link ^
 | Sprint 3 | {{ :report:sprint_3_report.pdf | Sprint 3 Report}} |
 | Sprint 4 | {{ :report:sprint_4_report.pdf | Sprint 4 Report}} |
-</table>
 </WRAP>
+</table>
 === 3.10.1 Sprint 3 Outcome ===