國際標準 ISO/IEC/IEEE 15288
第二版 2023-05 【第 1 部分（共 2 部分）】 中文版

**國際標準 系統與軟體工程 — 系統生命週期流程**

*Ingénierie des systèmes et dulogiciel — Processus du Cycle de vie du système*

譯者翻譯註解：
1. 持續翻譯中...，歡迎提供任何修改建議
2. 英文版佔128頁，所以需用掉兩個連結
3. Part 2 of 2 的連結：https://hackmd.io/yzGBiUU4ROGtOyh3afv45Q
4. 修改錯誤專有名詞：如System譯成係統，改為系統

LOG:
1. 2025-12-30 將英文版內容(出處: IEEE，https://standards.ieee.org/ieee/15288/10424/)，送Google翻譯系統，進行初步翻譯。
2.

[ToC]

# 前言

ISO（國際標準化組織）和IEC（國際電工委員會）構成了全球標準化的專門系統。作為 ISO 或 IEC 成員的國家機構透過各自組織設立的技術委員會參與國際標準的製定，這些技術委員會負責處理特定技術領域的工作。 ISO 和 IEC 的技術委員會在共同感興趣的領域開展合作。其他與 ISO 和 IEC 保持聯絡的國際組織（包括政府間組織和非政府組織）也參與相關工作。

本文件的製定程序以及後續維護程序在 ISO/IEC 指令第 1 部分中有所描述。尤其需要注意的是，不同類型的 ISO/IEC 文件需要不同的批准標準。本文件依據 ISO/IEC 指令第 2 部分的編輯規則撰寫（請參閱 [www.iso.org/directives](https://www.iso.org/directives-and-policies.html) 或 [www.iec.ch/members_experts/refdocs](https://www.ieiec.ch/m.ieiec.ch/www.ienc.chs/www.ienc.chs/www.ie>c.Pembers_ex）。

IEEE 標準文件由 IEEE 各學會和 IEEE 標準協會 (IEEE-SA) 標準委員會的標準協調委員會制定。 IEEE 透過美國國家標準協會 (ANSI) 批准的共識制定流程來製定其標準，該流程匯集了代表不同觀點和利益的志願者，以最終形成標準。志工不一定是 IEEE 的會員，且不領報酬。雖然 IEEE 負責管理該流程並製定規則以促進共識制定過程的公平性，但 IEEE 並未對其標準中包含的任何資訊的準確性進行獨立評估、測試或驗證。

請注意，本文件中的某些內容可能涉及專利權。 ISO 不負責識別任何或所有此類專利權。在文件制定過程中識別出的任何專利權的詳細資訊將在引言和/或 ISO 收到的專利聲明清單（請參閱 [www.iso.org/patents](https://www.iso.org/iso-standards-and-patents.html)）或 IEC 收到的專利聲明清單（請參閱 [https://patents.httpsc.chents.https://chents.

本文件中所使用的任何商標名稱僅為方便使用者而提供，並不構成認可。

關於標準的自願性、ISO特定術語和與合格評定相關的表達的含義，以及ISO在技術性貿易壁壘（TBT）方面對世界貿易組織（WTO）原則的遵守情況，請參閱[www.iso.org/iso/foreword.html](https://www.iso.org/foreword-supplementary-information.html)。關於IEC，請參閱[www.iec.ch/understanding-standards](https://www.iec.ch/understanding-standards)。

本文件由 ISO/JTC 1 聯合技術委員會*資訊技術* 分委員會 SC 7 *軟體和系統工程* 與 IEEE 電腦協會系統和軟體工程標準委員會 合作編寫，符合 ISO 和 IEEE 之間的合作夥伴標準制定組織合作協議。

本第二版取代了第一版（ISO/IEC/IEEE 15288:2015），第一版已進行技術修訂。

主要變更如下：

- 改進了部分技術流程，包括業務或任務分析、系統架構定義、系統分析、實施、整合、運作和維護；

- 改進了部分技術管理流程，包括風險管理和型態(或配置管理；

- 更新了[條款 5](#_bookmark47)中的關鍵概念，包括對迭代、遞歸、系統之系統、品質特性等的更清晰描述；

- 在[條款 5](#_bookmark47)中新增了關於概念和系統定義的內容，並擴展了關於流程應用和系統概念的內容；

- 更新了術語和定義；

- 新增一個附件，專門介紹基於模型的系統工程 (MBSE)。

如有任何關於本文檔的回饋或疑問，請聯絡使用者所在國家/地區的標準機構。這些機構的完整清單可在 [www.iso.org/members.html](https://www.iso.org/members.html) 和 [www.iec.ch/national-committees](https://www.iec.ch/national-committees) 上找到。

# 引言

系統的複雜性持續成長，達到了前所未有的水平。這帶來了新的機遇，同時也為創建和使用系統的組織帶來了更大的挑戰。這些挑戰貫穿系統的整個生命週期，並存在於架構細節的各個層面。本文檔提供了一個通用的流程框架，用於描述系統的生命週期，並採用系統工程方法。本文檔涉及的系統可配置以下一個或多個系統元素：硬體元素、軟體元素、資料、人員、流程、服務、程序、設施、材料和自然實體。

本文檔著重於在開發週期的早期階段，明確利害關係人對所需功能的需求、關注點、優先順序和約束條件，從而建立需求，並在考慮完整問題的基礎上進行設計綜合和系統驗證。它將所有學科和專業團隊整合到一個團隊協作中，形成一個結構化的開發流程，涵蓋從概念到生產再到營運的各個階段。本文檔考慮所有利害關係人的需求，旨在提供滿足使用者和其他相關利害關係人需求的高品質產品。它提供了系統獲取和供應的流程。它有助於改善創建、使用和管理現代系統的各方之間的溝通與合作，使他們能夠以整合、一致的方式工作。最後，本文檔也提供了生命週期流程評估和改進的架構。

系統在用途、應用領域、複雜性、規模、創新性、適應性、數量、位置、生命週期和演進等方面存在著巨大的差異。本文檔中的流程構成了一套全面的流程集，組織可以利用這些流程來建構適合其產品和服務的系統生命週期模型。組織可以根據其目標選擇並應用合適的子集來實現該目標。

本文檔可用於以下一種或多種模式：

- 由組織使用－協助建立所需流程的環境。這些流程可以由方法、程序、技術、工具和訓練有素的人員組成的基礎設施提供支援。組織隨後可以利用此環境來執行和管理其項目，並推動系統完成其生命週期的各個階段。在這種模式下，本文檔用於評估已聲明並已建立的環境是否符合其規定。它可以由單一組織以自我約束的方式使用，也可以在多方參與的情況下使用。參與者可以來自同一組織，也可以來自不同的組織，情況可以是非正式協議，也可以是正式合約。

- 由專案使用－協助選擇、建構和運用已建立環境的要素來提供產品和服務。在這種模式下，本文檔用於評估專案是否符合已聲明並已建立的環境。

- 由採購者和供應商使用－協助制定有關流程和活動的協議。透過協議，本文件中所述的流程和活動得以選擇、協商、達成協議並執行。在此模式下，本文件用於指導協議的製定。

- 由流程評估人員使用 — 作為流程參考模型，用於執行流程評估可用於支援組織流程改善。

在本文件和 ISO/IEC/IEEE 12207 的脈絡下，人為系統存在一個連續光譜，從幾乎不使用軟體的系統到以軟體為主要關注點的系統。當軟體是主要系統或專注於要素時，應使用 ISO/IEC/IEEE 12207。這兩個文件具有相同的過程模型，共享大部分活動和任務，主要區別在於描述性註釋。

雖然本文件並未建立管理體系，但其旨在與 ISO 9001 品質管理系統、ISO/IEC 20000 系列服務管理系統、ISO/IEC 19770 系列 IT 資產管理體係以及 ISO/IEC 27000 資訊安全管理系統相容。

**系統與軟體工程 — 系統生命週期流程**

## 1 範圍

本文件建立了一個通用的流程描述框架，用於描述人類創建的系統的生命週期，並從工程角度定義了一系列流程及其相關術語。這些過程可應用於感興趣的系統、其系統元素以及系統之系統。在系統生命週期的各個階段，都可以應用這些過程的特定組合。這需要利害關係人的參與，最終目標是實現客戶滿意。

本文件定義了一系列流程，旨在促進系統開發以及系統生命週期中採購方、供應商和其他利害關係人之間的資訊交換。

本文檔闡述了支援組織或專案內部系統生命週期流程定義、控制和改進的各項流程。組織和專案在取得和供應系統時均可使用這些流程。

本文檔適用於組織作為系統取得方和供應方的雙重角色。

本文檔適用於系統的完整生命週期，包括系統的概念、開發、生產、使用、支援和退役，以及系統的取得和供應，無論這些取得和供應是在組織內部還是外部進行的。本文檔中的生命週期流程可以迭代地、並發地應用於整個系統，也可以遞歸地應用於系統的各個組成部分。

本文檔適用於獨一無二的系統、大量生產的系統以及客製化、可適應的系統。它也適用於完整的獨立系統以及嵌入並整合到更大、更複雜、更完整的系統中的系統。

本文檔並未規定具體的系統生命週期模型、開發方法、建模方法或技術。

本文件未詳細說明資訊項目的名稱、格式、特定內容及記錄媒體。 ISO/IEC/IEEE 15289 規定了生命週期過程資訊項目（文件）的內容。

## 2 規範性引用文件

本文件無規範性引用文件。

## 3 術語、定義和縮寫

為便於理解本文件，以下術語和定義適用。

ISO、IEC 和 IEEE 維護用於標準化工作的術語資料庫，網址如下：

- ISO 線上瀏覽平台：<https://www.iso.org/obp>

- IEC 電工術語庫：<https://www.electropedia.org/>

- IEEE 標準字典線上版：<https://dictionary.ieee.org/>

註：其他系統和軟體工程術語的定義可在 ISO/IEC/IEEE 24765 中找到，該標準可在 [www.computer.org/sevocab](http://www.computer.org/sevocab) 取得。

##### 3.1

**收購方**

*利害關係人* ([3.44](#344)) 從下列物件取得或購買*系統* ([3.46](#346))、*產品* ([3.32](#332)) 或*服務* ([3.42](#342))：

*供應商* ([3.45](#345))

註1：其他常用的收購方術語包括買方、*客戶* ([3.12](#312))、所有者、購買者或內部/組織發起人。

##### 3.2

**取得**

取得系統 (3.46)、產品 (3.32) 或服務 (3.42) 的過程 (3.27)

##### 3.3

**活動**

構成流程 (3.27) 的一系列相互關聯的任務 (3.51)

##### 3.4

**協定**

雙方就建立工作關係的條款和條件所達成的相互認可

例：合約、諒解備忘錄。

##### 3.5

**架構**

系統（[3.46](#346)）在其環境（[3.16](#316)）中的基本概念或屬性，以及實現和演化的指導原則，以及相關的生命週期（[3.21](#321)）和過程（[3.27](#327)）。

[來源：ISO/IEC/IEEE 42020:2019，3.3，已修改－「實體」已替換為「系統」；條目註釋已刪除。 ]

##### 3.6

**製品**

在專案過程中產生和使用的工作成果（[3.32](#332)），用於捕獲和傳遞資訊。

EXAMPLE模型、利害關係人需求、系統/軟體需求、架構描述、設計描述、原始碼、已實現的系統元素、已驗證或已確認的系統。

[來源：ISO 19014-4:2020，3.9，已修改－新增範例。 ]

##### 3.7

**審核**

對一項或多項工作成果（[3.32](#332)）進行獨立檢查，以評估其是否符合規範、標準、合約協議（[3.4](#34)）或其他標準。

##### 3.8

**基線**

配置項（[3.11](#311)）的正式批准版本，無論其儲存媒體如何，均在配置項生命週期（[3.21](#321)）的特定時間點正式指定並確定。

[來源：IEEE Std 828-2012]

##### 3.9

**運行概念**

對配置項的運作概念進行概括性的文字和圖形描述。組織（[3.25](#325)）關於新建、改建或現有組織系統（[3.46](#346)）的一項或一系列操作的假設或意圖。

註1：操作概念通常體現在長期策略規劃和年度營運計畫。在後者中，計劃中的操作概念涵蓋一系列相互關聯的操作，這些操作將同時或依次執行，以實現組織績效目標。另請參閱「營運概念」（[3.23](#323)）。

註2：操作概念為界定營運空間、系統能力、介面（[3.19](#319)）和營運環境（[3.16](#316)）提供了基礎。

[資料來源：ANSI/AIAA G-043B-2018，5.2，已修改－採用第二個定義；刪除條目註 1 的最後兩句話；新增條目註 2。 ]

##### 3.10

**關注點**

對*利害關係人*（[3.44](#344)）而言重要或感興趣的事項

條目註 1：關注點是指對*系統*（[3.46](#346)）及其*環境*（[3.16](#316)）的任何影響，包括發展、技術、商業、營運、組織、政治、經濟、法律、監管、倫理、生態和社會影響。

[來源：ISO/IEC/IEEE 42020:2019，3.8，已修改－刪除範例；條目註 1 已新增。

##### 3.11

**配置項目**

硬體、軟體或兩者兼具的元件或集合，指定用於組態管理，並在組態管理*流程*中被視為單一實體 ([3.27](#327))。

##### 3.12

**客戶**

接收*產品* ([3.32](#332)) 或*服務* ([3.42](#342)) 的*組織* ([3.25](#325)) 或個人。

例如：消費者、顧客、*使用者* ([3.53](#353))、*購買者* ([3.1](#31))、買方或購買者。條目註 1：客戶可以是組織內部的，也可以是組織外部的。

##### 3.13

**設計**，名詞

對*系統元素*（[3.47](#347)）及其關係的詳細規範，足以支援*架構*（[3.5](#35)）的合規實現。

註1：設計提供了系統元素的詳細實現層級物理結構、行為、時間關係和其他屬性。

##### 3.14

**設計特性**

與產品 ([3.32](#332)) 或服務 ([3.42](#342)) 的可衡量描述相關的設計屬性或顯著特徵。

##### 3.15

**使能系統**

在目標系統 ([3.48](#348)) 的生命週期 ([3.21](#321)) 和各個階段 ([3.43](#343)) 中為其提供支援的系統 ([3.46](#346))，但

不一定直接參與目標系統的運作功能。

例如：生產使能系統，當目標系統進入生產階段時，需要該系統。

註1：每個使能系統都有其自身的生命週期。本文件適用於每個獨立運作的系統，前提是該系統本身被視為一個重要的系統。

##### 3.16

**環境**

系統上下文，決定影響系統的所有因素的設定和環境 ([3.46](#346))

##### 3.17

**事件**

在項目 ([3.33](#333))、產品 ([3.32](#332))、服務 ([3.42](#342)) 或系統 ([3.46](#346)) 的生命週期內任何時間發生的異常或意外事件、一系列事件、狀況或情況 ([321)(#321))

註 1：當需要分析和修正事件原因以防止再次發生或避免其他問題時，事件將被升級並作為問題處理 ([3.26](#326))。最大程度減少生命損失、財產損失或自然資源損失（[3.37](#337)）。

##### 3.18

**資訊項目**

為人類使用而生產、儲存和交付的可單獨識別的資訊體。

[來源：ISO/IEC/IEEE 15289:2019，3.1.12，已修改－已刪除首選術語「資訊產品」；已刪除條目註釋。 ]

##### 3.19

**接口**

兩個或多個邏輯、物理或兩者兼具的系統元素（[3.47](#347)）或軟體系統元素相遇並互動或通訊的點。其他

[來源：ISO/IEC/IEEE 24748-6：—，3.1.3]

##### 3.20

**互操作系統**

與目標系統 ([3.48]) 交換資訊並使用已交換資訊的*系統* ([3.46](#346))

##### 3.21

**生命週期**

*系統* ([3.46](#346))、*產品* ([3.32](#332))、*服務* ([3.42](#342))、*項目* ([3.33](#333)) 或其他人造實體的演進

從構思到*退役* ([3.38](#338))

##### 3.22

**生命週期模型**

架構*流程* ([3.27](#327)) 和 *活動* ([3.3](#33)) 與 *生命週期* ([3.21](#321)) 相關，這些流程和活動可以組織成 *階段* ([3.43](#343))，作為溝通和理解的共同參考。

##### 3.23

**運行概念**

*組織* ([3.25](#325)) 對特定 *系統* ([3.46](#346)) 或一組相關的特定新系統、現有系統或改進系統的運作或一系列運行的假設或意圖的文字和圖形描述。

註 1：運作概念旨在從組織運作*環境* ([3.16](#316)) 的角度，全面描述使用一個或多個特定系統或一組相關系統進行的運作。使用者視角（[3.53](#353)）和操作員視角（[3.24](#324)）。另請參閱運行概念（[3.9](#39)）。

條目註 2：運行概念針對的是系統，而運行概念（[3.9](#39)）通常指的是組織。

[來源：ANSI/AIAA G-043B-2018，5.2，已修改－採用了第三個定義；刪除了條目註釋 1 的第一句話；條目註釋 2 已新增。

##### 3.24

**操作員**

執行系統 ([3.46](#346)) 操作的個人或組織 ([3.25](#325))。

條目註 1：操作員和使用者 ([3.53](#353)) 的角色可以同時或先後賦予同一個人或組織。

條目註 2：具備相關知識、技能和流程的操作員可以被視為系統的一個組成部分。

條目註釋 3：操作員可以對正在運行的系統執行操作，也可以對正在運行的系統執行操作，這取決於系統邊界內是否包含操作指令。

##### 3.25

**組織**

指擁有自身職能、責任、權限和關係以實現其目標的個人或團體。

例如：公司、企業、商號、製造商、機構、慈善機構、自營商、協會或其組成部分或組合。

[來源：ISO 9000:2015，3.2.1，已修改－條目註解已刪除；已新增範例。

##### 3.26

**問題**

困難、不確定性或其他已實現的、不希望發生的事件、事件集、狀況或情況，需要進行調查並採取糾正措施。

##### 3.27

**過程**

一組相互關聯或相互作用的*活動*（[3.3](#33)），將輸入轉換為輸出。

##### 3.28

**迭代**

在系統（[3.46](#346)）結構的同一層級上重複應用相同的*過程*（[3.27](#327)）或一組過程。

##### 3.29

**過程目的**

執行*過程*（[3.27](#327)）的高階目標以及有效實施該過程的可能結果。

註1：該條目的目的實施該流程的目的是為利害關係人帶來利益（[3.44](#344)）。

##### 3.30

**過程結果**

成功達成*過程目標*（[3.29](#329)）的可觀察結果

##### 3.31

**遞迴**

將相同的*過程*（[3.27](#327)）或一組過程重複應用於系統結構中不同層級的*系統元素*（[3.47](#347)）

##### 3.32

**產品**

*組織*（[3.25](#325)）的產出，無需組織與*客戶*（[3.12](#312)）之間發生任何交易即可生產。

註1：產品的主要特徵是其通常具有有形性。

[來源：ISO 9000:2015，3.7.6，已修改－條目註釋1和3已刪除。 ]

##### 3.33

**專案**

為創造*產品* ([3.32](#332)) 或*服務* ([3.42](#342)) 而開展的、具有明確開始和結束標準的活動

根據指定的*資源* ([3.37](#337)) 和*需求* ([3.36](#336))

條目註1：項目有時被視為一個獨特的*過程* ([3.27](#327))，由協調和受控的*活動* ([3.3](#33)) 組成，這些活動來自本文件中定義的技術管理過程和技術過程。

註2：持續開發方法（例如敏捷開發和DevOps）在產品和服務創建過程中可能使用不同的術語。

##### 3.34

**品質保證 (QA)**

品質保證是品質管理的一部分，其重點在於確保品質*要求*（[3.36](#336)）得到滿足。

來源：ISO9000:2015，3.3.6，已修改－已新增縮寫術語。

##### 3.35

**品質特性**

產品（[3.32](#332)）、服務（[3.42](#342)）、過程（[3.27](#327)）或系統（[3.46](#346)）的固有特性，與

要求（[3.36](#336)）相關。

[來源：ISO 9000:2015，3.10.2，已修改－「物件」已替換為「產品、服務、流程或系統」；條目註釋已移除。 ]

##### 3.36

**需求**

表達需求及其相關約束和條件的陳述。 [來源：ISO/IEC/IEEE 29148:2018，3.1.19，已修改－條目註釋已移除。 ]

##### 3.37

**資源**

在執行*過程*期間利用或消耗的資產（[3.27](#327)）

條目註1：資源包括各種實體，例如資金、人員、設施、資本設備、工具以及公用設施，例如電力、水、燃料和通訊基礎設施。

條目註2：資源包括可重複使用、可再生或可消耗的資源。

##### 3.38

**退役**

系統退役：指運作維護機構停止對系統進行積極支援（[3.25](#325)），部分或全部替換為新系統（[3.46](#346)），或安裝升級系統，或最終退役和處置。

##### 3.39

**風險**

不確定性對目標的影響

註1：影響是指與預期結果的偏差－可以是正面的，也可以是負面的。正面影響也稱為機會。

註2：目標可以包含不同的面向（例如財務目標、健康與安全目標（[3.40](#340)）以及環境目標），並且可以應用於不同的層面（例如策略層面、組織層面、專案層面、產品層面（[3.32](#332)）以及流程層面（[3.27](#327)）。

註3：風險通常透過提及潛在事件及其後果，或二者的組合來描述。

註4：風險通常用事件的後果（包括環境變化）及其發生的可能性來表示。

註5：不確定性是指對事件、其後果或可能性缺乏理解或知識的狀態，即使是部分缺乏。

[來源：ISO 73:2009 指南，1.1，已修改－條目註釋 1 的最後一句話已新增。 ]

##### 3.40

**安全**

預期在特定條件下，系統（[3.46](#346)）不會導致危及人類生命、健康、財產或環境（[3.16](#316)）的狀態。

條目註 1：該術語也可定義為免於承擔不可容忍的*風險*（[3.39](#339)）。

[來源：ISO/IEC/IEEE 12207:2017，3.1.48，已修改－新增條目註釋1。 ]

##### 3.41

**安全性**

防止蓄意破壞或人為破壞

條目註1：安全性包括真實性、問責性、保密性、完整性、可用性、不可否認性和可靠性，所有這些都涉及其保證問題。

[來源：北約AEP-67，已修改－已更新條目註1。 ]

##### 3.42

**服務**

組織（[3.25](#325)）的產出，其中至少包含一項組織與客戶（[3.12](#312)）之間必須執行的活動（[3.3](#33)）。

條目註1：服務的主要要素通常是無形的。

條目註 2：服務是連貫的、獨立的，並且可以由其他服務組成。

[來源：ISO 9000:2015，3.7.7，已修改－條目註釋 2、3 和 4 已被新的條目註釋 2 取代。 ]

##### 3.43

**階段**

實體在其生命週期 ([3.21](#321)) 內與其描述或實現狀態相關的時期。

條目註 1：在本文件中，「階段」指的是實體在其生命週期中所取得的主要進展和里程碑。

條目註 2：階段之間經常重疊。

##### 3.44

**利害關係人**

對系統([3.46](#346))或其所具備的滿足自身需求和期望的特性擁有權利、份額、訴求或利益的個人或組織([3.25](#325))。

範例：最終使用者([3.53](#353))、最終使用者組織、支持者、開發者、客戶([3.12](#312))、生產商、培訓人員、維修人員、處置人員、採購人員([3.1](#31))、供應商([3.45](#345))、監管機構以及受影響的負面機構以及受影響的負面機構。

註1：某些利害關係人的利益可能彼此衝突，甚至與系統本身有衝突。

##### 3.45

**供應商**

指與收購方 (3.1) 簽訂協議 (3.4) 的組織 (3.25) 或個人，該協議旨在提供

產品 (3.32) 或服務 (3.42)

註 1：供應商的其他常用術語包括承包商、生產商、銷售商或供應商。註 2：收購方和供應商有時屬於同一組織。

##### 3.46

**系統**

安排指各個組成部分共同展現出特定行為或意義，而單一組成部分本身並不具備這些行為或意義的部件或元素。

註1：系統有時被視為*產品*（[3.32](#332)）或其提供的*服務*（[3.42](#342)）。

註2：在實踐中，通常使用關聯名詞來闡明其意義，例如「飛機系統」。或者，也可以用上下文相關的同義詞（例如“飛機”）來代替“系統”，但這可能會模糊系統原理的視角。

註3：完整的系統包括所有相關的設備、設施、材料、電腦程式、韌體、技術文件、*服務*（[3.42](#342)）以及人員，這些設備和人員在預期的*環境*（[3.16](#316)）中運作和支援所需的程度足以使其能夠獨立運作。

##### 3.47

**系統元素**

系統([3.46](#346))中可實現的離散部分，用於滿足特定需求([3.36](#336))。

範例：硬體、軟體、資料、人員、流程([3.27](#327))（例如，向使用者([3.53](#353))提供服務([3.42](#342))的流程）、程式（例如，操作員([3.24](#324))）指令、設施、任何存在的實體材料或其自然組合的存在。

##### 3.48

**感興趣的系統 (SoI)**

*系統* ([3.46](#346))，其*生命週期* ([3.21](#321)) 正在考慮中

##### 3.49

**系統之系統 (SoS)**

一組*系統* ([3.46](#346)) 或*系統元素* ([3.47](#347))，它們相互作用，提供一種獨特的能力，而這種能力是任何一個組成系統單獨都無法實現的

[來源：ISO/IEC/IEEE 21839:2019，3.1.4]

##### 3.50

**系統工程**

一種跨學科的綜合方法，旨在利用系統原理，成功實現、使用和*退役* ([3.38](#338)) 工程*系統* ([3.46](#346))。概念以及科學、技術和管理方法

[來源：INCOSE-TP-2020-002-06]

##### 3.51

**任務**

為實現過程的一個或多個結果而必須採取、建議採取或允許採取的行動 ([3.27](#327))

##### 3.52

**可追溯性**

兩個或多個邏輯實體之間的可辨別關聯，例如*需求* ([3.36](#336))*、系統元素*

([3.47](#347))、*驗證* ([3.55](#355)) 或*任務* ([3.51](#351))

[來源：ISO/IEC TR 29110-1:2016，3.71，已修改－新增了「可辨識的」；範例已移除。

##### 3.53

**使用者**

與系統互動（[3.46](#346)）或在使用系統期間受益的個人或群體

註1：使用者角色和操作員角色（[3.24](#324)）有時會同時或先後授予同一個人或組織（[3.25](#325)）。

[來源：ISO/IEC 25010:2011，4.3.16，已修改－原條目的註 1 已被新的註解取代。 ]

##### 3.54

**驗證**

透過提供客觀證據，確認特定預期用途或應用的*要求*（[3.36](#336)）已滿足。

條目註 1：在*生命週期*（[3.21](#321)）的背景下，驗證涉及一系列*活動*（[3.3](#33)），旨在確保*系統*（[3.46](#346)）能夠在類似運行環境的*環境*（[3.16](#316)）中實現其預期用途、目標和目標。已建置正確的系統。

[來源：ISO 9000:2015，3.8.13，已修改－刪除條目註釋 1 至 3；新增條目註釋 1。 ]

##### 3.55

**驗證**

透過提供客觀證據，確認已滿足規定的*要求*（[3.36](#336)）。

條目註 1：驗證是一系列*活動*（[3.3](#33)），用於將*系統*（[3.46](#346)）或*系統元素*（[3.47](#347)）與所需特性進行比較。這包括但不限於規定的要求、*設計*（[3.13](#313)）描述以及系統本身。系統已正確建置。

[來源：ISO 9000:2015，3.8.12，已修改－刪除條目註釋 1 至 3；新增條目註釋 1。 ]

##### 3.56

**視圖**

從一組相關的*關注點*（[3.10]（#310））的角度對*系統*（[3.46](#346)）的表示。

條目註 1：視圖可以是系統的運作、功能或架構表示。

[來源：ISO/IEC/IEEE 24774:2021，3.21，已修改——從定義中刪除了“whole”，並且條目的原始註釋 1 已被新的註釋替換。 ]

##### 3.57

**視點**

建構與使用*視點*的約定規範 ([3.56](#356))

[來源：ISO/IEC/IEEE 24774:2021，3.22，已修改－條目的註釋 1 至 3 已被刪除。 ]

## 4 符合性

### 4.1 預期用途

本文件中的要求包含在[條款 6](#_bookmark90)和[附件 A](#_bookmark126)中。本文件提供了以下方面的要求：本文檔列出了適用於系統生命週期內的各種流程。特定項目或組織可能只需要本文檔提供的部分流程。因此，本文檔的實施通常涉及選擇並聲明一組適合組織或專案的流程。有兩種方式可以聲明實施符合本文檔的規定－完全符合和自訂符合。

聲明完全符合有兩個標準。滿足其中任何一個標準即可視為符合，但必須在聲明中明確說明所選標準。聲明「完全符合任務要求」意味著聲明已滿足所聲明流程集中所有活動和任務的要求。或者，聲明「完全符合結果要求」意味著已滿足所聲明流程集中所有必需的結果。完全符合結果要求允許在實施符合要求的流程時擁有更大的自由度，並且對於在創新生命週期模型中使用流程的實施非常有用。

註1：為便於靈活應用本文件，提供了多種符合性選項。每個流程都有一組目標（表述為「成果」）以及一組活動和任務，這些活動和任務代表了實現這些目標的一種途徑。

註2：實施已聲明流程集中所有活動和任務的用戶，可以聲明其完全符合所選流程的任務要求。然而，有些使用者可能擁有創新的流程變體，這些變體無需實施所有活動和任務即可實現已聲明流程集的目標（即成果）。這些使用者可以聲明其完全符合已聲明流程集的成果要求。任務符合性和成果符合性這兩個標準並非必然等同，因為在某些情況下，執行特定活動和任務可能需要比僅僅實現成果更高的能力水準。

註3：將本文件作為貿易條件的組織（例如，國家機構、產業協會、公司）可以明確規定並公開構成供應商符合貿易條件的最低流程、成果、活動和任務集合。

註4：本文件中的要求以動詞「應」表示，建議以動詞「應當」表示，許可以動詞「可以」表示。然而，無論使用何種動詞，符合性要求的選擇均如前所述。

### 4.2 完全符合性

#### 4.2.1 完全符合結果

完全符合性聲明明確指出了聲明符合性的流程集合。完全符合結果是指證明所聲明的流程集合的所有結果均已實現。在這種情況下，無論條款中使用的動詞形式如何，所聲明的流程集合中關於活動和任務的規定均為指導性而非要求。

註：本文件的一個預期用途是促進流程評估和改進。為此，每個流程的目標均以與 ISO/IEC 33000 系列標準條款相容的「結果」形式編寫。這些標準規定了本文件中流程的評估方法，為改進提供了基礎。有意進行流程評估和改進的使用者可以將本文件中編寫的流程結果作為 ISO/IEC 33002 要求的「流程參考模型」。

#### 4.2.2 完全符合任務

完全符合聲明是指聲明符合的流程集合。完全符合任務是指證明所聲明的流程集合中所有活動和任務的要求均已實現。在這種情況下，無論條款中使用的動詞形式如何，所聲明的流程集合的結果規定均為指導性而非強制性要求。

注意：在合約情況下，如果採購方或監管機構要求詳細了解供應商的流程，則完全符合任務聲明可能適用。

### 4.3 自訂符合性

當本文件用作建立一套不符合完全符合性要求的流程的基礎時，應根據[附件A](#_bookmark126)中規定的定制流程，選擇或修改本文件[條款6](#_bookmark90)中的流程。聲明已聲明符合性要求的客製化流程集。

客製化符合性要求的實現方式是證明已實現客製化的結果、活動和任務。

註1：客製化可能會降低符合性聲明的知覺價值。這份文件之所以如此，是因為其他組織難以理解，客製化可能會刪除多少必要的條款。

註2：聲明符合本文件的組織可能會發現，聲明完全符合較少的流程清單比聲明完全符合較多的流程清單更有利。

註3：組織也可以選擇聲明完全符合一組選定的流程，同時聲明完全符合其他流程。

## 5 關鍵概念及其應用

### 5.1 總則

本條款重點介紹並解釋本文件所依據的基本概念。有關這些概念的進一步闡述，請參閱 ISO/IEC/IEEE 24748-1 和 ISO/IEC/IEEE 24748-2，它們提供了生命週期管理應用的指南。

### 5.2 系統概念

#### 5.2.1 系統

系統是由各個部分或元素組成的集合，這些部分或元素共同展現出單一組成部分所不具備的行為或意義。系統可以是物理系統、概念系統，或是二者的結合。物理宇宙中的系統由物質和能量構成，可能包含編碼在物質-能量載體中的訊息，並展現出可觀察的行為。概念系統是純粹訊息的抽象系統，它們不直接展現行為，而是展現「意義」。無論哪種情況，系統的整體屬性都源自於或湧現於各個組成部分及其各自的屬性，以及各部分之間、系統內部及其環境之間的關係和相互作用。

對特定系統、其架構及其系統元素的感知和定義取決於利害關係人的利益和責任。一個利害關係人的關注系統（SoI）可以被視為另一個利害關係人的關注系統中的一個系統元素。此外，一個關注系統也可以被視為另一個利害關係人的關注系統的環境組成部分。同時，一個關注系統也可以被視為系統系統（SoS）中的一個組成系統。

以下是關於SoI特徵的關鍵點（另見[圖1](#figure-1--system-and-system-element-relationship)和[圖2](#figure-2--system-of-interest-structure)）：

a) 明確的邊界涵蓋了有意義的需求和切實可行的解決方案；

b) 系統元素之間存在層級或其他關係；

c) SoI中任何層級的實體都可以被視為一個系統；

d) 一個系統包含一組整合且明確的下級系統元素；

e) 人既可以被視為系統外部的使用者（例如使用者），也可以被視為系統內部的系統元素（例如操作員）；

f) 一個系統既可以被視為一個獨立的實體，即一個產品；也可以被視為能夠與周圍環境互動的功能集合，即一組服務。

注意：服務、硬體元件和軟體元件可以是產品或服務，只要它們是獨立的系統介面（SoI）或系統系統（SoS）的組成部分。將服務和產品整合到系統中的考慮有時被稱為產品服務系統[[65](#_bookmark137)]。產品服務系統為組織提供了一種提供與其產品相關的服務的方式。

無論選擇何種邊界來定義系統，本文檔中的概念都是通用的，允許實踐者將生命週期的各個實例與其系統原則關聯或調整。

#### 5.2.2 系統結構

本文檔中所描述的系統生命週期過程與一個系統（參見[圖1](#figure-1--system-and-system-element-relationship)）相關。該系統由一組相互作用的系統元件組成，每個元件都可以透過實作來滿足其各自的特定需求。系統元件可以包括軟體元件、硬體元件、服務以及利用和支援資源。任何系統元件的實施責任都可以透過協議委託給另一方。


##### 圖 1 — 系統與系統元素的關係

系統元素之間的關係可以用多種形式表示，包括層級結構或網路結構。對於更複雜的系統目標 (SoI)，在能夠自信地定義完整的系統元素集合之前，可能需要將潛在的系統元素本身視為一個系統（該系統又由系統元素組成）（參見[圖 2](#figure-2--system-of-interest-structure)）。透過這種方式，可以將適當的系統生命週期流程遞歸地應用於系統目標，以解析其結構，直到能夠實現（製造、購買或重用）可理解和可管理的系統元素。雖然圖 1 和圖 2 暗示了一種層級關係，但實際上，越來越多的系統從一個或多個方面來看並非層級結構，例如網路和其他分散式系統。分散式系統。 [5.4](#_bookmark62)討論了系統之系統（SoS）的概念。


##### 圖2 — 目標系統結構

#### 5.2.3 介面系統、啟用系統與互操作系統

在目標系統生命週期的任何階段，任何與目標系統共享介面（資料或資訊、能源、資源、實體介面）的系統都是介面系統，需要在系統開發中加以考慮。人可以是目標系統的組成部分（例如操作員），也可以在目標系統的整個生命週期中與目標系統進行外部互動（例如要求資訊的使用者）。

在目標系統的整個生命週期中，需要使能系統提供必要的服務，例如大規模生產系統、訓練系統和維護系統。這些系統各自支援SoI的一個或多個生命週期流程。 SoI通常與其他系統具有接口，這些接口在除運行階段之外的其他生命週期階段使用。其中一些介面可能僅限於特定階段，在運行階段不使用。

相互互動以執行特定功能的系統稱為互操作系統，互操作系統是系統之系統（SoS）中的重要面向（參見[5.4](#_bookmark62)）。互操作系統是介面系統的子集。雖然互通性可能涉及資訊的交換和使用，但物理互通性和其他類型的互通性也同樣重要。例如，現在許多電子設備都配備了適合使用者所在位置的電源轉接器。

注意：互操作系統可以交換訊息，以確保SoI可靠、安全、有效或有效率地運行，或提高其可訪問性或易用性。互操作系統也可以從SoI接收訊息，供其他系統或SoS使用。

SoI 與介面系統、啟用系統和互操作系統之間的相互關係可以是雙向的，也可以是單向的。這些相互關係的要求需要包含在 SoI 的要求中。

關於這些概念的進一步闡述，請參閱 ISO/IEC/IEEE 24748-1 和 ISO/IEC/IEEE 24748-2，它們提供了生命週期過程應用的指南。

#### 5.2.4 與系統解決方案相關的概念

SoI 及其使能系統通常被視為一種解決方案，旨在解決利害關係人的關切。利害關係人的關切與其業務模式相關。特別是，SoI 供應商、採購方和使用者的關切各不相同；這促使他們需要考慮不同的

使能系統，以使 SoI 在其各自的系統解決方案環境中可行。因此，解決方案需要考慮不同利害關係人的需求和業務模式。

例如，製造系統對於供應商是必要的，但使用者和採購者通常不會考慮它。

從這個角度來看，對於給定的系統需求 (SoI)，業務或任務分析流程旨在解決一系列解決方案上下文（請參閱[圖 3](#figure-3--system-solution-contexts)）。


##### 圖 3 — 系統解決方案上下文

注意：給定的系統需求 (SoI) 可以關聯多種運行概念、採購上下文和部署。 ISO 15704 提供了這種多維生命週期描述。

應為系統需求 (SoI) 指定變體和選項，以解決一系列解決方案上下文。產品和服務通常按系統系列和產品線進行考慮，並識別不同項目共有的元素，以及每個項目的變體和選項（更多詳情請參閱 ISO/IEC 26550）。系統、產品和服務的開發通常受益於辨識專案間的重複使用機會，包括建立產品線、產品系列、系統和系統之系統。這些可供專案使用的資產透過知識管理流程進行管理。

#### 5.2.5 產品線工程 (PLE)

當組織開發產品線時，對產品線進行整體工程設計比對每個單獨的系統進行工程設計要高效得多。這要求將產品線作為一個單一的SoI（系統介面）進行工程設計，並在大部分生命週期內定義變體以支援各個系統實例。然而，在生命週期中，當某個特定系統實例被開發、驗證並部署到運行階段（即產品線中的一個成員）時，系統本身就成為一個SoI，可以繼續其自身的開發後生命週期，包括生產、支援、利用、退役等。變體管理模型用於管理系統實例的定義和生產。 PLE 通常專注於使用具有可重複使用資產的通用平台來管理產品系列，而基於功能的 PLE 則從整體解決 PLE 問題。以自動化方式（參見 ISO/IEC 26580）。

在這種方法中，所有系統生命週期流程都適用於將產品線視為 SoI 的情況，以及將產品線的每個實例及其變體視為 SoI 的情況。

從整體產品線 SoI 的角度來看，透過生命週期流程開發的許多工件在產品線的多個成員之間共享，從而提高了效率。

以下是基於特徵的產品生命週期工程 (PLE) 的關鍵原則：

- 產品線中系統實例的集合特徵（在 ISO/IEC 26580 中稱為特徵目錄）捕捉了產品線成員彼此之間的區別特徵，並在整個組織內提供了一種通用的變體語言。特徵目錄是一種特殊的基於模型的系統工程 (MBSE) 模型，有助於分析和解決產品線中的變體（參見[附錄 D](#_bookmark133)）。

- 產品線組合中系統實例所選取的功能，會在適用於此實例的功能集合（在 ISO/IEC 26580 中稱為功能清單）中進行指定。

- 所有支援產品創建、設計、實現、部署和運行的工程工件，都會被識別並維護為產品線中所有系統所用內容的單一副本——即無重複（在 ISO/IEC 26580 中稱為共享資產超集）。所有產品中使用的內容均為通用內容，並由產品線統一管理。在一個或多個系統實例中存在差異的內容，會與其變體（在 ISO/IEC 26580 中稱為變體點）一起封裝。根據所選功能，可以針對給定的系統實例包含、省略、產生或轉換這些變體。

- 系統實例由變體點（根據實例所選功能自動產生）以及所有通用內容組成。

### 5.3 組織概念

#### 5.3.1 組織

當一個組織（整體或部分）訂立協議時，它有時被稱為協議的「一方」。各方可以來自同一組織，也可以來自不同的組織。組織可以小到只有一個人，只要這個人被賦予了相應的職責和權限。
該
在非正式場合，負責執行某個流程的組織有時也被稱為該流程的名稱。例如，執行採購流程的組織有時被稱為「採購方」。其他例子包括供應商、實施方、維護方和營運商。

本文檔中也使用了其他一些術語來指稱組織：「使用者」是指從產品或服務的使用中受益的組織；「客戶」是指使用者和採購方的統稱；「利害關係人」是指對系統感興趣的個人或組織。

流程和組織之間僅存在功能上的關聯。本文件並未規定或暗示組織的具體結構，也未明確規定特定流程應由組織的特定部門執行。實施本文件的組織有責任為其定義合適的組織結構，並為流程的執行分配適當的角色和職責。

本文件中的流程構成一套完整的流程集，可服務於各類組織。無論規模大小，組織都可以根據其目標或獲取策略，選擇合適的流程集（以及相關的活動和任務）來實現其目標。一個組織可以執行一個或多個流程。

本文件旨在供組織內部使用，或供兩個或多個組織之間使用。在內部使用時，雙方通常會依據協議條款行事，該協議的正式程度可能因情況而異。在外部使用時，雙方通常會依據合約條款行事。本文件中使用「協議」一詞來指這兩種情況。

就本文件而言，任何項目均假定在組織內部進行。這一點至關重要，因為專案依賴組織流程產生的各種結果，例如專案所需的人員配備和專案所需的設施。為此，本文檔提供了一套「組織專案賦能」流程。這些流程並非旨在使組織能夠正常運作；相反，這些流程作為一個整體，旨在闡明專案對組織提出的最低限度依賴關係。

#### 5.3.2 組織與專案層面的採納

現代組織致力於開發一套穩健的生命週期流程，並將其重複應用於其專案中。組織層面。因此，本文件旨在供組織層面或專案層面採用。組織可以採納本文件，並輔以適當的程序、實務、工具和政策。組織的專案通常會遵循組織的流程，而不是直接遵循本文件。

在某些情況下，專案可能由尚未在組織層級採用適當流程的組織執行。此類項目可以直接採用本文件的條款。

#### 5.3.3 組織與協作活動

由於系統解決方案的複雜性日益增加，在系統生命週期中採用協作和平行工程方法通常很有幫助。以下是一些注意事項：

- 系統生命週期活動應以協作方式執行，盡可能同時讓利害關係人和領域專家參與。

- 可以在組織內部或組織之間定義協作框架，以促進各類利害關係人和專家的參與。協作框架包括共享的方法、工具和其他資源，並建立一個有利於更好溝通以及共享願景和價值觀的環境。

協作工程是迭代或漸進式開發方法的重要組成部分，有助於確保利害關係人之間及時回饋和溝通。

### 5.4 系統之系統概念

#### 5.4.1 系統與系統之系統的區別

系統之系統 (SoS) 是一組相互作用的系統，它們共同提供一種獨特的能力，而這種能力是任何一個組成系統單獨都無法實現的。在 SoS 的脈絡下，系統整合 (SoI) 的相關組成部分，根據定義，本身就是系統。一個 SoS 由若干組成系統以及任何必要的系統間基礎設施、設施和流程構成，這些基礎設施、設施和流程對於實現組成系統的整合或互通至關重要。

在 SoS 中，每個組成系統都是獨立的系統，構成 SoS 的一部分。組成系統可以屬於一個或多個 SoS。每個組成系統本身都是一個有用的系統，擁有自身的開發、管理、利用、目標和資源，但它們在 SoS 內部相互作用，共同提供 SoS 的獨特能力。這些額外的屬性使 SoS 區別於系統的集合。

一個系統可以作為一個或多個系統之系統 (SoS) 的一部分進行交互，以支援多種功能。在本文檔中，當討論一個系統整合 (SoI) 與一個系統之系統 (SoS) 的交互時，這可能包括一個或多個系統之系統 (SoS) 支援一項或多項功能。

系統與系統之系統 (SoS) 之間的差異不在於各個要素的結構或排列方式，而在於這些要素的行為和管理特徵。

#### 5.4.2 管理與運作獨立性

系統在受治理的管理控制下運作。組織透過目標和目的來管理一系列項目，並受法律、法規和外部協議（例如合約）的約束。專案管理若干個子專案以實現這些目標和目的。組成系統之間的關係會影響系統之系統 (SoS)。與某個系統之系統 (SoS) 的組成系統沒有任何互動的系統不屬於該系統之系統 (SoS)。

系統之系統 (SoS) 的一個基本特徵是，其內部的組成系統在運作上是獨立的。也就是說，組成系統可以（而且確實）獨立運行，以實現其自身的若干目標，而無需依賴系統之系統 (SoS)。儘管組成系統各自獨立運作以實現自身目標，但它們也相互依存，並與其他要素相互協作以產生系統之系統（SoS）的輸出。組成系統並非完全獨立，但也並非完全服從於SoS。

另一個重要特徵是，SoS內部的組成系統在管理上既獨立又相互依存。管理上的獨立性意味著，即使組成系統在參與SoS的過程中相互依存，它們仍可由保持一定程度獨立性的組織進行管理。這意味著這些組織可以為組成系統設定與SoS和其他組成系統不同的目標和目的。如果確實如此，那麼在治理和管理方面，很可能都存在一定程度的獨立性和相互依存性。

無論採用何種組織管理方式，目標和目的的一致性（或不一致性）都會影響SoS。雖然有些組成系統是被引導或影響而加入SoS的，但有些組成系統可能對SoS的存在毫不知情。有些組成系統選擇加入某個組織是基於成本效益的考量，也是為了更好地實現其目標。出於自身目的，也因為他們相信系統之系統（SoS）的整體目標。

#### 5.4.3 系統之系統分類

利用基本特徵劃分各種類型的系統之系統，可以為思考系統之系統提供一個簡明的命名體系。 ISO/IEC/IEEE 21841 定義了系統性系統（SoS）的標準化分類，以促進利害關係人之間的溝通。它也簡要地解釋了什麼是分類以及它如何應用於系統之系統，以幫助理解和溝通。分類可以圍繞許多特徵展開，例如規模和範圍。

ISO/IEC/IEEE 21841 中的系統性之系統分類組織了系統之系統的相關面向或基本特徵，提供了與利害關係人關注點一致的特定視角。這種組織方式促進了參與系統之系統治理、工程、運作和管理等活動的各個利害關係人之間的溝通，並為其他相關標準提供了參考。

在描述或比較系統之系統 (SoS) 時，ISO/IEC/IEEE 21841 非常有用。

#### 5.4.4 系統生命週期階段的 SoS 考慮因素

ISO/IEC/IEEE 21839 提供了一系列 SoS 考慮因素，需要在系統之系統 (SoI) 生命週期的關鍵節點上加以考慮。這些考慮因素和關鍵節點與本文檔中介紹的內容一致。透過利害關係人的參與，可以在系統生命週期內應用這些考量的選定子集。最終目標是實現利害關係人的滿意，從而使交付的 SoI 能夠在通常由一個或多個系統之系統組成的運作環境中有效運作。

一個組成系統可以同時存在於多個 SoS 中。一個 SoS 通常由現有的組成系統以及新開發並整合到該 SoS 中的組成系統構成。 ISO/IEC/IEEE 21839 的重點在於組成系統本身。 ISO/IEC/IEEE 21839 中提供的考量涉及為使組成系統能夠在預期的系統之系統 (SoS) 配置中互動而必須考慮的生命週期。

當系統之系統 (SoI) 是 SoS 中的一個組成系統時（這是目前系統的典型情況），ISO/IEC/IEEE 21839 可以作為本文件的補充。

#### 5.4.5 本文件在 SoS 的應用

ISO/IEC/IEEE 21840 為在 SoS 的背景下使用本文件提供了指導。雖然本文件適用於一般系統（包括組成系統），但 ISO/IEC/IEEE 21840 為將這些流程應用於 SoS 這種特殊情況提供了指導。然而，ISO/IEC/IEEE 21840 並不能完全取代本文件在 SoS 中的應用。 ISO/IEC/IEEE 21840 旨在與本文件、ISO/IEC/IEEE 21839 和 ISO/IEC/IEEE 21841 搭配使用，不應作為獨立指南使用。

當系統整合 (SoI) 是系統系統 (SoS) 的一部分時，本文件中流程的應用取決於 SoS 生命週期的類型以及 SoS 互動對 SoI 的影響。在某些情況下，SoS 的修訂可能呈現「波浪式」變化。在其他情況下，SoS 的變更是持續進行的，許多流程持續運作以實現漸進式變更。

### 5.5 生命週期概念

#### 5.5.1 系統生命週期模型

每個系統都有一個生命週期。生命週期可以使用抽象的功能模型來描述，該模型表示系統需求的構思、實現、利用、演化和處置。

系統在其生命週期中不斷演進，這是由組織中的人員執行和管理的行動的結果，而這些行動又透過流程來執行。生命週期模型中的細節是透過這些過程、它們的結果、關係和順序來表達的。本文檔不規定任何特定的生命週期模型。相反，它定義了一組過程，稱為生命週期過程，可用於定義系統的生命週期。本文檔中所述的過程支援順序開發模型以及迭代和增量開發模型。此外，本文檔不規定生命週期模型中任何特定的製程順序。過程的順序由專案目標和系統生命週期模型的選擇決定。

#### 5.5.2 系統生命週期階段

生命週期會根據系統的性質、用途、使用方式和當前環境而有所不同。每個階段都有其獨特的目的，並對整個生命週期做出貢獻，在規劃和執行系統生命週期時都會考慮這些階段。生命週期模型包含一個或多個階段，取決於需求。它由一系列階段組成，這些階段可以是迭代的、並行的或重疊的，這取決於SoI的範圍、規模、複雜性、不斷變化的需求和機會。

這些階段代表了系統的主要生命週期時期，它們重新系統描述或系統本身的狀態存在滯後。這些階段描述了系統在其生命週期中的主要進展和里程碑，並由此產生了生命週期的主要決策關卡。這些決策關卡應用特定的決策標準，組織利用這些標準來理解和管理與系統業務案例、成本、進度、效能或功能相關的固有不確定性和風險。因此，這些階段提供了一個框架，使組織管理層能夠對技術管理和技術流程進行高階的了解和控制。 ISO/IEC/IEEE 24748-1 描述了這些流程在任何階段的應用，提供了關於決策關口的更多細節，並定義了典型的系統生命週期階段，包括：

- 概念；

- 開發；

- 生產；

- 利用；

- 支持；

- 退役。

請注意，生命週期階段（例如利用、支援、退役）和流程（例如運作、維護、處置）之間存在顯著差異。

組織會根據不同的策略採用不同的階段。生命週期階段通常同時發生，尤其是在連續、增量或演進式方法中。同時使用不同階段以及以不同順序使用，可以形成具有截然不同特徵的生命週期形式。

ISO/IEC/IEEE 24748-1 和 ISO/IEC/IEEE 24748-2 對這些概念進行了更詳細的闡述，它們提供了生命週期管理應用的指南。

註：生命週期中發生的事件、現象和演進的集合有時被稱為系統生命週期。根據 ISO 15704，生命週期是指系統在其生命週期內實際經歷的、已記錄的、配置管理的步驟序列。

### 5.6 過程概念

#### 5.6.1 過程標準

本文件中生命週期過程的認定是基於三個基本原則：

- 每個生命週期過程與其結果、活動和任務之間都存在著緊密的聯繫。

- 過程之間的依賴性應盡可能降低。

- 流程是指在生命週期內可由單一組織執行的流程。

#### 5.6.2 流程描述

本文檔中的每個流程均根據以下屬性進行描述：

- 標題概括了流程的整體範圍。

- 目的描述了執行流程的目標。

- 結果表達了流程成功執行後預期可觀察到的結果。

- 活動是流程中一系列相互關聯的任務。

- 任務是旨在支援結果實現的各項要求。

有關此流程描述形式的更多詳細信息，請參閱 ISO/IEC/IEEE 24774。輸出是流程描述的可選屬性。它們是工件或資訊項。 [附錄 B](#_bookmark127) 包含流程輸出的範例。

#### 5.6.3 過程的一般特徵

除了[5.6.2](#_bookmark73)中所描述的基本屬性外，過程還可以透過所有過程共有的其他屬性來表徵。 ISO/IEC 33000系列標準確定了表徵製程能力測量框架內六個實現等級的通用製程屬性。

### 5.7 本文檔中的流程

#### 5.7.1 概述

本文檔將系統生命週期中可執行的活動分為四個流程組：

a) 協商過程；

b) 組織專案支援過程；

c) 技術管理流程；

d) 技術過程。

各過程組及其所包含的過程如圖4所示。每個生命週期過程都根據其目的和預期結果進行描述，並列出為實現這些結果而可執行的一系列相關活動和任務。

本文檔中所述的流程並非旨在排除或阻止組織使用其認為有用的其他流程。本文檔中定義流程的子條款順序並未決定這些流程在系統生命週期或其任何階段的執行順序（即，沒有規定的順序或序列）。每個流程組的描述請參閱[5.7.2](#_bookmark78)至[5.7.5](#_bookmark81)。


##### 圖 4 — 系統生命週期流程

#### 5.7.2 協定流程

組織既是系統的生產者，也是系統的使用者。一個組織（作為採購者）可以向另一個組織（作為供應商）訂購產品或服務。這是透過協議實現的。協議使採購方和供應商都能實現價值，並支持其組織的策略。

通常，組織會同時或先後採取行動。系統生命週期流程既是系統的採購方，也是系統的供應商。當採購者和供應商位於同一組織時，協議流程可以以較為簡化的方式使用。同樣，在組織內部，也可以使用協議流程來明確組織、專案和技術職能部門各自的職責。

協議流程包括以下內容（另見[圖 4](#figure-4--system-life-cycle-processes)）：

a) 採購流程 – 組織用於採購產品或服務；

b) 供應流程 – 組織用於供應產品或服務。

這些流程定義了兩個組織之間達成協議所需的活動。如果啟動採購流程，它將提供與供應商互動的方式。這可能包括供應商提供的用於運行系統的產品、支援運行活動的服務，或供應商提供的系統組件。如果啟動供應流程，它將提供就提供給採購方的產品或服務達成協議的方式。

註 1：安全性是系統工程中日益重要的關注點。有關供應商和採購者如何在供應商關係中保障資訊安全的要求和指南，請參閱 ISO/IEC 27036 系列標準。 ISO/IEC 27036-3 和 ISO/IEC 27036-4 專門針對資訊安全供應商關係的具體方面進行了闡述。

當互操作系統 (SoI) 作為互操作系統 (SoS) 的一部分參與時，通常需要考慮協定流程執行過程中的資源和能力依賴性。根據需要，協議將包含關於互操作系統互動和依賴性的條款，或產生其他協定。這些流程適用於互操作系統的利害關係人與互操作系統之間的協定。如果存在外部實體，其職責涵蓋互操作系統（互操作系統是其組成系統），則可能需要與該外部實體達成管理和支援安排。這些協定在互操作系統參與互操作系統的背景下，確定了各利益相關組織在生命週期各階段的責任以及支援和控制模式。如果組織對其組成系統的主要目標可能與互操作系統的目標不直接一致，則這一點尤其重要。

註2：有關系統之系統（SoS）流程應用的更多信息，請參閱ISO/IEC/IEEE 21839和ISO/IEC/IEEE 21840。

#### 5.7.3 組織專案支援流程

組織專案支援流程旨在提供必要的資源，使專案能夠滿足組織利害關係人的需求和期望。組織專案支援流程通常在策略層面關注組織業務的管理和改進、資源和資產的提供與部署，以及在競爭或不確定情況下進行風險管理。

組織專案支援流程建構了專案開展的環境。組織制定專案使用的流程和生命週期模型；啟動、調整或取消專案；提供所需的資源，包括人力和財力；並制定和監控專案開發的系統和其他交付成果的品質指標，以滿足內部和外部客戶的需求。

組織專案賦能流程並非必然包含商業或獲利動機。組織專案賦能流程同樣適用於非營利組織，因為它們也對利害關係人負責，管理資源，並在其工作中面臨風險。本文檔既適用於非營利組織，也適用於營利組織。

此外，組織專案賦能流程並非旨在成為一套完整的組織流程，以支援組織的策略管理。

組織專案賦能流程包含以下內容（另見[圖4](#figure-4--system-life-cycle-processes)）：

a) 生命週期模型管理流程；

b) 基礎設施管理流程；

c) 專案組合管理流程；

d) 人力資源管理流程；

e) 品質管理流程；

f) 知識管理流程。

在典型的系統整合（SoI）中，組織專案賦能流程為專案實施提供必要的環境和資源，以解決系統問題。該組織制定專案使用的流程和生命週期模型；啟動、調整或取消專案；提供所需的資源，包括人力、物力和財力；並制定和監控專案為內部和外部客戶開發的系統和其他交付成果的品質指標。這些流程還為系統整合體 (SoI) 提供環境和資源，使其能夠支援其參與的系統整合體 (SoS) 所提供的功能。負責組成系統的組織獨立於系統整合體，為其自身的系統整合體實施這些流程。這些流程可能受到法規、介面標準或協定的影響，這些法規、介面標準或協定適用於系統整合體中那些對整體系統整合體功能做出貢獻的部分。

附註：有關系統整合體流程應用的更多信息，請參閱 ISO/IEC/IEEE 21839 和 ISO/IEC/IEEE 21840。

#### 5.7.4 技術管理流程

技術管理流程涉及管理組織管理層分配的資源和資產，並將其應用於履行組織或各組織所簽訂的協議。技術管理流程與專案的技術工作相關，特別是成本、時間進度和成果方面的規劃；檢查各項行動以確保其符合計劃和績效標準；以及識別和選擇糾正措施，以彌補進度和成果方面的不足。這些流程用於制定和執行專案技術計劃，管理技術團隊的訊息，評估系統產品或服務的技術進度是否符合計劃，控制技術任務直至完成，並輔助決策過程。根據計劃或突發事件的需要，可以在專案生命週期的任何階段以及專案層級的任何層級呼叫各級技術管理流程。技術管理流程的嚴格程度和正式程度取決於協議以及專案的風險和複雜性。

註1：技術管理是指「運用技術和管理資源來規劃、組織和控制工程職能」（ISO/IEC/IEEE 24765）。

通常，任何一個組織中都會同時存在多個專案。技術管理流程可以在公司層面應用，以滿足內部需求。

註2：技術管理流程應用於每個技術流程的執行過程。

技術管理流程可用於管理系統（包括產品或服務）生命週期中的技術活動。

註3：這組技術管理流程旨在確保系統特定技術流程的有效執行。它們並非管理系統或專案管理的完整流程集，因為這不在本文檔的討論範圍之內。

技術管理流程包括以下內容（另見[圖4](#figure-4--system-life-cycle-processes)）：

a) 專案規劃流程；

b) 專案評估與控制流程；

c) 決策管理流程；

d) 風險管理流程；

e) 配置管理流程；

f) 資訊管理流程；

g) 測量流程；

h) 品質保證流程。

專案規劃與專案評估與控制是所有管理實務的關鍵。這些流程確立了專案或流程管理的一般方法。該組中的其他流程則提供了一組針對特定管理目標的具體任務。它們適用於任何規模的管理，從整個組織到單一生命週期流程及其任務。本文檔以專案為例來描述流程。同樣的流程也適用於服務執行。

技術管理流程關注的是管理組織管理層分配的資源和資產，並將其應用於履行組織或多個組織簽訂的協議。技術管理流程需要考慮預期的系統之系統（SoS）互動。這些考慮涵蓋資源、風險以及與其他互動系統相關的依賴關係的規劃、評估和管理。例如，規劃、評估和控制活動需要包含與系統之系統（SoI）相關的成本和進度考量。這包括監控跨系統依賴關係領域的進展。協議流程用於在各利益相關方之間協商所需的資源。

註4：有關系統之系統流程應用的更多信息，請參閱 ISO/IEC/IEEE 21839 和 ISO/IEC/IEEE 21840。

#### 5.7.5 技術流程

技術流程關注的是整個生命週期中的技術活動。技術流程將利害關係人的需求轉化為產品或服務。透過應用該產品或營運該服務，技術流程可在需要的時間和地點提供可持續的效能，以滿足利害關係人的需求並實現目標。提升客戶滿意度。技術流程用於創建和使用系統，無論該系統是模型還是成品。

技術流程用於定義系統需求，將需求轉化為有效的產品，在必要時實現產品的一致性複製，使用產品，提供所需服務，維持這些服務的提供，並在產品退役時進行處置。

技術流程定義了使組織和專案職能部門能夠優化收益並降低技術決策和行動所帶來的風險的活動。這些活動使產品和服務具備採購和供應組織所需的及時性、可用性、成本效益以及功能性、可靠性、可維護性、可生產性、易用性和其他品質特性。它們也使產品和服務符合社會期望、倫理規範或法律法規要求。

技術流程包括以下幾個部分（另見[圖4](#figure-4--system-life-cycle-processes)）：

a) 業務或任務分析流程；

b) 利害關係人需求和要求定義流程；

c) 系統需求定義流程；

d) 系統架構定義流程；

e) 設計定義流程；

f) 系統分析流程；

g) 實現流程；

h) 整合流程；

i) 驗證流程；

j) 過渡流程；

k) 確認流程；

l) 運作流程；

m) 維護流程；

n) 處置流程。

註1：對於軟體和硬體系統元素，這些流程在系統定義階段遞歸地應用到較低層級，在系統實現階段遞歸地應用到較高層級。

註2：這些流程通常是並行執行，相互迭代，以建立一個在需求、關鍵效能指標、關鍵品質特性和系統之系統 (SoS) 考慮因素方面均達到平衡的解決方案。在任何抽象層次上，系統需求和模型都透過迭代執行適用的技術流程來保持一致。當需求和模型無法直接實現時，相同的流程會在整個系統結構中遞歸重複執行。

註3：介面管理是一組貫穿系統工程流程的活動。這些是技術和技術管理流程的交叉活動，它們作為流程和系統的特定視圖進行應用和追蹤。有關介面管理流程視圖的範例，請參見 ISO/IEC/IEEE 24748-1；有關更多信息，請參見 INCOSE-TP-2003-002-5，第三部分，第 3.2.4 節。

技術流程的重點是 SoI 整個生命週期中的技術操作。由於技術流程是為了在生命週期的各個階段提供和支援技術解決方案而執行的，因此 SoI 的系統系統 (SoS) 考慮因素包括對互動系統及其利害關係人和基礎設施的技術影響。 ISO/IEC/IEEE 21839 指出，「這包括系統基礎設施 (SoI) 所依賴的系統/服務，以及依賴 SoI 的系統/服務」。 SoI 參與的系統系統 (SoS) 配置可能會對 SoI 施加新的要求或約束，以支援所需的業務或任務能力。 SoS 技術考量適用於生命週期各階段的所有技術流程，並在業務或任務分析、利害關係人需求和要求定義、系統需求定義、系統架構定義和設計定義流程中發揮尤為重要的作用。

註 4：ISO/IEC/IEEE 21839 和 ISO/IEC/IEEE 21840 提供了有關 SoS 流程應用的更多資訊。

### 5.8 流程應用

#### 5.8.1 概述

本文檔中定義的生命週期流程可供任何組織在取得、使用、建立、修改或提供系統時使用。它們可以應用於系統結構的任何位置以及生命週期的任何階段。

這些流程的功能是根據具體目標、結果以及構成流程的活動和任務集來定義的。

[圖 4](#figure-4--system-life-cycle-processes) 中的每個生命週期流程都可以根據需要在整個生命週期的任何時間呼叫。這些流程的應用受系統生命週期中許多因素的影響，可能需要以迭代、遞歸或併發的方式應用這些流程。

[圖 5](#figure-5--interrelationships-between-processes) 展示了本文檔中定義的流程之間的相互關係。技術管理流程持續應用於管理和控制所有流程和生命週期階段。系統分析流程提供數據。系統生命週期流程每次迭代所需的資訊和數據，這些流程旨在支援任何技術管理流程 ([6.3](#_bookmark101)) 和技術流程 ([6.4](#_bookmark111))。

註：[圖 5](#figure-5--interrelationships-between-processes) 中的箭頭旨在顯示包括迭代、遞歸和並發應用在內的一般關係。並非所有可能的關係都包含在內。專案流程之間的實際流程或互動取決於專案的客製化和需求。此外，箭頭並非旨在指示任何特定的時間關係、順序或調度。流程組之間或流程組內流程聚合之間的箭頭旨在表明專案可以按任意順序應用流程，可以在流程之間迭代，並且可以並發執行它們。

系統所受影響因素的不斷變化（例如，運作環境的變化、系統元素實施的新機會、組織結構和職責的調整）要求持續審查流程的選擇和使用時機。生命週期中的流程使用可以是動態的，以回應系統所受到的許多外部影響，或回應來自持續開發方法的內部影響。生命週期方法還允許將變更納入下一階段。面對生命週期的複雜性，生命週期階段透過提供易於理解和識別的高階目標和結構，幫助規劃、執行和管理生命週期流程。生命週期階段內的流程集應用的共同目標是滿足該階段的退出標準或該階段正式進度評審的進入標準。這適用於任何生命週期模型或開發方法。

在品質風險合理的情況下，也可以建立特定產品或服務背景下的流程實例的詳細描述。流程實例化包括：根據需求識別流程實例的具體成功標準；以及根據本文檔中已確定的活動和任務，識別實現這些成功標準所需的具體活動和任務。建立流程實例的詳細描述，有助於建立流程與特定需求之間的聯繫，從而更好地管理品質風險。


##### 圖 5 — 流程之間的相互關係

本文檔中的流程通常採用基於模型的系統工程 (MBSE) 方法進行應用。 MBSE 使用一組模型來實現流程並達成預期結果。有關 MBSE 的信息，請參閱[附錄 D](#_bookmark133)。

#### 5.8.2 流程迭代、遞迴與並發

當在系統結構的同一層級上重複應用相同的流程或流程集時，此應用稱為迭代應用。流程的迭代使用對於逐步改進流程輸出至關重要。例如，連續的驗證操作和整合操作之間的互動可以逐步增強對產品或服務符合性的信心。迭代不僅是恰當的，也是必要的。流程或流程集的應用會產生新的資訊。通常，這些資訊以問題的形式出現，涉及需求、已分析的風險或機會。流程或流程集的迭代應用應持續進行，直到這些問題解決為止。

業務或任務分析、利害關係人需求和需求定義、系統需求定義、系統架構定義和設計定義流程之間經常進行迭代，以幫助就待解決的問題達成共識，並找到令人滿意的解決方案。系統分析和決策管理流程為這些迭代提供了強而有力的支持（參見[圖5](#figure-5--interrelationships-between-processes)）。流程產生的資訊應被所有其他系統生命週期流程分享和使用。

遞歸地使用流程，即對系統結構中不同層級的系統元素重複應用相同的流程或流程集，是本文檔應用的關鍵面向。從系統及其系統元素之間的關係來看，應用於某個系統或系統元素的流程的輸出（無論是資訊、工件或服務）都可以作為其他流程或其他系統元素的輸入，用於進一步分析或更概括地綜合其系統元素，從而獲得更詳細或更成熟的結果集。這種方法能夠為系統中不同層級的系統增添價值。系統生命週期流程的結構。

本子條款中關於系統生命週期流程的迭代和遞歸使用的討論，並非暗示系統、使能系統、組織或專案存在任何特定的層級、垂直或水平結構。

流程的並行使用可以存在於專案內部（例如，同時執行系統設計活動和準備活動），也可以存在於專案之間（例如，在不同的專案職責下同時設計系統元素）。所有流程都可以與其他流程並行使用。例如，運行和維護流程需要為系統需求定義、系統架構定義、設計定義和實作流程提供輸入。

#### 5.8.3 流程視圖

在某些情況下，需要對從不同流程中選擇的活動和任務進行統一的關注，以便清晰地展現貫穿整個生命週期流程的重要概念或主線。為此，我們提出了流程視圖的概念。與流程類似，流程視圖的描述也包含目標和結果的陳述。但與流程不同的是，流程視圖的描述不包含具體的活動和任務。相反，它包含指導原則，解釋如何透過運用各個生命週期流程的活動和任務來實現預期結果。關於流程視圖的詳細信息，請參閱 ISO/IEC/IEEE 24748-1 和 ISO/IEC/IEEE 24774。以下國際標準提供了一些技術視角的詳細資訊：

- ISO/IEC/IEEE 24748-1

- 專業工程；

- 介面管理；

- 安全性。

- ISO/IEC/IEEE 15026-4

- 系統保障；

- 軟體保障。

### 5.9 概念與系統定義

概念、需求和要求會隨著組織營運概念、策略或環境的建立或變化而在不同層面上演變。營運概念闡述了領導階層預期的組織運作方式。這項演進是透過應用業務或使命分析、利害關係人需求和要求定義、系統需求定義、系統架構定義和設計定義流程來實現的，並根據需要輔以其他流程。透過迭代和並行地使用所有這些流程，可以識別利益相關者，並深入了解組織、利害關係人和系統之間的概念、需求和要求之間的關係，以及系統元素和環境之間交互作用和關係所產生的湧現屬性和行為。

業務或使命分析流程分析組織營運概念、環境和其他策略投入的變化，以識別和定義為實現組織使命、願景、目標或目的而需要解決的關鍵問題或機會。業務或使命分析流程也識別、描述和優先排序可解決問題或機會的備選解決方案類別（或通用方法）。利害關係人利用利害關係人需求和要求定義流程，在已定義的問題或機會、所需相關能力以及首選解決方案類別的背景下，定義他們的概念、需求和要求。這包括定義解決方案的運作環境。運行概念闡述了系統將要做什麼以及為什麼這樣做。負責提供解決方案的工程團隊運用系統需求定義流程，將利害關係人的需求轉化為系統需求。在應用本文檔討論的三個流程時，會迭代和遞歸地運用一系列分析技術和權衡方法，將概念轉化為需求，並將需求轉化為系統需求（例如，任務分析、業務分析、運行分析、需求分析）。

註1：ISO/IEC/IEEE 29148 提供了更多關於概念、需求和系統需求開發的細節。它包含了本文檔討論流程的更詳細闡述，以及用於記錄運作概念、利害關係人需求和系統需求的註釋的概要。

系統架構定義流程著重於定義一個能夠解決利害關係人關注點的架構，並與業務或任務分析、利害關係人需求定義和系統需求定義流程迭代且並行地應用，以確定解決利害關係人關注點的最佳方案。另一方面，設計定義過程是由經過評估驗證的需求所驅動的。架構和更詳細的可行性分析。架構著重於適用性、可行性和期望性，而設計著重於與技術和其他設計元素的兼容性，以及建構和整合的可行性。有效的架構應盡可能與設計無關，以便在設計權衡空間中實現最大的靈活性。

設計定義過程向系統架構定義過程提供回饋，以鞏固或確認架構實體（例如策略目標、能力和效果、營運活動、資源功能）與構成系統的系統元素之間的分配、劃分和對齊。請注意，架構實體（正在建構架構的實體或受系統架構定義過程約束的實體）和系統元素（滿足特定要求的系統的離散部分）代表兩個不同的概念。

註2：系統架構定義的實務、約定、原則和概念由ISO/IEC/IEEE 420x0系列標準規定。 ISO/IEC/IEEE 42020提供了架構治理、管理、概念化、評估和細化的架構流程； ISO/IEC/IEEE 42030 提供了一個架構評估框架，用於執行架構分析、價值評估和評估綜合；ISO/IEC/IEEE 42010 則提供了描述架構的關鍵原則和概念。

企業架構或相關的參考架構（如有）可在系統架構的整個生命週期中為系統架構提供有用的見解。此外，當組織或企業被視為系統架構時，企業架構就成為系統定義的重要組成部分，因為它是頂層系統架構。

本條款中討論的流程與其他技術流程和技術管理流程交互，以提供必要的輸入和資訊。例如，系統分析流程提供分析結果，以支援決策管理流程所管理的權衡取捨。此外，概念、需求、架構和設計的建立也受到其他技術流程（例如維運流程）的指導。

### 5.10 保證和品質特性

保證是指有充分理由相信某項聲明已經實現或將會實現。這種信心是透過應用適用的系統生命週期活動來實現的，這些活動包括採用計劃周密、系統化的方法，並採取可接受的系統保障措施和可利用漏洞的風險管理措施。利害關係人在依賴系統之前需要獲得保障，尤其是在系統複雜、新穎或技術存在歷史問題的情況下。依賴程度越高，對強保障的需求就越大。系統保障聲明通常涉及系統的功能或能力。

保障，例如對安全性、可靠性和穩定性等各種屬性的保障，通常是必要的。利害關係人關注的問題包括：如何確保系統在實現其預期目標的同時，不會產生非預期行為或後果。以聲明為導向的保障方法有助於解決那些通常未包含在專注於預期行為的需求中的擔憂。保障案例可以識別需求覆蓋範圍的差距，並為制定衍生需求以彌補這些差距提供資訊。

保障通常是透過建構保障案例的活動來實現的。保證案例是一種可審計的成果，它基於特定背景下的實際證據，為一項主張提供令人信服且有效的論證。要組織種類繁多、數量龐大的證據並將其與主張聯繫起來，需要精妙而複雜的論證。證據可以是測試的合格/不合格結果、定量測量或定性評估。當這些證據被整合到一個連貫的論證中時，需要仔細檢視其有效性、確定性、公平性等。通常，所提供的證據與整體主張之間並不存在簡單的直接聯繫，因此必須建構一個結構來描述子主張以及將整體主張與證據聯繫起來的推理。

專注於特定特性的保證案例包括安全案例、組合保證包（針對安全性）和可靠性案例。

保證活動應貫穿整個系統生命週期，並融入生命週期流程。建置保證案例需要對系統需求（SoI）和所考慮的特性有深入的了解。將具體分析納入SoI（意向聲明）的製定過程中，並讓專家參與SoI的製定，是實現合規且平衡的系統的關鍵成功因素。解決方案。

註：ISO/IEC/IEEE 15026 系列標準提供了有關系統和軟體保證及保證案例的更多資訊。

其他文件提供了有關特定特性要求的考慮因素，包括 IEC 61508 系列標準（安全性）；ISO/IEC 27000 和 ISO/IEC 15408-3（資訊安全）；IEC 60300-1 和 IEC 62741（可靠性）；以及 ISO/IEC 25000-1 和 IEC 62741（可靠性）；以及 ISO/IEC 25000-1）。

### 5.11 過程參考模型

[附錄 C](#_bookmark129) 定義了[條款 6](#_bookmark90) 中所包含的過程的過程參考模型。此過程參考模型適用於正在評估其流程以確定這些流程能力的組織。目的和結果是對每個過程績效目標的陳述。此目標聲明允許以除簡單符合性評估之外的其他方式評估流程的有效性。

## 6 系統生命週期流程

### 6.1 協定流程

#### 6.1.1 採購流程

##### 6.1.1.1 目的

採購流程的目的是根據採購方的要求取得產品或服務。

附註：作為此流程的一部分，當採購方和供應商均同意變更請求時，協議將被修改。

##### 6.1.1.2 結果

成功完成採購流程後：

a) 編製供貨請求；

b) 選擇一個或多個供應商；

c) 採購者與供應商之間達成協議；

d) 接受符合協議的產品或服務；

e) 履行協議中規定的採購方義務；

f) 依協議規定，轉移所購買產品或服務的責任。 6.1.1.3 活動和任務

收購方應根據適用的組織政策和程序，在收購過程中實施以下活動和任務。

註1：本流程的活動及最終達成的協議通常適用於供應鏈中的供應商，包括分包供應商。

a) 為收購做好準備。此項活動包括以下任務。

1) 制定收購策略。

註2：如果供應商是收購組織外部的，則該策略應描述或參考生命週期模型、風險和問題緩解措施、里程碑和決策節點計劃以及選擇標準。此外，還應包括收購的關鍵驅動因素和特徵，例如責任和義務；具體模型、方法或流程；重要性等級；正式程度；以及相關權衡因素的優先順序。

2) 準備一份包含需求的商品或服務供應請求。

註3：如果供應商是組織外部的，則需求通常包括供應商應遵守的規格以及選擇供應商的標準。

註4：向一個或多個供應商提供需求定義。根據採購方式的不同，需求可能是利害關係人需求或系統需求，並透過相關的需求定義流程來確定。

b) 發佈採購公告並選擇供應商。此活動包含以下任務：

1) 向潛在供應商傳達產品或服務供應需求。

2) 選擇一個或多個供應商。

註5：為了取得競爭性報價，需要對供應提案進行評估，並根據選擇標準進行比較和排名。每個提案的評級理由都會被公佈，並且供應商會被告知其被選中或未被選中的原因。

c) 建立並維護協議。此活動包含以下任務：

註6：透過專案評估和控制流程監控專案成本、進度和績效。任何需要修改協議的問題都將提交此活動。任何對系統元素或資訊進行變更的提議均透過配置管理流程中的變更管理活動進行控制。

註7：對於系統之系統 (SoS)，如果存在多邊協議，則在參與 SoS 的利害關係人之間，應在生命週期的各個階段明確各自的責任、支持和控制模式。協議應具有靈活性，以適應 SoS 不斷變化的需求，而 SoI 正是 SoS 的組成系統。

1) 與供應商制定並批准包含驗收標準的協議。

註8：該協議的正式程度不一，從書面合約到口頭協議均可。根據正式程度，協議應明確需求、開發和交付里程碑、驗證、確認和驗收條件以及流程要求（例如配置管理、風險管理）。（例如，衡量標準、異常處理程序、協議變更管理程序、付款計劃、違約時各方的責任以及資料權利和智慧財產權的處理），以便協議雙方理解執行協議的基礎。對於書面合同，這在合約簽署時即完成。

註9：協議明確了對參與分包商的任何要求。

2) 確定協議的必要變更。

註10：在要求變更協議時，採購方或供應商應詳細說明其具體要求、理由和背景。

3) 評估變更對協議的影響。

註11：任何變更都應調查其對專案計畫、進度、成本、技術能力和品質的影響。變更可以在現有協議範圍內處理，也可能需要修改協議，或需要簽訂新協議。

4) 根據需要與供應商更新協議。

註12：協議修改的結果將納入專案計劃，並傳達給所有相關方。

d) 監控協議。此項活動包含以下任務：

1) 評估協議的執行情況。

註13：這包括確認所有各方均依照協議履行其職責。專案評估和控制流程用於評估預期成本、進度、績效以及不良後果對組織的影響。這些資訊將與其他協議條款執行情況的評估結果結合。

2) 提供供應商所需的數據並及時解決問題。

e) 驗收產品或服務。此項活動包含以下任務：

1) 確認交付的產品或服務符合協議規定。

註14：在協議執行過程中或交付的產品或服務中出現的任何例外情況，均應依照協議中規定的程序進行解決。

註15：驗收可以透過驗證流程進行。

2) 支付款項或其他約定的對價。

3) 根據協議指示，從供應商或其他方接收產品或服務。

4) 終止協議。

註16：專案透過專案組合管理流程終止。

#### 6.1.2 供應流程

##### 6.1.2.1 目的

供應流程的目的是向採購方提供符合約定要求的產品或服務。

附註：作為此流程的一部分，當採購方和供應商均同意變更請求時，協議將被修改。

##### 6.1.2.2 結果

成功完成供應流程後：

a) 確定產品或服務的採購者；

b) 回應採購方的請求；

c) 採購者與供應商之間達成協議；

d) 提供產品或服務；

e) 履行協議中規定的供應商義務；

f) 依協議規定，所收購產品或服務的責任轉移。

##### 6.1.2.3 活動與任務

供應商應根據適用的組織政策和程序，在供應流程中實施以下活動和任務。

a) 準備供應。此活動包括以下任務。

1) 確定是否有需要產品或服務的採購方及其身分。

註1：潛在採購方通常透過業務或任務分析流程進行識別。對於面向消費者的產品或服務，採購者通常由供應商組織內部的某個代理商（例如行銷部門）代表。

2) 制定供應策略。

註2：此策略描述或參考生命週期模型、風險和問題緩解措施以及里程碑計畫。它還包括採購的關鍵驅動因素和特徵，例如責任和義務；具體模型；方法或流程；重要性等級；正式程度；以及相關權衡因素的優先順序。

b) 回應產品或服務供應請求。此項活動包含以下任務：

1) 評估產品或服務供應請求，以確定其可行性及回應方式。

2) 準備滿足請求要求的回應。

c) 建立並維護協議。此項活動包含以下任務：

1) 與採購方協商並批准包含驗收標準的協議。

註3：該協議的形式多種多樣，從書面合約到口頭協議均有涵蓋。根據協議的形式，協議應明確要求、開發和交付里程碑、驗證、確認和驗收條件以及流程要求。要求（例如配置管理、風險管理、度量）、異常處理程序、協議變更管理程序、付款計劃、各方在未履行協議時的責任，以及資料權利和智慧財產權的處理，以便協議雙方理解執行協議的基礎。對於書面合同，這在合約簽署時即完成。

註 4：對於系統之系統 (SoS)，如果存在多邊協議，則在參與 SoS 的利害關係人之間，應在生命週期的各個階段建立責任以及支援和控制模式。協定具有靈活性，可以適應 SoS 不斷變化的需求，而 SoI 是 SoS 的組成系統。

2) 確定協議的必要變更。

註 5：在要求變更協議時，採購方或供應商應詳細說明其規範、理由和背景。

3) 評估變更對協議的影響。

註 6：任何變更都應調查其對專案計畫、進度、成本、技術能力或品質的影響。變更可以在現有協議範圍內處理，也可能需要修改協議，或需要簽訂新協議。

4) 根據需要，與收購方更新協議。

註7：協議修改的結果將納入專案計劃，並傳達給所有相關方。

d) 執行協議。此活動包含以下任務。

1) 根據既定的專案計畫執行協議。

註8：供應商有時會採用或同意使用收購方的流程。

2) 評估協議的執行情況。

註9：這包括確認所有各方均依照協議履行其職責。專案評估和控制流程用於評估預期成本、進度、績效以及不良後果對組織的影響。配置管理流程中的變更管理活動用於控制系統元素的變更。此資訊將與其他協議條款執行情況的評估相結合。

e) 交付並支援產品或服務。此活動包含以下任務：

1) 根據協議標準交付產品或服務。

2) 根據協議，為接收者提供已交付產品或服務的支援。

3) 接受並確認付款或其他約定的對價。

4) 根據協議指示，將產品或服務移交給接收方或其他方。

5) 完成協議。

註 10：專案透過專案組合管理流程完成。

### 6.2 組織專案支援流程

#### 6.2.1 生命週期模型管理流程

##### 6.2.1.1 目的

生命週期模型管理流程的目的是定義、維護並確保組織在本文範圍內使用的政策、生命週期流程、生命週期模型和程序的可用性。

此流程提供與組織目標一致的政策、生命週期流程、生命週期模型和程序。這些生命週期資產經過定義、調整、改進和維護，以支援各個專案的特定需求，並能夠使用有效且經過驗證的方法和工具進行應用。

註：受監管領域有時需要特定的生命週期管理流程標準，例如 ANSI/AAMI/IEC 62304。

#### 6.2.1.2 成果

生命週期模型管理流程成功實施後，將達成以下目標：

a) 建立組織用於管理和部署生命週期模型和流程的政策和程序；

b) 明確生命週期政策、流程、模型和程序中的角色、職責、問責制和權限；

c) 選擇組織所使用的政策、生命週期流程、生命週期模型和程序；

d) 評估組織所使用的政策、生命週期流程、生命週期模型和程序；

e) 實施優先的流程、模型和程序改進。

#### 6.2.1.3 活動與任務

組織應根據其適用的政策和程序，實施以下與生命週期模型管理流程相關的活動和任務。

a) 建立生命週期流程。此活動包含以下任務。

註1：專案內生命週期實施的細節取決於工作的複雜性、所採用的方法以及參與執行工作的人員的技能和訓練。專案會根據自身需求和要求調整政策、流程、模型和程序，同時保持與法規的一致性。國家戰略和組織政策。

1) 制定與組織策略一致的流程管理和部署的政策和生命週期程序。

2) 制定符合本文件要求且與組織策略一致的生命週期流程。

3) 明確角色、職責、問責制和權限，以促進生命週期流程的實施和生命週期的策略管理。

4) 定義控制生命週期進展的標準。

註2：已確定進入和退出每個生命週期階段的決策標準以及關鍵里程碑和決策關卡。

5) 為組織建立由多個階段組成的標準生命週期模型，並定義每個階段的目標和預期成果。

註3：生命週期模型包含一個或多個階段，視需要而定。它由一系列重疊或迭代的階段組成，取決於SoI的範圍、規模、複雜性、不斷變化的需求和機會。 ISO/IEC/IEEE 24748-1 標準以常見的生命週期階段範例來說明各個階段。生命週期過程和活動經過選擇、適當調整後應用於各個階段，以實現該階段的目標和預期成果。

b) 評估生命週期過程。此活動包含以下任務。

註 4：ISO/IEC 33000 系列標準提供了一套更詳細的過程評估活動和任務，與下列任務相對應。

1) 監控整個組織的過程執行。

註 5：這包括分析過程指標並根據策略標準審查趨勢，收集專案關於過程有效性和效率的回饋，以及根據法規和組織政策監控執行情況。

2) 定期檢視專案使用的生命週期模型。

註 6：這包括確認專案使用的生命週期模型是否持續適用、充分和有效，並根據需要進行改進。這包括控制生命週期進展的各個階段、流程和成果標準。

3) 從評估結果中辨識改進機會。

C) 改善流程。此活動包含以下任務。

1) 確定改善機會的優先順序並制定計畫。

2) 實施改進機會並通知相關利害關係人。

註 7：流程改善包括組織內任何流程的改進。經驗教訓將被記錄並可供查閱。

#### 6.2.2 基礎架構管理流程

##### 6.2.2.1 目的

基礎設施管理流程的目的是為專案提供基礎設施和服務，以支援組織和專案在整個生命週期內的目標。

此流程定義、提供和維護組織在本文檔範圍內所需的設施、工具以及通訊和資訊科技資產。

#### 6.2.2.2 成果

成功實施基礎設施管理流程後，將達成以下目標：

a) 明確基礎設施需求；

b) 基礎設施要素已明確；

c) 基礎設施要素已取得；

d) 基礎設施可用；

e) 已實施優先的基礎設施改善措施。

##### 6.2.2.3 活動與任務

組織應根據適用的組織政策和程序，在基礎設施管理流程中實施以下活動和任務。

a) 建立基礎設施。此活動包含以下任務。

1) 確定專案基礎設施需求。

註1：基礎設施要素範例包括設施、工具、硬體、軟體、服務和標準。

註2：應結合組織內的其他專案和資源，以及組織的政策和策略規劃，考慮專案的基礎設施資源需求。同時，也應評估影響和控制專案基礎設施資源和服務提供的約束條件和時間節點。專案計劃和未來策略需求有助於理解所需的資源基礎設施。此外，還應考慮物理因素（例如設施）、物流需求和人為因素（包括健康和安全方面）。

註3：ISO/IEC 27036系列標準為外包基礎設施的安全問題提供了指導。

2) 識別、取得並提供實施和支援專案所需的基礎設施資源和服務。

註4：通常會建立資產清單登記冊，用於追蹤基礎設施元素並支援其重複使用。

b) 維護基礎設施。活動包含以下任務：

1) 評估已交付的基礎設施資源滿足專案需求的程度。

2) 根據需要識別並改善或變更基礎設施資源。

#### 6.2.3 專案組合管理流程

##### 6.2.3.1 目的

專案組合管理流程的目的是啟動並維持必要、充足且合適的項目，以實現組織的策略目標。

此流程承諾投入充足的組織資金和資源，並授權開展選定的專案。它持續評估項目，以確認是否值得繼續投資，或是否可以調整方向以證明繼續投資的合理性。

##### 6.2.3.2 成果

成功實施專案組合管理流程的成果包括：

a) 確定策略性投資機會、投資或必需品的優先順序；

b) 確定項目；

c) 為每個項目分配資源和預算；

d) 明確專案管理職責、問責制和權限；

e) 維持符合協議和利害關係人要求的項目；

f) 調整或終止不符合協議或利害關係人要求的項目；

g) 完成協議並滿足利害關係人要求的項目予以結項。

##### 6.2.3.3 活動與任務

組織應根據適用的組織政策和程序，在專案組合管理流程中實施以下活動和任務。

a) 定義並授權項目。此活動包含以下任務。

1) 辨識潛在的新增或修改的能力或任務。

註1：檢視組織策略、運作概念或差距/機會分析，以發現當前的差距、問題或機會。新的能力或策略需求通常在業務或任務分析過程中確定，在利害關係人需求和要求定義過程中進一步定義，並透過此流程進行管理。

2) 確定優先級，選擇並建立新的策略機會、專案或計劃。

註2：這些通常與組織的策略和行動計劃一致。潛在項目會進行優先排序，並設定閾值以確定哪些項目將被執行。通常會確定已識別專案的特徵，包括利害關係人的價值、風險和成功障礙、依賴關係和相互關係、約束條件、資源需求以及資源競爭情況。然後，對每個潛在項目的成功可能性和成本效益進行評估。決策管理和系統分析流程提供了有關如何進行替代方案分析的詳細資訊。

3) 定義項目、職責和權限。
該
4) 確定每個項目的預期目標、目的和成果。

5) 確定並指派用於實現專案目標和目的的資源。

6) 確定每個專案需要管理或支援的任何多專案介面和依賴關係。

註3：這包括多個項目使用或重複使用支援系統，以及多個項目使用或重複使用通用系統元素。

註4：在整體（策略或企業）架構或系統之系統（SoS）環境中理解每個項目，有助於確保識別介面和約束。

7) 明確專案報告要求，並檢視每個專案執行的里程碑。

8) 授權每個專案開始執行專案計畫。

註5：專案規劃流程中提供了有關製定專案計畫的更多資訊。專案計劃在專案生命週期的早期制定和批准最為有效。

b) 評估項目組合。此活動包含以下任務。

1) 評估項目以確認其持續可行性。

註6：可行性包括以下內容：

a) 專案正朝著實現既定目標和目的穩步推進。

b) 項目符合項目指令。

