Knowledge · Rules · Process

Iso 12207

ISO/IEC/IEEE 12207:2017 three-level process hierarchy for SBX framework governance

Tags

rule

Overview

Purpose

ISO/IEC/IEEE 12207:2017 three-level process hierarchy for SBX framework governance

Rules

ISO12207-001: Process definitions MUST follow the three-level hierarchy: Process → Activity → Task

ISO 12207 defines POAT (Purpose, Outcomes, Activities, Tasks) as the canonical decomposition. Mixing levels creates ambiguity in scope and responsibility.

Verification: Schema validation: process.yml contains activities (not tasks directly), activity.yml contains tasks, task.yml is atomic

ISO12207-002: Processes MUST define outcomes — observable results of successful execution

ISO 12207 uses outcomes as the primary process assessment mechanism. A process without outcomes cannot be assessed for implementation quality.

Verification: Schema validation: process.yml requires outcomes[] with minItems: 1

ISO12207-003: Activities MUST NOT contain sub-activities — decompose into tasks only

Activity is the middle level. If an activity needs sub-activities, it should be promoted to a process. Tasks are atomic work items within activities.

Verification: Schema validation: activity.yml contains tasks[], not sub-activities

ISO12207-004: Tasks MUST be atomic — no sub-tasks, no sub-activities

Task is the lowest level of the ISO 12207 hierarchy. A task that needs decomposition should be promoted to an activity with multiple tasks.

Verification: Schema validation: task.yml has checklist[] (flat list), no nesting

ISO12207-005: Process naming MUST use ISO 12207 terminology: process, activity, task

Consistent naming prevents confusion. Decision #0011 established this: pipeline→process, step→activity, ETVX→task.

Verification: Code review: no use of 'pipeline' for methodology definitions, no 'step' for activity-level concepts in .framework code

ISO12207-006: Activities MUST be reusable across processes via reference-by-name

ISO 12207 and SPEM 2.0 both model activities as reusable work units. An activity defined once can be referenced by multiple processes.

Verification: Schema validation: process.yml activities map uses items_conform_to: activity, entries reference by name

ISO12207-007: Status MUST be derived from filesystem state, not stored in files

STATE:no-files rule. Task pending = entry criteria not met. Task complete = exit criteria met. No status fields.

Verification: Code review: no 'status' field in process/activity/task instances