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/07 10:37] – [3.2 Time] team4report:prm [2026/04/23 11:50] (current) – [3.3 Cost] team4
Line 4: Line 4:
 Managing a project that intersects marine ecology, hardware engineering, and software development requires a framework that balances rigid constraints with creative flexibility. This chapter details the management strategy employed by the group, organized across key knowledge areas including scope, risk, and procurement. Managing a project that intersects marine ecology, hardware engineering, and software development requires a framework that balances rigid constraints with creative flexibility. This chapter details the management strategy employed by the group, organized across key knowledge areas including scope, risk, and procurement.
  
-Due to the unpredictable nature of environmental hardware testing, we adopted an Agile (Scrum-inspired) methodology. This iterative approach was essential for managing the project’s high-risk components, such as waterproofing and sensor calibration. By prioritizing continuous feedback loops and adaptive planning, the team was able to pivot in response to technical challenges without compromising the project's primary milestones or budgetary limits.+Due to the unpredictable nature of environmental hardware testing, the team adopted an Agile (Scrum-inspired) methodology. This iterative approach was essential for managing the project. By prioritizing continuous feedback loops and adaptive planning, the team was able to pivot in response to technical challenges without compromising the project's primary milestones or budgetary limits.
 ==== 3.1 Scope ==== ==== 3.1 Scope ====
  
Line 19: Line 19:
 Each main component is further broken down into smaller elements, representing the key functionalities required for the system to operate. This visual representation helps clarify the scope of the project by identifying all relevant parts of the system and their relationships. Each main component is further broken down into smaller elements, representing the key functionalities required for the system to operate. This visual representation helps clarify the scope of the project by identifying all relevant parts of the system and their relationships.
    
-(See Figure {{ref>fig:Product}} for the wbs for the project and see Figure {{ref>fig:Management}} for the wbs of the project).+Figure {{ref>fig:Product}} presents the WBS for the product and Figure {{ref>fig:Management}} the WBS of the project.
  
 <WRAP centeralign> <WRAP centeralign>
 <figure fig:Product> <figure fig:Product>
-{{ :report:wbs_product.png?nolink&600 |}} +{{ :report:wbs_product_last.png?nolink&600 |}} 
-<caption> Start of a WBS </caption>+<caption> WBS of the product</caption>
 </figure> </figure>
 </WRAP> </WRAP>
Line 30: Line 30:
 <WRAP centeralign> <WRAP centeralign>
 <figure fig:Management> <figure fig:Management>
-{{ :report:wbs_project.png?nolink&600 |}} +{{ :report:wbs_projectm.png?nolink&600 |}} 
-<caption> Start of a WBS </caption>+<caption>WBS of the project</caption>
 </figure> </figure>
 </WRAP> </WRAP>
Line 41: Line 41:
 The team followed the milestone schedule defined by the project supervisors. These milestones provided a structured framework to monitor progress and ensure alignment with the overall project timeline. Table {{ref>tab_labelmilestones}} presents the defined milestones. The team followed the milestone schedule defined by the project supervisors. These milestones provided a structured framework to monitor progress and ensure alignment with the overall project timeline. Table {{ref>tab_labelmilestones}} presents the defined milestones.
  
 +<WRAP>
 <table tab_labelmilestones> <table tab_labelmilestones>
 +<caption>  Milestones for the project  </caption>
 |< 100% 90px >| |< 100% 90px >|
 ^  Date  ^ Description ^ ^  Date  ^ Description ^
