Vee Life Cycle Model

There are a large number of life cycle process models in which systems engineering may operate. Some are relatively rigid, such as formal methods or waterfall models. Some are very lightly constrained, such as agile or innovative methods. Some address particular situations, such as rapid development, COTS-based development, product line creation and use, or proprietary corporate life cycle models. For the most part, these models fall into three major categories:

1. Primarily Prespecified and Sequential Processes. These models tend to assume that top-level system requirements can be prespecified at the beginning of the life cycle, and tend to associate life cycle activities with particular life cycle stages. Examples are the formal methods, waterfall, and Vee models.
2. Primarily Evolutionary and Concurrent Processes. These models tend to assume that many system requirements are not prespecifiable, but emerge with system elaboration and use, or with unforeseen changes in competition, technology, interoperating systems, and mission priorities. They tend to assume that life cycle activities will be performed concurrently across multiple stages. Examples are the Rational Unified Process and various forms of the Vee and spiral models.
3. Primarily Interpersonal and Unconstrained Processes. These models tend to operate on tacit interpersonal knowledge rather than explicit documented knowledge, and tend to assume that emergent requirements and unforeseen changes are the norm. Examples are Agile development, Scrum, eXtreme Programming, Dynamic System Development Method, and innovation-based processes.

A representative of each major category is presented below. The Vee Model represents the primarily prespecified and sequential models. The Incremental Commitment Spiral Model (ICSM) represents the primarily evolutionary and concurrent models. The Scrum Model represents the primarily interpersonal and unconstrained processes.

The qualifier “primarily” implies that there are considerably large gray areas among the categories. Versions of the Vee model show concurrent system development, verification, and validation activities, although the language and tables describing the Vee model below generally assign activities to stages more exclusively and sequentially. The ICSM has a prespecified approach for developing increments, while destabilizing change traffic is routed to a concurrent agile rebaselining team as in Figure 4-4. Organizations have found ways to scale up agile methods to projects of up to 100 people using a Scrum of Scrums approach within and overall architecture. Furthermore, very large systems and systems of systems will generally find it best to apply all three process categories to portions of their systems and their life cycles.

A Primarily Prespecified and Sequential Process Model: The Vee Model

The sequential version of the Vee model is shown in Figure 4-5. Its core involves a sequential progression of plans, specifications, and products that are baselined and put under configuration management. The vertical two-headed arrow enables projects to perform concurrent opportunity and risk analyses, and continuous in-process validation.

Figure 0 5 – Left side of the sequential Vee model (Forsberg, Mooz, and Cotterman 2005. Pg 111)

The disadvantage of this simplified view is that some project managers and systems engineers may assume incorrectly that they only need to focus on the “on-core” actions. A more complete view is presented later in Figures 4-9 and 4-10.

Well-resourced and knowledgeable project managers will consider the opportunity and risk management investigations and analyses essential to their success. However, many projects have shown that if resources are limited and the contract emphasizes the core activities, the effort goes into the core activities, the project misses the opportunities, and leaves the risks to be found later when they are much more expensive and time-consuming to fix.

Note: Table 0-1 is to be moved to "Life Cycle Models" Introduction, page 1

Table 0 1 Generic life cycle stages, their purposes, and decision gate options

Application of the Vee Model

In his book A Journey Through the Systems Landscape Lawson elaborates on the activities in each life cycle stage, and notes it is useful to consider the structure of a generic life cycle stage model for any type of System-of-Interest as portrayed in Figure 4-6 (Lawson 2010). The (T) model indicates that one or more Definition stages precede a Production stage(s) where the implementation (acquisition, provisioning or development) of two or more system elements has been accomplished. Also in these stages the system elements are integrated according to defined relationships into the System-of-Interest. The Implementation and Integration processes are followed in providing the primary stage results; namely assembled system product or service instances. Following the Production stage a Utilization Stage is entered. Further relevant stages can include Support and Retirement. Note that this model also displays the important distinction between definition versus implementation and integration.

Figure 0 6 Generic (T) Stage Structure of System Life Cycle Models (Lawson 2010, Figures 6-2 to 6-5)

The generic life cycle stages for a variety of different organizations, from standards (ISO/IEC) to commercial to government. See, for instance, INCOSE 2011, page 26, or Forsberg, Mooz, and Cotterman 2005, page 87. Note that although different in detail, all the life cycles have a similar sequential format that emphasizes the core activities. Again, well-resourced and knowledgeable project managers will ensure that the non-core activities of opportunity and risk management and the development and independent review of core artifact feasibility evidence are first-class project activities and artifacts. However, such resources and knowledge are generally in short supply, leading again to lost opportunities and costly, belated recovery from risks. The Vee model and the standards below are based on continuous opportunity and risk assessment, going down to the lowest level necessary to understand and define the steps to take advantage of the opportunities and resolve the risks as the basis for moving forward. Unfortunately these attributes are often ignored in trying to simplify the model, and the plans made using it. Project teams would have considerably higher success rates if they treated the feasibility evidence and related risks as first-class citizens.

Fundamentals of Life Cycle Stages and Program Management Phase

The notion of life cycle is related to the notion of program management that was presented in the previous section. We notice that:

• The term "stage" refers to the different states of the system during its life cycle; some stages may overlap in time such as the Utilization stage and the Support stage. The term “stage” is used in ISO/IEC 15288 and elaborated in ISO/IEC 24748.
• The term "phase" refers to the different steps of the program that supports and manages the life of the system; the phases usually do not overlap. The term “Phase” is used in many well-established models as equivalent to “Stage.”

Program management employs phases, milestones, and decision gates during which the stages of the system evolve. It is a shame that sometimes the names of the stages and those of the phases are the same. But we have indeed the two notions. The stages contain the activities performed to achieve their goals; the phases serve to the control and the management of the sequence of stages and the transitions from one stage to the others. For each project it is essential that the team define and publish the terms and related definitions used on their project to minimize confusion.

As an example, Figure 4-8 shows a typical program management sequence. This figure does not assume the detailed sequence of the system stages. This classical program is composed of the following phases:

• The pre-study phase - The first decision gate is after the pre-study phase during which appropriate research and development is carried out, technology challenges and opportunities are explored and potential system concepts are analyzed. Those concepts that have promise for future business opportunities are presented to the management for approval to continue the development of the more promising concepts. The concepts can be needed to develop a new market, to respond to a specific threat or to respond to a request for proposal. Preliminary studies, exploration of concepts, identification of stakeholders' needs, system requirements and design are more or less carried out. Implementation of technological prototypes can be made.
• The feasibility phase - This phase consists of studying the feasibility of alternative concepts to reach a second decision gate before initiating the execution stage. It is the “go-ahead decision” based on:
  • Whether a concept is feasible and is considered able to counter an identified threat or exploit an opportunity.
  • Whether a concept is sufficiently mature to warrant continued development of a new product or line of products.
  • Whether to approve a proposal generated in response to an RFP (Request for Proposal).

During the feasibility phase stakeholders' requirements and system requirements are identified, viable solutions are designed and studied, virtual prototypes are engineered and can be implemented.

• The execution phase – This phase includes activities related to four stages of the system: development, production, utilization and support. Typically there are two decision gates and two milestones associated with execution activities. The first milestone provides the opportunity for management to review the plans for execution before giving the go-ahead. The second milestone provides the opportunity to review progress before the decision is made to initiate production. The decision gates during execution can be used to determine whether to produce the developed system-of-interest and whether to improve it or retire it.

These Program Management views apply not only to the system of interest (soi) but also to its elements and structure. Different enterprises can be responsible for different systems of the system structure. And, the systems and system elements can have a shorter life than the SoI in which they are embedded, so during the life of the SoI, these elements may need to be replaced with improved systems or system elements.

