| @@ -61,11 +61,11 @@ Even though the case study only applied the feature selection twice, it proved i | |||||
| By prioritizing the end-effector, its failure had only a minor impact on the design. | By prioritizing the end-effector, its failure had only a minor impact on the design. | ||||
| During each iteration of the development cycle, the selected feature is implemented according to the variable-detail approach. | During each iteration of the development cycle, the selected feature is implemented according to the variable-detail approach. | ||||
| However, the ability to assess the influence of the variable-detail approach is limited by the absence of tooling for model orginization and testing. | |||||
| However, the ability to assess the influence of the variable-detail approach is limited by the absence of tooling for model organization and testing. | |||||
| Without the tooling it is difficult to switch between model versions, undo design changes or run automated testing. | Without the tooling it is difficult to switch between model versions, undo design changes or run automated testing. | ||||
| Furthermore, as the development did not distinct between design and model, the models used often contained more detail than strictly necessary. | Furthermore, as the development did not distinct between design and model, the models used often contained more detail than strictly necessary. | ||||
| Both these limitations resulted in models that would surpase the minimal required level of detail; therefore, it is not possible to assess whether the minimum required level of detail can be established with passing all the tests. | |||||
| Nevertheless, the variable-detail approach introduces a step wise addition of detail that enforces a structered method similar to the development cycle. | |||||
| Both these limitations resulted in models that would surpass the minimal required level of detail; therefore, it is not possible to assess whether the minimum required level of detail can be established with passing all the tests. | |||||
| Nevertheless, the variable-detail approach introduces a step wise addition of detail that enforces a structured method similar to the development cycle. | |||||
| It is unfortunate that the development cycle did not include a structured method to define the features nor their order of implementation. | It is unfortunate that the development cycle did not include a structured method to define the features nor their order of implementation. | ||||
| The performance of the variable-detail approach is currently hindered by the absence of tooling. | The performance of the variable-detail approach is currently hindered by the absence of tooling. | ||||
| @@ -79,7 +79,7 @@ The case study showed that it is possible to create a set of features and implem | |||||
| However, the adaptations show variable degrees of success. | However, the adaptations show variable degrees of success. | ||||
| 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 splitting 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. | ||||
| In the case of developing systems from scratch, therefore, it seems that the design steps of the preparation phase play a critical role in the success of the design process. | In the case of developing systems from scratch, therefore, it seems that the design steps of the preparation phase play a critical role in the success of the design process. | ||||
| @@ -102,13 +102,22 @@ The large set of models improves the testing results, but tooling for automated | |||||
| 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. | ||||
| \section{Recommendations} | \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. | |||||
| % Voordat er de hierboven genoemde adaptations worden meegenomen in het RIDM, is er eerst aanvullend onderzoek nodig naar de exacte invulling. | |||||
| % De aanbevelingen voor dat aanvullende onderzoek zijn als volgt: | |||||
| Before any of the adaptations are applied to the \ac{ridm}, further research on the exact format of these adaptations is recommended. | |||||
| The recommended steps taken in further research are: | |||||
| \begin{itemize} | |||||
| % - Bepaal in wat voor setting het RIDM moet opereren: Denk aan: cps-soort, samenstelling van ontwikkelteam, focus van de design methode. | % - 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. | % Aan de hand van deze setting. | ||||
| \item \emph{Make the application area and purpose of the \ac{ridm} specific}: To design a good design method, the design process must start with a clear problem description. | |||||
| Currently, the \ac{ridm} does provide a design method, but does not state clear requirements such as: | |||||
| \begin{itemize} | |||||
| \item \emph{Type of \ac{cps}}: mainly hardware, software or control? | |||||
| \item \emph{Design focus}: improve reliability, real-time guarantee, reduce complexity, shorten development-time? | |||||
| \item \emph{Internal or external use}: is the client directly involved? | |||||
| \item \emph{Development team}: number of developers from what background? | |||||
| \end{itemize} | |||||
| % - Explore bestaande design projecten die passen in de omschreven setting. | % - Explore bestaande design projecten die passen in de omschreven setting. | ||||
| % Evalueer de design projecten op | % Evalueer de design projecten op | ||||
| % -- Wat voor design paradigm of model wordt er gebruikt? | % -- Wat voor design paradigm of model wordt er gebruikt? | ||||
| @@ -119,8 +128,26 @@ Furthermore, to deal with the large set of models, the modelling software must b | |||||
| % -- Zijn er bepaalde pijnpunten waar alle design methodes mee te maken hebben? | % -- Zijn er bepaalde pijnpunten waar alle design methodes mee te maken hebben? | ||||
| % -- Hoe word de opdrachtgever meegenomen in het ontwikkeltraject? | % -- Hoe word de opdrachtgever meegenomen in het ontwikkeltraject? | ||||
| % -- Welke afweging wordt er gemaakt tussen modelleren en hardware prototyping. | % -- Welke afweging wordt er gemaakt tussen modelleren en hardware prototyping. | ||||
| These requirements improve the focus of further research and could help to get other organisations involved. | |||||
| Above all, it prevents the \ac{ridm} of becoming a "master of none". | |||||
| \item \emph{Explore existing design projects that share the application area and purpose}: To avoid a reinvention of the wheel or solve a problem that does not exist, it is recommended to collect and evaluate the results of existing design projects with at least the following questions: | |||||
| \begin{itemize} | |||||
| \item What type of design paradigm or model is being applied? | |||||
| \item Where is the complexity in the project and how is it dealt with? | |||||
| \item How are the metrics of \emph{cost of change} and \emph{chance of failure} defined? | |||||
| \item How are the design and models connected? | |||||
| \item Which design tools are used by the design team? Why are they used? | |||||
| \item Are there common problems that hinder (almost) all design projects? | |||||
| \item How is the client involved in the development process? | |||||
| \item What considerations are made to chose between modelling or hardware prototyping? | |||||
| \end{itemize} | |||||
| % - Onderzoek of en hoe het RIDM deze punten zou kunnen verbeteren. | % - Onderzoek of en hoe het RIDM deze punten zou kunnen verbeteren. | ||||
| % - Onderzoek of en hoe deze punten het RIDM zouden kunnen verbeteren. | % - Onderzoek of en hoe deze punten het RIDM zouden kunnen verbeteren. | ||||
| \item \emph{Hypothesize the improvements provided by \ac{ridm} for existing design projects, and vice versa}: Based on the existing design projects: | |||||
| How could the \ac{ridm} improve those existing design projects? What lessons can be drawn from the existing design projects? | |||||
| \end{itemize} | |||||
| % | % | ||||
| % Afhankelijk van de uitkomst moet er een strategie gemaakt worden om het RIDM uit te breiden. | % 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: | % Op dit moment zijn er twee voor de hand liggende opties: | ||||
| @@ -130,7 +157,44 @@ Furthermore, to deal with the large set of models, the modelling software must b | |||||
| % - Verwerk hierin de punten van het de project evaluatie | % - Verwerk hierin de punten van het de project evaluatie | ||||
| % - Voer het ontwerp van de vernieuwde RIDM uit door een multidisiplinair design team. | % - Voer het ontwerp van de vernieuwde RIDM uit door een multidisiplinair design team. | ||||
| % - Evalueer het RIDM aan de hand van realistische projecten. | % - Evalueer het RIDM aan de hand van realistische projecten. | ||||
| % | |||||
| Depending on what the results and conclusions of the recommended research topics are, a strategy has to be created to further develop the \ac{ridm}. | |||||
| Currently, there are two likely scenarios: | |||||
| \begin{itemize} | |||||
| \item Make the \ac{ridm} part of an existing design model, such that the advantages are integrated with existing design models. | |||||
| \item Develop the \ac{ridm} into a complete design method, such that it can be used for the development of the complete product life-cycle. | |||||
| \end{itemize} | |||||
| Independent of what strategy is chosen, it is recommended to: | |||||
| \begin{itemize} | |||||
| \item Implement the adaptations as described in this thesis. | |||||
| \item Perform the adaptations and improvements of the \ac{ridm} with a multi-disciplinary design team. | |||||
| \item Evaluate the \ac{ridm} with projects that are within the application area of the \ac{ridm}. | |||||
| \end{itemize} | |||||
| The recommendations result in a more focussed development of the \ac{ridm}. | |||||
| But expected is that a full development of the \ac{ridm} takes multiple years and multiple developers to complete. | |||||
| However, it is possible to improve separate techniques from the \ac{ridm}. | |||||
| These techniques can improve existing design methods. | |||||
| Based on this thesis, the following research topics are recommended: | |||||
| \begin{itemize} | |||||
| \item \emph{A technique or protocol for to organize the parameters of a design, such that the parameters can be used in modelling}: Can the current modelling tools be adapted to read parameters from a database and can design tools be adapted to write parameters to a database? | |||||
| \item \emph{Tooling for modelling software, to allow for unit testing}: Software development applies unit testing, where behavior of each function is tested separately. | |||||
| In modelling this would allow every sub-model to be tested separately. | |||||
| \end{itemize} | |||||
| % Kleine recommendations zijn | |||||
| % - Werk aan automated testing | |||||
| % - | |||||