1

軟體型態管理

郭忠義

jykuo@ntut.edu.tw

臺北科技大學資訊工程系

大綱

型態基礎

型態識別

型態控制和狀況描述

型態稽核

產品發行和分佈

2

型態基礎-型態 同時開發與測試

開發團隊設定系統元件的遞交時程。

新版系統透過編譯與連結元件型態，建置完整系統。

交付測試團隊，進行系統測試。

• 系統測試期間發現的錯誤須記錄，回報給開發者。 每日系統建置

儘早發現由元件互動所產生的問題。

單元測試 – 開發者避免開發失誤而造成系統故障。 嚴格的變更管理流程。

追蹤發現及修復的問題。

3

型態基礎-型態 型態(Configuration)是對一個產品實體與功能特徵的描述

實體特徵如產品形狀、大小、重量、使用材料等；

功能特徵如可靠度、安全性、精確度等。

4

型態基礎-型態管理 型態管理(Software Configuration Management, SCM)

產品在生命週期中，依據需求、設計與作業資訊，建立與維持產品表現、功能與實體屬性具一致性的管理程序。

型態管理原因

許多人共同開發一個常需改變的軟體系統。

軟體需超過一種版本，以支援

• 不同的發行。• 不同功能不同的安裝方式。• 發展的版本。

軟體需在不同作業系統、硬體上執行。

5

型態基礎-型態管理 SCM 標準

SCM 要有一定的標準且符合組織要求。 定義出何種項目需要的標準，如何變更控制和如何新版管理。

IEEE 標準，主要工作項目包含： 組態識別：將產品分解至可單獨獲得或管制的項目，以利管

制工作進行。

組態變更控制：透過系統化程序，管制各型態項目的變更。

組態稽核：對型態項目全盤審核，確認最終產品滿足原定義之需求。

組態狀況彙報：有效管理型態項目須擁有的產品資訊，並持續記錄型態項目之現況。

6

型態基礎-型態管理 CMMI軟體組態管理流程領域

SG1 建立基準線• SP1.1 界定組態項目• SP1.2 建立組態管理系統• SP1.3 建立或發行基準線

SG2 追蹤並管制變更• SP2.1 追蹤變更申請• SP2.2 管制組態項目

SG3 建立完整性• SP3.1 建立組態管理記錄• SP3.2 實施組態稽核

7

型態基礎-型態管理 CMMI ，軟體組態管理主要目的：

降低軟體修改導致專案失敗的風險。

建立軟體發展過程中所有的紀錄，作為專案規劃和維護管理的依據。

控制軟體的品質與改進軟體再用性。

控制專案成本與水準，避免軟體的修改而延誤專案進度與成本增加。

8

型態基礎-型態管理團隊 描述一個型態管理團隊(Software Configuration Management

Group)的角色和責任。 SCMG任務

負責策劃、協調和實施軟體專案的正式配置管理活動的團隊。

創造與管理基準線函式庫(baseline library)。 發展、維護、散布SCM計畫書、標準與程序。 確認正確的工作產品置於適當的SCM。 基準線library的存取管理。 更新基準線。

從基準線library造出產品。 紀錄SCM動作。 SCM報告的產出與散布。

9

型態基礎-型態管理團隊 不同角色須擔負不同責任：

構型管理者：辨識並組合構件項、定義構型管理流程；

構型控制委員會：負責核可或駁回變更申請、相依項目表列、衝擊分析；

用戶或顧客：提出變更申請、追蹤變更結果；

開發者：執行變更申請、建立新的版本；

稽核者：評估變更結果、確保新版本的完整性與一致性。

10

型態基礎-型態管理工具 描述管理函式庫、建置系統、缺失追蹤系統所使用的工具。

變更管理是一種流程，所以也可整合成版本管理系統

變更管理工具

表單編輯器：建立變更提議單，填入適當資料。

缺失追蹤系統：允許SCM小組指定不同人員負責變更要求單處理，並追蹤處理順序。

變更資料庫：管理所有變更提案，連結版本管理系統。

11

型態基礎-型態管理工具 版本管理工具

版本與發行識別

• 送至系統時都會指定識別碼。 儲存管理

• 版本管理系統提供儲存管理功能。 變更歷程記錄

• 記錄與列出對系統或元件程式碼所做的所有變更動作。 獨立開發

• 不同系統版本可多人並行開發、存取、修改，且每個版本可獨立變更修改。

• 支援專案：可管理一組與專案有關的檔案，而非僅僅單一檔案。

12

型態基礎-型態管理工具 所有軟體流程工作產品都要被管理

