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/06/14 15:01] – [3.3. Cost] team5report:prm [2026/06/14 18:22] (current) – [3.10.1 Sprint 3 Outcome] team5
Line 18: Line 18:
 ==== 3.1. Scope ==== ==== 3.1. Scope ====
  
-Defining the scope of CONNECT is essential for keeping our efforts focused on the project's objectives: reducing digital isolation and enhancing the passenger experience within the Metro do Porto. By mapping out exactly what is included in the project, we can prevent scope creep and ensure every team member understands the roadmap from conceptualization to final development. +Defining the scope of CONNECT and share is essential for keeping our efforts focused on the project's objectives: reducing digital isolation and enhancing the passenger experience within the Metro do Porto. By mapping out exactly what is included in the project, we can prevent scope creep and ensure every team member understands the roadmap from conceptualization to final development. 
  
 The Work Breakdown Structure (WBS) seen in the Figure {{ref>WBS}} ilustrates how we have divided the project into manageable phases and specific deliverables.  The Work Breakdown Structure (WBS) seen in the Figure {{ref>WBS}} ilustrates how we have divided the project into manageable phases and specific deliverables. 
Line 206: Line 206:
  
 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.  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.+The selected quality metrics focus on three dimensions: technical functionality, user experience, and project completeness. This ensures that CONNECT and share is not only operational, but also meaningful and usable in its intended social context.
 <table tab:quality> <table tab:quality>
 <caption>Quality Requirements and Metrics</caption> <caption>Quality Requirements and Metrics</caption>
Line 233: Line 233:
 | **5. Marketing** | 5.1 Flyer | Create brochure | Visual appeal | Professional, non-pixelated design | | **5. Marketing** | 5.1 Flyer | Create brochure | Visual appeal | Professional, non-pixelated design |
 | | 5.2 Leaflet | Explain the project | Message clarity | Passengers understand it instantly | | | 5.2 Leaflet | Explain the project | Message clarity | Passengers understand it instantly |
-| | 5.3 Poster | Design poster | Impact on the Metro | Visible colors and CONNECT logo |+| | 5.3 Poster | Design poster | Impact on the Metro | Visible colors and CONNECT and share logo |
 | | 5.4 Marketing Video | Record promotion | Promo quality | Fluid image and engaging message | | | 5.4 Marketing Video | Record promotion | Promo quality | Fluid image and engaging message |
 | | 5.5 3D Model Video | Show the interior | Technical fidelity | Internal mechanism is clearly visible | | | 5.5 3D Model Video | Show the interior | Technical fidelity | Internal mechanism is clearly visible |
Line 249: Line 249:
 </table> </table>
  
-To quantify the success of our work at the product level, we have established specific metrics and acceptance thresholds for the physical and digital architecture of CONNECT. As seen in Table {{ref>tab:product_metrics}}, each technical subsystem and deliverable is associated with a measurable requirement. The selected quality metrics focus on three dimensions: hardware stability, network communication, and software performance. This ensures that the Connect prototype is not only operationally sound under railway simulation constraints but also structurally safe and robust for real-world user interaction.+To quantify the success of our work at the product level, we have established specific metrics and acceptance thresholds for the physical and digital architecture of CONNECT and share. As seen in Table {{ref>tab:product_metrics}}, each technical subsystem and deliverable is associated with a measurable requirement. The selected quality metrics focus on three dimensions: hardware stability, network communication, and software performance. This ensures that the CONNECT and share prototype is not only operationally sound under railway simulation constraints but also structurally safe and robust for real-world user interaction.
  
 <table tab:product_metrics> <table tab:product_metrics>
Line 299: Line 299:
 | | 4.4 QR APP | Validate that 100% of scanned quick response paths trigger immediate HTTP 200 routing to the production landing URL. | | | 4.4 QR APP | Validate that 100% of scanned quick response paths trigger immediate HTTP 200 routing to the production landing URL. |
 | **5. Marketing** | 5.1 Flyer | Verify that all visual assets are exported with a professional graphic density of at least 300 DPI. | | **5. Marketing** | 5.1 Flyer | Verify that all visual assets are exported with a professional graphic density of at least 300 DPI. |