-|  2026-02-28  | Choose and share your top-3 preferred project proposals via email to [epsatisep@gmail.com](mailto:epsatisep@gmail.com) | +|  2026-02-28  | Choose and share your top-3 preferred project proposals via email to [epsatisep@gmail.com](mailto:epsatisep@gmail.com)  | 
-|  2026-03-11  | Upload the “black box” **System Diagrams** & **Structural Drafts** to the wiki (Deliverables) | +|  2026-03-11  | Upload the “black box” **System Diagrams** & **Structural Drafts** to the wiki (Deliverables)  | 
-|  2026-03-18  | Upload the **List of Components and Materials (what & quantity)** to the wiki (Deliverables) | +|  2026-03-18  | Upload the **List of Components and Materials (what & quantity)** to the wiki (Deliverables)  | 
-|  2026-03-21  | Define the **Project Backlog** (what must be done and key deliverables - every member should preferably participate in every task), **Global Sprint Plan**, **Initial Sprint Plan** (which tasks should be included, who does what) and **Release Gantt Chart** of the project and insert them on the wiki (Report) | +|  2026-03-21  | Define the **Project Backlog** (what must be done and key deliverables - every member should preferably participate in every task), **Global Sprint Plan**, **Initial Sprint Plan** (which tasks should be included, who does what) and **Release Gantt Chart** of the project and insert them on the wiki (Report)  | 
-|  2026-03-25  | Upload the detailed **System Schematics & Structural Drawings** to the wiki (Deliverables) and do the **cardboard scale model** of the structure | +|  2026-03-25  | Upload the detailed **System Schematics & Structural Drawings** to the wiki (Deliverables) and do the **cardboard scale model** of the structure  | 
-|  2026-04-12  | Upload the **Interim Report and Presentation** to the wiki (Deliverables) ((The interim report must contain the the following chapters: Introduction, Project Management, State of the Art, Marketing Plan, Eco-efficiency Measures for Sustainability, Ethical and Deontological Concerns, Proposed Solution and Bibliography. In particular, the Project Management chapter includes the updated project progress register, the sprint report for completed sprints (tasks that were included, statuses, assignees, allocations) and the updated release Gantt chart.)) | +|  2026-04-12  | Upload the **Interim Report and Presentation** to the wiki (Deliverables)  | 
-|  2026-04-16  | Interim Presentation, Discussion and Peer, Teacher and Supervisor feedbacks | +|  2026-04-16  | Interim Presentation, Discussion and Peer, Teacher and Supervisor feedbacks  | 
-|  2026-04-22  | Upload **3D model video** to Deliverables | +|  2026-04-22  | Upload **3D model video** to Deliverables  | 
-|  2026-04-29  | Upload the final **List of Materials (local providers & price, including VAT and transportation)** to Deliverables | +|  2026-04-29  | Upload the final **List of Materials (local providers & price, including VAT and transportation)** to Deliverables  | 
-|  2026-05-02  | Upload refined Interim Report (based on Teacher & Supervisor Feedback) | +|  2026-05-02  | Upload refined Interim Report (based on Teacher & Supervisor Feedback)  | 
-|  2026-05-13  | Upload **packaging solution** to Deliverables and Report | +|  2026-05-13  | Upload **packaging solution** to Deliverables and Report  | 
-|  2026-05-27  | Upload the results of the **Functional Tests** to the Report | +|  2026-05-27  | Upload the results of the **Functional Tests** to the Report  | 
-|  2026-06-13  | Upload the **Final Report, Presentation, Video, Paper, Poster and Manual** to Deliverables | +|  2026-06-13  | Upload the **Final Report, Presentation, Video, Paper, Poster and Manual** to Deliverables  | 
-|  2026-06-18  | Final Presentation, Individual Discussion and Assessment (reserve the whole day) | +|  2026-06-18  | Final Presentation, Individual Discussion and Assessment (reserve the whole day)  | 
-|  2026-06-23  | Update the wiki, report, paper with all suggested corrections | +|  2026-06-23  | Update the wiki, report, paper with all suggested corrections  | 
-|  :::         | Place in the Shared section of the MS Teams channel of your team a **folder with the refined deliverables (source + PDF) together with all code and drawings produced** | +|  :::         | Place in the Shared section of the MS Teams channel of your team a **folder with the refined deliverables (source + PDF) together with all code and drawings produced**  | 
-|  :::         | Hand in to the EPS coordinator a **printed copy of the poster, brochure and leaflet** | +|  :::         | 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** |  +|  2026-06-25  | Demonstration of the **operation of the prototype**  |  
-|  :::         | Hand in the **prototype and user manual** to the client | +|  :::         | Hand in the **prototype and user manual** to the client  | 
-|  :::         | Receive the **EPS@ISEP certificate** | +|  :::         | Receive the **EPS@ISEP certificate**  | 
-|  :::         | Bring **typical food** from your country | +|  :::         | Bring **typical food** from your country  |
- +
-<caption> Milestones </caption>+
 </table> </table>
 +</WRAP>
 +
 ==== 3.3 Cost ==== ==== 3.3 Cost ====
 +When calculating the cost of the project, there are two key factors that need to be taken into consideration: employee salaries and the cost of materials and components.
 +
 +
 +The average salary for a junior engineer in Portugal is €1,500 per month, and the project duration is five months.
 +
 +
 +
 +
 +Therefore, the total salary cost is calculated as:
 +6 employees × 1500 € × 5 months = 45000 €
 +
 //Describe your project budget and its key components. Explain how your budget was managed throughout the project. Document the planned vs. effective costs of your project.// //Describe your project budget and its key components. Explain how your budget was managed throughout the project. Document the planned vs. effective costs of your project.//
  
 ==== 3.4 Quality ==== ==== 3.4 Quality ====