c) 專案正在依照專案生命週期政策、流程和程序進行。

d) 專案仍然可行，例如，服務需求持續存在、產品實施實際且投資收益可接受。

2) 繼續推動進展順利的專案。

3) 調整專案方向，使其在適當調整後仍能順利進行。

c) 終止項目。此項活動包含以下任務：

1) 在協議允許的情況下，取消或暫停那些對組織弊大於利的項目。持續投資。

2) 產品和服務協議完成後，採取行動結束專案。

註7：專案結束應依照組織政策和程序以及協議完成。

#### 6.2.4 人力資源管理流程

##### 6.2.4.1 目的

人力資源管理流程的目的是為組織提供必要的人力資源，並根據策略需求保持其能力。

此流程提供技能嫻熟、經驗豐富的員工，使其能夠執行生命週期流程，從而實現組織、專案和利害關係人的目標。

##### 6.2.4.2 成果

成功實施人力資源管理流程後，將達成以下目標：

a) 確定專案所需的技能；

b) 為專案提供必要的人力資源；

c) 培養、維持或提升員工技能；

d) 解決人事衝突。

##### 6.2.4.3 活動與任務

組織應根據適用的組織政策和程序，在人力資源管理流程中實施以下活動和任務。

a) 辨識技能。此活動包含以下任務。

