| @@ -78,8 +78,6 @@ A new design method was created by adding a preparation phase and refining the s | |||||
| The case study showed that it is possible to create a set of features and implement those features with the new design method. | The case study showed that it is possible to create a set of features and implement those features with the new design method. | ||||
| However, the adaptations show variable degrees of success. | However, the adaptations show variable degrees of success. | ||||
| %When designing from scratch the preparation phase fullfills a far more important role than I initialy expected. | |||||
| In the design method in this thesis, the goal of the preparation phase is to define the features of the system. | In the design method in this thesis, the goal of the preparation phase is to define the features of the system. | ||||
| These features stem from spliting the functionality and each of the feature is then developed using the \ac{ridm}. | These features stem from spliting the functionality and each of the feature is then developed using the \ac{ridm}. | ||||
| However, the functionality of the system is dictated by the design choices made in the system. | However, the functionality of the system is dictated by the design choices made in the system. | ||||
| @@ -103,133 +101,53 @@ This results in more models that are smaller. | |||||
| The large set of models improves the testing results, but tooling for automated testing is required to handle the increasing amount of models. | The large set of models improves the testing results, but tooling for automated testing is required to handle the increasing amount of models. | ||||
| Furthermore, to deal with the large set of models, the modelling software must be compatible with version control. | Furthermore, to deal with the large set of models, the modelling software must be compatible with version control. | ||||
| %Er moet een preparation phase komen | |||||
| %%Software en hardware mogen niet los van elkaar gezien worden. | |||||
| %%Meenemen dat een feature uit functie, component en requirement bestaat. | |||||
| %Improve feature selection | |||||
| %% Betere berekening van coc en cof. | |||||
| %Organize development cycle | |||||
| %%Deze moet rekening houden met het verschil tussen design en methode | |||||
| %%Tooling voor design parameters | |||||
| %%Version control | |||||
| %Improve testing. | |||||
| %% De modellen moeten automatisch te testen zijn. | |||||
| %Omdat het RIDM geen complete methode aandraagt om dit gestructureerd te doen is in deze thesis een lineare set aan ontwikkelings stappen gebruikt. | |||||
| A method to obtain the features for the system is not provided by the \ac{ridm}. | |||||
| Therefore, in this thesis a linear set of design steps is used instead. | |||||
| %Helaas boden deze stappen te weinig structuur om tot een degelijke set aan features te komen. | |||||
| Although the case study shows a set of features that are partially implemented, the evaluation shows that the current method is flawed. | |||||
| %De feature based approach kan daadwerkelijk bijdragen aan het ontwerpproces, maar dan moet het RIDM een structurele methode bevatten om volledig tot zijn recht te komen. | |||||
| Further research should be carried out to improve the estimation for the \emph{cost of change} and \emph{chance of failure}. | |||||
| %With each cycle a single feature is implemented and tested. | |||||
| %The most obvious finding to emerge from this study is that the \ac{ridm} without any additions is not a valid design method. | |||||
| %The findings of the case study suggest that a worthwhile solution is to make \ac{ridm} part of a existing design method. | |||||
| %The existing method provides a basis wherein the \ac{ridm} can come to its own, which is to tackle complexity. | |||||
| %To answer this question I must put emphasis on the difference between the design and modelling process. | |||||
| %The design process embodies the development of a product or system as an answer to a problem or need. | |||||
| %The modelling process allows the developers to gain insight of the inner workings of a product. | |||||
| %By creating and simulating models for the system under design, the modelling process improves the design process tremendously. | |||||
| %Looking at the \ac{ridm}, the fact that the first research objective is to prepend design steps to the \ac{ridm} highlights its shortcoming as a design method. | |||||
| % | |||||
| %Despite its exploratory nature, the case study offers some insight into the \ac{ridm} as a technique for rapid prototyping. | |||||
| %The segmentation of the design provides a structured and organized approach. | |||||
| %Moreover, the in this thesis proposed feature selection procedure contribute to the risk management of the development. | |||||
| %By implementing high risk-per-time features first, the design problems are more likely to be found in the early stage of the design. | |||||
| % | |||||
| %The variable-detail approach is promising for the implementation of individual features. | |||||
| %Similar to the design begin split in features, this approach implements one feature as multiple levels of detail. | |||||
| %One benefit is that the structured addition of detail enables intermediate testing, allowing the development to continue when all tests are satisfied. | |||||
| %Another benefit is that having one model available in different level of detail is that these models can be reused with the minimum detail possible. | |||||
| %This keeps the complexity of models to a minimum and can be useful to improve simulation speed of large systems. | |||||
| %The major limitation in this thesis is that the model represented the design. | |||||
| %Therefore, the stopping at a certain level of detail or reusing lower detail models did not occur during the case study. | |||||
| %Notwithstanding these limitations, the variable-detail approach does offer a structured approach providing feedback during the implementation. | |||||
| %This thesis was designed to assess whether the physical part of \ac{cps} can be developed using the \ac{ridm}. | |||||
| %Whereby the \ac{ridm} aims to reduce the complexity of a system design. | |||||
| %The requirement for the case study was to develop a system with sufficient complexity, to apply the \ac{ridm} as intended. | |||||
| %Being focused on the physical part of the design, this thesis overlooks the significance of software in a \ac{cps}. | |||||
| %Especially because the complexity of a system is made possible with software. | |||||
| % | |||||
| %A design method regarding the full life cycle of \ac{cps}, must therefore incorporate both the computation and physical part of \ac{cps}. | |||||
| %To use the advantages of the \ac{ridm} in such a design method, there must be a clear distinction between the functions, requirements and components. | |||||
| %Where possibly each of these three require a different design approach. | |||||
| %The explicit focus on physical part in the design process, caused a neglect toward the computation part of a \ac{cps}. | |||||
| % | |||||
| %The design is the specification of a system, it contains the plans, drawings, documentation, etc. | |||||
| %A model represent portions of that design, depending on the goal purpose of the model. | |||||
| %Both methods, from this thesis and the \ac{ridm}, make no adequate distinction between the design and the model. | |||||
| %As the case study by \autocite{broenink_rapid_2019} is performed with existing hardware, the design is already finished. | |||||
| %This highlights the shortcoming of the \ac{ridm} as it does model, and not design a system. | |||||
| % | |||||
| %The method in this thesis introduces additional steps to implement the design process. | |||||
| %Although an initial design is produced, the design is implemented as a model. | |||||
| % | |||||
| %The point is, the design and the model are two separate components of the design process. | |||||
| %The fact that this thesis starts with adding half a \ac{se} approach shows that the design aspect lacks in the current method. | |||||
| %However, both case studies suggest that the \ac{ridm} is a good approach for implementing that design. | |||||
| \section{Recommendations} | |||||
| %Bovenop de hierboven genoemde required adaptations, zijn er ook nog een aantal andere aanbevelingen. | |||||
| %Dit bevat een deel visie vanuit de design method, maar ook mogelijkheden om het design verder op te pakken. | |||||
| % - Bepaal in wat voor setting het RIDM moet opereren: Denk aan: cps-soort, samenstelling van ontwikkelteam, focus van de design methode. | |||||
| % Aan de hand van deze setting. | |||||
| % - Explore bestaande design projecten die passen in de omschreven setting. | |||||
| % Evalueer de design projecten op | |||||
| % -- Wat voor design paradigm of model wordt er gebruikt? | |||||
| % -- Waar in het project bevind zich de complexiteit en hoe wordt daar mee om gegaan? | |||||
| % -- Hoe bepalen ze COF en COC in hun projecten? | |||||
| % -- Hoe wordt er gezorgd voor de connectie tussen het design en hun modellen? | |||||
| % -- Welke tooling wordt er gebruikt binnen deze projecten? | |||||
| % -- Zijn er bepaalde pijnpunten waar alle design methodes mee te maken hebben? | |||||
| % -- Hoe word de opdrachtgever meegenomen in het ontwikkeltraject? | |||||
| % -- Welke afweging wordt er gemaakt tussen modelleren en hardware prototyping. | |||||
| % - Onderzoek of en hoe het RIDM deze punten zou kunnen verbeteren. | |||||
| % - Onderzoek of en hoe deze punten het RIDM zouden kunnen verbeteren. | |||||
| % | |||||
| % Afhankelijk van de uitkomst moet er een strategie gemaakt worden om het RIDM uit te breiden. | |||||
| % Op dit moment zijn er twee voor de hand liggende opties: | |||||
| % - Verwerk het RIDM in een bestaand design model. | |||||
| % - Breidt het RIDM uit tot een compleet design model. | |||||
| % Voor deze beide opties geldt: | |||||
| % - Verwerk hierin de punten van het de project evaluatie | |||||
| % - Voer het ontwerp van de vernieuwde RIDM uit door een multidisiplinair design team. | |||||
| % - Evalueer het RIDM aan de hand van realistische projecten. | |||||
| % | % | ||||
| %This brings me to the last questions:\\ | |||||
| %It is clear that there has to be a design process added, which must implement the different elements of a feature: component, function, requirement. | |||||
| % Answer: Which adaptations are required to make the design method by Broenink and Broenink (2019) suitable for developing the computation and physical part of CPS? | |||||
| \section{Recommendations} | |||||
| \begin{itemize} | |||||
| \item To use the variable-detail approach in an optimal way, there are two issues that must be addressed. | |||||
| The first one is the continuous testing of dynamic models. | |||||
| In a similar approach to unit testing in software, it must be possible to apply changes to a model and check whether everything still works as expected. | |||||
| A big issue here is the two-port behavior of dynamic models in comparison with software functions. | |||||
| When a software function is called with given parameters, it returns a specific result. | |||||
| This result is independent of the program this function is part of. | |||||
| In contrary, a dynamic model is not independent. | |||||
| The step response of a electro motor is significantly different if a fly-wheel is attached or not. | |||||
| Unit testing on sub-models in a dynamic model is therefore not reliable, making intermediate testing of the model difficult. | |||||
| The second issue is the organization of model versions. | |||||
| The benefit of switching between different sub-models is discussed in this thesis. | |||||
| However, switching between different detail versions is difficult and labor intensive. | |||||
| \end{itemize} | |||||
| %\begin{itemize} | |||||
| % \item To use the variable-detail approach in an optimal way, there are two issues that must be addressed. | |||||
| % The first one is the continuous testing of dynamic models. | |||||
| % In a similar approach to unit testing in software, it must be possible to apply changes to a model and check whether everything still works as expected. | |||||
| % A big issue here is the two-port behavior of dynamic models in comparison with software functions. | |||||
| % When a software function is called with given parameters, it returns a specific result. | |||||
| % This result is independent of the program this function is part of. | |||||
| % In contrary, a dynamic model is not independent. | |||||
| % The step response of a electro motor is significantly different if a fly-wheel is attached or not. | |||||
| % Unit testing on sub-models in a dynamic model is therefore not reliable, making intermediate testing of the model difficult. | |||||
| % The second issue is the organization of model versions. | |||||
| % The benefit of switching between different sub-models is discussed in this thesis. | |||||
| % However, switching between different detail versions is difficult and labor intensive. | |||||
| %\end{itemize} | |||||