Figure 0 8 - Program Management and Engineering Views of the sequential System Life Cycle (ISO/IEC 19760:2003)

Life Cycle Stages

Exploratory Research Stage

The most important phase in the project cycle is the User Requirements Analysis and Agreement phase, which is part of the Exploratory Research Stage. First, one key focus of this phase is to define the user (and stakeholder) requirements and constraints. A key part of this process is to establish the feasibility of meeting the user requirements. Something that seems reasonable at a high level may in fact be impossible to achieve. However, without detailed studies the areas of high risk cannot be identified . In order to assess the project feasibility, it is necessary to develop a “reference design” to probe, identify, and assess critical issues that will be encountered in satisfying the user needs (Figure 4-9). Cost and schedule predictions will be built on this reference design, but do not mistake it for “the design solution.” Its purpose is only to substantiate that the set of user requirements jointly agreed to by the user and the development team can be satisfied. These are placed under configuration control so that all involved will have a common starting point. As the project evolves the user requirements will evolve as well, but the configuration control process will ensure that all are aware of the changes as they are made. For some projects the requirements are clear, but an evolutionary approach is required to produce a solution. For another class of projects, the user requirements will evolve as solutions are considered.

The phase shown in the figure encompasses what is often called early phase systems engineering (sometimes called “brainstorming” or “exploratory studies” in industry and pre-Milestone A in government projects). It is critical to broaden the stakeholder base at this point. A recent study by the National Research Council (2008) focused on reducing the development time for new US Air Force projects, and the report notes: “Simply stated, Systems Engineering is the translation of a user’s needs into a definition of a system and its architecture through an iterative process that results in an effective system design.” The iterative involvement with stakeholders is critical to the project success.

Figure 0 9 The Vee model in early Exploratory Research Phase, focusing on User Requirements Development (Forsberg 2010, pg 5)

In this phase the objective is to develop user requirements, not to create a design. However in order to determine if requirements are achievable, a reference design must be created. The customer needs to bound the cost and schedule in order to determine if the project is worth pursuing (is there sufficient value, compared to other possible uses for the resources required to complete this project). These preliminary projections will have a substantial margin of error, but they need to be within 300% or so. An example of the problems encountered in keeping funding for a project as it matures is illustrated in the Washington Post article (Washington Post Feb 2009) when the new Mars Rover project encountered a 20% overrun and schedule delay. Critics claimed the overrun was really well over 400%, based on the cost projections from the Exploratory Research phase several years earlier, and they wanted to cancel the project on that basis. In another example, in July 2011 the United States House of Representatives Appropriations Committee proposed cancelling the (multinational James Webb Space) Telescope project, in spite of the outstanding technical status, because it “is billions of dollars over budget and plagued by poor management.” The estimated cost had risen to $6.5 billion by July 2011, with a four-year delay in the originally scheduled launch date in 2014. The original cost was estimated at $1.6 billion a decade earlier. “The delay and cost overruns are due to an unrealistic original budget.”

Unfortunately the universal desire is to underestimate cost and schedule in the early stages to “sell the program.” This problem is prevalent on the parts of both the customer and developer.

Concept Stage

Stakeholder input is vital during evolution of any program, and this is emphasized in Figure 4-10 where the focus of the effort here is on concept formulation and description. The upward and downward iterations are the same pattern as for the design concept development, which is the focus of Figure 4-10. One of the reasons that the agile development process works so well is that the customer is an integral part of the small (20 people or less) development team. On larger projects the upward iterations are an opportunity to maintain user and customer involvement and achieve some of the benefits of a more agile team.

The upward iterations with the system specification and with the user requirements are encouraged, but previous decisions are under change management. “Change management” does not imply “change prevention,” but a disciplined process must be in place so that all teams are working to current goals.

Figure 4-10 - The Vee model in Design Concept Development (Forsberg 2010, pg 6)

To engineer a feasible system solution during the concept stage, a system structure needs to be sufficiently defined and evaluated. This should be done to assure that stakeholders' requirements are met and that the costs and risks are understood for the selected feasible system concept(s). Again upward iteration with the user is invaluable, and involvement of a customer representative in the decision process will minimize unpleasant surprises at the completion of the development stage.

Development Stage

To engineer a system solution during the development stage the process initiated in the Concept Stage is elaborated upon as shown in Figure 4-10. The system needs to be designed with appropriate detail from the system-of-interest level down through successive system levels until the system element (component) can be made, bought, reused or implemented by appropriate technologies. After verification, each system entity is transitioned to the acquirer where it can be assembled and integrated into a higher-level system that is verified and validated, to ensure it meets the users’ objectives. This action continues through successive levels upward to realize the desired system-of-interest. Development is managed through a project that contains:

• Temporal elements called “Phases,” which are intervals of sequential period within the Development Stage;
• Selected Milestones that act as intermediate decision gates to control the correct progression of the project; each phase within the Development Stage is separated from the following one by a milestone;
• Reviews performed at the intermediate milestones to identify the status of activities execution and work products to support the decision gates.
• Different segments of the project can run in parallel, each with its own Vee. On the Iridium project (the mobile phone system based on a fleet of low-earth orbit satellites), for instance, the project used eighteen Vee’s in parallel.

The development is carried out in Phases. The goal of a Phase is to reach and to pass a technical pre-established state of the development. The degree of partitioning of the development into Phases depends on the level of control that the project manager wants according to the project parameters.

Milestones and Decision Gates

As defined in ISO/IEC 15288, Decision Gates should be held at the beginning and conclusion of each Stage. Decision Gates would usually have the customer in attendance. Milestones are usually internal to the project, and are placed at the beginning and/or at the end of each phase within a Stage. The conditions to pass from one phase to the next one are preset. A new phase starts after successfully passing a Milestone, (including validation of the previous phase) which is a preset marker used to declare the work products of the phase are satisfactory. The Milestones cannot be dissociated from the phases; each phase has at least two Milestones:

• A Gate for entering with inputs and related conditions,
• A Gate for exiting with outputs and related conditions.

Except for the first and last Decision Gates of a project, the two Gates are performed simultaneously. See Figure 4-11.

Figure 4-11- Scheduling the Development Phases (Faisandier 2010)

Reviews

To control the progress of a project different types of Reviews are planned. The most commonly used are listed below but the names are not universal:

• System Requirements Review - SRR is planned to verify and validate the set of system requirements before starting the detailed design activities.
• Preliminary Design Review - PDR is planned to verify and validate the set of system requirements, the design artifacts and justification elements at the end of the first engineering loop. This review is sometimes called the “Design-to” gate.
• Critical Design Review – CDR is planned to verify and validate the set of system requirements, the design artifacts and justification elements at the end of the last engineering loop. The “Build-to” and “Code-to” design is released after this review. Most software projects have individually-scheduled peer reviews instead of having each module’s detailed design wait to be reviewed at a single CDR event.
• Integration, Verification, and Validation (IV&V) Reviews – As the components are assembled into higher level subsystems and elements, a sequence of reviews are held to ensure that everything integrates properly and that there is objective evidence that all requirements have been met (I&V). There should also be an in-process validation that the system, as it is evolving, will meet the Stakeholders’ Requirements (see Figure 4-12).
• Final Validation Review – FVR is carried out at the end of the integration phase.
• Other Project Reviews related to management can be planned in order to control the correct progress of work, based on the type of system and associated risks.

Figure 4-12 - Right side of the Vee Model (Forsberg, Mooz, and Cotterman 2005, Pg 115)

Production Stage

