| @@ -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. | |||
| 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. | |||
| 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. | |||
| 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. | |||
| 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. | |||
| 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. | |||
| \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. | |||
| % 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. | |||
| % Evalueer de design projecten op | |||
| % -- 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? | |||
| % -- Hoe word de opdrachtgever meegenomen in het ontwikkeltraject? | |||
| % -- 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 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. | |||
| % 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 | |||
| % - Voer het ontwerp van de vernieuwde RIDM uit door een multidisiplinair design team. | |||
| % - 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 | |||
| % - | |||