Basic Principles Of Successful System

The Incremental Commitment Spiral Model (ICSM) is a life cycle process model generator that has been evaluated to be a flexible but robust framework for system development. The ICSM combines the strengths of various current process models and limits their weaknesses. The ICSM, like the Vee model, emphasizes early verification and validation, but allows for multiple-incremental interpretation and emphasizes concurrent rather than sequential engineering. Compared to the Spiral Model, the ICSM also focuses on risk-driven activity prioritization, but offers an improvement by adding well-defined in-process milestones.

The following are the four key trends that require changes and how the ICSM suggests process changes for developing successful systems:

1. Increasingly complex, global systems of systems: The Internet and personal communication devices are connecting most everything and everyone together. Developers of 21st century systems will need to consider how they fit, not only within their own enterprise, but often within multiple networks of independently evolving, codependent systems. The ICSM commitment milestones require evidence that the system be scalable to operate with its intended full-up environment, and be interoperable with its codependent systems for global collaborative processes.
2. Emergent requirements: Asking people what they would like in their user interface usually results in a response such as “I’m not sure, but I’ll know it when I see it” (IKIWISI). The most appropriate user interfaces and collaboration modes for a complex human-intensive system are not specifiable in advance, but emerge with usage. Forcing users to specify them precisely in advance of development generally leads to poor business or mission performance and expensive late rework and delays. The ICSM provides support for incremental and concurrent definition of system requirements and solutions, including competitive prototyping approaches.
3. Rapid change: Trying to stay competitive in a world of increasingly rapid changes requires new levels of agility, and shorter times between new releases of products and services. The ICSM’s incremental definition and development stages directly support shorter increments, more agile methods, and evolutionary development.
4. High assurance of qualities: At the same time that systems engineering and development need to become more agile, the growing interdependence of systems and people requires systems to have higher assurance levels. Just assuring any of the quality attributes for a complex system of systems is difficult. It is even harder to get agreement among multiple system owners with widely disparate quality priorities. “Satisficing” means not everybody gets everything they want, but everybody gets something they are satisfied with. The ICSM’s principles of stakeholder satisficing and evidence-based commitment milestones help ensure that key stakeholders’ primary quality concerns are addressed.

Key Principles

To understand and apply the process model appropriately, the process users should understand the core concepts of the model. The followings are the key principles of the ICSM .

Principle 1: Stakeholder Value-Based System Definition and Evolution => 
The INCOSE definition of systems engineering is “An interdisciplinary approach and means to enable the realization of successful systems”. A system will be successful if and only if it makes winners of its success-critical stakeholders. Thus, in order to create a successful system, you need to identify which stakeholders are success-critical, to determine their value propositions or win conditions, and to define, design, develop, and evolve a mutually satisfactory or win-win system with respect to their value propositions. If a project fails toinclude and address the value propositions of its success-critical stakeholders such as end-users, maintainers, interoperators, or suppliers, these stakeholders will frequently feel little commitment (or active hostility) to the project and either underperform, decline to use, or block the use of the results.

Principle 2: Incremental Commitment and Accountability => 
Without key personnel commitment and accountability for the system under development, there is no way to build trust among the system’s stakeholders. It is too easy to overpromise and depart. And there must be clear visibility of progress versus plans up and down the supplier chain. If success-critical stakeholders are not accountable for their commitments, they may not provide necessary commitments or decisions in a timely manner and are likely to be drawn away to other pursuits when they are most needed.

Principle 3: Concurrent Multidiscipline System Definition and Development - 
The fundamental assumptions underlying sequential processes, prespecified requirements, and functional-hierarchy product models began to be seriously undermined in the 1970s and 1980s. The increasing pace of change in technology, competition, organizations, and life in general has made assumptions about stable, prespecifiable requirements unrealistic. The existence of cost-effective, competitive, incompatible commercial products or other reusable non-developmental items (NDIs) made it necessary to evaluate and often commit to solution components before finalizing the requirements. The difficulty of adapting to rapid change with brittle, optimized, point-solution architectures generally made optimized first-article design to fixed requirements unrealistic. The ICSM emphasizes the principle of concurrent rather than sequential work on understanding needs, envisioning opportunities, system scoping, system objectives and requirements determination, architecting and designing of the system and its hardware, software, and human elements, life cycle planning, and development of feasibility evidence. So, it is important to do everything in parallel, especially in the early phases. If definition and development of requirements and solutions; hardware, software, and human factors; or product and process definition are done sequentially, the project is likely both to go more slowly, and to make early, hard-to-undo commitments that accumulate technical debt and cut off the best options for project success.

Principle 4: Evidence-Based and Risk-based Decision making =>
Having evidence serves as the principal decision criterion at milestone decision reviews is a considerable step forward from traditional schedulebased or event-based reviews. This is better, but frequently leads to “Death by PowerPoint and SysML” reviews, which present much design detail, but there is little time to determine whether or not the design will meet the system’s key performance parameters. Such evidence of feasibility is generally desired, but is considered as an optional appendix and is often neglected. In an ICSM evidence-based review, the feasibility evidence is a first-class deliverable. As such, its planning and preparation becomes subject to earned value management and is factored into progress payments and award fees. Investments in feasibility evidence have been found to pay off significantly in development rework avoidance [BoehmValerdi-Honour, 2008]. The link between evidence-based and risk/opportunity-based decisionmaking is that shortfalls in evidence are uncertainties or probabilities of loss or gain. If the Opportunity Exposure OE is high and the window of opportunity is closing rapidly, proceeding at least incrementally with a small amount of evidence can be the best decision. Thus, we can see that Principle 4 brings all of the other principles together. It involves concerns with the stakeholders’ value propositions in making decisions as in Principle 1; with proceeding incrementally as in Principle 2; and with synchronizing and stabilizing the concurrent activity prescribed in Principle 3.

Frequently Asked Questions