規格、設計、程式、測試計畫、使用者手冊

數以萬計分開的文件產生一個大軟體系統。

制定SCM 計畫 開始專案之前，定義正式文件及文件管理等級。

• 文件應有系統維護、被定義和詳細的管理。 管理定義文件型態和文件命名計畫。

定義SCM責任和創造的基準。 定義變更控制的政策和版本管理。

定義 SCM 記錄的維護。

13

型態基礎-型態管理工具 型態管理計畫

描述用於組態管理的工具限制和使用。

定義使用工具時套用的流程。

定義用來記錄組態資訊的組態管理資料庫。

SCM計畫包含外部供應商的軟體管理，以及SCM流程的稽核程序。

IEEE 828 Software Configuration Management Plan IEEE 1042 Software Configuration Management ISO10007是國際標準組織針對ISO90001提出子條款，規範

企業對其產品制訂標準之型態管理程序，以利產品在其生命週期中之資料管理。

14

型態管理計畫

• 型態管理計畫內容– 計畫簡介：描述計畫的目的、應用範圍、專門用語與參考文獻。– 型態管理人員指派：指定由誰負責與授權完成型態管理所計畫的活

動。

– 型態管理活動：指定在專案中將實施的所有型態管理活動。– 型態管理時程：指定專案型態管理活動與其他活動之間的順序與關

係。計畫的型態管理時程需要與專案的里程碑與重要事件配合。型態管理里程碑的制訂可包含基準的建置、變更控制實作與型態稽核的開始與結束時間。

– 型態管理資源：指定需要執行型態管理活動所需要的軟硬體資源與人力資源。

– 型態管理計畫的維護：指定維護型態管理計畫所需要的活動與責任歸屬。計畫的變更如何被評估、核准、執行與溝通。

型態管理計畫目錄• 簡介

– 計畫目的– 範圍– 定義

• 標準定義• 其他定義• 符號

– 參考文獻

• 管理– 組織– 型態管理職責分配

• 型態識別• 型態控制• 型態狀態報告• 型態稽核

– 介面控管

• 型態管理活動– 型態識別

• 專案基線• 專案代碼

– 型態控制• 型態控管委員會• 變更需求單的追蹤與處理

– 型態狀態報告– 型態稽核

• 型態管理時程• 工具、技術與方法• 型態記錄的蒐集

型態基礎-函式庫流程 描述在Library系統使用之動態、靜態和控制流程，包括

check in, check out, merge change。 check out

從客戶端或伺服器端library取得文件檔案。 check in

將修改完的最新檔案，存入客戶端或伺服器端library。 串行方法

監控，阻止同時修改的事情發生。

並行方法

輔助，使同時修改內容合併。

17

型態基礎-函式庫流程 加鎖功能

檔案更新時保護檔案，避免不同使用者同時更改產生衝突。

文件比對

客戶端與伺服器上最新版本比對。

客戶端與伺服器端任一版本比對。

伺服器端不同版本比對。

合併主線或分支

快速往前合併

三向合併

合併方式

沒有衝突則自動合併，有衝突則人工合併。

18

Exercise 以下哪一種 libraries使用於基準線的管理？(A) Controlled (B) Public (C)

Dynamic (D) Static。A SCM的目的是 (A) 取代程式管理 (B) 協助避免相同的資訊有許多副本

(C) 在生命週期發展階段消除 “fire-fighting” (D) 確保適當的測試案例被開發。B

以下何者負責授權controlled library的變更？(A)公司实体 (B) Configuration control board (C) 開發團隊 (D) SCM經理。B

以下何者負責控制軟體產品的變更？(A) 軟體測試工程師 (B) 軟體專案經理 (C) SCM經理 (D) 軟體稽核員。C

19

型態識別流程定義

命名

獲得

程式碼、資料與文件

結構 基準

命名方法與規則

版本 唯一識別碼

儲存 取得 重製

型態項目 型態項目 型態項目

型態識別-型態項目 描述型態項目(Configuration item)，包括文件、軟體程式碼、

設備等；識別方法；建立基線(Baseline)。 型態識別

分析軟體系統的結構、辨識個別單獨元件，建立一套型態的存取方式。

區別物件區別，辨識物件之間的結構與相互關連。

包含以下活動：

• 選擇需加入SCM控制的項目；建立SCM軟體階層結構；• 建立能反映此一階層結構的辨識規範；• 決定哪一版本的元件可或不可加入基準線；• 辨識各種系統產品的修正版及其之間的關係；• 發布構型文件；建立基準線。

