IM Engineer Study Notes
← Back to list
SW Engineering & Management
#ISO/IEC 12207#소프트웨어 생명주기#프로세스#SDLC#ISO/IEC 15288
Last updated · 2026-11-07

ISO/IEC 12207 (Software Life Cycle Processes)

1. Overview

Definition: ISO/IEC 12207 is an international standard that defines the activities spanning the entire software life cycle — acquisition, supply, development, operation, maintenance, and disposal — in the common unit of a "Process." It is a Process Reference Model that specifies "what must be done," so that software work can be communicated, contracted, and assessed consistently between organizations and between people.

Behind the emergence of ISO/IEC 12207 lay the "formlessness of process" that the software industry suffered through in the 1980s–90s. At the time, acquirers and suppliers each proceeded with development using their own terms and procedures, so at contract time endless disputes arose over "where does development begin and end," "who is responsible for verification and validation," and "what is the scope of maintenance." Even the single word "design" meant something different from organization to organization, blurring the boundaries of deliverables and responsibility, which in turn led to schedule delays, quality degradation, and litigation. To resolve this confusion, ISO and IEC defined the activities of the software life cycle as a set of standardized processes, enacting ISO/IEC 12207:1995 as the first international standard in July 1995.

The fundamental reason this standard is needed lies in securing a "common framework" (common language) for software work. When an acquirer and a supplier reference the same process definitions, merely stating in the contract that "this project follows the supply and development processes of ISO/IEC 12207" settles a baseline agreement on scope, responsibility, and deliverables. Moreover, once processes are explicitly defined, whether those processes are "performed properly" can be objectively assessed and improved — and this is precisely the foundation of process assessment/improvement models such as SPICE (ISO/IEC 15504, now the ISO/IEC 33000 family) and CMMI, discussed later. In other words, 12207 does not by itself guarantee quality, but as the reference point that makes quality "measurable and improvable," it stands at the center of the body of software engineering standards.

ISO/IEC 12207's key features can be summarized as follows. First, it covers the entire life cycle, addressing not only development but also operation, maintenance, and disposal. Second, it is process-oriented, so it does not force any particular development methodology (waterfall, agile, etc.); it specifies only "what" and leaves "how" to the organization's choice. Third, it presupposes Tailoring capability, so from small projects to large systems, only the needed processes can be selected and adjusted for application. Fourth, it aims for alignment with the system life cycle standard (ISO/IEC 15288), reflecting the reality that software is integrated as a component of a larger system. These four features make 12207 not a mere procedure manual but a foundational standard for inter-organizational collaboration and process improvement.

2. The Overall Structure of Life Cycle Processes

ISO/IEC 12207 views the software life cycle as a network of interrelated processes. Each process is hierarchically defined by its "Purpose," the "Outcomes" that appear when that purpose is achieved, and the "Activities" and "Tasks" that bring them about. Thanks to this structure, an organization can freely choose an implementation approach suited to its environment while understanding the intent of the process. For example, the purpose of the "Verification process" is to confirm that a work product correctly reflects its specification, and its implementation may be a code review, a static analysis tool, or formal verification.

graph TD
    A["ISO/IEC 12207 Software Life Cycle Processes"] --> B["Agreement processes: Acquisition, Supply"]
    A --> C["Organizational Project-Enabling processes"]
    A --> D["Technical Management: planning, control, risk, configuration"]
    A --> E["Technical processes: requirements, design, implementation, verification, transition, operation, maintenance, disposal"]
    B --> F["Process element: Purpose"]
    C --> F
    D --> F
    E --> F
    F --> G["Outcome"]
    G --> H["Activity"]
    H --> I["Task"]