-| | 5.2 Leaflet | Measure that non-technical testers can decode the core CONNECT value proposition within $< 10$ seconds. | +| | 5.2 Leaflet | Measure that non-technical testers can decode the core CONNECT and share value proposition within $< 10$ seconds. | 
-| | 5.3 Poster | Ensure the corporate CONNECT logo identity remains perfectly legible from a physical distance of at least 3 meters. |+| | 5.3 Poster | Ensure the corporate CONNECT and share logo identity remains perfectly legible from a physical distance of at least 3 meters. |
 | | 5.4 Marketing Video | Render a full high-definition video track (1080p @ 60fps) with audio levels normalized strictly to -14 LUFS. | | | 5.4 Marketing Video | Render a full high-definition video track (1080p @ 60fps) with audio levels normalized strictly to -14 LUFS. |
 | | 5.5 3D Video | Display 100% of internal mechanism structures, including PCB positioning and internal CAN Bus network pathways. | | | 5.5 3D Video | Display 100% of internal mechanism structures, including PCB positioning and internal CAN Bus network pathways. |
Line 316: Line 316:
 </table> </table>
  
-Similarly, to verify the physical and digital architecture of the product without repeating project management milestones, Table {{ref>tab:product_verification}} provides the specific verification checklist for the technical deliverables of CONNECT. These product-level questions serve as the final engineering gate before hardware deployment.+Similarly, to verify the physical and digital architecture of the product without repeating project management milestones, Table {{ref>tab:product_verification}} provides the specific verification checklist for the technical deliverables of CONNECT and share. These product-level questions serve as the final engineering gate before hardware deployment.
  
 <table tab:product_verification> <table tab:product_verification>
Line 340: Line 340:
 /* //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.+To make CONNECT and share and share 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.
  
 == 3.5.1. Project Team and Internal Dynamics == == 3.5.1. Project Team and Internal Dynamics ==
Line 362: Line 362:
 | **Metro do Porto** | External client | Provides the operational context and establishes security and infrastructure standards. | | **Metro do Porto** | External client | Provides the operational context and establishes security and infrastructure standards. |
 | **Security Department (Metro)** | Regulatory body | Validates that the handle complies with fire, electrical, and physical safety regulations. | | **Security Department (Metro)** | Regulatory body | Validates that the handle complies with fire, electrical, and physical safety regulations. |
-| **Metro do Porto Users** | Target group | Live the CONNECT experience during their commutes and provide feedback. |+| **Metro do Porto Users** | Target group | Live the CONNECT and share experience during their commutes and provide feedback. |
 | **Suppliers** | Suppliers | Responsible for the timely delivery of components. | | **Suppliers** | Suppliers | Responsible for the timely delivery of components. |
 | **Legal** | Regulatory compliance | Guarantees that the QR app and data management comply with European regulations. | | **Legal** | Regulatory compliance | Guarantees that the QR app and data management comply with European regulations. |
Line 416: Line 416:
  
  
-To ensure CONNECT's success, communication is key. A communication strategy has been established to guarantee alignment between team members, supervisors and stakeholders.+To ensure CONNECT and share's success, communication is key. A communication strategy has been established to guarantee alignment between team members, supervisors and stakeholders.
  
  
Line 456: Line 456:
 /*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.*/ /*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.*/
  
-Risk management for CONNECT involves a systematic approach to identify and address potential challenges. Following the PMBOK standards, we have performed qualitative analyses to ensure that risks are treated effectively. +Risk management for CONNECT and share involves a systematic approach to identify and address potential challenges. Following the PMBOK standards, we have performed qualitative analyses to ensure that risks are treated effectively. 
  
 == 3.7.1. Identification of Key Risks == == 3.7.1. Identification of Key Risks ==
Line 527: Line 527:
  
 ==== 3.8. Procurement ==== ==== 3.8. Procurement ====
