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."
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.
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO Silicon Valley 2019 will cover all of these tools, with the most comprehensive program and with 222 rockstar speakers throughout our industry presenting 22 Keynotes and General Sessions, 250 Breakout Sessions along 10 Tracks, as well as our ...
Technological progress can be expressed as layers of abstraction - higher layers are built on top of lower layers treating them as abstract black boxes with known interfaces. A serverless approach represents an inflection point that entirely separates the runtime layer from the u...
Your job is mostly boring. Many of the IT operations tasks you perform on a day-to-day basis are repetitive and dull. Utilizing automation can improve your work life, automating away the drudgery and embracing the passion for technology that got you started in the first place. In...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and l...
Big Switch's mission is to disrupt the status quo of networking with order of magnitude improvements in network e ciency, intelligence and agility by delivering Next-Generation Data Center Networking. We enable data center transformation and accelerate business velocity by delive...
Your registrations includes: Golden Pass Delegates will receive full conference access on October 20-22, 2008 including: Lunch and Coffee Breaks, Collectible Bag and Archives of all sessions on DVD. Includes access to all Conference Sessions including the Technical Sessions, Exhibits, Keynotes, Vendor Technology Presentations, and Power Panels.
AJAXWorld offers the undisputed best platform to position your company as a leading vendor in the fast-emerging marketplace for AJAX and Enterprise Web 2.0.
Who Should Attend?
• CTOs & VPs of Engineering
• Directors of Technology
• Sr. User Interface Architects
• Front-End Engineers
• VCs & Industry Analysts
• Directors of Business Development
• Software Engineers
• Senior Architects
• Application Programmers & Software Developers
• Project Managers
• Web Programmers & Designers
• Companies & Organizations that need to stay in front of the latest Web technology
AJAXWorld Security Bootcamp
Introducing at AJAXWorld RIA Conference 2008 West the world's first-ever full, one-day immersive "AJAX Security Bootcamp" - led by one of the world's foremost AJAX security experts and teachers, HP's Billy Hoffman.