The Production Stage is where the system-of-interest is produced or manufactured. Product modifications may be required to resolve production problems, to reduce production costs, or to enhance product or system-of-interest capabilities. Any of these may influence system requirements and may require system re-qualification, re-verification, or re-validation. All such changes require SE assessment before changes are approved.

Utilization Stage

A significant aspect of Product Life Cycle Management is the provisioning of supporting systems that are vital in sustaining operation of the product. While the supplied product or service may be seen as the NSOI (Narrow System of Interest) for an acquirer, the acquirer also must incorporate the supporting systems into a WSOI (Wider System of Interest). These supporting systems should be seen as system assets that when needed are activated in responding to some situation that has arisen in respect to operation of the NSOI. The collective name for the set of supporting systems is the Integrated Logistics Support (ILS) System. Some typical types of ILS supporting systems are indicated below:

• • Logistics, maintenance, and support personnel
  • Technical data, reports, and documentation
  • Packaging, handling, storage, and distribution
  • Maintenance support facilities and utilities
  • Test and measurement equipment
  • Computer hardware and software responses
  • Training and technical support

Consistent with our earlier discussion of System of Interest, the typical ILS elements listed above are each systems requiring life cycle management. The elements are system assets for a supplying enterprise that are instantiated and put into operation in responding to logistics related situations.

As has been emphasized several times earlier, it is vital to have a holistic view when defining, producing and operating system products and services. Thus, in developing the System of Interest, the logistics aspects must be taken into account early in the life cycle. They indeed place vital requirements on the system. In Figure 4-14 the relationship between system design and development and the ILS requirements is portrayed.

Figure 4-14 - Relating ILS to the System Life Cycle (ASD-STAN, Fig 1, 2009 Products and Services S3000L, www.asd-stn.org.)

The requirements for reliability resulting in the need of maintainability and testability are driving factors. These needs are analyzed in a Logistics Support Analysis (LSA) based upon Customer Requirements and the Environmental and Operational Requirements. A support concept is to be developed that is then utilized in generating the individual ILS supporting systems.

Support Stage

In the Support Stage the system-of-interest is provided services that enable continued operation. Modifications may be proposed to resolve supportability problems, to reduce operational costs, or to extend the life of a system. These changes require SE assessment to avoid loss of system capabilities while under operation. The corresponding technical process is the Maintenance Process.

Retirement Stage

In the Retirement Stage the system-of-interest and its related services are removed from operation. SE activities in this stage are primarily focused on ensuring that disposal requirements are satisfied. In fact, planning for disposal is part of the system definition during the Concept Stage. Experience in the 20th century repeatedly demonstrated the consequences when system retirement and disposal are not considered from the outset. Early in the 21st century, many countries have changed their laws to hold the creator of a system-of-interest accountable for proper end-of-life disposal of the system.

Incremental and Evolutionary Development using the Vee Model

Overview of the Incremental Approach

Incremental and iterative development (IID) methods have been in use since the 1960s (and in some cases earlier: consider classical roadbuilding, in which construction methods were adapted to the terrain as road construction went along). They represent a practical and useful approach that allows a project to provide an initial capability followed by successive deliveries to reach the desired System-of-Interest. The goal is to provide rapid value and responsiveness. This approach is generally presented in opposition to the perceived burden associated with the prescriptive and sequential process model.

As discussed earlier, the IID approach, shown for a general case of the Vee model in Figure 4-15, is used when:

• Rapid exploration and implementation of part of the system is desired,
• The requirements are unclear from the beginning,
• Funding or other scarce resources are constrained, or
• The customer wishes to hold the System-of-Interest open to the possibilities of inserting new technology at a later time.
• The system’s full capabilities are dependent on the capabilities of independently-evolving external systems, or
• Experimentation is required to develop successive prototype versions

(There are several examples of this form of IID)

Only the core of the Vee is shown for each iteration, but the full off-core opportunity and risk management and in-process validation actions need to be considered, as shown earlier in Figure 4-10, for each increment. The focus is on flexibility and on allowing selected events to be taken out of sequence when the risk is acceptable. Tailoring in this way highlights the core activities of product development.

Based on an initial set of assumptions, selected aspects of the candidate System-of-Interest are developed in the first iteration, with the goal of quickly producing a useful capability. A second iteration can be initiated even before the first one is completed, and the process is repeated, with each subsequent increment building on the preceding ones, until the complete system is delivered which satisfies all stakeholder needs, or until the sponsoring organization decides to terminate the effort. Properly planned each increment will build on the previous one.

Another possibility is that a new capability is urgently needed. Imagine the unlikely event of a deep-water oil well failing in the Gulf of Mexico. The need is to quickly cap the well. While a long-term solution is being conceived and then developed, Increment 1 is the placement of a temporary cap, and a closely related Increment 2 is the placement of a better well cap. Increment 3 is a totally different approach (drilling a lateral well to stop the flow deeper in the well shaft). Increment 3 has no connection to the first two increments, but all three are part of the same top-level program. Note that the IID approach can work effectively in a high risk, rapid response mode for hardware as well as software projects.

The features that distinguish IID from the single-pass plan-driven approach are velocity and adaptability. While market strategies often emphasize that “time to market” or speed is critical, a more appropriate criterion is “velocity,” which considers direction in addition to speed. By incorporating the customer into the working-level teams, the project receives continuous feedback that they are going in a direction that satisfies the customer’s highest needs first. One downside is that reactive project management with a customer that often changes direction can result in an unstable, chaotic project. On one hand, this approach avoids the loss of large investments in faulty assumptions. Beware of over-emphasis on a tactical viewpoint that may generate short-term or localized solution optimizations, sometimes to the detriment of the overall project. Thus, as shown below, the left side of the initial Vee produces not only a preliminary design of the first increment, but a best-effort preliminary design of the desired full system.

Figure 4-15 Incremental Development with multiple deliveries (Forsberg, Mooz, Cotterman. 2005, Pg 358)

Incremental development may also be “plan-driven” in nature when the requirements are known early in the life cycle but the development of the functionality is performed incrementally to allow for the latest technology insertion or potential changes in needs or requirements.

By reconfiguring the individual Vees in Figure 4-15, the other forms of IID can be accommodated. For example, often portions of the system are developed but not fielded until a full next-increment user capability is ready for use. This could be because continual change in user interfaces would be risky, as is the case for air traffic control. Or it may be that high-risk elements need to be resolved, or critical infrastructure support provided, before developing the rest of the next increment. Such non-deliverable builds can be represented by modifying their representations in Figure 4-15 by making their right-hand sides vertically shorter. An example of this approach for software will also be shown as Figure 1 of Section 2.4.4.

While incremental development provides substantial flexibility to the project team, it also imposes constraints. For instance, in the early studies of the Space Shuttle system in the late 1960s, the main engines on the orbiter vehicle were identified as a high-risk subsystem. The challenge was that the engines had to be reusable, which had never been done before. Design studies focused on determining the number of engines and configurations needed on the orbiter during the boost phase. There were designs using three large engines, or five mid-sized engines, or seven smaller ones, with one design using 11 engines. The three-engine configuration was selected, and after an intense competition NASA awarded the engine development program to Rocketdyne in 1970. During the two years before the orbiter award was made in 1972, studies continued at other companies on optimum engine arrangement. It was decided in late 1971 that five smaller engines would be a better choice than the three-engine design (which was encountering significant technical challenges); but that was no longer an option since the first increment had already consumed substantial funds and the program could not afford the cost and time for an engine redesign at that point. The message is that each increment, as it is implemented, imposes constraints on the downstream system components.

Overview of the Evolutionary Approach

