|
|
|
@@ -30,16 +30,14 @@ Many publications give credit to \textcite{royce_managing_1970}, for the concept |
|
|
|
Where they refer to the simple 5 to 8 step design concept, similar to the one in \autoref{sec:SE}. |
|
|
|
What these publications fail to address is that \textcite{royce_managing_1970} says: "I believe in this concept, but the implementation described above is risky and invites failure." |
|
|
|
Followed by multiple steps of improving the waterfall model. |
|
|
|
Royce adds a complete design step, loads of intermittent testing and documentation, and a literal instruction "Do it twice". |
|
|
|
With "Do it twice", he adds an extra 6 steps to develop a prototype parallel to the simple waterfall model, with the goal to spot every unforeseen requirement prior to any actual development. |
|
|
|
|
|
|
|
Interestingly, the mentioned problems that \textcite{royce_managing_1970} is providing a solution for, are similar to the difficulties in this case study. |
|
|
|
Studies and publications about the waterfall model would have been far more relevant if the authors included Royce's improvements. |
|
|
|
Especially as Royce explains that in his experience, the method without his improvements has never worked and that recovery costs far exceeded the added cost of the proposed improvements. |
|
|
|
I expect that these improvements would have had a significant impact on the design process. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Royce adds a complete design step, loads of intermittent testing and documentation, and the instruction to "Do it twice". |
|
|
|
On initial thought this feels as a disproportionate amount of extra work. |
|
|
|
Especially since the current design plan already includes small feedback cycles. |
|
|
|
However, the small feedback cycles only apply to the current design, and do not provide information about the current design direction. |
|
|
|
Thus, the current level of detail might work, passing the tests of the current cycle does not guarantee a successful implementation of the design. |
|
|
|
Based on the evaluation, it was often difficult to justify the design decisions as there was insufficient information. |
|
|
|
A simple proof of concept would improve the information about the direction of the design, required resources and the feasibility of the project. |
|
|
|
Although this requires additional work, it is very likely that it improves the projects feasibility and thus reducing the risks of the project. |
|
|
|
|
|
|
|
\section{Development Cycle} |
|
|
|
\subsection{Design and model} |
|
|
|
|