-The Connect procurement strategy balances regulated industrial components with cost-effective prototyping through centralized purchasing and institutional resource utilization. All components are sourced with a primary supplier and a defined fallback to ensure prototype assembly is not blocked by availability issues.+The CONNECT and share procurement strategy balances regulated industrial components with cost-effective prototyping through centralized purchasing and institutional resource utilization. All components are sourced with a primary supplier and a defined fallback to ensure prototype assembly is not blocked by availability issues.
  
 === 3.8.1. Sources === === 3.8.1. Sources ===
Line 692: Line 692:
 In Sprint 3 we consolidated both the technical foundation of the project and the supporting documentation. The team completed all planned issues in Jira, with no carry‑over work. Key outcomes included updated structural drawings and schematics (V2), the cardboard model, and a refined selection of materials and components. We also advanced the digital side with Figma designs for the message application and progressed written deliverables such as the background/related work and eco‑efficiency measures. Routine work like daily meetings, the sprint retrospective, and logbook updates was completed, ensuring the project stayed aligned and well documented. In Sprint 3 we consolidated both the technical foundation of the project and the supporting documentation. The team completed all planned issues in Jira, with no carry‑over work. Key outcomes included updated structural drawings and schematics (V2), the cardboard model, and a refined selection of materials and components. We also advanced the digital side with Figma designs for the message application and progressed written deliverables such as the background/related work and eco‑efficiency measures. Routine work like daily meetings, the sprint retrospective, and logbook updates was completed, ensuring the project stayed aligned and well documented.
  
-  * **Why the velocity report/burndown looks like this:** Being our first sprint managed in Jira, the chart reflects initial planning chaos. The scope (red line) suddenly spiked mid-sprint because we committed the mistake of **scope creep**, adding major deliverables like the Cardboard Model and V2 designs on the fly instead of locking the backlog on day one.+  * **Why the velocity report/burndown looks like this:** Being our first sprint managed in Jira, the chart reflects initial planning chaos. The scope (red line) suddenly spiked mid-sprint because we committed the mistake of scope creep, adding major deliverables like the Cardboard Model and V2 designs on the fly instead of locking the backlog on day one.
   * **The Good and the Bad (Why we didn't complete 100%):** The bad habit was a prolonged flatline at zero due to last-minute status changes; the team was working in the lab but forgot to update Jira progressively. On the good side, a powerful final surge allowed us to bulk-update and close the core technical foundations just before the deadline.   * **The Good and the Bad (Why we didn't complete 100%):** The bad habit was a prolonged flatline at zero due to last-minute status changes; the team was working in the lab but forgot to update Jira progressively. On the good side, a powerful final surge allowed us to bulk-update and close the core technical foundations just before the deadline.
   * **Retrospective & Group Dynamic:** We realized that our initial estimations were pure guesswork due to a lack of historical data. For the next cycles, we officially banned adding any new tasks once a sprint is active and established a strict rule for real-time status updates.   * **Retrospective & Group Dynamic:** We realized that our initial estimations were pure guesswork due to a lack of historical data. For the next cycles, we officially banned adding any new tasks once a sprint is active and established a strict rule for real-time status updates.
Line 707: Line 707:
 </WRAP> </WRAP>
  