-//Document quality metrics that will apply to your project deliverables, associated thresholds and how they should be reviewed.//+Quality in this project is ensured by defining clear quality metrics for both the system and the documentation, together with acceptable thresholds and review procedures. 
 + 
 +For the product, key quality metrics include system functionality, structural stability, and sensor reliability. The system is considered acceptable when all core functions operate as intended, the structure remains stable under expected conditions, and the sensors provide consistent and reasonable data. These aspects are reviewed through testing in controlled environments and validation of system performance. 
 + 
 +For the documentation, quality is measured in terms of clarity, structure, consistency, and completeness. The report must clearly explain the project, follow a logical structure, and include all required sections. The acceptable threshold is that the documentation is understandable, coherent, and meets the academic guidelines provided. This is reviewed through internal checks within the team and feedback from supervisors. 
 + 
 +Regular reviews during sprint meetings are used to monitor progress and identify issues early. Corrections are made continuously to ensure that both the system and the documentation meet the expected quality standards.
  
 ==== People & Stakeholder Management ==== ==== People & Stakeholder Management ====
Line 81: Line 99:
 To achieve effective task allocation and maximize project outcomes, responsibilities are assigned based on each team member’s skills, field of study, and previous experience. This approach ensures that tasks are aligned with individual competencies, promoting efficiency, accountability, and overall team performance. To achieve effective task allocation and maximize project outcomes, responsibilities are assigned based on each team member’s skills, field of study, and previous experience. This approach ensures that tasks are aligned with individual competencies, promoting efficiency, accountability, and overall team performance.
  
-Academic supervisors from ISEP act as a key stakeholder by providing guidance, feedback and evaluation trouhgout the project. Their role is essential in ensuring that the project meets academic and technical standards.  +Academic supervisors from ISEP act as a key stakeholder by providing guidance, feedback and evaluation throughout the project. Their role is essential in ensuring that the project meets academic and technical standards.  
  
-External stakeholders include research intsitutions, NGOs and governmental organizations intressted in marine conservation and environmental monitoring. These stakeholders are potential future users or partners, as they can benefit from the data collected and the ecological impact of the solution. +External stakeholders include research institutions, Non Governamental Organizations (NGOs) and governmental organizations governmental organizations interested in marine conservation and environmental monitoring. These stakeholders are potential future users or partners, as they can benefit from the data collected and the ecological impact of the solution. 
  
  
Line 100: Line 118:
  
    
 +
 ==== Risk ==== ==== Risk ====
 The project involves several potential risks related to both technical and organizational aspects. One of the main risks is technical failure, particularly in the integration of sensors, electronics, and structural components in a marine-like environment. To reduce this risk, the system is tested in controlled conditions and components are selected based on reliability and compatibility.  The project involves several potential risks related to both technical and organizational aspects. One of the main risks is technical failure, particularly in the integration of sensors, electronics, and structural components in a marine-like environment. To reduce this risk, the system is tested in controlled conditions and components are selected based on reliability and compatibility. 
Line 107: Line 126:
 There is also a risk related to limited resources, including budget constraints and access to specialized equipment or testing environments. This is addressed by prioritizing essential features and selecting cost-effective solutions.  There is also a risk related to limited resources, including budget constraints and access to specialized equipment or testing environments. This is addressed by prioritizing essential features and selecting cost-effective solutions. 
  
-Team-related risks such as miscommunication or uneven workload distribution may affect progress. These risks are mitigated through regular Scrum meetings, clear task allocation, and continuous collaboration among team members. (See Table {{ref>tab_label6}} ).+Team-related risks such as miscommunication or uneven workload distribution may affect progress. These risks are mitigated through regular Scrum meetings, clear task allocation, and continuous collaboration among team members (see Table {{ref>tab_label6}}).
  
 <table tab_label6> <table tab_label6>
 +<caption> Table of different risks </caption>
 ^ Risk ^ Description ^ Probability ^ Impact ^ Risk Level ^ Mitigation Strategy ^ ^ Risk ^ Description ^ Probability ^ Impact ^ Risk Level ^ Mitigation Strategy ^
 | Technical failure (sensors/electronics) | Failure in integration of sensors, electronics, and structure in marine conditions | Medium | High | High | Test components and validate system | | Technical failure (sensors/electronics) | Failure in integration of sensors, electronics, and structure in marine conditions | Medium | High | High | Test components and validate system |
