Discussion - Group 4 - 2018/2019, Semester B, Quartile 3: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
Line 50: Line 50:
The main takeaways from this project that should definitely be kept in mind in future projects are as follows:
The main takeaways from this project that should definitely be kept in mind in future projects are as follows:
* Make the planning extremely detailed. Really note down who should do what and when it should be finished. Make sure that the items in this planning are formulated as detailed deliverables rather than letting them be abstract ideas.
* Make the planning extremely detailed. Really note down who should do what and when it should be finished. Make sure that the items in this planning are formulated as detailed deliverables rather than letting them be abstract ideas.
* Verify the work of others against the deliverables described in the planning. Furthermore, talk about these things if they are not as they should be.
* Meeting up together to work on certain aspects can be useful, but this should be minimised as much as possible. Using a planning with explicit deliverables and not more than two people on a certain item in the planning is preferable.

Revision as of 13:05, 25 March 2019

<link rel="shortcut icon" href="https://www.tue.nl/favicon-64.ico" type="image/x-icon"> <link rel=http://cstwiki.wtb.tue.nl/index.php?title=PRE2018_3_Group4&action=edit"stylesheet" type="text/css" href="theme.css">

Discussion

Introduction

In the discussion, we want to touch upon some important aspects of the project. We take a step back from the content of the project itself and take a closer look at how the process went and what we can learn from these developments. It is not only the development of the process that can provide useful insights, but also the stumbling blocks encountered on the road towards the final result can provide useful insights.

The process

The very first thing of the project, namely picking a topic and what to exactly do with that topic proved to be the most difficult part. In the current day and age, where there are millions of exciting topics when it comes to robotics, it is tough to limit oneself to a single topic. While deciding on a rough draft of what to research was still quite doable and only took a few days, explicitly formulating the deliverables was much harder. The first week consisted of doing a literature study regarding drone interceptions, documented in the State of the Art. While meeting with the professors of 0LAUK0 during the first weekly meeting, it quickly became clear that researching `drone interceptions' was not explicit enough and way too broad. This resulted in us focusing more on drone interceptions and illegal drone activity surrounding airports in The Netherlands. Choosing all types of airports (commercial airports, airlines, et cetera) was done on purpose, and it was thought if this would be too broad, but everyone thought this would still be feasible.

Now that the research space was limited to illegal drone activity around airports in The Netherlands, the next steps could be taken. What would the deliverables look like? At first, a literature study seemed like the preferable option. We, however, thought this would be too short for the time we had for the course and thus decided to also design a decision model that airports in The Netherlands could use to decide what their `best' solution against illegal drone activity was. This quickly resulted in the group wanting to produce a recommendation report for airports located in The Netherlands.

Researching what types of decision models exist and which one we could use also proved to be quite difficult. There exist numerous types of decision models available and therefore, it was rather hard to pick one based on the things we wanted to achieve. We thought we found the right type of decision model to use, but after working out the questions, we found that this did not work as well as we thought. Thus, we had to change the type of decision model we used. This leads us to a different model, which worked significantly better for the idea we had in mind. It was still tough to design propositions based on the attributes of various solutions as most solutions had the same attributes. In parallel, we started working on a Web App that implemented this decision model. When it comes to communication during this process, it was rather rough. This was partly due to planning not stating explicit deliverables for each week. We did try to incorporate the `delivering deliverables each week', but the deliverables were not explicit enough until we realised this issue. After this issue was brought up, it was tackled appropriately.

Main takeaways

The main takeaways from this project that should definitely be kept in mind in future projects are as follows:

  • Make the planning extremely detailed. Really note down who should do what and when it should be finished. Make sure that the items in this planning are formulated as detailed deliverables rather than letting them be abstract ideas.
  • Verify the work of others against the deliverables described in the planning. Furthermore, talk about these things if they are not as they should be.
  • Meeting up together to work on certain aspects can be useful, but this should be minimised as much as possible. Using a planning with explicit deliverables and not more than two people on a certain item in the planning is preferable.