System Lifecycle Process Models: Vee

Introductory Paragraph

Software lifecycle models

The lifecycle 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.

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 this article and the aspects of software development that are emphasized by those models.

Table 1. Primary emphases of three iterative software development models

Incremental-build: Iterative implementation-verification-validation-demonstration cycles

Agile: Iterative evolution of requirements and code

Spiral: Iterative risk-based analysis of alternative approaches and evaluation of outcomes

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. 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.

Each of these models is briefly described.

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. Partitions are decomposed into incremental build units of, typically, one calendar-week each. One-week 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.

Table 2. Some partitioning criteria for incremental builds

Kind of system Partitioning criteria Application package Priority of features Safety-critical systems Safety features first; prioritized others follow User-intensive systems User interface first; prioritized others follow System software Kernel first; prioritized utilities follow

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.

Insert Figure 1 here

Figure 1. Incremental build-verify-validate-demonstrate cycles

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 process works well when each team consists of 2 to 5 developers plus a team leader (who is also a technical contributor). Team members may work as individuals, or perhaps in pairs. Each individual or pair may produce unofficial builds on a daily basis using a copy of the current official version as a test bed. An official build that integrates, verifies, validates, and demonstrates progress made by all developer teams is typically produced on a weekly or bi-weekly basis.

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.

Agile development models

Agile development models are evolutionary, in that the requirements evolve during implementation, Agile development is best suited to software projects that are conducted with the involvement of a knowledgeable customer/user who has a clear understanding of the needs to be satisfied by the system that is being built. There are several variations on the agile theme, but most agile-process models emphasize the following aspects [Agile]:

1. continuous, on-going involvement of a knowledgeable customer/user;
2. development of test cases and test scenarios before implementing the next version of the product;
3. implementation and testing of the resulting software;
4. demonstration of each version of the evolving product to the customer;
5. eliciting the next set of requirement(s) from the customer; and
6. periodic delivery into the operational environment, if desired.

The customer’s roles are to provide the “story line” that determines the requirements, to review demonstrated capabilities, and to specify the next chapter of the story for the next iteration. An iterative process model for agile development is depicted in Figure 2.

Insert Figure 2 here

Figure 2. Depicting the Agile development process

As indicated in Figure 2, there is no explicit design step and no design documentation in an Agile development process. This is compensated for by a design “metaphor” that is shared among the developers. A design metaphor might be based on an architectural style; for example, the system may be based on a layered style (e.g., a 3-tier architecture) or a separation-of-concerns architecture (e.g., a Model-View-Control architecture). Lack of explicit design documentation requires that the developers be highly skilled; otherwise “agile” becomes a euphemism “code it-test it-fix it.”

In some versions of the agile process, the duration of an iterative cycle is one day; in other versions it is extend to one month. However, the software developers always have a running version of the software to which they add capabilities on a daily basis. Some agile models use pair programming, in which pairs of developers share one computer terminal and develop software together.

Experience with agile models indicates that the resulting products are rated low in defect levels and high in user satisfaction. However, user satisfaction is critically dependent on having a knowledgeable and prototypical user as the customer in the iterative development loop. Some critics have raised the concern that an agile process may result in a functionally structured product that, lacking design documentation, will be hard to modify in the future. This problem can be minimized if the software developers share a common design metaphor and use standard coding and code documentation practices.

Agile development seems to be best suited to small projects that develop applications software . Small projects because there is no partitioning of an a priori design or allocation of requirements to subsystems, which is necessary if members of large project teams are to work concurrently. Agile processes are appropriate for applications projects because user-stories provided by the customer and design metaphors used by developers are best suited to end-item software that will be used by people in pursuing their work activities or recreational pastimes, as opposed to complex embedded and mission-critical systems.

Development models other than Agile are sometime characterized as “plan-driven,” because of the intentional lack of emphasis on written requirements specifications, design documentation, and V&V plans in the agile models. The text Balancing Agility and Discipline by Boehm and Turner contrasts plan-driven and agile approaches to software development and presents a middle-ground approach to achieving a balance than incorporates aspects of both approaches, based on the particular situation [BOEHM04].

The Spiral Model

Originally, the Spiral model was presented as a software development model [Boehm88]. In recent times, it has come to be regarded as a meta-model (i.e., a development process framework) from which various kinds of iterative models can be derived. As illustrated in Figure 3, each cycle of a Spiral process involves:

1. analyzing objectives, identifying alternative approaches, and establishing constraints for the next process cycle;
2. planning the next cycle by evaluating alternative approaches, identifying the risk factors of each approach, and selecting an approach;
3. implementing the selected alternative; and
4. evaluating the outcome and deciding what to do next.

Insert Figure 3 here

Figure 3. The Spiral model

What-to-do-next depends on the particular instantiation of the Spiral meta-model. In an Incremental-build Spiral model the next cycle involves building and integrating the next set of features. The duration of a Spiral cycle might range from one day for an Agile Spiral to one month for an Evolutionary Spiral.

Although systematic evaluation of risk is a major theme of Spiral models, it should not be inferred that the lowest risk approach should always be chosen. High-risk endeavors, if successful, often result in high payoffs; a spin-off parallel investigation of a high risk approach might be pursued while implementing a lower risk alternative. The evaluation step would then consider both outcomes, which provides information for the next cycle.

The concepts of the Spiral model can be integrated into all iterative process models; the Spiral model adds the dimensions of systematically generating alternative approaches for the next iteration, evaluating the risk of each, selecting an alternative for implementation, and evaluating the outcome.

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 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.

Lifecycle 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.

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

List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Primary References

All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the reference title only (title). Please do not include version numbers in the links.

Additional References

All additional references should be listed in alphabetical order.

---

Article Discussion

[Go to discussion page]

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