Line 116: Line 136:
 | Project delays | Delays caused by time constraints and task dependencies | Medium | High | High | Sprint planning, regular meetings, and buffer time | | Project delays | Delays caused by time constraints and task dependencies | Medium | High | High | Sprint planning, regular meetings, and buffer time |
 | Limited resources | Budget constraints and limited access to equipment or testing environments | Medium | Medium | Medium | Prioritize essential features and use cost-effective solutions | | Limited resources | Budget constraints and limited access to equipment or testing environments | Medium | Medium | Medium | Prioritize essential features and use cost-effective solutions |
-| Team miscommunication | Lack of coordination or unclear communication within the team | Low | Medium | Low | Regular Scrum meetings and clear communication |+| Team miscommunication | Lack of coordination or unclear communication within the team | Low | Medium | High | Regular Scrum meetings and clear communication |
 | Uneven workload distribution | Some team members contribute less, affecting progress | Low | Medium | Low | Clear task allocation and team collaboration | | Uneven workload distribution | Some team members contribute less, affecting progress | Low | Medium | Low | Clear task allocation and team collaboration |
-| Loss of buoy connection (data/power cable failure) | Interruption of data or power transfer between buoy and system | Low | High | Medium | Reinforced cables and redundancy |+| Loss of buoy connection (data/power cable failure) | Interruption of data or power transfer between buoy and system | Low | High | High | Reinforced cables and redundancy |
 | Corrosion of metallic components | Degradation due to exposure to saltwater | Medium | Medium | Medium | Use corrosion-resistant materials (BFRP, coatings) | | Corrosion of metallic components | Degradation due to exposure to saltwater | Medium | Medium | Medium | Use corrosion-resistant materials (BFRP, coatings) |
 | Extreme weather (storms, currents) | Harsh conditions affecting stability and performance | Low | High | Medium | Stable structure and secure anchoring | | Extreme weather (storms, currents) | Harsh conditions affecting stability and performance | Low | High | Medium | Stable structure and secure anchoring |
-| Waterproofing failure (IP68 breach) | Water entering electronic components causing malfunction | Low | High | Medium | Seal testing and proper enclosure |+| Waterproofing failure (IP68 breach) | Water entering electronic components causing malfunction | Low | High |High | Seal testing and proper enclosure |
 | Data transmission failure | Loss or interruption of data communication | Medium | Medium | Medium | Local data storage and redundancy | | Data transmission failure | Loss or interruption of data communication | Medium | Medium | Medium | Local data storage and redundancy |
-<caption> Tabel of different risks </caption> 
 </table> </table>
  
  
-{{ :report:risk_matrix.png?nolink&400 |}}+ 
 +To further support the risk assessment, a risk matrix based on probability and impact was used. The matrix classifies risks into three categories: low, medium, and high, depending on their likelihood of occurrence and potential impact on the project. 
 + 
 +Based on this matrix, risks such as technical failure, power system failure, integration issues, and project delays are classified as high risk, as they combine medium to high probability with high impact. These risks require priority attention and mitigation (see Figure {{ref>fig:Matrix}}). 
 + 
 +Risks such as limited resources, corrosion, extreme weather conditions, and data transmission failure fall into the medium-risk category. These are monitored and addressed through preventive design measures and planning. 
 + 
 +Lower-risk factors, including team miscommunication and uneven workload distribution, are classified as low risk, as they have limited impact and can be managed through regular communication and task organization. 
 + 
 +The use of this risk matrix provides a clear and structured way to prioritize risks and supports more effective decision-making throughout the project. 
 + 
 + 
 + 
 +<WRAP centeralign> 
 +<figure fig:Matrix> 
 +{{ :report:risk_matrix.png?nolink&200 |}}  
 +<caption>Risk matrix</caption> 
 +</figure> 
 +</WRAP> 
 + 
    
 ==== Procurement ==== ==== Procurement ====
Line 141: Line 180:
 <WRAP centeralign> <WRAP centeralign>
 <figure fig:gantt_chart> <figure fig:gantt_chart>
-{{ :report:gantt_chart.png?nolink&1000 |}} 
 <caption> Gantt chart showing the project timeline from March to June.</caption> <caption> Gantt chart showing the project timeline from March to June.</caption>
 +{{ :report:gantt_chart.png?nolink&1000 |}}
 </figure> </figure>
 </WRAP> </WRAP>
Line 149: Line 188:
 === Global Sprint === === Global Sprint ===
  