-In Sprint 4 we advanced both the written deliverables and the technical foundations of the CONNECT system. The team completed the core report chapters (Introduction, Background & Related Work, Marketing Plan, Eco‑Efficiency Measures, Ethical & Deontological Concerns) and updated the project wiki start page, ensuring the documentation is coherent and aligned with the project vision. On the technical side, we produced Structural Drawings V3 with measurements, Detailed Schematics V3, a general software flow chart, and updated the list of materials and components, while also finalizing the clickable web app prototype and the design system/brand guidelines. Routine process tasks such as daily meetings, the sprint retrospective, and logbook updates were completed, keeping communication and traceability strong. Some higher‑effort items like Chapter 3 – Project Management, Chapter 7 – Project Developments, and the Interim Presentation remained in progress and will be continued in Sprint 5.+In Sprint 4 we advanced both the written deliverables and the technical foundations of the CONNECT and share system. The team completed the core report chapters (Introduction, Background & Related Work, Marketing Plan, Eco‑Efficiency Measures, Ethical & Deontological Concerns) and updated the project wiki start page, ensuring the documentation is coherent and aligned with the project vision. On the technical side, we produced Structural Drawings V3 with measurements, Detailed Schematics V3, a general software flow chart, and updated the list of materials and components, while also finalizing the clickable web app prototype and the design system/brand guidelines. Routine process tasks such as daily meetings, the sprint retrospective, and logbook updates were completed, keeping communication and traceability strong. Some higher‑effort items like Chapter 3 – Project Management, Chapter 7 – Project Developments, and the Interim Presentation remained in progress and will be continued in Sprint 5.
  
   * **Why the velocity report/burndown looks like this:** In Sprint 4, we grew overly ambitious and massive overestimation took place, setting a giant baseline of over 110 Story Points. The scope stayed flat, but our completed work (green line) shows that we finished barely 50% of what we promised, revealing a clear bottleneck in our velocity.   * **Why the velocity report/burndown looks like this:** In Sprint 4, we grew overly ambitious and massive overestimation took place, setting a giant baseline of over 110 Story Points. The scope stayed flat, but our completed work (green line) shows that we finished barely 50% of what we promised, revealing a clear bottleneck in our velocity.
Line 820: Line 820:
  
 === 3.10.10 Sprint 12 Outcome === === 3.10.10 Sprint 12 Outcome ===
-Figure {{ref>sprint12}} +Figure {{ref>sprint12}} presents the tracking metrics and burndown trend from Sprint 12, highlighting the critical challenges faced by the team during the late-stage integration phase.
  
 <WRAP centeralign> <WRAP centeralign>
 <figure sprint12> <figure sprint12>
 {{ :report:sprint_12.png?800 |}} {{ :report:sprint_12.png?800 |}}
 +
 <caption>Sprint 12 Outcome </caption> <caption>Sprint 12 Outcome </caption>
 </figure> </figure>
 </WRAP> </WRAP>
  
 +  * **Why the velocity report/burndown looks like this:** The chart shows a severe execution gap, where we completed less than 50% of our planned tasks (reaching only around 17 Story Points out of 38). Furthermore, the scope (red line) shows unexpected increases both at the very beginning and at the absolute deadline, proving that we suffered from late-stage scope creep by adding unplanned emergency tasks on the fly.
 +  * **The Good and the Bad (Why we didn't complete 100%):** When combining the hardware and software systems, we discovered critical bugs, communication lags, and power instability that flatlined our progress (green line) between June 4th and June 8th. The good side was that once these technical bottlenecks were unblocked, the team achieved an acceleration during the final days to rescue the core data routing features.
 +  * **Retrospective & Group Dynamic:** We realized that leaving complex integrations for the next sprint was a high-risk management mistake. In our retrospective, we decided that the final cycle (Sprint 13) must be completely locked with zero new features, dedicating 100% of our remaining capacity to fixing small things and perfecting the final presentation.
  
-=== 3.10.11 Sprint 13 Outcome === 
-Figure {{ref>sprint13}}  
  
-<WRAP centeralign> 
-<figure sprint13> 
-{{ :report:sprint_13.png?800 |}} 
-<caption>Sprint 13 Outcome </caption> 
-</figure> 
-</WRAP> 
 ==== 3.11. Sprint Evaluations ==== ==== 3.11. Sprint Evaluations ====
 Sprint evaluations and retrospectives are fundamental to the team’s Agile workflow, allowing for continuous process improvement. Starting from Sprint 3, the team implemented formal retrospective sessions to identify bottlenecks and refine internal methodologies. Sprint evaluations and retrospectives are fundamental to the team’s Agile workflow, allowing for continuous process improvement. Starting from Sprint 3, the team implemented formal retrospective sessions to identify bottlenecks and refine internal methodologies.
  • report/prm.1781445660.txt.gz
  • Last modified: 2026/06/14 15:01
  • by team5