1) 根據目前和預期項目識別技能需求。

2) 辨識並記錄員工技能。

b) 培養技能。此活動包含以下任務。

1) 制定技能發展策略。

註1：此策略包括訓練類型和等級、人員類別、進度安排、人員資源需求和訓練需求。

2) 取得或發展訓練、教育或指導資源。

註2：這些資源包括組織或外部機構開發的培訓材料、外部供應商提供的培訓課程或電腦輔助教學。

3) 提供計畫內的技能發展。

4) 維護技能發展記錄。

c) 取得和提供技能。此活動包含以下任務。

註3：這包括招募和留住具備專案所需經驗和技能的人員；對員工進行評估和審查，例如他們的熟練程度、積極性、團隊合作能力，以及是否需要再培訓、重新分配或重新調配。

1) 當發現技能短缺時，取得合格人員。

註4：這包括使用外包資源。

2) 維護和管理滿足正在進行的專案所需技能人員儲備。

3) 根據專案和員工發展需求進行專案分配。

4) 激勵員工，例如透過職涯發展和獎勵機制。

5) 解決專案之間或專案內部的人員衝突。

註5：這包括正在進行的專案之間在組織架構、支援服務和人員資源方面的能力衝突；或專案人員過度投入所造成的衝突。

#### 6.2.5 品質管理流程