A point to note in the above structure is that processes are woven not into a vertical hierarchy but into a horizontal cooperative relationship. Once the agreement processes set the boundaries of the contract, the organizational project-enabling processes provide the infrastructure, personnel, and quality foundation, the technical management processes control schedule and risk, and within all this the technical processes produce the actual software. These are not traversed sequentially just once; through iteration and recursion they are repeated and interact many times throughout the life cycle. The fact that requirements, design, implementation, and verification repeat on a two-week cycle in an agile sprint is also interpreted, from the 12207 viewpoint, as "iterative application of technical processes."

The practical implication of this process-network view is traceability of responsibility and deliverables. When a quality problem arises in a project, it can be traced back at the process level to whether it was a shortfall in requirements definition, an omission in the verification process, or a failure of configuration management. For example, if change control of requirements repeatedly fails in a next-generation financial system, the problem can be structurally diagnosed by checking whether 12207's "Configuration Management" and "Information Management" processes are properly defined and performed.

3. The Three Process Categories of the 1995 Original

The original ISO/IEC 12207:1995 divided life cycle processes into three categories, and this classification is still widely cited as the starting point for a textbook understanding. Each category is not a mere list but a grouping from the viewpoint of "whose responsibility the activity is."

A. Primary Life Cycle Processes

Primary processes are the core activities performed directly by the parties who actually acquire, supply, produce, and use the software; in the original they comprised five: Acquisition, Supply, Development, Operation, and Maintenance. Acquisition defines the activity by which an acquirer procures software or a service, and Supply defines the activity by which a supplier provides the product per contract, clearly separating the roles of the two contracting parties. This separation matters because a large share of software disputes stem from an ambiguous boundary between "the acquirer's responsibility to clarify requirements" and "the supplier's responsibility to implement."

The Development process is the most extensive process, spanning requirements analysis, design, implementation, integration, and testing; it is the central axis where the actual deliverables are made. The Operation process holds the activity of running the accepted software in the real environment and supporting users, and the Maintenance process holds the activity of systematically managing post-delivery changes — defect correction (corrective), adaptation to environmental change (adaptive), feature enhancement (perfective), and failure prevention (preventive). Considering that 60–70% of software total cost of ownership (TCO) arises in the maintenance phase, 12207's elevation of maintenance to an independent process on par with development reflects in the standard the reality that "the center of gravity of software cost lies after delivery."

B. Supporting Life Cycle Processes

Supporting processes are the auxiliary activities that underpin the quality and reliability of the primary processes; in the original, eight were defined: Documentation, Configuration Management, Quality Assurance, Verification, Validation, Joint Review, Audit, and Problem Resolution. Rather than creating value independently, these are performed "embedded" in other processes and assure quality. For instance, configuration management controls the versions and change history of work products throughout development and maintenance, making it traceable what changed, when, and why.

Here, the distinction between Verification and Validation is a core concept frequently demanded in professional-engineer answers. Verification is the activity that asks "Are we building the product right?" — it examines whether a work product accurately reflects the input specification of that stage. Validation, by contrast, is the activity that asks "Are we building the right product?" — it examines whether the final work product satisfies the user's actual needs and intent. For example, if something was implemented exactly per the requirements specification (verification passes) but was not the feature the user wanted (validation fails), this is traced to a failure in the requirements elicitation stage. Defining these two separately serves to structurally distinguish whether the cause of a quality defect is "implementation inaccuracy" or "misunderstanding of requirements."

C. Organizational Life Cycle Processes

Organizational processes are the activities that operate and improve the processes themselves at the organizational level, beyond individual projects; in the original they comprised four: Management, Infrastructure, Improvement, and Training. The Management process handles project planning, tracking, and control; the Infrastructure process handles securing the development environment, tools, and facilities; the Improvement process handles continuously assessing and improving the organization's processes; and the Training process handles securing personnel competency.

Organizational processes exist as a separate category because software quality is not sustained by the effort of individual projects alone. No matter how successful one project is, unless that experience is asset-ized into the organization's standard processes and training system, the next project again comes to depend on heroic individuals. This very "Improvement" process is the root of the "organizational maturity" that CMMI and SPICE speak of, and it makes the organization turn a virtuous cycle of defining → measuring → improving processes.