-The global sprint plan provides an overview of the project timeline, including the duration of each sprint, start and end dates, and the number of available working days. Its main purpose is to ensure a realistic distribution of workload based on the team’s availability throughout the project period. (See Table {{ref>tab:sprint1}} for the global sprint plan)+The global sprint plan provides an overview of the project timeline, including the duration of each sprint, start and end dates, and the number of available working days. Its main purpose is to ensure a realistic distribution of workload based on the team’s availability throughout the project period. See Table {{ref>tab:sprint1}} for the global sprint plan.
  
 By defining how long each sprint lasts and how many working days are available, the team can better plan tasks and avoid overloading specific periods. Variations in working days reflect differences in availability, such as holidays or other commitments, which allows for more accurate and achievable planning. By defining how long each sprint lasts and how many working days are available, the team can better plan tasks and avoid overloading specific periods. Variations in working days reflect differences in availability, such as holidays or other commitments, which allows for more accurate and achievable planning.
  
 <table tab:sprint1> <table tab:sprint1>
 +<caption> Table of Global Sprint Plan.</caption>
  
 ^ Sprint ^ Start ^ Finish ^ Working Days ^ Status ^ ^ Sprint ^ Start ^ Finish ^ Working Days ^ Status ^
 | 1 | 5 Mar | 12 Mar | 5 days | Done | | 1 | 5 Mar | 12 Mar | 5 days | Done |
 | 2 | 12 Mar | 19 Mar | 5 days | Done | | 2 | 12 Mar | 19 Mar | 5 days | Done |
-| 3 | 19 Mar | 26 Mar | 5 days | Started | +| 3 | 19 Mar | 26 Mar | 5 days | Done | 
-| 4 | 26 Mar | 2 Apr | 5 days | To do | +| 4 | 26 Mar | 2 Apr | 5 days | Done | 
-| 5 | 2 Apr | 9 Apr | 0 days | To do | +| 5 | 2 Apr | 9 Apr | 0 days | Done | 
-| 6 | 9 Apr | 16 Apr | 3 days | To do | +| 6 | 9 Apr | 16 Apr | 3 days | Done | 
-| 7 | 16 Apr | 23 Apr | 5 days | To do |+| 7 | 16 Apr | 23 Apr | 5 days | Started |
 | 8 | 23 Apr | 30 Apr | 5 days | To do | | 8 | 23 Apr | 30 Apr | 5 days | To do |
 | 9 | 30 Apr | 7 May | 3 days | To do | | 9 | 30 Apr | 7 May | 3 days | To do |
Line 172: Line 212:
 | 15 | 11 Jun | 18 Jun | 5 days | To do | | 15 | 11 Jun | 18 Jun | 5 days | To do |
 | 16 | 18 Jun | 25 Jun | 5 days | To do | | 16 | 18 Jun | 25 Jun | 5 days | To do |
-<caption> Table of Global Sprint Plan.</caption>+
 </table> </table>
  
Line 178: Line 218:
  
 The project backlog contains all identified tasks required to complete the project.  The project backlog contains all identified tasks required to complete the project. 
- 
 Tasks are continuously updated and prioritized based on project needs, deadlines, and dependencies.  Tasks are continuously updated and prioritized based on project needs, deadlines, and dependencies. 
- 
 Completed tasks are marked as "Done", while ongoing and future tasks are labeled accordingly.  Completed tasks are marked as "Done", while ongoing and future tasks are labeled accordingly. 
- +Table {{ref>tab_label3}} lists the backlog.
-(See Table {{ref>tab_label3}} for the backlog).+
  
 <table tab_label3> <table tab_label3>
 +<caption> Table of Backlog.</caption>
 ^ PBI ^ Title ^ Status ^ ^ PBI ^ Title ^ Status ^
 | A | Define project | Done | | A | Define project | Done |
 | B | System diagrams and structural plans | In progress | | B | System diagrams and structural plans | In progress |
 | C | Project backlog | Done | | C | Project backlog | Done |
-| D | State of the Art | In progress |+| D | State of the Art | Done |
 | E | Gantt chart | Done | | E | Gantt chart | Done |
 | F | System diagrams and drafts | To do | | F | System diagrams and drafts | To do |
 | G | Global sprint plan | Done | | G | Global sprint plan | Done |
-| H | List of components and materials | In progress | +| H | List of components and materials | Done | 
-| I | Schematics and structural drawings | In progress |+| I | Schematics and structural drawings | Done |
 | J | Design development | In progress | | J | Design development | In progress |