##### 6.2.5.1 目的

品質管理過程的目的是確保產品、服務以及品質管理過程的實施符合組織和專案的品質目標，並實現客戶滿意。

##### 6.2.5.2 成果

成功實施品質管理流程後，將實現以下目標：

a) 組織品質管理政策、目標和程序得以實施；

b) 品質評估標準和方法得以建立；

c) 為專案提供資源和訊息，以支援專案品質保證活動的運作和監控；

d) 分析品質保證評估結果；

e) 根據專案和組織的成果改善品質管理政策和程序。

註：以上成果的編寫符合 ISO 9001:2015 4.4.1 的規定。有關如何建立完整的品質管理系統的信息，請參閱 ISO 9001。

##### 6.2.5.3 活動與任務

組織應根據適用的組織政策和程序，實施以下與品質管理流程相關的活動和任務。

a) 規劃品質管理。此活動包含以下任務。

1) 制定品質管理政策、目標和程序。

註1：ISO 9001 是品質管理系統的流程模型。 ISO 9004 包含績效改善指南。受監管領域有時需要特定的品質管理流程標準，例如 ISO 13485。

註2：政策、目標和程序應基於組織的客戶滿意度策略。

2) 明確品質管理實施的責任和權限。
該
註3：為確保品質管理獨立於專案管理，品質管理資源通常由不同的組織分配。