A specific IID methodology called evolutionary development is common in research and development (R&D) environments. It can be derived from Figure 4-15 by making the multiple Vees sequential. It was used in the evolution of the high temperature tiles for the NASA Space Shuttle (Forsberg 1995).

In the Evolutionary Approach the principal investigator sets the objectives for the first iteration. The project is managed as if these were customer requirements. At the end of the first cycle the product is evaluated through system test to determine if the outcome will be useful. Often the first iteration provides valuable insight but does not result in a useful product. So the project team revises the system requirements, and another iteration is initiated. At the start of the process the end result is unknown. Hopefully a useful product will evolve, but the process has no guaranteed outcome. This is the process that Robert Beasley followed in modifying a dense ceramic antenna window, and exploring alternate ways of reducing the antenna weight. After three years of study the result was a rigid fibrous insulation that had no known value. This project funding ended and the tiles sat on a shelf for three years. It was pure chance that the Space Shuttle program manager at Lockheed found the material and championed its use for the Shuttle program. The evolutionary development is widely used in research laboratories in both commercial and government environments. It is also widely used in situations involving rapid changes in mission objectives, available technologies, or competitive threats.

The real world development environment is complex to map because many different project cycles are underway simultaneously. Figure 4–18 shows the applied research era for the development of the space shuttle orbiter. The overall system of systems was called the Space Transportation System (STS), and it had the Space Shuttle orbiter as one of the many programs being managed. The launch base, the external tanks, the emergency landing sites worldwide, and the worldwide communications system were all part of the total program. The orbiter project followed the “Prespecified and Sequential Process Model (Section 2.4.1).” The start of the orbiter development is shown in the heavy line in Figure 4–18. In 1968 and 1969 the focus was on the orbiter configuration, and simultaneously on key subsystems such as thermal protection. The thermal protection studies included metallic heat shields, active cooling, ceramic insulators, and ablators. The driving requirement was reuse for 100 missions. In parallel studies of the rocket motors continued and in 1970 contract award was made for the engines two years in advance of selecting the orbiter final configuration, because the engines were seen as the most critical subsystem. Figure 4-18 illustrates the multi-levels of simultaneous development, trade studies, and ultimately implementation.

It is noteworthy that the commercial project, Iridium (the mobile phone system based on a fleet of low-earth orbit satellites) had a highly successful technical development. The management of their technical environment involved eighteen different, parallel Vee models for the various parts of their system. Their business failure was caused by their inability to stay current with the evolving business case in the rapidly growing GSM mobile phone market.

Figure 4-18 - Evolution of components and orbiter subsystems (including space shuttle tiles) during creation of a large “single-pass” project (Forsberg 1995)

Iterative Software Development Process Models

Since software is a major part of most systems built after 1960, and since software development can be approached in ways quite different from traditional hardware development, it is important to specifically discuss software development models as a part of the project life cycle, and to highlight the systems engineering role in the process. Published articles and books sometimes imply that hardware follows a linear development path, and incremental or evolutionary approaches are primarily the domain of software. As illustrated in the history of the Lockheed Blackbird (the SR-71 and its relatives) the design and development of one of the world’s fastest air-breathing aircraft went through twelve different design evolutions over a two-year period before achieving the design goals and the final production configuration (Landis 2010). So while incremental and evolutionary development are not the new and exclusive domain of software, there are unique considerations that must be addressed.

The life cycle processes of software engineering follow the pattern of systems engineering: analysis, design, construction, verification and validation, acceptance, installation, sustainment, and retirement. However, software is a flexible and malleable medium, which facilitates iterative analysis, design, construction, verification, and validation to a greater degree than is usually possible for the physical components of a system. Each iteration of an iterative development model adds code to the growing software base; the expanded code base is tested, reworked as necessary, and demonstrated to satisfy the requirements for that baseline. Software can also be electronically upgraded, making it an attractive choice for field upgrades as compared to hardware.

Some process models for software development support iterative development on daily cycles. Other iterative development models support weekly, bi-weekly, and monthly iterations. The outcome of each iterative cycle is demonstrated to the satisfaction of the software team and other internal stakeholders while the results of some iterations are demonstrated for users, customers, and other external stakeholders. The evolving baselines of code may be tested and demonstrated on the actual system hardware or on emulated hardware. Table 1 lists three iterative software development models presented in the Life Cycle Models topic area and the aspects of software development that are emphasized by those models.

Table 1. Primary emphases of three iterative software development models

Iterative-development process models

Developing and modifying software involves creative processes that are subject to many external and changeable forces. Long experience has shown that it is impossible to “get it right” the first time, and that iterative development processes are preferable to linear, sequential development process models such as the well-known Waterfall model.

In iterative development, each cycle of the iteration subsumes the software of the previous iteration and adds new capabilities to the evolving product to produce a next, expanded version of the software (obsolete portions may also be retired). Iterative development processes provide the following advantages:

• continuous integration, verification, and validation of the evolving product,
• frequent demonstrations of progress,
• early detection of defects,
• early warning of process problems,
• systematic incorporation of the inevitable rework that occurs in software development, and
• early delivery of subset capabilities (if desired).

Iterative development takes many forms in software engineering, including these:

• An Incremental-build process is used to produce periodic (typically weekly) builds of increasing product capabilities;
• Agile development is used to closely involve a prototypical customer in an iterative process that may repeat on a daily basis;
• The Spiral model is used to confront and mitigate risk factors encountered in developing the successive versions of a product.

This section focuses on the Incremental-build model.

The Incremental-build model

The Incremental-build model is a build-test-demonstrate model of iterative cycles in which frequent demonstrations of progress and verification & validation of work to date are emphasized. The Incremental-build model is based on stable requirements and a software architectural specification. Prioritized requirements are allocated to various elements of the software architecture, which is the basis for specifying a prioritized sequence of builds. Each build adds new capabilities to the incrementally growing product. The development process ends when Version N (the final version) is verified, validated, demonstrated, and accepted by the customer.

Table 2 lists some partitioning criteria for incremental development. As discussed in section 2.4.3.1, these criteria include early development of high-risk elements or of necessary support imfrastructure. Partitions are decomposed into incremental build units as short as one calendar-week each; or for complex systems of systems, as long as several months. The length of the increments and the number of developers available to work on the project determine the number of features that can be included in each incremental build. This, in turn, determines the overall schedule. This, in turn, determines the overall schedule.

Table 2. Some partitioning criteria for incremental builds

Figure 1 illustrates the details of the build-verify-validate-demonstrate cycles in the Incremental-build process. Each “build” includes detailed design, coding, integration, and review and testing by the developers. In cases where code is to be reused without modification, some or all of an incremental build may consist of review, integration, and test of the base code augmented with the reused code.

Figure 1. Incremental build-verify-validate-demonstrate cycles (Fairley, R.)

Development of an increment may result in rework of previously developed components to better accommodate the new components being integrated, or to fix defects in previously developed components exposed by addition of the new components, or to fix defects in the new components. In any case, frequent demonstrations of progress (or lack thereof) are a major benefit of an Incremental-build development process.

Incremental verification, validation, and demonstration, as illustrated in Figure 1 overcomes two of the major problems of a Waterfall approach: 1) problems are exposed early and can be corrected as they occur; 2) minor in-scope changes to requirements that occur as a result of incremental demonstrations can be incorporated in subsequent incremental builds. Figure 1 also illustrates that it may be possible to overlap successive builds of the product. It may be possible, for example, to start detailed design of the next version while the present version is being validated. Three factors determine the degree of overlap that can be achieved:

1. availability of sufficient personnel to concurrently pursue multiple activities,
2. adequate progress on the previous version to provide needed capabilities for the next version, and
3. the risk of significant rework that must be accomplished on the next overlapped build because of changes to the previous in-progress build.