Category Processes in the original (1995) View of performing party Core character
Primary Acquisition, Supply, Development, Operation, Maintenance Performed directly by contracting parties Produces value directly
Supporting Documentation, Config. Mgmt, QA, Verification, Validation, Joint Review, Audit, Problem Resolution Embedded in primary processes Assures quality and reliability
Organizational Management, Infrastructure, Improvement, Training Operated at organizational level Asset-izes and improves processes

4. The 2017 Revision: Harmonization with ISO/IEC 15288 and Four Process Groups

As the reality deepened that software does not exist alone but operates as part of a larger system (hardware, networks, human elements), operating the software life cycle (12207) and the system life cycle (ISO/IEC 15288) separately produced redundancy and inconsistency. Accordingly, the 2008 revision began to align the structures of the two standards, and in 2017 ISO/IEC/IEEE 12207:2017 was released as the culmination of harmonization, almost matching the terminology and process structure with 15288:2015. This enabled systems engineers and software engineers to collaborate on a single, consistent process framework.

The 2017 revision reorganized processes into four groups. This recomposed the original's "Primary/Supporting/Organizational" three-way classification into a contract view (Agreement), an organization-enabling view, a project-management view, and an engineering view.

flowchart LR
    subgraph AG["Agreement processes"]
      A1["Acquisition"]
      A2["Supply"]
    end
    subgraph OP["Organizational Project-Enabling"]
      O1["Life cycle model management"]
      O2["Infrastructure, portfolio, human resource"]
      O3["Quality management, knowledge management"]
    end
    subgraph TM["Technical Management"]
      M1["Project planning, assessment, control"]
      M2["Decision, risk, configuration management"]
      M3["Information management, measurement, QA"]
    end
    subgraph TP["Technical processes"]
      P1["Requirements definition, architecture, design"]
      P2["Implementation, integration, verification, transition"]
      P3["Validation, operation, maintenance, disposal"]
    end
    AG --> OP --> TM --> TP
    TP -. feedback, iteration .-> TM

Rendering the roles of the four groups in prose: Agreement processes fix the boundaries and responsibilities of work through inter-organizational contracts (acquisition, supply). Organizational project-enabling processes are activities by which the organization creates the foundation for individual projects to succeed, such as life cycle model management, infrastructure management, portfolio management, human resource management, quality management, and knowledge management. Technical management processes contain project planning, assessment and control, decision management, risk management, configuration management, information management, measurement, and quality assurance, managing engineering so it proceeds in a controlled state. Technical processes consist of roughly 14 engineering activities — from business/mission analysis through stakeholder needs definition, system/software requirements definition, architecture definition, design, implementation, integration, verification, transition, validation, operation, maintenance, to disposal — forming the center that actually produces the product.

The transition from the original's three-way classification to 2017's four groups embodies a design intent of separation of viewpoints, not mere rearrangement. In particular, dividing management activities into "a foundation the organization provides (organizational project-enabling)" and "control inside the project (technical management)" serves to clarify the governance structure by distinguishing organizational-level responsibility from project-level responsibility. For instance, "quality" is split into organization-level Quality Management and project-level Quality Assurance, so that the former establishes quality policy and standards while the latter assures that a specific project adheres to them — a division of roles.

5. Process Tailoring and Application

Applying all of ISO/IEC 12207's processes in full to every project is unrealistic, and the standard itself does not require it. The standard defines Tailoring as a formal activity, permitting processes to be selected, adjusted, or deleted to fit the project's scale, risk, contract nature, and life cycle model. Tailoring matters because applying defense-system-grade heavy configuration-management and audit procedures as-is to a small web service development only increases bureaucracy and cost without improving quality.