產生規格樹(Specification tree)。 21

型態識別-型態項目

開發大型軟體系統，產生大量技術性工作文件需被定義。

有些文件用來維護軟體生命週期。

文件命名應有意義，與文件名稱相關。

可運用階層命名法達到靈活命名方式。

22

型態識別-型態項目 各開發階段型態項目(Configuration item)

23

型態識別-型態項目 型態資料庫

所有組態管理的資訊維護都需存於組態資料庫。

提供對系統組態各種查詢的答案。

哪一個客戶已取用某個系統版本的交付成果。

執行給定的系統版本需什麼硬體和作業系統組態。

變更元件 X有多少影響。 版本 T有多少錯誤回報。 組態管理資料庫應整合到型態管理軟體中。

24

型態識別-軟體建置 描述軟體建置和型態管理功能之間的關係，和描述控制建

置的方法(自動化、新版本等)。 系統建置

編譯和鏈結軟體元件，建置完整系統的流程。

不同的子系統中的元件之建立與整合。

藉由建立描述檔(build scripts)完成自動建置工具。 系統建置問題

組成系統的所有元件是否都已包含在建置指令中。

當有數百元件在建立時，少一個元件安裝程式是否可偵測到

每一個所需元件適當版本是否已包含在建置指令中 ? 所需的全部資料檔案是否都在 ?

25

型態識別-軟體建置 系統建置問題

資料檔案受到某個元件的參考是否正確?• 名稱轉換是否會造成系統建置問題

系統建置在錯誤的平台

• 有些需建置在特定作業系統版本或硬體需求上 是否有適當版本的編譯器和其他所需工具可用 ?

• 不同的編輯器版本及元件會產文不同的程式碼

26

Exercise 從版本1.0，一個特別的單元測試已有四個建置，這些建置的三個式設

計變更的結果。以下何者可以描述目前的建置？(A) 3.0 (B) 3.4 (C) 4.1 (D) 4.3。C

有關軟體基準線的描述，以下何者正確？他們是 (A) 軟體變更控制的基本 (B) 在規劃階段建立 (C) 直到測試階段才使用(D) 置於版本控制直到下一個版本發行才變更。A

一個型態項目清單是一個特殊的樹狀結構，輸入一個設備規劃圖以設定 (A) identification (B) control (C) baselining (D) accounting。A

下列哪些可拿作為軟體組態管理之工具？(A) CVS (B) Rational ClearCase (C) Crystal Report (D) Vmware Workstation (E) Git。ABE

27

型態控制-項目和版本控制 管理各種不同型態(configuration)的流程。

文件控制流程、項目(item)變更追蹤流程、版本控制流程。 管理型態項目(configuration item)的流程。

相依於軟體建置和版本之型態項目。

版本識別

版本識別程序可定義清楚的元件版本方法。

三種元件識別技術

• 版本編號。• 屬性式識別。• 變更式識別。

28

型態控制-項目和版本控制 元件識別技術 - 版本編號

簡單命名法，如 V1, V1.1, V1.2, V2.1, V2.2 。• 不一定需以線性增加、或連續版本編號。

階層命名法。

29

型態控制-項目和版本控制 基準線(baseline)

在某一特定時點衡量系統特性的正式參考點。

系統分析師利用基準線作為系統開發過程中，記錄特性及績效的量尺。

基準線: 功能基準線、分配基準線，及產品基準線。• 功能基準線(functional baseline)指在專案一開始記錄的系統環境配置。包括所有必要的需求及限制。

• 分配基準線(allocated baseline)記錄設計階段結束時的系統，描述對功能基準線的所有改變。包括對所有系統需求及性能的測試及驗證。

• 產品基準線(product baseline)描繪出開始運作時的系統。產品基準線涵蓋分配基準線之後所有改變，包括對執行中的系統所做的績效及可接受度測試結果。

30

型態控制-型態控制委員會 描述型態控制委員會(change control board, CCB)的角色和

責任，成員及運作流程。

型態控制委員會

決定系統是否變更的小組，從策略組織角度而非技術觀點考慮變更影響。

包括管理人員、資深客戶與契約負責人員。

ICWG界面控制工作小组 Interface Control Working Group 在各項不同專業"間"，對介面處理，要有「極佳」協調能力。 ICWG為系統與組件間聯絡工作站，意見交換與溝通。

31

型態控制-變更管理 組態變更控制：

追蹤變更申請：針對基準線或是客戶的需求變更來做控制。

變更管理

軟體系統經常會需要進行變更

• 從使用者、從開發者、從市場因素 變更管理能以合乎成本效益的方式記錄與應用。