The Incremental-build model can be scaled up for large projects by partitioning the architecture into well-defined subsystems and allocating requirements and interfaces to each subsystem. The subsystems can be independently tested and demonstrated, perhaps using stubs and drivers for the subsystem interfaces, or perhaps using early, incremental versions of other evolving subsystems. System integration can proceed incrementally as intermediate versions of the various subsystems become operational.

A significant advantage of an Incremental-build process is that features built first are verified, validated, and demonstrated most frequently because subsequent builds incorporate the features of the earlier builds. In building the software to control a nuclear reactor, for example, the emergency shutdown software could be built first. Operation of emergency shutdown (scramming) would then be verified and validated in conjunction with the features of each successive build.

In summary, the Incremental-build model, like all iterative models, provides the advantages of continuous integration and validation of the evolving product, frequent demonstrations of progress, early warning of problems, early delivery of subset capabilities, and systematic incorporation of the inevitable rework that occurs in software development.

The role of prototyping in software development

In software engineering, a prototype is a mock-up of the desired functionality of some part of the system. This is in contrast to physical systems, where a prototype is usually a first full functionality version of a system. Software prototypes are constructed to investigate a situation or to evaluate a proposed approach to solving a technical problem. A prototype of a user interface, for example, might be constructed to promote dialog with users and to thus better understand their needs and concerns. A prototype implementation of an algorithm might be undertaken to study the performance or security aspects of the algorithm.

Prototypes are not constructed with the same attention to architectural structure, interfaces, documentation, and quality concerns as is devoted to product components. Prototypes may be built using different tools than are used to build production systems. For example, a prototype of a user interface might be rapidly developed in Visual Basic but the production version of the interface might be implemented in the programming language C to provide the required performance and compatibility with other system components.

In the past, incorporating prototype software into production systems has created many problems. Prototyping is a useful technique that should be employed whenever appropriate; however, prototyping is not a process model for software development. Some organizations use the term “prototyping,” in conjunction with other terms such as “structured” or “rapid” to describe their software development model. In many cases this is a euphemism for chaotic development.

When building a software prototype, we keep the knowledge we have gained but we do not use the code in the deliverable version of the system unless we are willing to do additional work to develop production-quality code from the prototype code.

In many cases it is more efficient and more effective to build the production code “from scratch” using the knowledge gained by prototyping than to re-engineer the prototype code.

Life cycle sustainment of software

Software, like all systems, requires sustainment efforts to enhance capabilities, to adapt to new environments, and to correct defects. The primary distinction for software is that sustainment efforts change the software; unlike physical entities, software components do not have to be replaced because of physical wear and tear. Changing the software requires re-verification and re-validation, which may involve extensive regression testing to determine that the change has the desired effect and that the change has not altered other aspects of functionality or behavior.

Retirement of software

Useful software is seldom retired. Software that is useful often experiences many upgrades during its lifetime so that a later upgrade may bear little similarity to the initial version. In some cases, software that ran in a former operational environment is executed on hardware emulators that provide a virtual machine on newer hardware. In other cases, a major enhancement may replace, and rename, an older version of the software, but the enhanced version provides all of the capabilities of the previous software in a compatible manner. Sometimes, however, a newer version of software may fail to provide compatibility with the older version, which necessitates other changes to a system.

Primarily Evolutionary and Concurrent Processes: The Incremental Commitment Spiral Model (ICSM)

Overview of the Incremental Commitment Spiral Model

A view of the Incremental Commitment Spiral Model is shown in Figure 4-19. As with the original spiral model (Boehm 1988), its expanding spirals reflect increasing cumulative levels of system understanding, product detail and process detail. These do not expand uniformly, but as a function of the relative risks of doing too much or too little of product and process definition. Thus, valuation and selection of COTS products or purchased services may be the highest-risk item and receive most of the early effort, or it might be prototyping of user interfaces, of operational concept scenarios, of use of maturing new materials, or of alternative vehicle platform configurations.

Figure 4-19. The Incremental Commitment Spiral Model

Each spiral will be concurrently rather than sequentially addressing requirements and solutions; products and processes; hardware, software and human factors aspects; and business case analysis of alternative product configurations or product line investments. All of this concurrency is synchronized and stabilized by having the development team collaborate in producing not only artifacts, but also evidence of their combined feasibility. This evidence is then assessed at the various stakeholder commitment decision milestones by independent experts, and any shortfalls in evidence are considered as uncertainties or probabilities of loss, which when multiplied by the relative or absolute size of the prospective loss, becomes its level of Risk Exposure. Any such significant risks should then be addressed by a risk mitigation plan.

The stakeholders then consider the risks and risk mitigation plans, and decide on a course of action. If the risks are acceptable and will covered by risk mitigation plans, the project would proceed into the next spiral. If the risks were high but addressable, the project would remain in the current spiral until the risks are resolved (e.g., working out safety cases for a safety-critical system, or producing acceptable versions of missing risk mitigation plans). If the risks are negligible (e.g., finding at the end of the Exploration spiral that the solution can be easily produced via an already-owned COTS package which has been successfully used to produce more complex applications), there would be no need to perform a Valuation and a Foundations spiral, and the project could go straight into Development.

If the risk is too high and unaddressable (e.g., the market window for such a product has already closed), the project should be terminated or rescoped, perhaps to address a different market sector whose market window is clearly sufficiently open. This outcome is shown by the dotted line “going into the third dimension” in the Risk-Based Decisions figure at the lower left of Figure 4-19, but is not visible for simplicity on the numbered circles in the larger spiral diagram.

The Development spirals after the first Development Commitment Review follow the three-team incremental development approach for achieving both agility and assurance shown in Figure 4-4 and discussed in Section 4.3.2.

Other Views of the Incremental Commitment Spiral Model (ICSM)

Figure 4-20 presents an updated view of the ICSM life cycle process recommended in the National Research Council “Human-System Integration in the System Development Process” study (Pew and Mavor 2007). It was called the Incremental Commitment Model (ICM) in the study. The ICSM builds on the strengths of current process models: early verification and validation concepts in the V-model, concurrency concepts in the Concurrent Engineering model, lighter-weight concepts in the Agile and Lean models, risk-driven concepts in the spiral model, the phases and anchor points in the Rational Unified Process (RUP) (Kruchten 1999; Boehm 1996), and recent extensions of the spiral model to address SoS capability acquisition (Boehm and Lane 2007).

The ICSM builds on the strengths of other process models: early verification and validation concepts in the V-model, concurrent hardware-software-human factors engineering from soft systems approaches (Warfield 1976, Checkland 1981) , lighter-weight concepts in the Agile, Lean, and Kanban models (Beck 1999, Schwaber and Beedle 2002, Goldratt 1984, Womack and Jones 1996, Poppendieck 2003, Anderson 2010), automated process programming (Osterweil 1987), value-based processes (Baldwin-Clark 2000, Biffl et al. 2005, Gilb 2005, Boehm and Jain 2007), continuous interacting processes (Forrester 1961, Madachy 2008, Hitchins 2010), complex adaptive systems (Dorner 1996, Holland 1998), and recent extensions of the spiral model to address SoS capability acquisition (Boehm and Lane 2007).