3) 定義品質。評估標準和方法。

4) 提供品質管理所需的資源和資訊。

b) 評估品質管理。此項活動包含以下任務：

1) 根據既定標準收集和分析品質保證評估結果。

2) 評估客戶滿意度。

註4：ISO 10004 包含監控和衡量顧客滿意度的指南。

3) 定期檢視專案品質保證活動，以確保其符合品質管理政策、目標和程序。

4) 監控流程、產品和服務品質改進的進度。

c) 執行品質管理糾正和預防措施。此項活動包含以下任務：

1) 當品質管理目標未實現時，制定糾正措施。

2) 當有足夠的品質管理目標無法實現的風險時，制定預防措施。

3) 監控糾正和預防措施的完成情況，並通知相關利害關係人。

註5：糾正和預防措施的實施在其他相關流程中進行，例如生命週期模型管理或專案評估與控制。

#### 6.2.6 知識管理流程

##### 6.2.6.1 目的

知識管理流程的目的是創造能力和資產，使組織能夠抓住機會重新應用現有知識。

這涵蓋知識、技能和知識資產，包括系統要素。

##### 6.2.6.2 成果

成功實施知識管理流程後，將達成以下目標：

a) 確定知識資產應用分類；

b) 組織知識、技能和知識資產得到整理；

