report:prm

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
report:prm [2026/04/30 17:22] – [3.3.2. Prototype Cost] team5report:prm [2026/05/16 20:40] (current) – team5
Line 143: Line 143:
 and demonstrate fiscal responsibility within the constraints set by the project brief. and demonstrate fiscal responsibility within the constraints set by the project brief.
  
-=== 3.3.1. Ideal Product Cost ===+== 3.3.1. Ideal Product Cost ==
    
 This section outlines the projected costs for a full-scale, production-ready deployment This section outlines the projected costs for a full-scale, production-ready deployment
Line 170: Line 170:
  
 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. 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 ===+== 3.3.2. Prototype Cost ==
  
 All components were procured through a single supplier ([[https://mauser.pt/|Mauser]]) to consolidate All components were procured through a single supplier ([[https://mauser.pt/|Mauser]]) to consolidate
Line 204: Line 204:
 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.  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 ===+== 3.4.1 Quality Requirements and Metrics ==
  
 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 is not only operational, but also meaningful and usable in its intended social context.
-<WRAP center round 100%> 
 <table tab:quality> <table tab:quality>
 <caption>Quality Requirements and Metrics</caption> <caption>Quality Requirements and Metrics</caption>
 +<WRAP center round box 1200px>
 ^ WP ^ Deliverable (WBS) ^ Requirement ^ Quality Metric ^ Threshold (Acceptance) ^ ^ WP ^ Deliverable (WBS) ^ Requirement ^ Quality Metric ^ Threshold (Acceptance) ^
 | **1. Management** | 1.1 WBS | Organize tasks | Complete list of deliverables | All mandatory deliverables included | | **1. Management** | 1.1 WBS | Organize tasks | Complete list of deliverables | All mandatory deliverables included |
Line 247: Line 247:
 | | 7.5 Paper | Write article | Paper format | Finished article | | | 7.5 Paper | Write article | Paper format | Finished article |
 | | 7.6 Manual | User guide | Instructions for use | Easy-to-follow guide | | | 7.6 Manual | User guide | Instructions for use | Easy-to-follow guide |
 +</WRAP>
 </table> </table>
-</WRAP> +== 3.4.2 Verification Sheets ==
- +
-Ja, hier is precies hetzelfde principe aan de hand! Een "100%" claim voor recyclebaarheid is in de praktijk (door bijvoorbeeld lijm, inkt of verontreiniging) heel lastig te garanderen en vormt daarom een red flag voor academische beoordelaars. +
- +
-Door dit te veranderen naar "> 95%" (net als in de vorige tabel), maak je de checkvraag realistisch en professioneel, zonder de inhoudelijke eis van jullie project te verliezen. +
- +
-Hier is de aangepaste code voor de tweede tabel. Je kunt deze direct kopiëren en de oude tabel in jullie wiki vervangen: +
- +
-Plaintext +
-=== 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. 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> <table tab:verification>
 <caption>Verification Sheets for Deliverables</caption> <caption>Verification Sheets for Deliverables</caption>
 +<WRAP center round box 1200px>
 ^ WP ^ Deliverable (WBS) ^ Necessary Steps (Checklist) ^ ^ WP ^ Deliverable (WBS) ^ Necessary Steps (Checklist) ^
 | **1. Management** | 1.1 WBS | Are all 35 deliverables included in the structure? | | **1. Management** | 1.1 WBS | Are all 35 deliverables included in the structure? |
Line 300: Line 291:
 | | 7.5 Paper | Does the article comply with the scientific paper format? | | | 7.5 Paper | Does the article comply with the scientific paper format? |
 | | 7.6 Manual | Are the instructions easy to follow for any user? | | | 7.6 Manual | Are the instructions easy to follow for any user? |
-</table> 
 </WRAP> </WRAP>
 +</table>
  
 ==== 3.5. People & Stakeholder Management ==== ==== 3.5. People & Stakeholder Management ====
Line 308: Line 299:
 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 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 ==
  
 We operate under a structure where all members share responsibility for project management. However, as we are a team of students with diverse backgrounds, special tasks are delegated based on individual expertise.  We operate under a structure where all members share responsibility for project management. However, as we are a team of students with diverse backgrounds, special tasks are delegated based on individual expertise. 
Line 314: Line 305:
 Using the weekly sprint plan helps us to redistribute tasks if a member is overburdened to prevent burnout and ensure quality. Using the weekly sprint plan helps us to redistribute tasks if a member is overburdened to prevent burnout and ensure quality.
  
-=== 3.5.2. Stakeholders Identification and Roles ===+== 3.5.2. Stakeholders Identification and Roles ==
  
 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.  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> <table tab:stakeholders>
 <caption>Stakeholders, Roles, and Responsibilities</caption> <caption>Stakeholders, Roles, and Responsibilities</caption>
 +<WRAP center round box 1200px>
 ^ Entity / Name ^ Project Role ^ Primary Responsibility ^ ^ Entity / Name ^ Project Role ^ Primary Responsibility ^
 | **Team Members** | Project owners | Responsible for the full development cycle and all mandatory deliverables. | | **Team Members** | Project owners | Responsible for the full development cycle and all mandatory deliverables. |
Line 333: Line 324:
 | **Maintenance Team (Metro)** | Operational stakeholder | Evaluates ease of installation, durability, and maintenance of the smart handle. | | **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. | | **Cleaning Staff (Metro)** | Operational support | Provides hygiene, accessibility, and resistance of the materials. |
-</table> 
 </WRAP> </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. 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.
-=== 3.5.2. Stakeholders Management Strategy ===+== 3.5.3. Stakeholders Management Strategy ==
  
 To manage these relationships effectively, we have analyzed each stakeholder based on their Power and Interest. This analysis allows us to prioritize our communication and engagement efforts. To manage these relationships effectively, we have analyzed each stakeholder based on their Power and Interest. This analysis allows us to prioritize our communication and engagement efforts.
Line 357: 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.  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> <table tab:engagement>
 <caption>Stakeholder Engagement Plan</caption> <caption>Stakeholder Engagement Plan</caption>
Line 386: Line 377:
  
  
-=== 3.6.1. Communication Channels and Tools ===+== 3.6.1. Communication Channels and Tools ==
  
 The team uses multiple tools to maintain a continuous flow of information: The team uses multiple tools to maintain a continuous flow of information:
Line 397: Line 388:
  
  
-=== 3.6.2. Communication Matrix === +== 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> <table tab:communication>
 <caption>Communication Matrix</caption> <caption>Communication Matrix</caption>
 +<WRAP center round box 800px>
 |**Activity**|**Objective**|**Frequency**|**Medium**|**Participants**| |**Activity**|**Objective**|**Frequency**|**Medium**|**Participants**|
 |Daily Stand-up|Daily tasks and identify blockers.|Daily|WhatsApp / Face-to-Face|Team Members| |Daily Stand-up|Daily tasks and identify blockers.|Daily|WhatsApp / Face-to-Face|Team Members|
Line 408: Line 399:
 |Retrospective|Evaluate team performance and workflow.|Weekly|Face-to-Face|Team Members| |Retrospective|Evaluate team performance and workflow.|Weekly|Face-to-Face|Team Members|
 |Interim Demo|Present project status to coordinators.|Milestone-based|Presentation|Team & Supervisors| |Interim Demo|Present project status to coordinators.|Milestone-based|Presentation|Team & Supervisors|
 +</WRAP>
 </table> </table>
-</WRAP> 
  
-=== 3.6.3. Stakeholder Management ===+== 3.6.3. Stakeholder Management ==
  
 We maintain a specific communication frequency with external parties: We maintain a specific communication frequency with external parties:
Line 424: Line 415:
 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 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 ==
  
 We have identified the following risks categorized into project and product levels. We have identified the following risks categorized into project and product levels.
Line 443: Line 434:
   * Privacy Breach: Unauthorized collection or exposure of user data through the interaction app.   * Privacy Breach: Unauthorized collection or exposure of user data through the interaction app.
  
-=== 3.7.2. Qualitative and Quantitative Evaluation ===+== 3.7.2. Qualitative and Quantitative Evaluation ==
 To evaluate these risks, we adopt a 5x5 Risk Matrix seen on the Figure {{ref>fig:risk_matrix}}. The exposure score is calculated by multiplying Probability (1-5) and Impact (1-5). To evaluate these risks, we adopt a 5x5 Risk Matrix seen on the Figure {{ref>fig:risk_matrix}}. The exposure score is calculated by multiplying Probability (1-5) and Impact (1-5).
  
Line 463: Line 454:
   * Extreme (15-25): Critical; requires immediate action and response.   * Extreme (15-25): Critical; requires immediate action and response.
  
-=== 3.7.3. Risk Analysis, Handling, and Monitoring Table ===+== 3.7.3. Risk Analysis, Handling, and Monitoring Table ==
  
 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}}. 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> <table risk_analysis_final>
 <caption>Risk Analysis</caption> <caption>Risk Analysis</caption>
 +<WRAP center round box 1200px>
 ^ ID ^ Risk Description ^ Probability ^ Impact ^ Score ^ Response ^ Management (Action) ^ Follow-up ^ ^ 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. | | R1 | Delivery (Component delays) | 4 | 4 | 16 | Avoid | Purchase from local suppliers as soon as possible. | Weekly tracking of shipment ID. |
Line 482: Line 472:
 | R9 | Ergonomic Strain | 2 | 3 | 6 | Reduce | Create several 3D-printed prototypes for testing. | User feedback surveys. | | 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. | | R10 | Privacy Breach | 1 | 5 | 5 | Avoid | No personal data is collected via the application. | Legal checklist verification. |
-</table> 
 </WRAP> </WRAP>
 +</table>
  
-=== 3.7.3. Definition of Appropriate Risk Responses ===+== 3.7.4. Definition of Appropriate Risk Responses ==
  
 Based on the results, our strategy prioritizes Extreme and High risks. Delivery (R1) and Vandalism (R5) require immediate mitigation through early procurement and robust mechanical design.  Based on the results, our strategy prioritizes Extreme and High risks. Delivery (R1) and Vandalism (R5) require immediate mitigation through early procurement and robust mechanical design. 
Line 498: Line 488:
 Connect and share procurement strategy balances regulated industrial components with cost-effective prototyping through centralized purchasing and institutional resource utilization. Connect and share procurement strategy balances regulated industrial components with cost-effective prototyping through centralized purchasing and institutional resource utilization.
  
-=== 3.8.1. Sources ===+== 3.8.1. Sources ==
  
 Three procurement streams are defined: Three procurement streams are defined:
Line 506: Line 496:
   * Fabrication (Make): ISEP facilities used for 3D printing and lab testing, reducing costs to raw filament only.   * Fabrication (Make): ISEP facilities used for 3D printing and lab testing, reducing costs to raw filament only.
  
-=== 3.8.2. Make vs. Buy Decisions ===+== 3.8.2. Make vs. Buy Decisions ==
  
 The following Table {{ref>tab:makebuy}} summarizes the strategic choices for key project elements. The following Table {{ref>tab:makebuy}} summarizes the strategic choices for key project elements.
  
-<WRAP center round box 100%> 
 <table tab:makebuy> <table tab:makebuy>
 <caption>Make vs. Buy Decision Summary</caption> <caption>Make vs. Buy Decision Summary</caption>
 +<WRAP center round box 600px>
 ^ Item ^ Decision ^ Rationale ^ ^ Item ^ Decision ^ Rationale ^
 | Electronic Nodes | Buy | Wemos C3 Mini boards offer greater reliability and lower cost than custom PCBs at prototype stage. | | Electronic Nodes | Buy | Wemos C3 Mini boards offer greater reliability and lower cost than custom PCBs at prototype stage. |
Line 518: Line 508:
 | Sensing Material | Buy | Velostat is a specialized piezoresistive material with no viable in-house alternative. | | 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. | | Web Platform | Make | Custom React/Supabase implementation ensures delayed-gratification logic and anonymization requirements are precisely met. |
-</table> 
 </WRAP> </WRAP>
 +</table>
  
-=== 3.8.3. Cost and Schedule Control ===+== 3.8.3. Cost and Schedule Control ==
  
 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. 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.
Line 527: Line 517:
 ==== 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. 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> <table sprint_plan>
 <caption>Global sprint plan</caption> <caption>Global sprint plan</caption>
 +<WRAP center round box 600px>
 ^  Sprint  ^  Start  ^  Finish  ^  Working days  ^ ^  Sprint  ^  Start  ^  Finish  ^  Working days  ^
 |  1  |  5 march  |  12 march  |  4 days of availability  | |  1  |  5 march  |  12 march  |  4 days of availability  |
Line 544: Line 534:
 |  12  |  4 june  |  11 june  |  5 days of availability  | |  12  |  4 june  |  11 june  |  5 days of availability  |
 |  13  |  11 june  |  18 june  |  5 days of availability  | |  13  |  11 june  |  18 june  |  5 days of availability  |
-</table> 
 </WRAP> </WRAP>
 +</table>
  
 The specific tasks and deliverables assigned to these periods are managed in the Project Backlog (see Table {{ref>project_backlog}}). 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> <table project_backlog>
 <caption>Project backlog</caption> <caption>Project backlog</caption>
 +<WRAP center round box 900px>
 ^ Timeline ^ Epic ^ Ticket code ^ Ticket title ^ Status ^ ^ Timeline ^ Epic ^ Ticket code ^ Ticket title ^ Status ^
 | Sprint 1 (5 Mar - 12 Mar) | General / No Epic | SCRUM-3 | Communication presentation | Done | | Sprint 1 (5 Mar - 12 Mar) | General / No Epic | SCRUM-3 | Communication presentation | Done |
Line 605: Line 595:
 | Backlog | TESTING | SCRUM-67 | Non-functional testing | To Do | | Backlog | TESTING | SCRUM-67 | Non-functional testing | To Do |
 | Backlog | TESTING | SCRUM-68 | User-acceptance testing | To Do | | Backlog | TESTING | SCRUM-68 | User-acceptance testing | To Do |
 +</WRAP>
 </table> </table>
-</WRAP> 
  
  
 The high-level distribution of Epic responsibilities across the timeline is summarized in the Initial Sprint Plan (see Table{{ref>initial_sprint}}). 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> <table initial_sprint>
 <caption>Initial sprint plan</caption> <caption>Initial sprint plan</caption>
 +<WRAP center round box 900px>
 ^ Sprint ^ Start ^ Finish ^ Epics ^ Responsible ^ ^ Sprint ^ Start ^ Finish ^ Epics ^ Responsible ^
 | 1 | 5 march | 12 march | INITIATION & PLANNING | All | | 1 | 5 march | 12 march | INITIATION & PLANNING | All |
Line 630: Line 620:
 | 14 | 4 june | 11 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 | | 15 | 11 june | 18 june | FINAL REPORT, PRESENTATION & VIDEO ; FINAL DELIVERABLES | All |
-</table> 
 </WRAP> </WRAP>
 +</table>
  
 Lastly, the visual dependencies and duration of these tasks are illustrated in the Gantt Chart (see Figure {{ref>fig:gantt_chart}}). Lastly, the visual dependencies and duration of these tasks are illustrated in the Gantt Chart (see Figure {{ref>fig:gantt_chart}}).
Line 652: 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. 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> <table sprint_reports>
 <caption>Reports of sprint exported from Jira</caption> <caption>Reports of sprint exported from Jira</caption>
 +<WRAP center round box 600px>
 ^ Sprint ^ Report Link ^ ^ Sprint ^ Report Link ^
 | Sprint 3 | {{ :report:sprint_3_report.pdf | Sprint 3 Report}} | | Sprint 3 | {{ :report:sprint_3_report.pdf | Sprint 3 Report}} |
 | Sprint 4 | {{ :report:sprint_4_report.pdf | Sprint 4 Report}} | | Sprint 4 | {{ :report:sprint_4_report.pdf | Sprint 4 Report}} |
-</table> 
 </WRAP> </WRAP>
 +</table>
  
-=== 3.10.1 Sprint 3 Outcome ===+== 3.10.1 Sprint 3 Outcome ==
 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.
  
-=== 3.10.2 Sprint 4 Outcome ===+== 3.10.2 Sprint 4 Outcome ==
 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 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.
  
Line 670: Line 660:
 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.
  
-=== 3.11.1. Sprint 3 Retrospective ===+== 3.11.1. Sprint 3 Retrospective ==
 In this sprint, the focus was on establishing the technical foundation. The retrospective revealed significant gaps in task granularity and time management. In this sprint, the focus was on establishing the technical foundation. The retrospective revealed significant gaps in task granularity and time management.
  
Line 681: Line 671:
   *Action Plan: The team committed to breaking down tasks into sub-tasks (max 4h each) and ensuring Jira is updated daily.   *Action Plan: The team committed to breaking down tasks into sub-tasks (max 4h each) and ensuring Jira is updated daily.
  
-=== 3.11.2. Sprint 4 Retrospective ===+== 3.11.2. Sprint 4 Retrospective ==
 Following the action plan from the previous sprint, Sprint 4 showed a marked improvement in organization and team morale. Following the action plan from the previous sprint, Sprint 4 showed a marked improvement in organization and team morale.
  
  • report/prm.1777566175.txt.gz
  • Last modified: 2026/04/30 17:22
  • by team5