The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software Book Review

Processes are not documented and reused by a set of individuals because they lead to failure. Like design patterns, they are documented and reused because they lead to success. They are all put together by very talented people who have successfully used them to develop software multiple times. For them the process is easy to use and understand. The teams that have not used it have a steep learning curve ahead of them. Just looking at the diagram of a pattern or process, definitely will lead you to failure every time. I have seen Waterfall, Spiral, RUP, OpenUP, and Scrum all fail multiple times each because project managers, architects, developers, CIOs, and IT managers have only gone as far as looking at the diagram of the process they choose to use. They apply practices and principles they already know to the models instead of the ones that go with the models. The principles and practices that are behind the model must be learned and used in order to succeed. I assume this is a trick insanity plays on them. Doing the same thing over and over again expecting a different result. They thought renaming and reordering what they already do was actually changing. This book is required reading if you want to understand the Incremental Commitment Spiral Model (ICSM) and it's related diagrams. If you are not going to read the book, please do not attempt to use the diagram. After a very nice introduction it is broken down into five parts including the afterword. I have list each part and the chapters it includes below. 0. Introduction Part I: The Four ICSM Principles 1. The First Principle: Stakeholder Value-Based Guidance 2. The Second Principle: Incremental Commitment and Accountability 3. The Third Principle: Concurrent Multidiscipline Engineering 4. The Fourth Principle: Evidence- and Risk-Based Decisions Part II: ICSM Life Cycle and Stage I: Incremental Definition 5. The ICSM Life Cycle 6. Exploration Phase 7. Valuation Phase 8. Foundations Phase Part III: Stage II: Incremental Development and Evolution 9. Development Phase 10. System Production and Operations Part IV: Applying ICSM to Your Organization 11. ICSM Patterns and Common Cases 12. ICSM and Your Organization 13. Evidence-Based Life-Cycle Management 14. Cost and Schedule Evidence Development 15. Risk–Opportunity Assessment and Control Afterword Appendix A. Evidence Evaluation Framework Appendix B. Mapping between ICSM and Other Standards Appendix C. A Value-Based Theory of Systems Engineering Don't make the mistake of looking at this book and saying "oh, it's that old model again", it's not the 1988 spiral model- A Spiral Model of Software Development and Enhancement. The 1988 spiral model began the long process leading to the spiral model in this book, the Incremental Commitment Spiral Model (ICSM). Developing software correctly is easy. The hard part is having all the skills needed to do that. Since most teams do not possess the skills needed to easily execute a software development process, they usually have a hard time. Even those who gave it their best shot learning the practices and principles behind the 1988 model had a hard time succeeding. Within a short time the feedback that reached Dr. Boehm lead him to claim "What we really need are process model generators". I agree 100%. Implementing a development process instance for a given project is the only way to correctly use software development processes. Just as important, if not more important, is the ability to understand what is happening with your project and to change the process as needed. Teams seem to have a much harder time with that. Luckily that is what we got with this book. Software process engineering allows you to account for your team's skills and availability, your businesses needs, the tools you have available, the environment you are working in, the difficulty of the solution, the working environment - team member locations, greenfield vs. brownfield development, and many more things that are usually not taken into consideration at all. Software process engineering not only gives you the instance to work with, it also allows for tailoring the process to meet the needs of the project as circumstances change throughout the project. People leave, laws changes, hurricanes happen (although that didn't stop us- dumb, dumb, dumb), people get sick, and so on. The point is your process must be as agile and resilient as your software. That means the process must be changeable. I have sat in a room watching project managers and business users debate for hours about what to do now that they have discovered the next 3 sprints will take 3-4 weeks and not the 2 weeks they had agreed on. 1/2 of them wanted to split functionality (user stories) to meet the 2 week mark and add it back later with 3 more sprints but that would really mean 4 extra sprints because splitting the functionality adds complexity to the programming. Some of them wanted to borrow a few developers, while others just wanted to pretend they didn't know and just start the next 2 weeks after they got done this sprint. No deliverables or tests, just keep going and hope they weren't questioned. All of this is non-transparent nonsense, and is anything but agile. This book is not a software development process. The author's say "The ICSM is not a single, one-size-fits-all process. It is actually a process generator…". The book did not meet my expectation of what that means to me. In order for it to be a process generator, it would need to reference one or more specific process asset repositories which can be configured into an instance of a process. That does not detract from the value of the book, because we already have enough process asset repositories. My perception of the content of the book is that it is material that will help you audit, adjust, and manage a software process. That is needed more in today's industry. The rest of the sentence that begins the paragraph above is consistent with my understanding of the book's content- "… that steers your process in different directions, depending on your particular circumstances." One very cool thing about this book is that the material is available online. The material has been published from Eclipse Process Framework. At least it looks like it to me. There are two sites, The Incremental Commitment Spiral Model (ICSM) and The Instructional Incremental Commitment Spiral Model (ICSM) Electronic Process Guide. The Instructional Incremental Commitment Spiral Model (ICSM) Electronic Process Guide is a version of ICSM which is tailored to fit the nature of CSCI577ab Software Engineering Class. The one thing that drove me kind of nuts while reading this book is the very heavy use of acronyms. They probably drove me crazy because they brought back flashbacks of being in the Army and working for the State of PA. The thing I liked most about this book is the honesty found in it. An example is found in the first paragraph of the Preface- "Rumor has it, however, that some people would rather deliver an unsuccessful system so that they can continue being paid to make it successful; rumor also doubts those people will read this book." They also present failure stories for each success story, which really helps to keep the book grounded in reality. All in all I found this book an excellent read. It contains a ton of wisdom gathered over a very long period of time.

The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software

The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software