To give a practical example of tailoring: in a startup's two-week sprint-based mobile app development, "Joint Review" can be replaced with daily stand-ups and sprint reviews instead of formal document reviews, and "Documentation" can be minimized so that code and automated tests substitute for documents. By contrast, in safety-critical areas such as nuclear power and aviation, the verification, validation, audit, and configuration-management processes are instead reinforced, adding a traceability matrix and independent verification (IV&V). That the same standard can apply to projects at both extremes is because 12207 specifies only "what" and delegates "how strictly" to tailoring.

This tailoring concept is especially important in public software projects. When defining the life cycle processes and deliverables list to apply in a statement of work or request for proposal (RFP) for a domestic public SI project, referencing 12207's process framework makes it possible to adjust deliverable demands that are excessive or insufficient relative to the project scale. In other words, tailoring is the core device of a pragmatism of "keeping the standard while fitting reality," and documenting tailoring decisions and their rationale provides a balance point for dispute prevention and quality assurance.

Gauging the quantitative effect of tailoring: in a public project that uniformly demanded dozens of deliverables, removing documents that do not fit the project's character and keeping only the core deliverables can save a substantial portion of the effort spent on formal document creation without affecting traceability. However, which processes to delete must be judged on a risk basis; deleting processes that catch defects early — such as verification, configuration management, and problem resolution — for the sake of cost reduction can produce the adverse effect of later rework costs exceeding the savings. Therefore tailoring should be approached from the viewpoint of "what risk can we accept" rather than "what can we cut," and this judgment itself is a core competency of a professional engineer.

6. Comparison and Linkage: 12207 · 15288 · CMMI · SPICE

To understand ISO/IEC 12207 accurately, one must also view its relationship with adjacent standards and models. The key is the division of labor whereby 12207 and 15288 are reference models that "define processes," while CMMI and SPICE (ISO/IEC 15504, now the 33000 family) are models that assess and improve "how well" those processes are performed. By analogy, 12207 is "a standard textbook stating what must be done," and SPICE/CMMI are "the exam and report card grading how well that textbook has been mastered."

This difference arises because the standards' purposes differ. Since 12207's purpose is to provide a common basis for inter-organizational communication and contracts, it concentrates on "definition," whereas SPICE is an assessment framework that appraises the performance level of those defined processes at six capability levels (0–5). In fact, SPICE's process reference model takes the process definitions of 12207 and 15288 directly as the subject of assessment (Process Reference Model). Thus the three standards complement one another as a division of "define–assess–improve" roles rather than as competitors.

Category ISO/IEC 12207 ISO/IEC 15288 CMMI SPICE (ISO/IEC 15504→33000)
Subject Software life cycle System life cycle Organizational process capability Process performance capability
Purpose Process "definition" (reference model) Process "definition" (reference model) Maturity diagnosis and improvement Capability level assessment
Structure 4 process groups (2017) 4 process groups (aligned) Maturity 1–5 / Capability 0–3 Capability level 0–5
Relationship Harmonized with 15288 Harmonized with 12207 References 12207 as best practice References 12207 as assessment subject

7. Deep Dive: Evolution of the Standard and Integration with Agile/DevOps

The revision history of ISO/IEC 12207 directly reflects paradigm shifts in the software industry. The 1995 original set out from the immediate task of resolving inter-organizational contract disputes; through two amendments in 2002 and 2004, and in the 2008 revision it began alignment with the system life cycle standard (15288); and in ISO/IEC/IEEE 12207:2017 it harmonized structure and terminology with 15288:2015, completing the frame of an "integrated system–software life cycle." Reports indicate a successor revision (second edition) was released in April 2026, but since detailed clauses can change with revisions, it is safest in an answer to describe it as "periodically revised, in a direction that strengthens alignment with 15288."

