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:28] – [3.2 Time] team4report:prm [2026/04/16 15:26] (current) – [Sprint Evaluations] team4
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.png?nolink&600 |}}
-<caption> Start of a WBS </caption>+<caption> WBS of the product</caption>
 </figure> </figure>
 </WRAP> </WRAP>
Line 31: Line 31:
 <figure fig:Management> <figure fig:Management>
 {{ :report:wbs_project.png?nolink&600 |}} {{ :report:wbs_project.png?nolink&600 |}}
-<caption> Start of a WBS </caption>+<caption>WBS of the project</caption>
 </figure> </figure>
 </WRAP> </WRAP>
Line 37: Line 37:
  
 ==== 3.2 Time ==== ==== 3.2 Time ====
-To manange the time, and get the product finished at the right time, we both have our own internal deadlines, like be done with the report the 10th to have time to change and edit things if there is anything wrong and so we can be happy with our project.  +To ensure effective time management and the timely completion of the project, the team aimed to complete as much work as possible during school hours and before weekends. This approach helped maintain steady progress and allowed time for review and adjustments when needed.
-we are also following the milestone plan that are made by the professors. Table {{ref>tab_lable}} to see the 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.
 +
 +<table tab_labelmilestones>
 +
 +<caption> Milestones for the project </caption>
 +|< 100% 90px >|
 +^  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-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-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-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-16  | Interim Presentation, Discussion and Peer, Teacher and Supervisor feedbacks |
 +|  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-05-02  | Upload refined Interim Report (based on Teacher & Supervisor Feedback) |
 +|  2026-05-13  | Upload **packaging solution** to Deliverables and 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-18  | Final Presentation, Individual Discussion and Assessment (reserve the whole day) |
 +|  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** |
 +|  :::         | 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** | 
 +|  :::         | Hand in the **prototype and user manual** to the client |
 +|  :::         | Receive the **EPS@ISEP certificate** |
 +|  :::         | Bring **typical food** from your country |
 +
 +</table>
 ==== 3.3 Cost ==== ==== 3.3 Cost ====
 //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 71: Line 106:
  
    
 +
 ==== 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 81: Line 117:
  
 <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 94: Line 131:
 | 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 | Medium | 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 (see Figure {{ref>fig:Matrix}} figur). 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. 
 + 
 +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:matrixrisk.png?nolink&600 |}} 
 +<caption>Risk matrix</caption> 
 +</figure> 
 +</WRAP> 
 + 
    
 ==== Procurement ==== ==== Procurement ====
Line 129: Line 185:
 | 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 | Started |
 | 6 | 9 Apr | 16 Apr | 3 days | To do | | 6 | 9 Apr | 16 Apr | 3 days | To do |
 | 7 | 16 Apr | 23 Apr | 5 days | To do | | 7 | 16 Apr | 23 Apr | 5 days | To do |
Line 213: Line 269:
  
 ==== 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>
 +^ 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 |
 +<caption> Week 1 outcome </caption>
 +</table>
 +
 +<table tab_labelSprint2>
 +^ 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 |
 +<caption> Week 2 outcome </caption>
 +</table>
 +
 +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 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 **
 +
 +**What went good**
 +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.
 +
 +**What went bad**
 +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**
 +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 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.
 +
 +**Summary**
 +The team developed ideas to simplify the concept by focusing on one main solution, while also exploring sustainable materials and improving both design and functionality. They also considered ways to make the system more practical and efficient.
 +
 +
 +
 +
 +**Third week retrospective**
 +
 +**What went good**
 +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.
 +
 +**What went bad**
 +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**
 +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 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.
 +
 +**Summary**
 +Overall, the team made good progress in design, organization, and collaboration. However, some uncertainties and planning issues remain, and the team needs to focus on clearer decisions and more structured work moving forward.
 +
 +**Fourth week retrospective**
 +
 +**What went good**
 +The presentations went good, and the components were selected.
 +
 +**What went bad**
 +The communication presentation did not go that well
 +
 +**Ideas**
 +No ideas
 +
 +**Actions**
 +For the next week, the team need to finish the interim report, and deliver it.
 +
 +**Fifth week retrospective**
 +
 +**What went good**
 +The interim report was delivered
 +
 +**What went bad**
 +Should have done the report finish before the sunday.
 +
 +**Ideas**
 +No ideas
 +
 +**Actions**
 +For the next week, the team are prepering for the interim presentation.
 +
 +**Sixth week retrospective**
 +
 +**What went good**
 +The prep for the presentation
 +
 +**What went bad**
 +...
 +
 +**Ideas**
 +Some of the feedback from the supervisors were to have fish in the flyer/brand. The team will look in to it.
 +
 +**Actions**
 +For nexts week, the team are going to research more of the smart box, to check if there are different batteries to use and how to design it in the best way. Also to create a 3D-model video of the product.
 ==== 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.
  • report/prm.1775554097.txt.gz
  • Last modified: 2026/04/07 10:28
  • by team4