c) 組織知識、技能和知識資產可供使用；

d) 組織知識、技能和知識資產在組織內溝通；

e) 分析知識管理使用資料。

##### 6.2.6.3 活動與任務

組織應根據適用的組織政策和程序，實施以下與知識管理流程相關的活動和任務。

a) 制定知識管理計畫。此活動包含以下任務。

1) 定義知識管理策略。

註1：知識管理策略通常包括：

a) 辨識知識領域及其知識再應用潛力；

b) 制定獲取和維護知識、技能和知識資產的計劃，以確保其使用壽命；

c) 明確待收集和維護的知識、技能和知識資產的類型；

d) 制定知識、技能和知識資產的接收、鑑定和淘汰標準；

e) 制定控制知識、技能和知識資產變更的程序；

f) 制定保護、控制和存取機密或敏感資料和資訊的計畫、機制和程序；

g) 制定儲存和檢索機制。

註2：知識管理包括組織內部共享的知識，以及受智慧財產權和保密協議約束的、與組織外部的利害關係人、收購者和合作夥伴共享的知識。

2) 辨識需要管理的知識、技能和知識資產。

3) 辨識能夠受益於應用這些知識、技能和知識資產的項目。

b) 在整個組織內共享知識和技能。此活動包含以下任務：

1) 建立並維護一個用於在整個組織內捕獲和共享知識和技能的分類體系。

註3：此分類體系包括專家知識與技能、一般知識與技能以及領域知識與技能，以及經驗教訓。

2) 捕獲或獲取知識和技能。

3) 使組織能夠存取這些知識和技能。

c) 在整個組織內共享知識資產。此活動包含以下任務：

1) 建立知識資產分類體系。

註4：此分類法包括以下內容：

a) 定義領域邊界及其與其他領域的關係；

b) 領域模型，用於捕捉必要的共同特徵和差異特徵、能力、概念和功能；

c) 領域內一系列系統的架構，包括它們的共同特徵和差異特徵。

註5：有關產品線知識資產的更多信息，請參閱 ISO/IEC 26550；有關架構框架、視點、模型類型、視圖和模型的知識資產，請參閱 ISO/IEC/IEEE 42010。

2) 開發或取得知識資產。

註6：知識資產包括系統元素或其表示形式（例如，可重複使用程式碼庫、參考架構）、架構或設計元素（例如，架構或設計模式）、流程、標準或其他技術資訊。n（例如培訓材料）與領域知識和經驗教訓相關。

3) 使組織能夠存取知識資產。

d) 管理知識、技能和知識資產。此項活動包含以下任務：

1) 維護知識、技能和知識資產。

2) 監控並記錄知識、技能和知識資產的使用。

3) 定期重新評估知識資產的技術和市場需求。

### 6.3 技術管理流程

#### 6.3.1 專案規劃流程

##### 6.3.1 目的

專案規劃流程的目的是製定和協調有效且可行的計劃。

此流程確定專案管理和技術活動的範圍，識別流程產出、任務和交付成果，制定任務執行進度計畫（包括完成標準）以及完成任務所需的資源。這是一個貫穿整個專案的持續性流程，需要定期修訂計劃。 ISO/IEC/IEEE 16326 提供了關於專案規劃的補充資訊。

註：其他各流程定義的策略作為輸入，整合到專案規劃流程中。專案評估與控制流程用於評估計劃是否整合、協調一致且可行。任何計劃修訂均需經專案管理計劃中規定的授權機構批准。

#### 6.3.1.2 成果

專案規劃流程成功實施後，將達成以下目標：

a) 明確目標和計劃；

b) 明確專案內的角色、職責、問責制和權限；

c) 明確績效和成果標準；

d) 落實實現目標所需的資源與服務；

e) 啟動專案執行計劃。

#### 6.3.1.3 活動與任務

以下活動和任務應根據組織關於專案規劃流程的適用政策和程序執行。

a) 定義項目。此活動包含以下任務。

1) 明確專案目標、假設和限制條件。

註1：目標和限制條件包括策略目標、性能和其他品質方面、成本、進度和客戶滿意度。每個目標都需詳細定義，以便選擇、調整和實施相應的流程和活動。

2) 根據協議確定專案範圍。

註2：專案範圍包括滿足決策標準並成功完成專案所需的所有相關活動。一個專案可以負責整個系統生命週期中的一個或多個階段。規劃包括制定維護專案計劃、執行評估和控制專案的適當措施。

3) 定義並維護一個生命週期模型，該模型應包含組織已定義的生命週期模型的各個階段。

註3：ISO/IEC/IEEE 24748-1 提供了有關生命週期階段和代表性生命週期模型定義的詳細資訊。有關生命週期模型和階段的信息，請參閱[5.5.2](#_bookmark70)和 ISO/IEC/IEEE 24748-1。

4) 建立適當的分解結構。