-| K | Interim deliverables | In progress | +| K | Interim deliverables | Done | 
-| L | 3D model and video | To do | +| L | 3D model and video | In progress | 
-| M | Interim report and presentation | To do |+| M | Interim report and presentation | Done |
 | N | Functional testing | To do | | N | Functional testing | To do |
 | O | Packaging solution | To do | | O | Packaging solution | To do |
Line 212: Line 249:
 | X | Final presentation | To do | | X | Final presentation | To do |
 | Y | Final review and submission | To do | | Y | Final review and submission | To do |
-<caption> Table of Backlog.</caption>+
 </table> </table>
  
Line 222: Line 259:
  
 <table tab_label4> <table tab_label4>
 +<caption>Initial Sprint Plan.</caption>
 ^ Sprint ^ Period ^ Sprint Goal ^ Task ^ ^ Sprint ^ Period ^ Sprint Goal ^ Task ^
 | 1 | 19 Mar – 26 Mar | Establish project foundation | Selection of materials  | | 1 | 19 Mar – 26 Mar | Establish project foundation | Selection of materials  |
 | 1 | 19 Mar – 26 Mar | Establish project foundation | Backlog, global & initial sprint plan, Gantt chart  | | 1 | 19 Mar – 26 Mar | Establish project foundation | Backlog, global & initial sprint plan, Gantt chart  |
-| 1 | 19 Mar – 26 Mar | Establish project foundation | Detailed schematics ) |+| 1 | 19 Mar – 26 Mar | Establish project foundation | Detailed schematics  |
 | 1 | 19 Mar – 26 Mar | Establish project foundation | Researching information | | 1 | 19 Mar – 26 Mar | Establish project foundation | Researching information |
-| 1 | 19 Mar – 26 Mar | Establish project foundation | Define project roles ) |+| 1 | 19 Mar – 26 Mar | Establish project foundation | Define project roles  |
 | 1 | 19 Mar – 26 Mar | Establish project foundation | Flyer & logo presentation  | | 1 | 19 Mar – 26 Mar | Establish project foundation | Flyer & logo presentation  |
 | 1 | 19 Mar – 26 Mar | Establish project foundation | Cardboard model | | 1 | 19 Mar – 26 Mar | Establish project foundation | Cardboard model |
Line 235: Line 272:
 | 1 | 19 Mar – 26 Mar | Establish project foundation | Selection of components  | | 1 | 19 Mar – 26 Mar | Establish project foundation | Selection of components  |
 | 1 | 19 Mar – 26 Mar | Establish project foundation | Structural drawing  | | 1 | 19 Mar – 26 Mar | Establish project foundation | Structural drawing  |
-<caption>Initial Sprint Plan.</caption> 
 </table> </table>
  
Line 242: Line 278:
  
 ==== Sprint Outcomes ==== ==== Sprint Outcomes ====