In comparison to the software-intensive RUP (the closest widely-used predecessor to the ICM), the ICM also addresses hardware and human factors integration. It extends the RUP phases to cover the full system life cycle: an Exploration phase precedes the RUP Inception phase, which is refocused on valuation and investment analysis. The RUP Elaboration phase is refocused on Foundations (a term based on the (Rechtin 1991 and Rechtin-Maier 1997) approach to Systems Architecting, describing concurrent development of requirements, architecture, and plans as the essential foundations for committing to develop and operate a new system), to which it adds feasibility evidence as a first-class deliverable. The RUP Construction and Transition phases are combined into Development; and an additional Operations phase combines operations, production, maintenance, and phase-out. Also, the names of the milestones are changed to emphasize that their objectives are to ensure stakeholder commitment to proceed to the next level of resource expenditure based on a thorough feasibility and risk analysis, and not just on the existence of a set of system requirements and a set of architecture diagrams. Thus, the RUP Life Cycle Objectives (LCO) milestone is called the Foundations Commitment Review (FCR) in the ICM and the RUP Life Cycle Architecture (LCA) milestone is called the Development Commitment Review (DCR).

In comparison to the stages and phases in ISO/IEC 15288 and 24748, the general ICSM has only two stages. Stage I comprises Incremental Definition, which has three sequential phases: Exploration, Valuation, and Foundations. Stage II comprises Incremental Development, Operations, and Production, in which these three activities are performed concurrently for successive increments, rather than sequentially for a single increment as shown for ISO/IEC 15288 and 24748 in Table 4-1. As seen in the right column of Figure 4-19, as Increment 2 is undergoing Development, Increment 1 is undergoing concurrent Operations (including Utilization and Support) and Production (and perhaps selective Retirement), while a concurrent agile team is handling unforeseen change traffic and rebaselining the specifications and plans for execution in Increment 3, as depicted in Figure 4-4.

Figure 4-20. Phased View of the Generic Incremental Commitment Spiral Model Process (Pew and Mavor 2007 Fig 2-1)

The top row of Activities in Figure 4-20 indicates that a number of system aspects are being concurrently engineered at an increasing level of understanding, definition, and development. The most significant of these aspects are shown in Figure 4-21, an extension of a similar “hump diagram” view of concurrently engineered software activities developed as part of the RUP [Kruchten 1999].

Figure 4-21. ICSM Activity Categories and Level of Effort (Pew and Mavor 2007 Fig 2-3)

As with the RUP version, it should be emphasized that the magnitude and shape of the levels of effort will be risk-driven and likely to vary from project to project. In particular, they are likely to have mini risk/opportunity-driven peaks and valleys, rather than the smooth curves shown for simplicity in Figure 4-21. The main intent of this view is to emphasize the necessary concurrency of the primary success-critical activities shown as rows in Figure 4-21. Thus, in interpreting the Exploration column, although system scoping is the primary objective of the Exploration phase, doing it well involves a considerable amount of activity in understanding needs, envisioning opportunities, identifying and reconciling stakeholder goals and objectives, architecting solutions, life cycle planning, evaluating alternatives, and negotiating stakeholder commitments.

For example, if one were exploring the initial scoping of a new medical device product line, one would not just interview a number of stakeholders and compile a list of their expressed needs into a requirements specification. One would also envision and explore opportunities for using alternative technologies, perhaps via competitive prototyping. In the area of understanding needs, one would determine relevant key performance parameters, scenarios, and evaluation criteria for evaluating the prototypers’ results. And via the prototypes, one would explore alternative architectural concepts for developing, producing, and evolving the medical device product line; evaluate their relative feasibility, benefits, and risks for stakeholders to review; and if the risks and rewards are acceptable to the stakeholders, to negotiate commitments of further resources to proceed into a Valuation phase with a clearer understanding of what level of capabilities would be worth exploring as downstream requirements.