註 4：每個要素的描述詳細程度應與已識別的風險和所需的可見性一致。典型的分解結構包括工作分解結構、功能分解結構、系統分解結構和組織分解結構。工作分解結構中的相關任務被分組為專案任務。 《PMI®[^1] 工作分解結構實務標準》[[68](#_bookmark138)] 包含更多詳細資訊。

[^1]：PMI® 是專案管理協會的商標。提供此資訊是為了方便本文檔的用戶，並不構成 ISO 對所提及產品的認可。

5) 定義並維護將應用於專案的生命週期流程。

註 5：這些流程是基於組織已定義的流程（請參閱生命週期模型管理流程）。流程的定義可以包括：准入標準；退出標準；輸入；輸出；流程順序約束（前置/後置關係）；流程並發性要求（哪些流程和任務與其他流程領域的任務或活動同時進行）；以及範圍和成本參數（用於至關重要的成本估算）。

b) 規劃專案和技術管理。此活動包含以下任務。

1) 根據專案目標和工作量估算，制定並維護進度計畫。

註 6：這包括定義活動的持續時間、關係、依賴性和順序；里程碑；所用資源；評審；以及用於風險管理的進度儲備。為確保專案按時完成，必須滿足以下條件：

2) 定義生命週期各階段決策點、交付日期以及對外部輸入或輸出的主要依賴關係的達成標準。

3) 定義專案績效標準。

4) 定義成本並制定預算。

註7：成本基於進度計劃、人工成本估算、基礎設施成本、採購項目、已購服務和支援系統估算以及風險管理預算儲備。

5) 定義角色、職責、問責制和權限。
該
註8：這包括定義專案組織架構、人員配置和人員技能發展。權限包括（如適用）具有法律責任的角色和個人，例如設計授權、安全授權以及認證或認可的授予。

6) 定義所需的基礎設施和服務。

註9：這包括定義所需容量、其可用性及其在專案任務中的分配。基礎設施包括設施、工具、通訊和資訊科技資產。也需明確每個生命週期階段對支援系統的要求。

7) 規劃從專案外部取得材料和支援系統服務的採購。

註10：這包括必要的招標、供應商選擇、驗收、合約管理和合約終止計畫。計劃採購將採用協議流程。

註11：ISO/IEC 27036系列標準為基礎設施和服務採購提供了指導。

8) 制定並傳達專案和技術管理及執行計劃，包括評審。

註12：系統的技術規劃通常體現在系統工程管理計畫 (SEMP) 中（請參閱ISO/IEC/IEEE 24748-4），或軟體工程管理計畫。軟體系統的開發計劃通常體現在軟體開發計劃中（參見ISO/IEC/IEEE 24748-5）。

註13：其他各流程的策略活動和任務為專案規劃流程提供輸入，並整合到其中。專案評估和控制流程用於確保計劃的整合性、一致性和可行性。

c) 啟動專案。此活動包含以下任務：

1) 取得項目授權。

註 14：專案組合管理流程提供授權。

2) 提交申請並獲得執行專案所需資源的承諾。

3) 執行專案計劃。

#### 6.3.2 專案評估與控制流程

##### 6.3.2.1 目的

專案評估與控制流程的目的在於評估計劃是否協調一致且可行；確定專案、技術和流程的績效狀態；並指導執行，以確保績效符合計劃和進度安排，在預算範圍內，並滿足專案目標。

此流程定期以及在重大事件發生時，評估專案進度和成果與需求、計劃和整體策略目標的對比情況。當發現重大偏差時，會提供資訊供管理層採取行動。此流程還包括根據需要調整專案活動和任務，以糾正已發現的與其他技術管理或技術流程的偏差和差異。必要時，可能需要重新規劃。

##### 6.3.2.2 成果

專案評估和控制流程成功實施後，將實現以下目標：

1. 獲得績效指標或評估結果；

2. 評估角色、職責、問責、權限和資源的充足性；

3. 進行技術進度審查；

4. 分析專案績效與計畫的偏差；

5. 將專案狀態告知相關利害關係人；

6. 當專案績效或成果未達目標時，採取糾正措施；

7. 根據需要啟動專案重新規劃；

8. 授權專案從一個預定里程碑、決策節點或事件推進（或停止）到下一個階段。

##### 6.3.2.3 活動與任務

以下活動和任務應根據組織關於專案評估和控制流程的適用政策和程序執行。

a) 專案評估與控制計畫。此項活動包含以下任務：

1) 定義專案評估和控制策略。

註1：此策略明確了預期的專案評估和控制活動，包括計畫的評估方法和時間安排，以及必要的管理和技術評審。

b) 評估項目。此項活動包含以下任務：

1) 評估專案目標和計畫與專案背景的一致性。

2) 根據目標評估管理和技術計劃。確定充分性和可行性。

3) 根據相應的計畫評估專案和技術現狀，以確定實際成本、進度和績效與預期成本、進度和績效的偏差。

4) 評估角色、職責、問責制和權限的充分性。

註2：這包括評估人員勝任專案角色和完成專案任務的能力是否充分。盡可能使用客觀指標，例如資源利用效率、專案完成。

5) 評估資源的充分性和可用性。

註3：資源包括基礎設施、人員、資金、時間或其他相關項目。此項任務包括評估現有流程和基礎設施資源的再利用情況，並確認組織內部的承諾已得到履行。

6) 使用衡量成果和里程碑完成情況來評估進度。

註4：這包括收集和評估勞動力、材料、服務成本和技術績效的數據，以及其他關於目標的技術數據，例如可負擔性。這些結果將與既定的績效指標進行比較。這包括進行有效性評估，以確定不斷演進的系統是否符合要求。此外，還包括評估使能系統在需要時提供服務的準備。

7) 進行必要的管理和技術評審、審計和檢查。

註5：這些評審、審計和檢查可以是正式的，也可以是非正式的，其目的是確定是否準備好進入生命週期的下一階段或專案里程碑，以確保專案和技術目標的實現，或取得利害關係人的回饋。這些評審、審計和檢查與品質保證流程密切協調。有關技術評審的更多信息，請參閱 ISO/IEC/IEEE 24748-8。

8) 監控關鍵流程和新技術。

註6：這包括識別和評估技術的成熟度和技術引入的可行性。

9) 根據測量結果和其他項目資訊提出建議。

註7：分析測量結果，以識別與計劃值的偏差、變化或不良趨勢（包括潛在問題），並提出適當的糾正、預防、適應、補充或完善措施建議。這包括（在適當情況下）對指示趨勢的測量值進行統計分析，例如，故障密度（用於指示輸出品質）和測量參數分佈（用於指示製程重複性）。

10) 記錄並提供評估任務的狀態和結果。

11) 監控專案內的過程執行情況。

註8：這包括分析過程測量值並審查與專案目標相關的趨勢。任何已確定的改進措施都將透過品質保證流程或生命週期模型管理流程進行處理。

c) 控制項目。此活動包括以下任務。

1) 啟動解決已識別問題的必要措施。

註9：當專案或技術成果未達到計畫目標時，就會發生這種情況。這包括糾正、預防和問題解決措施。這些行動通常需要重新規劃或重新分配人員、工具和基礎設施資產，並且往往會影響成本、進度或技術範圍或定義。有時，這些行動也需要對生命週期流程的實施和執行進行更改。

註10：所有行動均需記錄並審查，以確認其充分性和及時性。

2) 啟動必要的項目重新規劃。

註11：當專案目標或限制條件發生變化，或規劃假設被證明無效時，將啟動專案規劃流程進行重新規劃。

註12：任何需要變更採購者和供應商之間協議的變更都將啟動採購和供應流程。

3) 當因採購方或供應商的要求導致成本、時間或品質發生合約變更時，啟動必要的變更行動。

註13：這包括考慮修改供應條款和條件或啟動新的供應商選擇，這些都將啟動採購和供應流程。

4) 如有必要，授權項目進入下一個里程碑、決策關卡或事件。

註14：決策管理流程用於就里程碑或決策關口的完成達成一致意見。

#### 6.3.3 決策管理流程

##### 6.3.3.1 目的

決策管理流程的目的是提供一個結構化的分析框架，用於客觀地識別、描述和評估生命週期中任何階段的一系列決策替代方案，並選擇最有利的行動方案。

註1：此流程用於解決技術或專案問題。d 回應系統生命週期中遇到的決策請求。典型方法包括識別能夠為當前情況提供最佳結果的備選方案。最常用的決策管理方法包括權衡研究、成本效益分析、工程分析和問題解決分析（例如，TRIZ 和 Kepner-Tregoe）。每個備選方案都根據決策標準進行評估（例如，成本影響、進度影響、專案限制、監管影響、技術性能特徵、關鍵品質特徵、系統狀態考量和風險）。透過適當的選擇模型對這些比較結果進行排序，然後用於確定最優解。關鍵研究數據（例如，假設和決策理由）通常會進行管理，以便為決策者提供資訊、在未來重新論證決策以及支持未來的決策。

註 2：當需要對某個標準的某個參數進行詳細評估時，將採用系統分析過程來進行評估。

##### 6.3.3.2 成果

成功執行決策管理流程後，將達成以下目標：

a) 辨識需要備選方案分析的決策；

b) 評估備選方案；

c) 選擇首選方案；

d) 記錄決議、決策理由和假設。

##### 6.3.3.3 成果活動與任務

以下活動和任務應根據組織適用的決策管理流程政策和程序執行。

a) 決策準備。此活動包含以下任務。

1) 制定決策管理策略。

註1：決策管理策略包括明確角色、職責、問責與權限。它還包括確定決策類別和優先排序方案。決策通常源自於有效性評估、技術權衡、待解決的問題、應對風險超過可接受門檻所需採取的行動，或專案進入下一生命週期階段的新機會或批准。組織或專案指南決定了決策分析的嚴謹性和正式程度。

2) 確定決策的背景和必要性。

註2：記錄、分類並報告問題或機會以及可解決這些問題或機會的替代方案。

3) 讓相關利害關係人參與決策，以藉鏡他們的經驗和知識。

b) 分析決策資訊。此活動包含以下任務。

1) 為每個決策選擇並制定決策管理策略。

註3：確定解決這些問題或機會所需的嚴謹程度，以及評估備選方案所需的數據和系統分析。

2) 確定預期結果和可衡量的選擇標準。

註4：確定所有可量化標準的理想值以及屬性不合格的閾值。通常，需要確定所有標準的權重因子。

3) 辨識權衡空間和備選方案。

註5：如果備選方案數量眾多，則對其進行定性篩選，以將備選方案數量減少到便於進一步詳細系統分析的程度。此篩選通常是基於對風險、成本、進度和監管影響等因素的定性評估。這包括新的設計參數、不同的架構特性、系統之系統 (SoS) 考慮因素、關鍵品質特性的取值範圍以及風險和機會。

4) 根據標準評估每個備選方案。

註6：必要時，使用系統分析流程來量化每個待評估權衡方案的具體標準。這包括新的設計參數、不同的架構特性、系統之系統 (SoS) 考慮因素以及關鍵品質特性的取值範圍。系統分析過程評估參數變化範圍，從而對每個權衡方案進行敏感度分析。這些結果用於確定各種權衡方案的可行性。

c) 制定和管理決策。此活動包含以下任務：

1) 確定每個決策的首選方案。

註7：使用選擇標準對方案進行定量評估。選定的方案通常可以優化或改進已確定的決策。

2) 記錄決議、決策理由和假設。

3) 記錄、追蹤、評估和報告決策。

註8：這包括記錄問題和機遇，以及責任追究。決策和處置應按照協議或組織程序中的規定進行，並允許進行審計和從經驗中學習。

註9：這使得組織能夠確認問題已得到有效解決，不利趨勢已得到扭轉，意外風險和後果已得到應對，並且機會已得到把握。

#### 6.3.4 風險管理流程

##### 6.3.4.1 目的

風險管理流程的目的是持續識別、分析、處理和監控風險。

風險管理流程系統性地因應系統產品或服務生命週期中的不確定性，以實現目標。

註：在[條款3](#_bookmark4)中，風險被定義為「不確定性對目標的影響」。因此，風險可以是正面的，也可以是負面的。然而，在通常用法中，風險通常指負面影響。本文檔採用風險的通常解釋，即有負面影響的情況。當影響是正面的時，通常被視為機會。以下定義的風險管理活動可以輕鬆調整，以涵蓋機會；風險管理流程活動和任務的註釋中提供了更多指導。

##### 6.3.4.2 成果

成功執行風險管理流程後，將達成以下目標：

a) 辨識風險；

b) 分析風險；

c) 選擇風險因應措施；

d) 實施適當的因應措施；

e) 評估風險，以了解風險狀態的變化和應對措施的進展；

f) 維護風險概況。

##### 6.3.4.3 活動與任務

以下活動和任務應根據組織適用的風險管理流程政策和程序執行。

註1：ISO/IEC/IEEE 16085 提供了一套更詳細的風險管理活動和任務，並與 ISO 31000 和 ISO 指南 73* 保持一致。 * ISO 9001:2015 條款 A.4 提供了更多基於風險的思維方式，以因應品質管理方面的預防措施。

a) 規劃風險管理。此活動包含以下任務。

1) 定義風險管理策略。

註2：此策略通常定義風險管理流程的範圍、風險管理方法以及風險標準、措施、參數、評級等級和處理方案。這包括對供應鏈各級風險管理流程的描述，並說明如何將所有供應商的風險提升到下一層級，以便納入專案風險管理流程。

註3：為了進一步涵蓋機會管理，此策略可以將機會納入範圍和方法，並定義機會標準、措施、參數、評級等級和處理方案。

2) 定義並記錄風險管理流程的背景。

註 4：這包括識別利害關係人並描述他們的觀點、風險類別，以及（可能透過參考文獻）技術和管理目標、假設和約束條件的描述。風險類別涵蓋系統的相關技術領域，並有助於識別系統生命週期中的風險。

註 5：機會為系統或專案帶來潛在收益。每個機會都伴隨著會削弱預期效益的風險。這包括不抓住機會的風險，以及未能實現機會預期效果的風險。

b) 維護風險概況。此活動包含以下任務。

1) 定義並記錄風險閾值和條件。

註 6：風險（和機會）閾值定義了考慮採取適當因應策略的等級。

2) 建立並維護風險概況。

註 7：風險概況包括：

- 風險描述；

- 風險的可能原因和事件；

- 風險可能造成的後果；

- 風險後果的嚴重程度；

- 風險發生的可能性；

- 風險發生時被發現的可能性；

- 風險的閾值和條件；

- 風險的當前狀態；

- 風險目前的應對措施、緊急策略或計劃；

- 風險的歷史。

風險概況會定期更新並設定基準。通常在以下情況下進行更新：

- 風險管理環境發生變化；

- 發現新的風險；

- 現有風險資訊有任何變更。

註 8：在評估機會時，通常會使用同一份概況來同時評估風險和機遇，以便更好地了解整體情況。

3) 定期提供相關的風險概況。e 向利害關係人傳達。

c) 分析風險。此活動包含以下任務。

1) 識別風險管理背景下所述的風險類別。

註 9：風險通常透過各種分析來識別，例如安全性、可靠性、保證性、可生產性和效能分析；技術、架構、整合和就緒性評估；測量報告；以及權衡研究。有時，這些風險在生命週期的早期階段就被識別出來，並持續到系統的使用、支援和退役階段。此外，風險通常透過分析與系統目標相關的指標來識別，例如有效性指標或績效指標。請參閱 IEC 31010，其中包含幾種識別風險的方法。

2) 估計每個已識別風險的發生可能性及其後果。

3) 根據風險閾值評估每個風險。

4) 為超過風險閾值的每個風險定義並記錄建議的處理策略和措施。

註10：風險因應策略包括但不限於消除風險、降低風險發生的可能性或後果的嚴重程度，或接受風險。機會因應策略包括抓住或利用機會、延遲或監控。因應策略還可以包括承擔或增加風險以抓住機會。衡量指標提供有關應對方案有效性的資訊。

d) 應對超過風險閾值的風險。此項活動包含以下任務：

1) 確定建議的風險因應方案。

2) 定義用於確定風險因應措施有效性的衡量指標。

3) 實施選定的風險因應措施。

註11：通常，實施的方案可以是利害關係人認為採取的行動能夠使風險可接受的方案。如果存在多個風險等級可接受的方案，則需要製定並應用決策標準來選擇最佳方案。

4) 協調針對選定風險因應措施的管理行動。

註12：更多資訊請參閱[6.3.2](#_bookmark103)。

e) 風險監控。此項活動包含以下任務：

1) 持續監控所有風險及其風險管理環境。

註 13：當風險狀態改變時，應記錄這些變化並重新評估風險。超過閾值的風險被視為高優先級，並持續監控以確定是否需要採取任何後續風險處理措施。

2) 實施並監控評估風險處理措施有效性的措施。

3) 持續監控整個生命週期中新出現的風險和風險來源。

#### 6.3.5 設定管理流程

##### 6.3.5.1 目的

配置管理流程的目的是管理系統及其系統元素在其生命週期內的配置。

管理包括建立和維護一致性、完整性、可追溯性和控制。配置包括產品及其產品配置資訊。