-//Include the outcomes of all sprint reviews (what was the sprint backlog, completion status, planned capacity vs. achieved velocity).//+The sprints officially started from 19 March to 26 March, as the previous weeks were mainly used to become familiar with Jira and project tools. 
 + 
 +However, the initial work began earlier, and the first weeks were structured as follows: 
 + 
 +An overview of the outcomes from the initial sprints is presented in Table {{ref>tab_labelSprint1}} and Table {{ref>tab_labelSprint2}}. 
 + 
 + 
 +<table tab_labelSprint1> 
 +<caption> Week 1 outcome </caption> 
 +^ Sprint ^ Period ^ Objective ^ Activities ^ Outcome ^ 
 +| 1 | Week 1 | Define project scope and direction | Brainstorming of project ideas, discussion of possible approaches, evaluation of feasibility | Selection of project concept and initial understanding of project scope | 
 +</table> 
 + 
 +<table tab_labelSprint2> 
 +<caption> Week 2 outcome </caption> 
 +^ Sprint ^ Period ^ Objective ^ Activities ^ Outcome ^ 
 +| 2 | 12 Mar – 19 Mar | Develop system concept and research state of the art | Continued research on artificial reefs and sensors, worked on the state of the art chapter, explored materials and structural ideas, started defining system components, followed milestone plan | Clearer understanding of technical solutions and initial system concept defined | 
 +</table> 
 + 
 +**Sprint 3** 
 +The burndown chart for sprint 3 shows that additional tasks were identified and added at the beginning of the sprint, resulting in an increase in the total amount of work. This reflects a better understanding of the project requirements as the team moved from concept to design. 
 + 
 +During the middle of the sprint, progress remained relatively stable, indicating that fewer tasks were completed in that period. Towards the end of the sprint, a significant decrease in remaining work can be observed, showing that most tasks were completed close to the deadline. 
 + 
 +This pattern indicates that the team made substantial progress during sprint 3, particularly in the final phase, where key design elements and system components were defined. It also highlights the need for improved task distribution to ensure more consistent progress throughout the sprint (see Figure {{ref>fig:Week3}}). 
 + 
 +<WRAP centeralign> 
 +<figure fig:Week3> 
 +{{ :report:week3.png?nolink&600 |}} 
 +<caption>Week 3 burndown chart</caption> 
 +</figure> 
 +</WRAP> 
 + 
 + 
 +**Sprint 4** 
 + 
 +The burndown chart for Sprint 4 shows a noticeable increase in workload at the beginning of the sprint, indicating that additional tasks were identified as the project scope became clearer. This reflects an ongoing refinement of requirements and system definition. Shown in Figur {{ref>fig:Week4}}. 
 + 
 +Throughout most of the sprint, progress was relatively slow, with only minor reductions in remaining work. A more significant decrease occurs towards the end, suggesting that many tasks were completed close to the deadline. 
 + 
 +This pattern indicates that work was concentrated in the final phase of the sprint. Although the planned objectives were achieved, this approach suggests a need for better time management and a more even distribution of tasks across the sprint. 
 + 
 +<WRAP centeralign> 
 +<figure fig:Week4> 
 +{{ :report:week_4_sprint.png?nolink&400 |}} 
 +<caption>Week 4 burndown chart</caption> 
 +</figure> 
 +</WRAP> 
 + 
 +**Sprint 5** 
 + 
 +The burndown chart for Sprint 5 shows no significant changes in the remaining workload throughout most of the sprint. This indicates that tasks were not actively tracked or completed within the sprint period. Week 5 is shown in Figure {{ref>fig:Week5}}. 
 + 
 + 
 +This sprint coincided with the Easter holiday, during which no substantial work was carried out. Additionally, the project management tool (Jira) was not updated during this period, resulting in a lack of visibility and progress tracking. 
 + 
 +The sprint did not function as intended and cannot be considered effective from an Agile perspective. The absence of recorded progress highlights the importance of maintaining consistent engagement and updating project management tools, even during periods of reduced activity. 
 + 
 +<WRAP centeralign> 
 +<figure fig:Week5> 
 +{{ :report:week_5_sprint.png?nolink&400 |}} 
 +<caption>Week 5 burndown chart</caption> 
 +</figure> 
 +</WRAP> 
 + 
 +**Sprint 6** 
 + 
 +The burndown chart for Sprint 6, shown in Figure {{ref>fig:Week6}}, indicates limited progress during the initial phase of the sprint, suggesting that relatively little work was carried out at the beginning of the period. 
 + 
 +Subsequently, an increase in the remaining workload can be observed. This is explained because the incomplete tasks from Sprint 5 were carried over into Sprint 6. As a result, the workload appears to increase rather than decrease at that stage. 
 + 
 +Towards the end of the sprint, a noticeable reduction in remaining work is observed, indicating that several tasks were completed before the sprint was concluded. 
 + 
 +This pattern reflects an improvement in task completion compared to the previous sprint. However, it also highlights the importance of maintaining consistent progress and timely updates in order to ensure accurate tracking and effective sprint execution. 
 + 
 +<WRAP centeralign> 
 +<figure fig:Week6> 
 +{{ :report:week_6_sprint.png?nolink&400 |}} 
 +<caption>Week 6 burndown chart</caption> 
 +</figure> 
 +</WRAP>
  
 ==== Sprint Evaluations ==== ==== Sprint Evaluations ====
