by Jim Moore, The MITRE Corporation, moorej@acm.org
This note describes ISO 12207, a high-level standard addressing all processes of the software life cycle. It also traces the evolution of life-cycle standards, differentiates the efforts of IEEE, ISO, and other organizations, and discusses the significance of 12207 to international software acquisition.
The Institute of Electrical and Electronics Engineers (IEEE) is now voting on whether the U.S. should adopt International Organization for Standardization (ISO) 12207, which specifies software life-cycle processes. Because of the burgeoning of standards over the last few years, it is important that software engineers understand what 12207 provides and how it relates to other standards dealing with life-cycle processes.
ISO 12207 offers a framework for software life-cycle processes from concept through retirement. It is especially suitable for acquisitions because it recognizes the distinct roles of acquirer and supplier. In fact, the standard is intended for two-party use where an agreement or contract defines the development, maintenance, or operation of a software system. It is not applicable to the purchase of commercial-off-the-shelf (COTS) software products.
In most cases, 12207 uses conventional standards language: "shall" to indicate mandatory provisions, "should" for recommendations, and "may" for permissible actions. Since the standard applies to both acquirer and supplier, one might expect it to place mandatory requirements upon both parties. Its language, however, makes a subtle distinction: those provisions that apply to the acquirer typically use the verb "will," denoting a "declaration of purpose or intent by one party," not a requirement.
ISO 12207 provides a structure of processes using mutually accepted terminology, rather than dictating a particular life-cycle model or software development method. Since it is a relatively high-level document, 12207 does not specify the details of how to perform the activities and tasks comprising the processes. Nor does it prescribe the name, format, or content of documentation. Therefore, organizations seeking to apply 12207 may want to use additional standards or procedures that specify those details.
The ISO is currently developing such guides and assessment procedures to complement 12207; the IEEE Software Engineering Standards Committee is also planning to reorganize its collection of standards to complement 12207.
ISO 12207 describes five "primary processes"-- acquisition, supply, development, maintenance, and operation. It divides the five processes into "activities," and the activities into "tasks," while placing requirements upon their execution. It also specifies eight "supporting processes"--documentation, configuration management, quality assurance, verification, validation, joint review, audit, and problem resolution--as well as four "organiza-tional processes"--management, infrastructure, improvement, and training.
The ISO standard intends for organizations to tailor these seventeen processes to fit the scope of their particular projects by deleting all inapplicable activities; and it defines 12207 compliance as the performance of those processes, activities, and tasks selected by tailoring.
The Department of Defense is a pioneer in defining software development life cycles. In the last few years, the DoD undertook an effort to unify DoD-STD-2167A (used by the mission-critical community) and MIL-STD-7935 (used by the information systems community) to create one life-cycle standard--MIL-STD-498.
Just as 498 was nearing approval, however, the DoD shifted its acquisition policies toward more reliance on commercial standards. As a result, 498 was approved for an interim period of only two years. The IEEE and the Electronics Industry Association (EIA) then initiated a joint project to create a commercial replacement for 498. This effort produced one standard with two names: an IEEE Trial Use Standard 1498 and an EIA Interim Standard 640. Since both the IEEE and the EIA produced the standard, the American National Standards Institute (ANSI) designated the document as ANSI Joint Standard 016.
Meanwhile, ISO 12207 was also underway. Whereas J-016 defined only the development process, 12207 described four additional primary processes, as discussed above. Furthermore, in 1992, the IEEE had completed its own life-cycle process standard, 1074, providing detailed descriptions of development and maintenance activities as well as their connections. In principle, one could use 1074 to construct processes that would comply with the requirements of either J-016 or 12207. The challenge now is to "harmonize" or otherwise converge these three different documents. Two current efforts will accomplish this goal.
First, the IEEE is balloting on the U.S. Adoption of ISO 12207. A yes vote would provide a common basis of understanding for organizations who wish to acquire software across international boundaries. Some parties contend that 12207 is essential if the U.S. is to play a role in worldwide software acquisitions.
Second, the IEEE and the EIA are collaborating on another joint standard--the "U.S. Industrial Implementation" of 12207--which will be structured around the process framework of 12207 but add the "technical goodness" of J-016 to the development process. This standard will be useful for defense, commercial, and international acquisitions.
The new joint standard is scheduled for completion in December 1996. The results of this effort will then guide the planned revisions to 12207 and 1074, creating a harmonized pair of standards: the former specifying requirements for the software life cycle and the latter specifying how to construct a life-cycle model.