Figure 4-21 indicates that a great deal of concurrent activity occurs within and across the various ICM phases, all of which needs to be synchronized and stabilized (a best-practice term taken from Microsoft Secrets (Cusumano and Selby 1996) to keep the project under control. To make this concurrency work, the evidence-based anchor point milestone reviews are used to synchronize, stabilize, and risk-assess the ensemble of artifacts at the end of each phase. Each of these anchor point milestone reviews, labeled at the top of Figure 4-20, is focused on developer-produced and expert-reviewed evidence, instead of individual PowerPoint charts and Unified Modeling Language (UML) diagrams with associated assertions and assumptions, to help the key stakeholders determine the next level of commitment.

The review processes and use of independent experts are based on the highly successful AT&T Architecture Review Board procedures described in (Maranzano et al. 2005). Figure 4-22 shows the content of the Feasibility Evidence Description. Showing feasibility of the concurrently-developed elements helps synchronize and stabilize the concurrent activities.

Figure 4-22 Feasibility Evidence Description Content (Pew and Mavor 2007 Box 2-2)

The Operations Commitment Review (OCR) is different, in that it addresses the often much higher operational risks of fielding an inadequate system. In general, stakeholders will experience a factor of two-to-ten increase in commitment level in going through the sequence of ECR to DCR milestones, but the increase in going from DCR to OCR can be much higher. These commitment levels are based on typical cost profiles across the various stages of the acquisition life cycle.

Underlying ICSM Principles

At least as important as the diagrams depicting the ICSM views are its four underlying principles. If a project just follows the diagrams without following the principles (as often happened with the original spiral model), the project will have a serious risk of failure. The four principles are:

1. Stakeholder value-based system definition and evolution. If a project fails to include success-critical stakeholders such as end-users, maintainers, or suppliers, these stakeholders will frequently feel little commitment to the project and will either underperform or refuse to use the results.
2. Incremental commitment and accountability. If success-critical stakeholders are not accountable for their commitments, they are likely to be drawn away to other pursuits when they are most needed.
3. Concurrent system and software definition and development. 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 cut off the best options for project success.
4. Evidence and risk-based decisionmaking. If key decisions are made based on assertions, vendor literature, or meeting an arbitrary schedule without access to evidence of feasibility, the project is building up uncertainties and risks. And in the words of Tom Gilb, “If you do not actively attack the risks, the risks will actively attack you.”

Model Experience to Date

During the National Research Council Human-Systems Integration study, it was found that the ICSM processes and principles corresponded well with best commercial practices. A good example documented in Part 7 of the SEBoK the study showed its application to a highly successful commercial medical infusion pump development (Pew and Mavor 2007, Chapter 5). A counterpart well-documented successful government-acquisition project using its principles was the CCPDS-R project (Royce 1998, Appendix D).

A further source of successful projects that have applied the ICSM principles is the annual series of Top-5 software-intensive systems projects published in CrossTalk (CrossTalk 2002-2005). Tailored use of the ICSM on the software portion of the ultralarge Future Combat Systems program enabled the sponsors to much better identify and deal with the software-intensive program risks and identify improved courses of action (Crosson and Boehm 2009). On an annual series of small USC e-services projects used to test and evolve the ICSM since 1996, 92% of the projects have produced client-satisfactory results on a fixed schedule (e.g., Boehm et al. 1998).

A word of caution is that experiences to date indicate that the three teams’ activities during evolutionary development are not as neatly orthogonal as they look in Figure 4-4. Feedback on development shortfalls from the V&V team either requires a response from the development team (early fixes will be less disruptive and expensive than later fixes), or deferral to a later increment, adding work and coordination by the agile systems engineering team. The agile team’s analyses and prototypes addressing how to accommodate changes and deferred capabilities need to draw on the experience and expertise of the plan-driven development team, requiring some additional development team resources and calendar time. Additional challenges arise if different versions of each increment are going to be deployed in different ways into different environments. The model has sufficient degrees of freedom to address such challenges, but they need to be planned for within the project’s schedules and budgets.

Primarily Interpersonal and Unconstrained Processes: Scrum and Agile

Agile methods have emerged over the past decade as a more cost-effective way to develop certain classes of software, sparking interest in them as a possible way to accelerate systems engineering as well. The primary agile success factors have been its reliance on tacit interpersonal knowledge rather than explicit documented knowledge to track the project’s status and plans; and its focus on small, short increments of development. There are several agile methods available; the most widely applied are eXtreme Programming (XP)(Beck 1999), a set of a dozen recommended practices, and Scrum (Schwaber-Beedle 2002), the most unconstrained agile method, with only four recommended practices.

Figure 4-23 shows an example of Scrum as an agile process flow. (Note: The term “Scrum” is taken from the game of rugby, where one cross-functional team “tries to go the distance as a unit, passing the ball back and forth.”) As with most other agile methods, Scrum uses the Evolutionary Sequential process shown in Figure 4-2 and described in Section 2.3.1, in which systems capabilities are developed in short periods, usually around 30 days. The project then re-prioritizes its backlog of desired features and determines how many features the team (usually 10 people or less) can develop in the next 30 days. Clearly, this approach will not work for a product with an irreducibile set of initial features that take longer than 30 days to develop: usually the hardware portion, but often also the initial set of core software capabilities needed for the system to operate. But it has often worked for incrementally developing the value-adding software features that use the core capabilities.

As shown in Figure 4-23, once the features to be developed for the current Scrum have been expanded (usually in the form of informal stories) and allocated to the team members, the team establishes a daily rhythm of starting with a short meeting at which each team member does about a one-minute summary of progress since the last Scrum meeting, potential obstacles, and plans for the upcoming day. Any problems or concerns are discussed, and either resolved or established as action items for the concerned team members. Sometimes a problem is serious enough that it requires some team members to take a few days finding a solution. If so, the team and the customer will use the feature priorities to determine which features to drop in order to stay on the 30-day schedule.

These are essentially all of the practices required by Scrum. The team can decide to use other agile methods, such as pair development (one person developing, the other surfacing concerns), test-driven continuous integration (test cases developed early in place of requirements, and re-run each time new features are checked in), and continuous customer collocation. These serve not only to quickly discover defects or misunderstandings, but also to build up shared tacit interpersonal knowledge about the system being developed, so that the team can get along with a minimum of documentation. This informality means that defects will get delivered, but the 30-day cycle time means that they will generally get fixed in the next 30-day sprint. This is acceptable for many applications, but a serious risk for safety-critical or security-critical systems.

Figure 4-23. Example Agile process flow: Scrum (Boehm and Turner 2004; ControlChaos.com)

An analysis in (Boehm and Turner 2004) found five critical factors distinguishing the “home grounds” where agile methods or traditional plan-driven methods have worked well. These are:

• 1. Project size. Pure agile methods work well for teams up to 10 or perhaps 15 members, but run into problems in maintaining shared tacit knowledge in larger teams.
• 2. Project criticality. For projects where defects cause a loss of comfort or of discretionary resources, the agile promise to fix defects in the next 30-day sprint is acceptable. But where defects could cause major financial losses or loss of life, this promise is unacceptable.
• 3. Personnel capability. Agile methods require a rich mix of agile personnel who can keep and update a good deal of tacit knowledge in their heads. Traditional plan-driven projects can use a rich mix of high-capability people up front to work the high-risk items and organize the project so that much of the work can be done by less-capable or junior people.
• 4. Requirements volatility. A high volume of change traffic will slow down a plan-driven team significantly in keeping all of its documentation up to date and consistent. An agile team operating on tacit knowledge will not have such a slowdown.
• 5. Organizational culture. People tend to gravitate to organizations whose culture fits their preferences. Planning-oriented people will feel comfortable and empowered if there are policies and guidelines defining how to succeed. Agile-oriented people will feel comfortable and empowered if there is a minimum of such policies and guidelines. Trying to introduce agile methods in a plan-driven culture will be very difficult, and vice versa.

However, many projects will fit somewhere in between the pure agile and pure plan-driven home grounds. Some progress is being made to develop hybrid methods. One such, an Architected Agile process, is described next.

Architected Agile Methods

Over the last decade, several organizations have been able to scale up agile methods by using two layers of 10-person Scrum teams This involves, among other things, having each Scrum team’s daily meeting followed up by a daily meeting of the Scrum team leaders, and by up-front investments in an evolving system architecture. We have analyzed several of these projects and organizational initiatives are analyzed in (Boehm et al. 2010); a successful example and a partial counterexample are provided next.

The successful example is provided by a US medical services company with over 1000 software developers in the US, two European countries, and India. The corporation was on the brink of failure, due largely to its slow, error-prone, and incompatible software applications and processes. A senior internal technical manager, expert in both safety-critical medical applications and agile development, was commissioned by top management to organize a corporate-wide team to transform the company’s software development approach. In particular, the team was to address agility, safety, and Federally-mandated governance and accountability practices.

Software technology and project management leaders from all of its major sites were brought together to architect a corporate information framework and develop a corporate architected-agile process approach. The resulting Scrum of Scrums approach was successfully used in a collocated pilot project to create the new information framework while maintaining continuity of service in their existing operations.

Based on the success of this pilot project, the team members returned to their sites and led similar transformational efforts. Within three years, they had almost 100 Scrum teams and 1000 software developers using compatible and coordinated architected-agile approaches. The effort involved their customers and marketers in the effort. Expectations were managed via the pilot project. The release management approach included a 2-12 week architecting Sprint Zero, a series of 3-10 one-month development Sprints, a Release Sprint, and 1-6 months of beta testing; the next release Sprint Zero overlapped the Release Sprint and beta testing. Their agile Scrum approach involved a tailored mix of eXtreme Programming (XP) and corporate practices, 6-12 person teams with dedicated team rooms, and global teams with wiki and daily virtual meeting support—working as if located next-door. Figure 4-24 shows this example of the Architected Agile approach.

Figure 4-24. Example of Architected Agile Process (Dingsoyr et al 2010 Fig 9.6)

Two of the other success stories had similar approaches. However, circumstances may require different tailorings of the architected agile approach. Another variant analyzed was an automated maintenance system that found its Scrum teams aligned with different stakeholders whose objectives diverged in ways that could not be reconciled by daily standup meetings. The project recognized this and has evolved to a more decentralized Scrum-based approach, with centrifugal tendencies monitored and resolved by an empowered Product Framework Group (PFG) consisting of the product owners and technical leads from each development team, and the project systems engineering, architecting, construction, and test leads. The PFG meets near the end of an iteration to assess progress and problems, and to steer the priorities of the upcoming iteration by writing new backlog items and reprioritizing the product backlog. A few days after the start of the next iteration, the PFG meets again to assess what was planned vs. what was needed, and to make necessary adjustments. This has been working much more successfully. It is an example of a blend of the pure Evolutionary Sequential and the Evolutionary Concurrent process models for evolutionary development presented in Section 4.3.1.

References

Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Citations

Anderson, D., 2010. Kanban, Blue Hole Press.

Baldwin, C., and K. Clark, 2000. Design Rules: The Power of Modularity, MIT Press.

Beck, K., 1999. Extreme Programming Explained, Addison Wesley.

Biffl, S., A. Aurum, B. Boehm, H. Erdogmus, P. Gruenbacher (eds.), 2005. Value-Based Software Engineering, Springer.

Boehm, B., May 1988. “A Spiral Model of Software Development,” Computer, pp. 61-72.

Boehm, B., 2006. “Some Future Trends and Implications for Systems and Software Engineering Processes”, Systems Engineering 9(1), pp. 1-19.

Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah, and R. Madachy, July 1998. “Using the WinWin Spiral Model: A Case Study,” IEEE Computer, pp. 33-44.

Boehm, B., and J. Lane, October 2007. “Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering,” CrossTalk, pp. 4-9.

Boehm, B., and R. Turner. 2004. Balancing Agility and Discipline, Addison-Wesley.

Boehm, B., J. Lane, S. Koolmanjwong, and R, Turner. 2012 (planned publication date). Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model. Addison Wesley

Checkland, P., 1981. Systems Thinking, Systems Practice, Wiley.

CrossTalk, January 2002, July 2003, July 2004, September 2005. “Top Five Quality Software Projects,” www.stsc.hill.af.mil/crosstalk

Crosson, S., and B. Boehm, April 2009. “Adjusting Software Life cycle Anchorpoints: Lessons Learned in a System of Systems Context,” Proceedings, SSTC 2009.

Cusumano, M. and R. Selby, 1996. Microsoft Secrets. Harper Collins.

Dingsoyr, T., T. Dyba. and N. Moe (eds.). 2010 "Agile Software Development: Current Research and Future Directions”; Chapter in the book by Boehm, J. Lane, S. Koolmanjwong, and R, Turner, "Architected Agile Solutions for Software-Reliant Systems," Springer.

Dorner, D., 1996. The Logic of Failure, Basic Books.

Faisandier, A. 2011. Engineering and Architecting Multidisciplinary Systems (to be published).

Forsberg, K., H. Mooz, H. Cotterman. 2005. Visualizing Project Management. 3rd Ed., J. Wiley & Sons.

Forsberg, K. 1995. “’If I Could Do That, Then I Could…’ System Engineering in a Research and Development Environment,” Proceedings of Fifth NCOSE Summer Symposium.

Forsberg, K. 2010. “Projects Don’t Begin With Requirements.” IEEE Systems Conf. San Diego, CA. April.

Gilb, T., 2005. Competitive Engineering, Elsevier Butterworth Heinemann.

Goldratt, E., 1984. The Goal, North River Press.

Hitchins, D., 2007. Systems Engineering: A 21st Century Systems Methodology, Wiley.

Holland, J., 1998. Emergence, Perseus Books.

INCOSE. 2011. Systems Engineering Handbook, version 3.2.1. INCOSE-TP-2003-002-03.2.1.

ISO/IEC 15288:2008. Systems and software engineering – System life cycle processes.

ISO/IEC 19760:2003. A guide for application of ISO/IEC 15288 System Life Cycle Processes.

ISO/IEC 24748-1:2010. Systems and software engineering, Part 1: Guide for life cycle management

Kruchten, P., 1999. The Rational Unified Process. Addison Wesley.

Landis, T. R. 2010. Lockheed Blackbird Family (A-12, YF-12, D-21/M-21 & SR-71). Specialty Press.

Lawson, Harold. 2010. A Journey Through the Systems Landscape, College Publications, Kings College, UK.

Madachy, R., 2008. Software Process Dynamics, Wiley.

Maranzano, J., et al., March/April 2005, “Architecture reviews: Practice and experience,” IEEE Software, pp. 34-43.

National Research Council of the National Academies (USA). 2008. Pre-Milestone A and Early-Phase Systems Engineering, Washington, D.C.: The National Academies Press. http://www.nap.edu

Osterweil, L. 1987. “Software Processes are Software Too,” Proceedings, ICSE 9.

Pew, R., and A. Mavor (eds.) 2007. Human-System Integration in the System Development Process: A New Look, The National Academies Press. http://www.nap.edu

Poppendeick, M. and T., 2003. Lean Software Development: an Agile Toolkit, Addison Wesley.

“Principles behind the Agile Manifesto,” 15 Dec 2009, http://www.agilemanifesto.org/principles.html

Rechtin, E. 1991. System Architecting.: Creating and Building Complex Systems. Prentice-Hall.

Rechtin, E., and M. Maier, 1997. The Art of System Architecting.

Royce, W. E. 1998. Software Project Management. Addison Wesley.

Schwaber, K. and M. Beedle, 2002. Agile Software Development with Scrum, Prentice Hall.

Washington Post, February 11, 2009, “NASA’s Ambitious New Mars Rover Is Too Costly, Critics Say.”

Warfield, J., 1976. Societal Systems: Planning, Policy, and Complexity, Wiley.

Womack, J., and D. Jones, 1996. Lean Thinking, Simon and Schuster.

Primary References

Boehm, B., J. Lane, S. Koolmanojwong, and R, Turner. 2012 (planned publication date). Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model. Addison Wesley.

Boehm, B., and R. Turner. 2004. Balancing Agility and Discipline, Addison-Wesley.

Fairley, R. 2009. Managing and Leading Software Projects. J. Wiley & Sons.

Forsberg, K., H. Mooz, H. Cotterman. 2005.Visualizing Project Management. 3rd Ed., J. Wiley & Sons.

Faisandier, A. 2011. Engineering and Architecting Multidisciplinary Systems (to be published).

INCOSE. 2011. Systems Engineering Handbook, version 3.2.1. INCOSE-TP-2003-002-03.2.1.

Lawson, Harold. 2010. A Journey Through the Systems Landscape. College Publications, Kings College, UK.

Pew, R., and A. Mavor (eds.) 2007. Human-System Integration in the System Development Process: A New Look. The National Academies Press. http://www.nap.edu

Additional References

Beck, K., 1999. Extreme Programming Explained, Addison Wesley

Boehm, B., May 1988. “A Spiral Model of Software Development,” Computer, pp. 61-72

Boehm, B., 2006. “Some Future Trends and Implications for Systems and Software Engineering Processes”, Systems Engineering 9(1), pp. 1-19

Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah, and R. Madachy, July 1998. “Using the WinWin Spiral Model: A Case Study,” IEEE Computer, pp. 33-44

Boehm, B., and J. Lane, October 2007. ‘Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering,” CrossTalk, pp. 4-9

CrossTalk, January 2002, July 2003, July 2004, September 2005. “Top Five Quality Software Projects,” www.stsc.hill.af.mil/crosstalk

Crosson, S., and B. Boehm, April 2009. “ Adjusting Software Life cycle Anchorpoints: Lessons Learned in a System of Systems Context,” Proceedings, SSTC 2009

Cusumano, M. and R. Selby, 1996. Microsoft Secrets. Harper Collins

Dingsoyr, T., T. Dyba. and N. Moe (eds.). 2010 "Agile Software Development: Current Research and Future Directions”; Chapter in the book by Boehm, J. Lane, S. Koolmanjwong, and R, Turner, "Architected Agile Solutions for Software-Reliant Systems," Springer.

Forsberg, K. 1995. “’If I Could Do That, Then I Could…’ System Engineering in a Research and Development Environment,” Proceedings of Fifth NCOSE Summer Symposium.

Forsberg, K. 2010. “Projects Don’t Begin With Requirements.” IEEE Systems Conf. San Diego, CA. April.

ISO/IEC 15288:2008 Systems and software engineering – System life cycle processes

ISO/IEC 19760:2003 – A guide for application of ISO/IEC 15288 System Life Cycle Processes.

Kruchten, P., 1999. The Rational Unified Process. Addison Wesley.

Maranzano, J., et al., March/April 2005, “Architecture reviews: Practice and experience,” IEEE Software, pp. 34-43

National Research Council of the National Academies (USA). 2008. Pre-Milestone A and Early-Phase Systems Engineering, Washington, D.C.: The National Academies Press. http://www.nap.edu

Principles behind the Agile Manifesto, 15 Dec 2009, http://www.agilemanifesto.org/principles.html

Rechtin, E. 1990. System Architecting.: Creating and Building Complex Systems. Prentice-Hall.

Royce, W. E. 1998. Software Project Management. Addison Wesley

---

Article Discussion

[Go to discussion page]

<- Previous Article | Parent Article | Next Article ->