-//Include the summary of all the sprint retrospectives, including any actions implemented as part of the team’s continuous improvement strategy.//+ 
 +**Second week retrospective ** 
 + 
 +**Positive Aspects** 
 +During this week, the team worked well together and showed good coordination in roles and responsibilities. The wiki and Jira were kept relatively updated, and the team made solid progress in research and design. There were also strong ideas developed for the project’s features, structure, and overall concept, along with progress on the ethics work. Overall, the team showed improvement in both collaboration and organization. 
 + 
 +**Challenges** 
 +During this week, the team faced several challenges. There was a lack of clear discussion about project expectations, which led to some uncertainty. Task division was not always effective, and deadlines were not used efficiently. The wiki and report structure were somewhat disorganized, with resources not properly organized or uploaded. Additionally, the team could have shown more initiative and been more critical of their work. Overall, better structure, clarity, and efficiency are needed moving forward. 
 + 
 +**Ideas for Improvement** 
 +During this week, the team developed ideas to improve the project by focusing on one main “smartblock” with simpler supporting blocks. They also explored sustainable materials, clearer separation between prototype and final product, and ways to improve functionality, such as adding sensors and using 3D printing. 
 + 
 +**Actions for Next Week** 
 +For the next week, the team should focus on finalizing the structure and deciding on the materials for the project. It is important to continue and complete the necessary research while also developing the product design. The team should create a few sketches and present them for feedback. Additionally, roles and tasks need to be clearly defined, and the wiki should be properly updated with sources and kept organized. Work on communication materials such as a flyer, key facts, and an elevator pitch should also be continued. 
 + 
 +**Third week retrospective** 
 + 
 +**Positive Aspects** 
 +During this week, the team made strong overall progress and showed improved organization. The wiki was well maintained, and Jira was used effectively to keep track of tasks. The product design became clearer, supported by good structural drawings and a successful cardboard model. There was also progress in marketing, and the team had good planning for the upcoming weeks. Overall, collaboration was strong, with everyone showing up on time and contributing to steady progress. 
 + 
 +**Challenges** 
 +During this week, the team faced challenges due to missing components, which slowed progress and led to some waiting time. There were still uncertainties regarding materials, sensors, and electronics, and decisions about these were not finalized. Parts of the wiki were disorganized, and project management could have been more structured. Additionally, the team had not clearly defined a target customer and needed to improve consistency in updating and sharing progress. 
 + 
 +**Ideas for Improvement** 
 +During this week, the team developed ideas to improve planning and analysis. This included visualizing the market analysis more clearly and creating a risk matrix to better understand potential challenges. The team also focused on preparing for the interim presentation in order to improve communication and confidence.  
 + 
 +**Actions for Next Week** 
 +For the next week, the team should focus on deciding on materials and further developing the technical aspects, such as weight and water flow. Each member should take clear responsibility for specific parts of the project and break tasks into smaller subtasks if needed. The team should also create a plan for the upcoming period to stay organized and maintain steady progress. 
 + 
 + 
 +**Fourth Week Retrospective** 
 + 
 +**Positive Aspects** 
 +During this week, the team successfully delivered the scheduled presentations, and key project components were selected. This contributed to clarifying the technical direction of the project and ensured alignment among team members. 
 + 
 +**Challenges** 
 +The communication presentation did not meet expectations. The content and delivery could have been better structured and more effectively communicated. 
 + 
 +**Ideas for Improvement** 
 +No specific improvement ideas were identified during this period. 
 + 
 +**Actions for Next Week** 
 +The team will focus on completing and submitting the interim report. Emphasis will be placed on ensuring that all required sections are finalized and meet the expected quality standards. 
 + 
 +**Fifth Week Retrospective** 
 + 
 +**Positive Aspects** 
 +The interim report was successfully completed and submitted, marking an important milestone in the project timeline. 
 + 
 +**Challenges** 
 +The report was finalized later than planned, indicating inefficiencies in time management and task distribution. Ideally, the report should have been completed before the final deadline to allow time for review and refinement. 
 + 
 +**Ideas for Improvement** 
 +No additional improvement ideas were identified during this week. 
 + 
 +**Actions for Next Week** 
 +The team will begin preparing for the interim presentation, focusing on improving content clarity, structure, and delivery. 
 + 
 +**Sixth Week Retrospective** 
 + 
 +**Positive Aspects** 
 +The team made good progress in preparing for the interim presentation, demonstrating improved coordination and focus on communication aspects. 
 + 
 +**Challenges** 
 +Some challenges were encountered during the week; however, they were not clearly identified or documented. 
 + 
 +**Ideas for Improvement** 
 +Based on feedback from supervisors, the team identified the need to improve the visual identity of the project, particularly by incorporating marine elements such as fish into the flyer and branding materials. 
 + 
 +**Actions for Next Week** 
 +The team will further develop the technical aspects of the smart system, with a particular focus on evaluating alternative battery options and improving the design of the smart module. In addition, work will continue on creating a 3D model video of the product to support visualization and presentation. 
 + 
  
 ==== Summary ==== ==== Summary ====
-//Provide here the conclusions of this chapter and make the bridge to the next chapter.//+The project has been managed using an iterative and structured approach, allowing the team to balance technical challenges with continuous development. Through defined scope, milestone planning, and Agile methods, the team has made steady progress in both design and implementation. While some challenges remain, particularly related to decision-making and organization, the project is moving forward with a clearer direction and improved collaboration.