1. SIMS Waterfall Simulation – Seminar 3 PRM Eran Padumadasa

2. This model was designed to embody an iterative development process that values regularly providing the customer with incremental versions of the software throughout the life cycle. We accomplished this using a module-based approach that accommodated the partial submissions of a project throughout the process. In this model, a module represents an anonymous part of the project that can be worked on and developed independently of the other parts. Development actions, such as risk analysis, requirements analysis, design, and implementation are performed on each module separately. We specifically designed the attributes of a module to facilitate teaching about incremental software process approaches.

3. Questions to Consider: In particular, a module in this model has the following attributes (none of which are visible to the player at the beginning of the game, but instead are only revealed through various analysis activities performed on each module): Value: This represents the priority of this module to the customer, which in turn controls how much the completion of that module will help the player’s final score. Discovering this value through risk analysis can help the player to prioritize the completion of each module if time constraints prevent a complete submission. Inflexibility: This value signifies the degree to which the customer will be unwilling to accept deviations from their ideal concept of the module. The higher the inflexibility of a module, the more the player’s score will be hurt if that module is implemented incorrectly. Once again, using risk analysis to discover this value will help to guide the player in prioritizing modules.

4. Changeability: This value corresponds to how often the module is likely to be changed by the customer and, like value and inflexibility, is also discovered using risk analysis. This value is very important to determining how the player should proceed. Overcoming frequent customer changes is one of the primary challenges of this model, so knowing which modules are most likely to change is one of the most important pieces of information that should be used when devising a strategy for playing the game. Accuracy: This represents how well the developed module corresponds to the customer’s expectations for that module. Accuracy is improved by working on a module’s requirements, and it is eroded whenever the customer makes changes to the module. Even if a module is complete, if its accuracy is too low, it might represent no value at all to the customer in terms of the final project. This is especially true in modules with high inflexibility values. Phase difficulties: Each module contains a difficulty value for each development action that can be performed on it (requirements, design, and implementation). These values can help a player to determine which modules might make good candidates for the basis of early, rapid prototypes. Performing difficulty analysis on a module reveals that module’s difficulty values.

5. Questions Which artifact attribute seemed to be most important and most strongly affect the outcome of the game (e.g., inflexibility, difficulty, changeability, etc.)? Why? Try skipping one or more of the documentation phases (requirements/design) on one or more modules. What effect does this have? How does the early submission of a partially complete project affect your work on the remainder of the project? Describe your approach to the game in terms of the lifecycle models we discussed in class. In what ways did you follow a given lifecycle model? Is there any situation where it might be valuable to use the “start over” action?

6. Write a report divided into two parts. Part A describes your experience. Run the simulation five times. Each time record your score. And indicate what strategies you used to improve your score in each successive scenarios.

7. Additional Reading 1.Beck, K., Extreme Programming Explained: Embrace Change. 2000, Reading, MA: Addison-Wesley. 2.Boehm, B.W., A Spiral Model of Software Development and Enhancement. IEEE Computer, 1988. 21(5): p. 61-72. 3.Glib, T., Evolutionary Delivery versus the Waterfall Model. ACM SIGSOFT Software Engineering Notes, 1985: p. 49-61. 4.Laman, C. and V. Basili, Iterative and Incremental Development: A Brief History. IEEE Computer, 2003. 36(6): p. 47-56. 5.Royce, W., TRW's Ada Process Model for Incremental Development of Large Software Systems, in Proceedings of the 12th International Conference on Software Engineering. 1990. p. 2-11. 6.Scacchi, W., Process Models in Software Engineering, in Encyclopedia of Software Engineering, J. Marciniak, Editor. 2001, Wiley.