Differences

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

--- report:prm [2026/06/11 15:40] – [3.13 Sprint Evaluations] team4
+++ report:prm [2026/06/18 19:56] (current) – [3.11.2 Global Sprint] team4
@@ Line 150: / Line 150: @@
 | Transportation and shipping | Shipping costs from all suppliers |  310.45 € |
 | **Total materials and sensors including shipping** | Components, sensors and shipping combined |  **2 526.11 €** |
-| Structural material for habitat blocks | Concrete and basalt fibre |  4.43 € per block |
+| Structural material for habitat blocks | Concrete and basalt fiber |  4.43 € per block |
 | **Total project cost excluding habitat blocks** | Labor + materials and sensors including shipping |  **47 526.11 €** |
 </table>
@@ Line 211: / Line 211: @@
 | Plastic lunchbox (single compartment) | Prototype enclosure |  3 € |  1  | IKEA | [[https://www.ikea.com/pt/pt/p/ikea-365-recipiente-p-alim-c-tmp-retangular-plastico-s19269079/|link]] | Simple enclosure |
 | Smaller plastic lunchbox | Backup enclosure |  1.5 € |  1  | IKEA | [[https://www.ikea.com/pt/en/p/pruta-food-container-with-lid-blue-10597103/|link]] | Backup option |
-| PLA filament 1 kg | 3D printing material |  14.60 € |  1  | Filament 3D | [[https://fillment3d.pt/produto/pla-cinzento-winkle-1kg-1-75mm/|link]] | Backup option |
+| PLA filament 1 kg | Used for 3D-printed mold |  14.60 € |  1  | Filament 3D | [[https://fillment3d.pt/produto/pla-cinzento-winkle-1kg-1-75mm/|link]] | Backup option |
 | Ceys Total Tech Universal Glue and Sealant 290 ml Transparent | Silicone sealant |  8.99 € |  1  | Leroy Merlin | [[https://www.leroymerlin.pt/produtos/cola-e-veda-total-tech-universal-290-ml-transparente-ceys-13132966.html|link]] |  |
 | Continente cooking oil 1 L | Oil for enclosure |  1.69 € |  1  | Continente | [[https://www.continente.pt/produto/oleo-alimentar-continente-continente-5045342.html|link]] | Used only if needed |
@@ Line 247: / Line 247: @@
-Although the estimated total cost exceeds the budget, some components and materials may already be available at the university, reducing the need for additional purchases. Furthermore, transportation costs may be avoided if other groups also are ordering from the same supplier and the total order exceeds the free shipping limit. Consequently, the actual cost is difficult to determine precisely but is expected to be lower than the estimated 136 €.
+Although the estimated total cost exceeds the budget, some components and materials may already be available at the university, reducing the need for additional purchases. Furthermore, transportation costs may be avoided if other groups are also ordering from the same supplier and the total order exceeds the free shipping limit. Consequently, the actual cost is difficult to determine precisely but is expected to be lower than the estimated 136 €.
+The materials that were actually provided for the prototype were similar to the components and materials originally requested by the team. Although some parts differed slightly from the initial list, they fulfilled the same basic purpose and were suitable for building and testing the prototype. The total cost of the provided prototype parts was approximately 90 €.
@@ Line 272: / Line 274: @@
 | Sensor functionality | Sensors collect environmental data such as temperature, pressure, and TDS. | All prototype sensors provide readable values. | Functional sensor test |
 | Data logging | Sensor data is stored locally on an SD card. | Data is saved in a readable format after each measurement cycle. | SD card inspection |
-| Waterproofing | Electronics are protected from water ingress. | No visible leakage during prototype testing; the final product requires IP68 housing. | Leakage test |
 | Structural stability | Reef blocks remain stable under expected conditions. | Structure does not move easily during controlled testing. | Stability test |
 | Energy efficiency | System uses low power for long-term operation. | Final system supports approximately 340 days of operation. | Battery calculation |
 | Maintainability | Smartlogger can be removed for service. | Battery, SD card, and sensors can be accessed without removing the whole reef module. | Maintenance check |
-| Environmental compatibility | Materials are safe for marine environments. | Materials are non-toxic, durable, and corrosion-resistant. | Material review |
 | Documentation quality | Report is clear, complete, and well structured. | Required sections, figures, tables, and sources are included. | Internal review and supervisor feedback |
+| Temperature reading | Accuracy of the temperature sensor. | Within ±2 °C of reference thermometer. | Reference thermometer comparison |
+| Logging interval | Accuracy of the time between each saved measurement. | 10 seconds ±1 second between logged rows. | Compare timestamps in the CSV file |
+| TDS reading | Accuracy of the TDS sensor response. | Within ±10 % of reference or clearly changes between test samples. | Controlled water sample test |
+| Pressure reading | Stability of the pressure sensor output. | Reading variation less than ±10 % during a stable test condition. | Serial Monitor inspection |
+| Turbidity reading | Response of the turbidity sensor to interruption. | Sensor voltage changes by at least 0.1 V when the sensor area is interrupted. | Turbidity interruption test |
 </table>
-The quality metrics are checked continuously during the project using practical measurement methods. Sensor functionality is evaluated by checking whether the temperature, pressure, and TDS sensors provide readable values during controlled testing. Data logging is verified by checking whether the SD card creates a readable file containing the measurement cycle and sensor values.
+==Review and Validation Process==
-Waterproofing is evaluated through a prototype leakage check, where no visible water should enter the enclosure. Structural stability is reviewed through controlled handling tests and simulation results. The module should remain stable during basic handling, while the final product would require further stability calculations and field testing.
+The prototype will be checked by testing the main parts one by one. First, the team will confirm that the smartlogger starts correctly and that the sensors give values in the Serial Monitor. Then the SD card file will be opened to check that the values are stored with the correct time interval. The physical prototype will also be checked by measuring the structure, testing that it stands stable. The results from these checks will show whether the prototype is good enough for the final demonstration.
-Energy efficiency is evaluated through battery-life calculation based on the estimated current consumption and the selected measurement cycle. In the current final-system calculation, the system is expected to support approximately 340 days of operation under the assumed cycle of one 1-minute measurement per hour. Maintainability is checked by confirming that the smartlogger can be removed without removing the whole reef module and that the battery, SD card, and sensors in the smart box remain accessible for inspection, replacement, or data retrieval.
+==Acceptance Criteria==
-Environmental compatibility is reviewed through material selection and literature or supplier information. Documentation quality is reviewed through team checks and supervisor feedback. If a metric does not meet the required threshold, corrective actions are added to the project backlog and followed up during sprint meetings.
+The prototype is good enough when it can run the logging program, read the sensors, and save data to the SD card without stopping during the test. The structure must also be stable and possible to handle without loose parts or damaged connections. Since this is only a prototype, the goal is to prove that the concept works, not to prove that it is ready for long-term underwater use.
 ==== 3.6 People ===
@@ Line 338: / Line 343: @@
 ==== 3.7 Stakeholder Management ====
-Stakeholder management refers to the identification, analysis, engagement and communication with individuals or organizations that can affect or be affected by the project. In the Maris Habitats project, stakeholder management is important because the solution is connected to marine restoration, environmental monitoring, academic requirements and future users of the system.
+Stakeholder management is used to identify, analyze and communicate with the people, groups and organizations that can affect or be affected by the project. For Maris Habitats, this is important because the project combines academic requirements, technical development, marine restoration, environmental monitoring and potential future users of the system.
-The project includes both internal and external stakeholders. Internal stakeholders are directly involved in the development process, while external stakeholders may influence the project or benefit from the final solution.
+The stakeholders were divided into internal and external groups. Internal stakeholders are directly involved in the project development, such as the team members, EPS coordinator, supervisors and professors. External stakeholders are not part of the daily project work, but they may influence the project or benefit from the final solution. These include suppliers, research institutions, environmental NGOs, public authorities, potential customers and marine life.
-**Key Stakeholders**
+To understand how the team should communicate with each stakeholder, a power-interest matrix was created. This matrix shows which stakeholders need close involvement, which should be kept informed, and which only require limited monitoring. Figure {{ref>fig_stakeholderMatrix}} presents the stakeholder matrix for Maris Habitats.
-**Team members**
+<WRAP centeralign>
+<figure fig_stakeholderMatrix>
+{{ :report:stakeholdermatrix.png?nolink600 |}}
+<caption> Stakeholder matrix for Maris Habitats </caption>
+</figure>
+</WRAP>
-The team members are responsible for developing the project concept, designing the structure, selecting components, building the prototype, testing the system and completing the required documentation. They are the main decision-makers during the development process and are responsible for keeping the project within scope.
+The project team, supervisors, coordinator and client/project owner are placed in the high-interest and high-power category because they are directly connected to project decisions, evaluation and progress. These stakeholders must therefore be managed closely through regular meetings, feedback, documentation and continuous communication.
-**EPS Coordinator**
+Stakeholders such as ISEP and project supervisors have strong influence on the academic framework, but they are not involved in every daily task. They should be kept satisfied through formal deliverables, progress updates and clear communication. Future users, research institutions, NGOs and possible investors have high interest in the final product, but limited influence during the current prototype phase. These stakeholders should be kept informed through reports, presentations and future collaboration opportunities. Stakeholders with low power and low interest, such as logistics partners and the general public, only need to be monitored when relevant.
-The EPS coordinator supports the team by organizing the academic framework and control meetings. The coordinator also helps ensure that the project follows EPS requirements and that deliverables are submitted according to the project timeline.
+The stakeholder overview in Table {{ref>tab_labelSM}} gives a more detailed explanation of each stakeholder’s role, interest and engagement strategy.
-**Project supervisors**
+<table tab_labelSM>
-The supervisors provide academic and technical guidance throughout the project. They review the team’s progress, give feedback on design and documentation, and help the team make informed decisions.
-**ISEP**
-ISEP is the hosting institution and provides the project environment, facilities, tools and academic structure. The institution also defines deadlines, evaluation criteria and general requirements for the EPS project.
-**Professors and advisors**
-Professors and advisors provide knowledge in different subject areas such as project management, ethics, sustainability, marketing, design and engineering. Their feedback helps improve the quality of the project.
-**Suppliers**
-Suppliers provide the components and materials needed for the prototype and final product concept. Delivery time, price, availability and component quality can affect the project schedule and technical feasibility.
-**Potential users and customers**
-Potential users include public institutions, coastal municipalities, research institutions, environmental NGOs, port authorities, aquaculture operators and marine infrastructure companies. These stakeholders may use Maris Habitats for marine restoration support, environmental monitoring, research or sustainability reporting.
-**Research institutions and NGOs**
-Research institutions and NGOs are important future stakeholders because they may use the collected environmental data for analysis, monitoring and marine conservation projects. They can also provide feedback on how the system should be developed further.
-**Public authorities**
-Public authorities may be involved in future deployment because underwater installations can require permits, environmental assessments and compliance with regulations. Their role is important for real-world implementation.
-**Marine life**
-Marine life is not a traditional stakeholder, but it is the primary beneficiary of the project. The design must therefore consider the needs of fish, algae, corals and other marine organisms by using safe materials, stable structures and habitat-friendly geometry. See {{ref>tab_labelSM}} table
- <table tab_labelSM>
 <caption> Stakeholder Overview </caption>
 ^ Stakeholder ^ Role ^ Interest in the Project ^ Engagement Strategy ^
@@ Line 400: / Line 378: @@
 </table>
-**Engagement Strategy**
+The main engagement strategy is based on regular communication and clear documentation. Internal stakeholders are involved through weekly supervisor meetings, team meetings, Jira updates and wiki documentation. Feedback from supervisors and professors is used to improve the design, prototype, report and final deliverables.
-The team uses weekly supervisor meetings, internal team meetings, Jira updates and wiki documentation to keep stakeholders informed. Feedback from supervisors and professors is used to improve the project and correct issues early. For external stakeholders, the main engagement strategy is based on clear documentation, realistic communication and future project presentations.
+For external stakeholders, the engagement strategy is more focused on presenting the value and feasibility of the concept. This includes explaining how Maris Habitats can support marine restoration, collect environmental data and reduce disturbance through the removable smartlogger.
-**Risk Mitigation Related to Stakeholders**
+Stakeholder-related risks include unclear communication, delayed feedback, supplier delays and misunderstandings about project expectations. These risks are reduced through regular meetings, defined responsibilities, updated documentation and early procurement planning.
-Stakeholder-related risks include unclear communication, delayed feedback, poor documentation, supplier delays and misunderstanding of project expectations. These risks are reduced through regular meetings, clear task distribution, updated documentation, early supplier research and continuous feedback loops.
+Stakeholder management helps the team keep the project aligned with academic expectations, technical requirements and future user needs. It also supports better decision-making and improves the feasibility of Maris Habitats as a marine restoration and monitoring solution [(STAKEHOLDER)].
-Overall, stakeholder management helps ensure that the project remains aligned with academic expectations, technical requirements and future user needs. It also supports better decision-making and improves the feasibility of Maris Habitats as a marine restoration and monitoring solution [(STAKEHOLDER)].
 ==== 3.8 Communications ====
@@ Line 464: / Line 440: @@
-This communication structure helps the team maintain a clear workflow, follow deadlines and solve problems early. Regular meetings, shared documentation and continuous task updates support collaboration and ensure that all members remain informed about the development of Maris Habitats. See {{ref>tab_CommunicationStakeholders}} table for the ways of communication with stakeholders.
+This communication structure helps the team maintain a clear workflow, follow deadlines and solve problems early. Regular meetings, shared documentation and continuous task updates support collaboration and ensure that all members remain informed about the development of Maris Habitats. See {{ref>tab_CommunicationStakeholders}} table for the communication approaches with stakeholders.
 <table tab_CommunicationStakeholders>
@@ Line 615: / Line 591: @@
 | 11 | 14 May | 21 May | 5 days | Done |
 | 13 | 28 May | 4 Jun | 5 days | Done |
-| 14 | 4 Jun | 11 Jun | 5 days | Started |
+| 14 | 4 Jun | 11 Jun | 5 days | Done |
-| 15 | 11 Jun | 18 Jun | 5 days | To do |
+| 15 | 11 Jun | 18 Jun | 5 days | Done |
-| 16 | 18 Jun | 25 Jun | 5 days | To do |
+| 16 | 18 Jun | 25 Jun | 5 days | Done |
 </table>
@@ Line 632: / Line 608: @@
 ^ PBI ^ Title ^ Status ^
 | A | Define project | Done |
-| B | System diagrams and structural plans | In progress |
+| B | System diagrams and structural plans | Done |
 | C | Project backlog | Done |
 | D | State of the Art | Done |
 | E | Gantt chart | Done |
-| F | System diagrams and drafts | To do |
+| F | System diagrams and drafts | Done |
 | G | Global sprint plan | Done |
 | H | List of components and materials | Done |
 | I | Schematics and structural drawings | Done |
-| J | Design development | In progress |
+| J | Design development | Done |
 | K | Interim deliverables | Done |
-| L | 3D model and video | In progress |
+| L | 3D model and video | Done |
 | M | Interim report and presentation | Done |
-| N | Functional testing | To do |
+| N | Functional testing | Done |
-| O | Packaging solution | To do |
+| O | Packaging solution | Done |
-| P | Poster | In progress |
+| P | Poster | Done |
-| Q | Folder and manual | To do |
+| Q | Folder and manual | Done |
-| R | Brochure and leaflet | In progress |
+| R | Brochure and leaflet | Done |
-| S | Prototype | To do |
+| S | Prototype | Done |
-| T | Video | To do |
+| T | Video | Done |
-| V | Final report | To do |
+| V | Final report | Done |
-| W | Upload final deliverables | To do |
+| W | Upload final deliverables | Done |
-| X | Final presentation | To do |
+| X | Final presentation | Done |
-| Y | Final review and submission | To do |
+| Y | Final review and submission | Done |
 </table>
@@ Line 684: / Line 660: @@
 ==== 3.12 Sprint Outcomes ====
-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.
+The sprints officially started from March 19th to March 26th, as the previous weeks were mainly used to become familiar with Jira and project tools.
@@ Line 753: / Line 729: @@
 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.
-An increase in the remaining workload can also be observed on 14 April, when new tasks were added after the sprint had already started. This was partly caused by incomplete tasks from Sprint 5 being carried over into Sprint 6. As a result, the workload appears to increase rather than decrease at that stage.
+An increase in the remaining workload can also be observed on April 14th, when new tasks were added after the sprint had already started. This was partly caused by incomplete tasks from Sprint 5 being 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.
@@ Line 768: / Line 744: @@
 **Sprint 7**
-The burndown chart for Sprint 7 shows that little or no progress was recorded during the first part of the sprint. No significant task completion was registered until 20 April, when a new task was added to the sprint.
+The burndown chart for Sprint 7 shows that little or no progress was recorded during the first part of the sprint. No significant task completion was registered until April 20th, when a new task was added to the sprint.
 Most of the remaining work was then checked off on the final day of the sprint. This indicates that tasks were either completed late or not updated continuously in Jira. As a result, the burndown chart does not show a steady reduction in workload.
 This sprint demonstrates the importance of updating tasks more regularly and ensuring that work is distributed more evenly throughout the sprint. The burndown chart for Sprint 7 is shown in Figure {{ref>fig:Week7}}.
@@ Line 785: / Line 761: @@
 The burndown chart for Sprint 8 shows that the sprint was started before all tasks had been properly added and assigned story points. This made the initial sprint planning less accurate and reduced the reliability of the burndown chart.
-During the sprint, the workload was adjusted again. On 28 April, story points were added or changed, which affected the chart after the sprint had already started. Despite these changes, all tasks were completed by the end of the sprint.
+During the sprint, the workload was adjusted again. On April 28th, story points were added or changed, which affected the chart after the sprint had already started. Despite these changes, all tasks were completed by the end of the sprint.
 Although the final outcome was positive, the chart shows that the sprint was not planned according to Scrum principles, since tasks and story points should ideally be defined before the sprint begins. The burndown chart for Sprint 8 is shown in Figure {{ref>fig:Week8}}.
@@ Line 843: / Line 819: @@
 <figure fig:Week12>
 {{ :report:week12.png?nolink&800 |}}
-<caption>Week 11 burndown chart</caption>
+<caption>Week 12 burndown chart</caption>
 </figure>
 </WRAP>
@@ Line 851: / Line 827: @@
 **Sprint 13 **
-The burndown chart for Sprint 13 shows that no significant progress was recorded until 1 July. On this date, a new task was added to the sprint and assigned story points, which increased the total workload after the sprint had already started.
+The burndown chart for Sprint 13 shows that no significant progress was recorded until June 1st. On this date, a new task was added to the sprint and assigned story points, which increased the total workload after the sprint had already started.
 The sprint was also closed one day earlier than planned. As a result, several tasks were not completed during Sprint 13 and had to be transferred to the Week 14 sprint. This affected the accuracy of the sprint outcome and shows that the planned workload was not fully achieved.
-On 3 July, a significant part of the sprint work was completed or closed. However, because several tasks had already been moved forward, the sprint does not show a steady or fully successful workflow.
+On June 3rd, a significant part of the sprint work was completed or closed. However, because several tasks had already been moved forward, the sprint does not show a steady or fully successful workflow.
 Sprint 13 highlights challenges related to late task creation, incomplete sprint execution, and early sprint closure. It also shows the importance of completing and updating tasks within the correct sprint period to ensure accurate progress tracking. The burndown chart for Sprint 13 is shown in Figure {{ref>fig:Week13}}.
@@ Line 967: / Line 943: @@
-==Eight Week Retrospective==
+==Eighth Week Retrospective==
 **Positive Aspects**
@@ Line 1015: / Line 991: @@
 **Positive Aspects**
-During this week, the team made important progress by figuring out how to produce the 3D mold. The 3D video was also completed, and work began on both the testing phase and the prototype.
+During this week, the team made important progress by figuring out how to produce the 3D mould. The 3D video was also completed, and work began on both the testing phase and the prototype.
 **Challenges**
@@ Line 1046: / Line 1022: @@
 **Challenges**
-One challenge this week was the name change from Smartblock to Smartlogger, which required updates in the documentation and project material. In addition, the scientific paper is still not finished. The team is also waiting for the final part of the 3D mold before the prototype can be fully completed.
+One challenge this week was the name change from Smartblock to Smartlogger, which required updates in the documentation and project material. In addition, the scientific paper is still not finished. The team is also waiting for the final part of the 3D mould before the prototype can be fully completed.
 **Ideas for Improvement**
@@ Line 1058: / Line 1034: @@
 **Positive Aspects**
-During this week, the team delivered the scientific paper, completed the 3D print mold, finalized the wiki, finished the video, and prepared the final presentation. These tasks were important steps toward completing the final project deliverables.
+During this week, the team delivered the scientific paper, completed the 3D print mould, finalized the wiki, finished the video, and prepared the final presentation. These tasks were important steps toward completing the final project deliverables.
 **Challenges**