| @@ -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. | |||
| 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. | |||
| 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. | |||
| @@ -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. | |||
| 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} | |||