##### 6.3.5.2 成果

配置管理流程成功實施後，將達成以下目標：

a) 系統和系統元素配置得到管理；

b) 配置基線（包括已核准的配置）得到維護；

c) 配置管理項的變更得到控制；

d) 配置狀態資訊可用；

e) 完成必要的配置審核；

f) 系統版本發布獲得批准。

##### 6.3.5.3 活動與任務

以下活動和任務應根據組織適用的配置管理流程政策和程序執行。

a) 配置管理準備工作。此活動包含以下任務。

1) 定義組態管理策略。

註1：這包括以下內容的詳細資訊：

a) 角色、職責、問責制和權限；

b) 配置管理項目變更的管理，包括處置、存取、發布和控制；

c) 需要建立的基線；

d) 儲存位置與條件、儲存媒體及其環境，均需符合指定的完整性、安全性和保障等級；

e) 啟動配置控制和維護不斷演進配置基線的標準或事件；

f) 審計策略以及評估配置定義資訊持續完整性和安全性的職責；

g) 變更管理，包括任何計畫的配置控制委員會、常規和緊急變更請求以及變更管理程序；

h) 與相關利害關係人之間的協調，包括採購者、供應商和供應鏈組織，以及其他相關方。在系統之系統 (SoS) 環境中運作的組織。

註 2：此策略涵蓋系統的整個生命週期或合約期限（視情況而定）。

註 3：有關組態管理活動的更多指導，請參閱 ISO 10007、IEEE Std 828、SAE EIA-649、STANAG 4427 和 SAE ARP4754A。

2) 定義組態管理項目以及組態管理工件和資料的歸檔和檢索方法。

註 4：這包括需要與資訊管理流程保持一致的資料保留程序。

b) 執行配置識別。此活動包含以下任務。

1) 識別需要進行組態管理的系統元素和工件。

註 5：配置管理項通常稱為配置項。它們會受到特別關注。它們通常是審查和配置審計的對象。受配置管理約束的專案通常包括需求、模型、產品和系統元素、服務以及基準。

2) 識別待管理的配置資料。

註 6：這包括系統元素之間的關係以及相關數據。

3) 為受組態管理的項目建立唯一識別碼。

註 7：項目透過唯一識別碼或標記進行區分。這些標識符符合相關標準和產品行業慣例，確保受配置控制的項目能夠明確地追溯到其規範或等效的已記錄描述。 ISO/IEC 19770 系列標準包含對作為配置項目的 IT 資產進行唯一識別的要求。

4) 在生命週期中定義基線。

註 8：基線記錄系統元素在指定時間或特定情況下的配置狀態演變。基線的內容透過技術流程開發，但會在某個時間點透過配置管理流程正式化。基線構成下一次變更的基礎。

5) 取得相關利害關係人的同意，以建立基準。

註9：專案評估和控制流程用於達成一致意見。

6) 批准並追蹤系統或系統元素的發布。

註10：發布的目的在於授權將系統或系統元素用於特定用途，無論是否有附加限制。例如，用於測試或運行的發布。

註11：發布通常包含一系列變更。這些變更透過技術流程完成，然後透過驗證和確認流程進行驗證或確認。批准發布通常包括接受已驗證和確認的變更。

c) 執行配置變更管理。此活動包含以下任務。

註12：配置變更管理建立了在基準建立後管理變更的程序和方法。這有時被稱為配置控制。

1) 識別並記錄變更請求和偏差請求。

註13：變更請求有時也稱為偏差、豁免或讓步。

2) 協調、評估和處理變更請求和變更請求。

註14：這包括對擬議變更的影響評估，包括對專案計畫、成本、效益、風險、品質和進度的影響。並決定是否實施或關閉變更請求。

3) 提交請求以供審查和批准。

註15：變更請求和變更請求通常由配置控制委員會 (CCB) 正式控制。評估包括需求與影響的分析。

4) 追蹤和管理已批准的基線變更、變更請求和變更請求。

註16：此任務涉及變更的優先排序、追蹤、進度安排和關閉。變更隨後透過技術流程實施。這些變更透過驗證和確認流程進行驗證或確認，以確保已實施已批准的變更。

註17：記錄變更的理由是一種好的做法。 d) 執行配置狀態統計。此活動包含以下任務。

1) 開發並維護系統元素、基線和版本的組態管理狀態資訊。

註 18：配置狀態統計提供有關受控產品或服務狀態的數據，這些數據用於在整個產品生命週期內對系統元素做出決策。這包括考慮配置控制項的性質。配置描述盡可能符合產品或技術標準。配置資訊允許向前和向後追溯到其他配置狀態。基準、版本發布及其相關授權的依據通常會記錄在設定資料中。配置記錄在系統生命週期內持續維護，並根據協議、相關法規或最佳行業實踐進行歸檔。

註 19：對目前配置狀態以及所有先前配置狀態的記錄、檢索和整合進行管理，以確認資訊的正確性、及時性、完整性和安全性。執行審核以驗證基線是否符合圖面、介面控製文件和其他協定要求。

2) 擷取、儲存和報告配置管理資料。

e) 執行設定驗證和審核。此活動包含以下任務。

1) 確定配置和配置管理驗證活動及審核的必要性。

註 20：配置管理流程與驗證流程協同工作，以識別和執行驗證活動。

2) 驗證產品或服務配置是否符合配置要求。

註 21：透過將要求、約束和豁免（差異）與正式驗證活動的結果進行比較來執行此操作。

3) 監控已核准配置變更的實施情形。

4) 執行設定及組態管理驗證活動及審核，以建立產品基準。

註22：典型的審核包括專注於功能和效能的功能配置審核 (FCA) 和專注於系統與運行和配置資訊項一致性的物理配置審核 (PCA)。驗證過程用於執行組態驗證和審核。

5) 記錄配置管理審核和其他配置評估結果以及處置行動項。

#### 6.3.6 資訊管理流程

##### 6.3.6.1 目的

資訊管理流程的目的是為指定的利害關係人產生、取得、確認、轉換、保留、檢索、分發和處置資訊。

資訊管理計劃、執行和控制向指定的利害關係人提供的信息，確保資訊清晰、完整、可驗證、一致、可修改、可追溯且易於呈現。資訊包括技術資訊、專案資訊、組織資訊、協議資訊和使用者資訊。資訊通常來自組織、系統、流程或專案的資料記錄。

##### 6.3.6.2 成果

成功實施資訊管理流程後，將達成以下目標：

a) 辨識待管理的資訊；

b) 定義資訊表示形式；

c) 管理資訊；

d) 識別資訊狀態；

e) 指定利害關係人可取得資訊。

##### 6.3.6.3 活動與任務

以下活動和任務應根據組織適用的資訊管理流程政策和程序執行。

註 1：ISO/IEC/IEEE 15289 總結了生命週期流程資訊項目（文件）的內容要求，並提供了相關開髮指南。

a) 資訊管理準備工作。此活動包含以下任務：

1) 制定資訊管理策略。

註2：同一主題的訊息在生命週期的不同階段，針對不同的受眾，可以用不同的方式來發展。

2) 定義需要管理的資訊項。

註3：這包括在系統生命週期內需要管理的訊息，以及可能在生命週期結束後的一段特定時間內需要維護的資訊。應考慮組織政策、協議或法律法規。

3) 指定資訊管理的權限和職責。

註4：應充分考慮資訊和資料相關的法律法規、安全和隱私規定，例如所有權、協議限制、存取權、資料權利、智慧財產權和專利。如果存在限製或約束，則應相應地標識資訊。了解此類資訊的員工應被告知其義務和責任。

4) 定義資訊項的內容、格式和結構。

註5：資訊以多種形式（例如，視聽、文字、圖形、數位）和媒介（例如，電子、印刷、磁性、光學）產生和終止。應考慮組織限制，例如…基礎設施、組織間溝通和分散式專案運作均納入考慮。相關資訊項標準和慣例的使用需兼顧政策、協議和法律法規的限制。

5) 定義資訊維護措施。

註6：資訊維護包括對已儲存資訊的狀態進行審查。完整性、有效性和可用性。此外，還包括根據需要進行複製或轉換為其他媒體的任何需求，以便在技術變更時保留基礎設施，從而確保存檔媒體可讀，或將存檔媒體遷移到更新的技術。

b) 執行資訊管理。此活動包含以下任務。

1) 取得、開發或轉換已識別的資訊項。

註7：這包括從適當的來源（例如，任何生命週期過程的產物）收集資料、資訊或資訊項，並將其編寫、圖示或轉換為利害關係人可用的資訊。這包括根據資訊標準審查、驗證和編輯資訊。

2) 維護資訊項目及其儲存記錄，並記錄資訊狀態。

註8：資訊項的維護應符合其完整性、安全性和隱私要求。資訊項的狀態應得到維護（例如，版本描述、發布日期或有效期限、分發記錄、安全分類）。清晰易讀的資訊應以易於檢索的方式儲存和保留。

註9：用於轉換資訊的來源資料和工具，以及產生的文檔，均依照配置管理流程置於配置控制之下。 ISO/IEC/IEEE 26531 提供了有關生命週期資訊和文件內容管理系統要求的資訊。

3) 向指定的利害關係人發布、散佈或提供資訊存取權限。

註10：依約定的時間表或既定情況，以適當的形式向指定的利害關係人提供資訊。資訊項目包括用於認證、認可、許可或評估評級的官方文件（如有需要）。

4) 歸檔指定資訊。

註11：歸檔工作應符合審計、知識保留、監管、協議及項目收尾的目的。資訊的儲存媒體、位置和保護措施的選擇應符合規定的儲存和檢索期限，並考慮組織政策、協議和法律法規。應制定相關安排，以便在專案結束後保留必要的資訊項目。

5) 處置不需要的、無效的或未經驗證的資訊。

註12：需考慮法律法規、組織政策以及安全和隱私要求。

#### 6.3.7 測量過程

##### 6.3.7.1 目的

測量過程的目的是收集、分析和報告客觀數據和信息，以支持有效管理並滿足有關產品、服務和流程的資訊需求。

##### 6.3.7.2 成果

成功執行測量過程後，將實現以下目標：

a) 辨識資訊需求；

b) 根據資訊需求，確定或製定一套適當的衡量指標；

c) 管理所需資料；

d) 分析數據並解釋結果；

e) 測量結果提供支持決策的客觀資訊。

##### 6.3.7.3 活動與任務

以下活動和任務應根據適用於測量過程的組織政策和程序執行。

註1：ISO/IEC/IEEE 15939 提供了一套更詳細的測量活動和任務，與下文所示的活動和任務一致。

註2：ISO 9001:2015 7.1.5 規定了品質管理系統對製程和產品測量與監控的要求。

a) 測量準備。此活動包含以下任務：

1) 定義測量策略。

2) 描述與測量相關的組織特徵。

3) 識別資訊需求並確定其優先順序。

註3：資訊需求是基於組織的策略目標、專案目標、已識別的風險以及與專案決策相關的其他事項。

4) 選擇並指定滿足資訊需求的測量方法。

5) 定義資料收集、分析、存取和報告程序。

6) 定義評估資訊項和測量過程的標準。

7) 辨識並規劃所需的支援系統或服務。

8) 取得或取得所需系統或服務的存取權限。

b) 執行測量。此活動包含以下任務。

1) 將資料產生、收集、分析和報告程序整合到相關流程中。

註 4：其中一些必要的變更已整合到其他生命週期流程中。

2) 收集、儲存和驗證資料。

3) 分析數據並產生資訊項。

4) 記錄結果並通知測量用戶。

註 5：測量 a分析結果會及時、有效地報告給相關利害關係人，以支持決策並協助採取糾正、預防、適應、補充和完善措施；進行風險管理；以及改善工作。結果會報告給決策過程參與者、技術和管理評審參與者以及產品和流程改善流程負責人。

#### 6.3.8 品質保證流程

#### 6.3.8.1 目的

品質保證流程的目的是幫助確保組織的品質管理流程有效地應用於專案。

品質保證的重點在於確保品質要求得到滿足。透過對專案生命週期流程和產出進行主動分析，可以幫助確保所生產的產品或所開發的服務達到預期質量，並確保組織和專案的政策和程序得到遵守。

註：建立保證案例（參見[5.10](#_bookmark88)）可用於指導品質保證活動，並有助於確保關鍵品質特性被考慮。

#### 6.3.8.2 成果

品質保證流程成功實施後，將達成以下目標：

a) 實施品質保證程序，包括品質保證評估的標準和方法；

b) 根據品質管理政策、程序和要求，對產品、服務和流程進行評估；

c) 將評估結果提供給相關利害關係人；

d) 解決事件；

e) 處理優先問題。

註：成果 a) 至 d) 與品質管理流程的成果一致。

#### 6.3.8.3 活動與任務

應根據適用的組織政策和程序實施以下活動和任務。

a) 為品質保證做好準備。此活動包含以下任務。

1) 制定品質保證策略。

註 1：該策略應與品質管理政策、目標和程序一致，並包括：

a) 專案品質保證程序；

b) 明確的角色、職責、問責制和權限；

c) 適用於每個生命週期過程的活動；

d) 適用於每個供應商（包括分包商）的活動；

e) 產品或服務所需的驗證、確認、監控、測量、檢驗和測試活動；

f) 產品或服務驗收標準以及製程、產品和服務評估的標準和方法。

2) 確保品質保證 (QA) 與其他生命週期過程的獨立性。

註 2：為確保品質保證獨立於專案管理，通常從不同的組織中調配資源。

b) 執行產品或服務評估。此活動包含以下任務：

1) 評估產品和服務是否符合既定標準、合約、規範和法規。

註 3：這包括源自利害關係人需求和需求定義以及系統需求定義過程的系統品質要求。更多資訊請參閱 ISO/IEC 25010。

2) 對生命週期過程的輸出進行驗證和確認，以確定其是否符合規定的要求。 c) 執行流程評估。此活動包含以下任務：

1) 評估專案生命週期流程的符合性。

2) 評估支援或自動化流程的工具和環境的符合性。

3) 評估供應商流程是否符合流程要求。

註 4：通常會考慮協作開發環境、供應商必須提供的流程指標或供應商必須使用的風險流程等因素。

d) 管理品質保證記錄和報告。此活動包含以下任務：

1) 建立與品質保證活動相關的記錄和報告。

註 5：記錄和報告的創建需遵循資訊管理流程，並考慮組織、法規和專案要求。

2) 維護、儲存和分發記錄和報告。

3) 辨識與產品、服務和流程評估相關的事件和問題。

註 6：這包括總結經驗教訓，以及對供應鏈中的流程實施情況進行監督審查。

e) 處理事件和問題。此活動包含以下任務。

註 7：在品質管理術語中，問題通常被描述為“不符合項”，如果不加以處理，可能會導致專案無法滿足其要求。

註 8：有關問題類別和優先分類的更多資訊和範例，請參閱 ISO/IEC/IEEE 24748-1:2018 附錄 G。

1) 記錄、分析和分類事件。

2) 解決事件或將其升級為問題。

3) 記錄、分析和分類問題。

注意：E 9 分析結果包括潛在的處理方案。

4) 對問題處理方案進行優先排序，並追蹤實施情況。

註 10 實施工作在專案評估和控制流程啟動後，在技術流程中進行。

5) 記錄並分析事件和問題的趨勢。

6) 將事件和問題的狀態告知利害關係人。

7) 追蹤事件和問題直至解決。

### 6.4 技術流程

#### 6.4.1 業務或任務分析流程

##### 6.4.1.1 目的

業務或任務分析流程的目的是定義整體策略問題或機遇，描述解決方案空間，並確定能夠解決問題或抓住機會的潛在解決方案類別。

註 1 可能需要系統解決方案的組織的組織策略和營運理念構成了開展業務或任務分析的背景。組織運作概念反映了領導階層預期的組織運作方式。它描述了組織的假設，以及組織計劃如何利用待開發的系統、現有系統和未來可能開發的系統來支援業務的整體運作或一系列營運。如果組織本身就是系統定義（SoI），那麼組織的策略就是系統定義的一部分。

註2：在某些領域，這與識別和分析組織所需或期望的能力的概念相關。此過程著重於必要的能力，並與組合管理流程交互，以確定能夠滿足該能力需求的權衡空間。已識別的問題或機會通常會轉化為目標能力。在特定領域內，問題或機會空間包含目標能力。

註3：業務或任務分析是概念定義活動的一部分－概念定義是一系列系統工程活動，其中對問題空間以及業務或企業和利害關係人的需求進行深入研究。

##### 6.4.1.2 成果

成功完成業務或任務分析流程後，將達成以下目標：

a) 明確問題或機會空間；

b) 確定解決方案空間；

c) 定義初步運作概念以及生命週期各階段的其他概念；

d) 分析備選解決方案類別；

e) 選擇首選備選解決方案類別；

f) 確保業務或任務分析所需的支援系統或服務可用；

g) 建立策略問題和機會以及首選備選解決方案類別的可追溯性。

##### 6.4.1.3 活動與任務