變更管理流程

第一個階段完成變更要求單，記錄

• 變更要求和變更理由。• 變更預估，分析，成本、人員。

32

型態控制-變更管理 變更要求單

33

變更要求單

Project: Proteus/PCL-Tools Number: 23/94Change requester: I. Sommerville Date: 105/12/18Requested change: 當元件從結構中被選取時，即顯示儲存它的檔案名稱。Change analyser: G. Dean Analysis date: 105/12/21Components affected: Display-Icon.Select, Display-Icon.DisplayAssociated components: FileTableChange assessment: 非常容易製作，因為有檔名表格可用。需要設計與實作顯示的欄位。不需要變更相關的元件。Change priority: 低Change implementation:Estimated effort: 0.5 天Date to CCB: 105/12/25 CCB decision date: 105/12/30CCB decision: 接受變更。變更製作在 Release 2.1.Change implementor: Date of change:Date submitted to QA: QA decision:Date submitted to CM:Comments

型態控制-變更管理 變更要求單

34

型態控制-變更管理 變更要求單

35

型態控制-變更管理

36

型態控制-變更管理 變更追蹤

變更管理最主要的問題在變更情況的追蹤。

追蹤工具可針對每一次變更狀況自動記錄。

整合 E-mail 通知系統。

37

型態控制-同時發展 描述使用型態管理控制原則在同時發展流程中。

確保文件的版本一致

指派一位專人John負責管理文件存取，在一間小辦公室。 小組成員 Eric 要修改文件，就拿隨身碟到此窗口請John複製

一份給他(check out) ，複製的同時記下此文件正由 Eric 修改。 Eric 把檔案複製到其機器上的工作目錄，進行修改。 Eric 修改完畢，從工作目錄中把檔案複製到隨身碟交給John。 John將文件更新到文件庫中(check in)，修改更新程序完成。 若 Eric 修改期間，Vivi 也拿隨身碟向John要求修改同一份文

件，此時John 告訴 Vivi此文件目前由 Eric 領出(check out)，尚在修改中，你得等他改完。

38

Exercise 非正規變更控制是適合的，當 (A) 軟體型態項目變成基準線一部分之

前 (B) 直到產品基準線被建置 (C) 一個短期有限功能的專案 (D) 直到接受測試開始之前。A

變更X 比變更 Y 需更高層次的授權，是以下哪一個配對 (變更X、變更Y) (A) 開發中的程式碼、發行的程式碼 (B) 需求分析的規格、系統測試的規格 (C) 技術開發團隊需要文件、客戶需要文件 (D) 產品散布到許多地方、產品散布給單一使用者。D

下列關於組態狀態報告產生的作業流程，何者正確？(A) 開始 → 建立組態管理設施 → 確認組態報告需求 → 建立及更新組態管理資料庫 → 產生組態狀況報告 (B) 開始 → 建立及更新組態管理資料庫 → 建立組態管理設施 → 確認組態報告需求 → 產生組態狀況報告 (C) 開始 → 確認組態報告需求 → 建立組態管理設施 → 建立及更新組態管理資料庫 → 產生組態狀況報告 (D) 開始 → 建立組態管理設施 → 建立及更新組態管理資料庫 → 確認組態報告需求 → 產生組態狀況報告。C

39

型態稽核

型態稽核

利用測試報告與文件來驗證軟體產品之建造，是否符合需求、標準或其它合約協訂，確保所有產品都遵守原先規畫。

型態稽核包含以下活動：

定義稽核時程與程序，

找出誰來稽核，

產生稽核報告。

40

型態稽核

型態稽核類型

功能性型態稽核核(FCAs)：執行稽核以驗證型態項目的發展已經圓滿完成，並已達成其功能基準或配置基準所指定的功能及品質屬性，且具有完整並滿足要求的操作及支援文件。。

實體性型態稽核(PCAs) ：執行稽核以驗證建置的型態項目符合技術文件的定義與描述。

建構管理稽核:稽核的執行是在確認建構管理紀錄及建構項目的完整性、一致性及正確性。

41

型態稽核類型

功能性型態稽核

驗證型態項目是否滿足效率和功能特性，滿足使用者需求。

實體性型態稽核

檢查是否合乎技術規格。

確認設計及參考文件是否代表所建造的軟體。

42

狀態記錄描述

討論各種不同流程對於建立、維護和報告型態項目的狀況。

型態狀況彙報

建立型態管理記錄：負責收集與紀錄型態基準線、變更流程的紀錄、報告等文件的狀態、歷程。

