master-thesis
/
mar
1
0
Fork 0
Koodi Ongelmat 0 Pull-pyynnöt 0 Julkaisut 16 Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
91 Commitit
10 Branchit
9.1MB
Puu: 0069d20dd1
Branchit Tagit
${ item.name }
Create branch ${ searchTerm }
from '0069d20dd1'
${ noResults }
mar/content/case_evaluation.tex

65 lines
5.1KB
Raaka Blame Historia 

  1. %&tex

  2. \chapter{Case Evaluation}

  3. \label{chap:case_evaluation}

  4. 

  5. \section{Preparation Phase}

  6. \subsection{One-man development team}

  7. The case study was performed by me, as a single developer.

  8. Against all expectations, this one-man development team made the preparation phase more difficult instead of easier.

  9. The goal of the problem description and the specifications step is to get the stakeholders on the same line \autocite{shafaat_exploring_2015}.

  10. This involves creating agreed-upon requirements for the system, but with only one stakeholder, this agreement is implicit.

  11. Moreover, it undermines the incentive of the problem description and specifications step.

  12. Part of this is that there is no penalty for future reviews of the specifications, as I already agreed.

  13. 

  14. Furthermore, specific details and decisions were often made subconsciously, while I was commuting, waiting in line, or even showering.

  15. Making structured documentation of these decisions at a later point in time without missing any of them was impossible.

  16. The social interaction within a design team stimulates this documenting process as it improves the recall and interpretation of information.

  17. It also improves the judgement and selection between design alternatives \autocite{lamb_221_2008}.

  18. 

  19. \subsection{Information Flow}

  20. %% Aanknopen op het vorige verhaal?

  21. Although team members improve the information flow within a design team, it does not guarantee that all information is available.

  22. Throughout the case study, more and more information becomes available.

  23. During the initial design, new insight was gained that would have been useful during the problem description and the specifications step.

  24. And while making the tests, it became clear that the specifications were incomplete.

  25. It is possible to review the specifications step, but the succeeding steps have to be redone as well. 

  26. During the case study, I decided to continue with the design due to the scope of the research, namely the development design cycle was.

  27. 

  28. Dealing with these design changes is a known weakness of the waterfall model.

  29. Many publications give credit to \textcite{royce_managing_1970}, for the concept of the waterfall model.

  30. Where they refer to the simple 5 to 8 step design concept, similar to the one in \autoref{sec:SE}.

  31. 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."

  32. Followed by multiple steps of improving the waterfall model.

  33. Royce adds a complete design step, loads of intermittent testing and documentation, and a literal instruction "Do it twice".

  34. 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.

  35. 

  36. Interestingly, the mentioned problems that \textcite{royce_managing_1970} is providing a solution for, are similar to the difficulties in this case study.

  37. Studies and publications about the waterfall model would have been far more relevant if the authors included Royce's improvements.

  38. 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.

  39. I expect that these improvements would have had a significant impact on the design process.

  40. 

  41. 

  42. 

  43. 

  44. \section{Development Cycle}

  45. \subsection{Design and model}

  46.             Prior to the case study I expected the model to be the design.

  47.             So when the level of detail of the design is increased, this is achieved by expanding the model with more detail or components.

  48.             Resulting in different versions of a single model where each version has more detail than the previous one.

  49.             However, during this development a 2D dynamics model, 3D dynamics model and a 3D component model.

  50.             Although these models have components in common, they are not compatible.

  51.             Therefore, adding detail to the design requires two or three models to be updated.

  52. 

  53.             Furthermore, the step from 2D to 3D physics was in no means a small increment in detail.

  54.             The first four levels of detail, as describe in the previous section, all were implemented in with two dimensions.

  55.             As the later details required a third dimension, all the detail was directly converted from 2D into 3D.

  56.             This is a large amount of work, introducing a high cost when the conversion fails.

  57.             Moreover, it creates a new 3D physics model, parallel to the 2D physics model instead of adding detail to the latter.

  58.             Alternative approaches for 3D model physics could be:

  59.             \begin{itemize}

  60.                 \item Ignore 2D and start implementation in 3D modelling.

  61.                 \item Retrace all incremental detail steps of the 2D model in a 3D model.

  62.             \end{itemize}

  63.             Both options are not ideal, the first one does not allow a simple basic model and the second approach redoes work.

  64.             The advantage of starting with 3D is that allows for a continuous development of one model, instead of switching the complete model.