The core of recent trends is the integration of 12207 with lightweight, iterative methodologies such as agile and DevOps. In the past 12207 was sometimes misunderstood as a heavy, document-centric standard coupled with the waterfall model, but the standard does not actually mandate a life cycle model. The 2017 revision's defining of processes around purpose and outcomes and its explicit statement of iterative and recursive application serve to allow agile's iterative sprints or DevOps's continuous integration/deployment (CI/CD) pipelines to be interpreted as iterative execution of 12207 processes. For example, DevOps's automated build, test, and deployment maps to a form in which 12207's "implementation–integration–verification–transition" processes are repeated at high speed by tools.

Another trend is the integration of supply chain, security, and AI elements into the life cycle. As open source and third-party components come to constitute most of the software, 12207's acquisition and supply processes are being interpreted in a direction linked with the SBOM (Software Bill of Materials) and supply chain security. Furthermore, since AI/machine-learning-based systems include new life cycle elements of data and models, integrated governance that applies the traditional software life cycle standard together with ISO/IEC 42001 (AI management system) or an MLOps framework is required. In other words, 12207 should be seen not as a fixed procedure manual but as a "living reference" whose interpretation and linkages evolve with industry change.

8. Considerations and Implications (Professional Engineer's View)

First, it must be made clear that the essence of the standard is "process definition," not "quality assurance." Adopting 12207 does not automatically guarantee quality; only when the defined processes are actually performed and their performance level is assessed and improved via SPICE/CMMI does it lead to results. From an application-strategy viewpoint, an organization should jointly design the triangular system of "define–assess–improve": defining processes with 12207, diagnosing capability with SPICE, and turning an improvement roadmap.

Second, the appropriateness of Tailoring determines success or failure. Applying processes excessively loses out on agility and cost, while applying them too sparsely loses traceability and quality control. From a trade-off viewpoint, safety-critical systems should tailor toward reinforcing verification, validation, and audit, while services where fast market response matters should tailor toward lightening documentation and reviews — all while documenting the rationale of tailoring decisions to prepare for disputes and audits. The key is distinguishing that tailoring is "intelligent application of the standard," not "ignoring the standard."

Third, since verification (V&V) and configuration management are the backbone of life cycle quality, they warrant up-front investment. Because the cost of fixing defects increases exponentially the later in the life cycle they are found (tens to hundreds of times more in operation than at the requirements stage), embedding verification and validation into each process stage — a "shift-left" — is cost-effective. At this point 12207 naturally links with DevSecOps, automated testing, and continuous integration toolchains.

Fourth, an integrated governance view of the system, software, and AI life cycles is needed. In the reality where software is part of a system and combines with AI and data, 12207 must be operated in alignment with 15288 (system), 42001 (AI), MLOps, and SBOM supply chain security to eliminate redundancy and blind spots. From a prospective viewpoint, 12207 will continue to evolve in a direction that strengthens harmonization with 15288 and encompasses the agile, DevOps, and AI life cycles, and a professional engineer must have the integrated-design competency to weave these into "a single life cycle governance" rather than memorizing individual standards.

Fifth, the practical utility in the domestic public/procurement environment must be considered. When designing the scope definition, deliverable standards, and audit criteria of a public SI project, 12207's process framework becomes the basis for clarifying the responsibility boundary between acquirer and contractor. However, tailoring that aligns with real-world systems such as the domestic SW-project cost estimation and audit regimes is needed, and one must guard against "declarative application" where the standard is formally cited only while diverging from the actual process. Ultimately, 12207 delivers substantive value when operated interlocked with the organization's quality, procurement, security, and AI governance as a whole, not as a standalone norm.

References

In one line: ISO/IEC 12207 is an international standard defining the entire software life cycle — acquisition, supply, development, operation, maintenance, disposal — as standard processes; it was reorganized from the original's Primary/Supporting/Organizational three-way classification into four process groups (Agreement, Organizational Project-Enabling, Technical Management, Technical) harmonized with ISO/IEC 15288 in the 2017 revision, and it is a "common language of process definition" applied through tailoring without mandating any methodology, serving as the foundation for SPICE/CMMI process assessment and improvement.