型態管理記錄彙報：針對型態項目的進度和變更提供一份完整的資訊且進行彙報。

目標是維護所有基準線項目的最新狀態、歷史紀錄與提交過的變更，包含對所有基準線變更的可追蹤性報告。

43

狀態記錄描述

狀態報告可以回答：系統做了什麼改變？哪些檔案受到這份問題報告的影響？其日常活動包括：

決定日誌的型態與相關報告；

追蹤SCM項目的狀態； 追蹤系統改變後的狀態；

記錄並報告SCM的活動。 狀態紀錄使與型態有關的關鍵資訊，被傳送與溝通：工程

師可看到基準線中哪些被修正；專案管理者可追蹤問題報告及其它維護活動。

狀態紀錄應包括異動日誌、修改日誌、項目差異(delta)報告、型態的衍生歷史(包括做了什麼改變、誰做的、何時，及為何這樣做)。

44

狀態記錄描述

變更歷程與狀況

軟體元件變更後，須維護對每一個元件所做的變更記錄。

• 如記錄、外型、變更理由、程式碼註解、誰變更和什麼時候執行。

工具可自動處理此變更歷程狀況。

元件標頭資訊

45

// PROTEUS project (ESPRIT 6087)//// PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE//// Object: PCL-Tool-Desc// Author: G. Dean// Creation date: 10th November 2016//// © Lancaster University 2016//// Modification history// Version ModifierDate Change Reason// 1.0 J. Jones 1/12/2016 Add header Submitted to CM// 1.1 G. Dean 9/4/2017 New field Change req. R07/2017

產品發行

審查產品發行流程(規劃、時程、定義硬體和軟體相容性等)和評估其效益。

版本與發行

版本 - 新版系統可能有不同功能、執行效能或錯誤修正 特殊 - 版本可能功能相同，但專為不同硬體或軟體組態設計 發行 - 系統版本通常會比發行多，因版本是在內部開發或測

試用，不會發行給客戶使用。

版本與發行管理規劃

針對系統版本發展辨識方法。

計畫什麼時候發行新版本。

確認版本管理程序和工具的應用。

計畫和配置新系統的發行。46

產品發行

版本發行管理

發行需包含重大變更、系統新功能。

系統發行不只發行安裝程式、可執行檔，要包含

• 定義特定安裝設定發行組態檔• 成功運作系統所需資料檔案、描述系統的文件。

發行建立

建立的發行版本包含系統發行所有元件及所需檔案文件。

組態的指令與描述須針對不同硬體和作業系統編寫。

特定版本發行要有詳細文件記錄和檔案，必要時要允許重新建立。

47

產品發行

版本發行問題

客戶或許不需新發行系統，而對現有系統版本很滿意。

版本發行問題

48

因素 說明

系統的技術品質 如果嚴重的系統錯誤影響許多客戶使用方式，可能須發行錯誤修復版本。但很小的系統錯誤可發行修補程式進行修復。

Lehman的第五條定律

每一個發行版本中的遞增功能幾乎是持續發生。因此，若某系統發行很多新增功能，後面可能就會跟著一些修復程式。

競爭 由於出現競爭產品，所以新的系統發行版本可能是必須的。

市場需求 組織的行銷部門可能承諾在某一天發行新版本。

客戶變更提議 對客製化系統，客戶可能已對某些特定系統變更提案決定且已付款，他們希望系統發行版本能儘快完成。

Exercise 以下何者不是功能性的型態稽核所需? (A) 正規測試文件 (B) 功能點分

析報告 (C) 所有正式認可變更報告 (D) 前一個發行文件的更新。B 下列有關組態管理(Configuration Management)敘述，哪些是正確的？

(A) 組態狀況報告在提供軟體發展過程之紀錄，作為專案規劃、執行與控制之參考依據(B) 組態管理之目的在建立軟體發展過程中所有紀錄，作為專案規劃與維護管理的依據(C) 組態變更控制為在控制軟體組態的項目、基準線，安排組態項目的發展時程(D) 組態稽核是針對組態項目中已建立的基準線提出修改，進行評估、協調及核准。AB

下列關於組態稽核工作應把握原則之敘述，何者有誤？(A) 稽核小組應與軟體開發工作人員在一起，以加速稽核的速度與成效 (B) 稽核的主要對象是正在開發中的軟體為主 (C) 稽核必須針對各基準線產生變更的軟體項目實施稽核工作 (D) 實施稽核工作除了進度追蹤以外，在品質管理方面必須做更深入的探討。A

49

軟體建構管理工具應用

GIT VSTS

50