A Case Study of SQA Planning

1. A Case Study of SQA Planning 在軟體發展之前的系統需求與分析階段中，訂定了日後產品的需求，而為了能更進一步地要求此產品的品質，則需要在軟體發展階段中加入軟體品保的工作。 同樣地，在軟體的發展過程中，包括設計、測試、維護階段中，軟體品保工作可以使人相信各CSCI與所有的需求及軟體技術標準能夠一致。 1

2. 1. 何謂品保 在談到軟體品保的過程以前，必先定義何謂品保？在Pressman的教科書中談到基本的定義：“品保即是與需求的一致性”，其特性包括： (1) 可指明的 (2) 可測試的 (3) 為USER定義的 (4) 可建立的 這些特性的基準乃是以需求為基準並指明以何種標準為主，另外尚包含一 些內含式需求，如維修度、可靠度等等，若不能滿足這些需求，仍然不能號稱產品具有高度品質。那麼，究竟是那些因素會影響軟體品質呢？大概來說，其可以分為兩大類： (1) 能夠直接量測的，如錯誤次數/KLDC(Thousand Line of Code) (2) 不能直接，而只能間接量測的因素，如維修度、可靠度等。 有些學者提出過的因素如下: (1) 產品操作部份： a. 正確性 (產品作用為需要的嗎？) b. 可靠度 (產品永遠正確地操作嗎？) c. 效率性 (產品可以在硬體架構上運轉地很好嗎？) d. 完整性 (該產品完整嗎？) e. 使用性 (能執行該產品嗎 ？) 2

3. (2) 產品校正 a. 維護度 (我能將產品修定嗎 ？) b. 彈性 (我能改變它嗎？) c. 安裝性 (我能測試它嗎？) (3)產品轉移 a. 移轉性 (該產品能夠容易地轉移到另一機器上執行嗎？) b. 重使用性 (我能夠使用到該產品的一部份嗎？) c. 溝通性 (我能夠與其他系統做介面嗎？) 這些因素構成一個量測的公式，其數學式為： : Fq = C1 × m1 + C2 × m2 + ．．．+ Cn × mn 其中 Fq為軟體品質因素 Cn 為迴歸係數(Regression Coefficient) mn為影響軟體品質因素的公制(共同制定的品質指標)，其為Checklist 的形式，用以指定軟體產品的特性，其grade由0 (低)至 10(高)，該mn包括下列各項因素： (1) Auditability :檢查與標準之一致性。 (2) Accuracy：計算與控制的精準度。 (3) Communication commonality：標準介面、Protocols與頻寬的程度。 (4) Completeness：完成整個軟體功能。 3

4. (5) Conciseness ：程式的簡明性。 (6) Consistency ：軟體專案中使用一致的設計與文件標準。 (7) Data Commonality：在程式中使用標準的資料結構與型態。 (8) Error Tolerance：當程式碰到錯誤的損壞情形。 (9) Execution Efficiency：程式的執行效率。 (10) Expandability：設計方法能延伸的程度。 (11)Generality：程式元件能運用的延伸程度。 (12) Hardware：程式執行環境的獨立性。 (13) Instrumentation：監督程式運轉與標明錯誤發生的程度。 (14) Modularity：程式元件的功能獨立性。 (15) Operability：程式運轉的容易性。 (16) Security：控制與保護程式與資料的程度。 (17) Self-Documentation：程式提供有意義說明文件的程度。 (18) Simplicity：程式容易瞭解的程度。 (19) Software System Independence：程式與作業系統特性、非標準程式語言與其他環境限制的獨立程度。 (20) Traceability ：追溯設計或實際程式至需求的程度。 (21) Training：程式協助使用者去運作程式的能力。 這些量測標準與軟體品質因素的關係如圖 7.1-1 4

5. (Usability) 使用性 (Interoperability)溝通性 (Reusability) 重使用性 (Portability) 移轉性 (Installability) 安裝性 (Flexibility) 彈性 (Maintainability) 維護性 (Integrity) 安全性 (Efficiency) 效率性 (Reliability) 可靠度 (Correctness) 正確性 軟體品質公制 軟體品質因素 Auditability X X Accuracy X X Communication Commonality X Completeness X Conciseness X X X Consistency X X Data Commonality X Error Tolerance X Execution Efficiency X Expandability X Generality X X X X Hardware Independence X X Instrumentation X X X Modularity X X X X X X X Operability X Security X Self - DocumentationX X X X X Simplicity X X X X Software System X X Independence Traceability X Training Complexity X 5

6. 2 軟體品保工作 在軟體發展過程中的軟體品保工作包括： (1) 審查所有軟體文件，以求得該文件與文件及程式標準的正確性及完整性。 (2) 監督所有的軟體資料，媒體與文件的確認及控制。 (3) 確保所有軟體設計審查(SDR)有舉行，而且所有的Action Item有追蹤及解決。 (4) 監督軟體測試以確保有執行軟體測試，測試結果亦撰寫在文件中，而且所有的差異有改正及重新測試。 (5) 參與軟體修正系統中，以確保所有的軟體問題有撰寫在文件中，亦有經過分析，並且問題亦有改正過。 各階段的軟體品保工作，茲分別敘述如下： 2.1 軟體需求分析階段 此階段軟體品保目的包括： (1) 避免與User間有任何不瞭解或誤會的需求。 (2) 確保所有的需求為User所需要，且可以解決User的問題。 (3) 提供給User一個很好的概念，以使User瞭解到即將建立的軟體的輪廓。 (4) 確保User的系統為可實行的，而不是紙上談兵。 (5) 確保所有的需求分析工作，發展者都有執行到。 此階段的軟體品保工作Checklist包括： (1) 協助審查需求 (4) 協助審查此階段所產生的所有技術文件 (2) 分析該需求 (5) 確保所有需求的可追蹤性 (3) 記錄所發現的需求問題 6

7. 2.2 軟體規格 此軟體規範的軟體品保目的，包括： (1) 確保該規範與軟體需求具有一致性 (2) 確保所有規範的時程都有明確標明 (3) 確保所有規範的時程與合約需求一致 (4) 確保所有的軟體規範都有明確的規定 軟體規範的軟體品保工作的Checklist，包括： (1) 各軟體規範是否能夠追蹤到存在的需求 (2) 各軟體規範是否具有彈性與維護性 (3) 完成各軟體規範的責任是否都有指定 (4) 完成各軟體規範的時程是否都已經規定 (5) 完成各軟體規範的成本是否都已經預估 (6) 測試策略是否已經建立，以展示軟體產品符合需求 (7) 特殊的設計標準是否已經指定 (8) 各軟體規範是否已經檢查，以符合內部文件的一致性及完整性 (9) 修改規範的流程是否已經修正過 (10) 各軟體規範是否軍用規範標準 7

8. 2.3 軟體設計階段 此階段的軟體品保目的，包括： (1) 確保軟體設計為可追溯到軟體規範 (2) 確保軟體設計有根據產品指引及品質目標 (3) 確保軟體設計的修正為控制之中 (4) 確保所有的設計工作指引已經建立好後，才開始展開程式撰寫工作 此階段的軟體品保工作的checklist，包括： (1) 是否所有的軟體規範在設計工作展開之前已經依序完成 (2) 是否建立一套標準已表示如何設計 (3) 是否有依照標準來執行設計工作 (4) 是否所有的設計審查工作皆有準時舉行 (5) 是否所有的設計工作皆能追溯到各規範 (6) User是否皆有被通知到設計工作的狀況 (7) 是否所有的設計修改皆有得到正式的許可 (8) 是否所有的設計修改記錄皆有保留 (9) 是否設計階段所有碰到的問題有恰當地報告及解決 (10) 是否所有的設計在release之前皆有符合標準，以利於撰寫程式工作的進行 8

9. 2.4 軟體程式撰寫階段 此階段的軟體品保目的，包括： (1) 確保所有的程式皆能追溯到設計 (2) 確保所有的程式皆能符合規範 (3) 確保所有的程式皆能符合發展標準 (4) 確保所有的程式皆能符合計劃及時程 此階段軟體品保工作的checklist，包括： (1) 是否程式能追溯到既存在的設計 (2) 是否取得程式的保護措施有執行 (3) 是否程式的整合，依照標準的程序 (4) 是否有考慮到不同版本的程式 (5) 是否有撰寫軟體測試計劃 (6) 程式撰寫工作是否依照撰寫標準 (7) 是否所有的程式審查皆有依需求來執行 (8) 是否所有的審查記錄皆有保留 9

10. 2.5 軟體測試階段 此階段軟體品保工作目標包括： (1) 確保有撰寫軟體測試計劃？ (2) 確保有遵守軟體測試計劃？ (3) 確保所有的測試數據，期望的測試結果，實際的測試結果皆有記錄而且保存。 (4) 確保所有的軟體在測試及重新更正後皆與規範一致。 此階段軟體品保工作的checklist包括： (1) 是否建立所有測試數據及測試結果的管理？ (2) 改進測試的工具是否存在？ (3) 是否在測試階段中碰到的問題皆有註明及解決？ (4) 是否所有的測試皆有依據已建立的標準程序？ (5) 是否執行足夠的測試？ (6) 在測試當中是否有嚴格地控制程序？ (7) 是否執行既排定的測試？ (8) 是否審核過測試結果？而且正式答覆滿足合約需求？ 10

11. 2.6 軟體維護階段 此階段軟體品保目標包括： (1) 確保文件與程式的一致性。 (2) 確保程式的修改被嚴格地控制。 (3) 確保程式結構沒有被破壞。 (4) 確保程式符合User的需要。 此階段軟體品保工作的Checklist包括： (1) 是否所有的修改評估記錄皆有保留？ (2) 是否所有的規範、程式、文件皆有因任何的修改而隨著修訂？ (3) 是否監督程序式標準元件？ (4) 是否修改有獨立地審查以求得正確性及可讀性？ (5) 是否有接到修改的任何通知？ (6) 是否修改具有整合到產品的流程？ 11

12. 3 軟體品保成員 在瞭解 軟體品保的重要性、特性後，最重要的是由誰去執行及如何去執行軟體品保工作。軟體品保成員可視為是顧客的代表，去監督發展者如何去發展軟體，它的責任為發掘缺，但不是去修改缺點，它必須是與顧客站在同一立場的人。 軟體品保成員的任務在於： (1) 展現整體之軟體品質的改進。 (2) 定義有用的品質量測公制。 (3) 定義可接收的軟體品質水準。 (4) 解釋/執行合約上的品保需求。 (5) 提供一個與軟體產品品質獨立評估的專案管理。 (6) 提供在發展組織上工作負荷如何降低的計劃。 因此為完成這些任務，軟體品保成員必須撰寫軟體品保計劃，內容包括： (1) 軟體品保計劃的目的。 (2) 參考文件 (3) 管理計劃，包括組織架構、工作、責任。 (4) 文件，包括如何管理與驗證軟體的流程，所需要的文件為SRS、SDD、SDP、 CPDP、SCMP、Standard 。 (5) 所建立的標準，包括Coding Standard 。 12

13. (6) Review與Audit，包括SSR, PDR, CDRFCA/PCA等。 (7) 型管計劃。 (8) 問題報告與修正的流程。 (9) 工具、技巧與方法：敘述其目的及如何運用各項方法。 (10) 程序的控制：敘述如何組合各版本軟體的方法。 (11) 媒體的控制：敘述媒體取得的保護措施。 (12) 轉包商的控制：敘述如何去控制轉包商的軟體品質的計劃。 　　此軟體品保計劃在整個軟體發展計劃中亦是一本非常重要的文件，其品質的好壞將會影響到整個產品的品質。因此，必須花費相當大的代價去撰寫及審查。同時執行軟體品保計劃的成員亦必須具有多方面的知識，才能勝任，所以在挑撰寫成員時亦必須相當慎重。 13

14. 4 最有效的軟體品保工具 有了相當好的軟體品保人員、品保計劃之後，尚必須具有最有效的工具，才能將整個軟體品保工作執行得相當透徹。 甚麼是最有效的品保工具？答案是Peer Review。 在所有的發展及維護過程中，Peer Review能找出相當多的問題。如何找出？茲分別敘述如下： (1) 在需求分析階段：藉由需求審查，以確定需求是否正確地定義。 (2) 在設計階段：藉由審查程式架構及細部設計與PDL。 (3) 在程式撰寫階段：藉由審查Source Code。 (4) 在軟體測試階段：藉由審查所有的測試文件。 (5) 在軟體維護階段：藉由審查所有的文件、Code、修改。 Peer Review的指引(Guidelines)包括： (1) Review 時包括越少人越好，而且成員越早通知越好。 (2) Review必須常舉行，而且必須包括很小部份的工作。 (3) Review必須強調效率及注重所Review 的材料內容，其必須是該階段所能產生的 最佳產品。 (4) Review 最好能有4小時以上的時間來閱讀資料。 (5) Review 最好能有Lead Engineer以上的人參加，以知道問題所在。 14

15. 5. 軟體品質評估 - Trend Analysis 一個系統，包括軟體和硬體難免會發生錯誤，如果錯誤發現得早，則很容易就可以矯正過來，所要付出的代價亦不致於太大，反之如果在後期以後才發現錯誤，則就可能花費10倍以上的代價才能加以矯正，所以近年來有許多單位都投下許多經費在研究如何才能提高產能，也因此才有Trend Analysis的方法產生。 Trend Analysis及是在訂定需求階段時，藉以分析設計需求Sizing與Timing的一個工具。本節將介紹此工具中所利用的幾項軟體品保因素來評估軟體的品質。 15

16. 5.1. 完成度分析(Completeness) 此項因素乃是提供一項因素，藉以表示系統需求轉換成為軟體需求的程度，它可說是最複雜的一項因素了。此項因素可以應用於軟體發展生命週期中，亦可以應用於維護軟體週期中。其輸入參數為： P1：沒有適當地定義的軟體功能之數目 (可在SSR中發現) P2：軟體功能的總數 (在SSR中計算) P3：沒有定義的資料項目的總數 (在PDR中計算) P4：資料項目的總數 (PDR) P5：有定義但沒有使用的功能 (PDR) P6：有定義的軟體功能 (PDR, P6 = P2 - P1) P7：被有定義的軟體功能所參考，但沒有定義的軟體功能數目 (PDR) P8：被有定義的軟體功能所參考到的軟體功能數目 (PDR) P9：沒有使用任一狀態的決定點 (PDR) P10：決定點的總數 (PDR) P11：沒有使用的狀態 (PDR) P12：狀態的總數 (PDR) P13：有呼叫參數，但與所定義的參數不一致的呼叫程式數目 (PDR) P14：所有呼叫程式的總數 (PDR) P15：沒有被設定的狀態之總數 (PDR) P16：有設定但是沒有處理的狀態 (PDR) P17：有設定的狀態之總數 (PDR, P17 = P12 - P15) 16

17. Completeness 1.0 0.75 0.5 0.25 Contract Month 4 5 6 7 8 9 10 … … 15 16 17 18 19 20 21 PDR CDR P18：沒有目的地的參考資料的數目 (PDR) 10 完成度 Cp =  Wi Ci i=1 P1：沒有適當地定義的軟體功能之數目 (可在SSR中發現) P2：軟體功能的總數 (在SSR中計算) P3：沒有定義的資料項目的總數 (在PDR中計算) P4：資料項目的總數 (PDR) P5：有定義但沒有使用的功能 (PDR) P6：有定義的軟體功能 (PDR, P6 = P2 - P1) P7：被有定義的軟體功能所參考，但沒有定義的軟體功能數目 (PDR) P8：被有定義的軟體功能所參考到的軟體功能數目 (PDR) P9：沒有使用任一狀態的決定點 (PDR) P10：決定點的總數 (PDR) P11：沒有使用的狀態 (PDR) P12：狀態的總數 (PDR) P13：有呼叫參數，但與所定義的參數不一致的呼叫程式數目 (PDR) P14：所有呼叫程式的總數 (PDR) P15：沒有被設定的狀態之總數 (PDR) P16：有設定但是沒有處理的狀態 (PDR) P17：有設定的狀態之總數 (PDR, P17 = P12 - P15) 其中 Wi = 1，0  Wi  1 為各項Ci之比重，靠自己決定。 　　 0  Ci  1，其定義為 C1：滿足需求定義的軟體功能，C1 = (P2 - P1) / P2 C2：所定義的資料項目， C2 = (P4 - P3) / P4 C3：所使用的有定義之軟體功能， C3 = (P6 - P5) / P6 C4：所定義的參考軟體， C4 = (P8 - P7) / P8 C5：在決定點所使用的狀態數目， C5 = (P10 - P11) / P10 C6：在決定點所使用的有處理的狀態， C6 = (P12 - P11) / P12 C7：與定義參數一致的呼叫程式， C7 = (P14 - P13) / P14 C8：所有被設定的狀態， C8 = (P12 - P15) / P12 C9：伴隨設定狀態的處理， C9 = (P17 - P16) / P17 C10：具有目的地的資料項目之數目， C10 = (P4 - P16) / P4 0  Cp  1，值越大，越好，可接受的最小值約0.75 17

18. 5.2 設計結構 此項因素乃用於決定一CSCI的細部設計是否簡單。其輸入參數來自於設計與程計，即Design與Code Walkthrough。 S1：軟體之大小 D1：設計是否為Top-Down，Botton-Up， S2：與輸入資料來源有關的單元數目 D1 = (1 = Yes 0 = No) S3：與批次處理有關的單元數目 D2：單元之獨立性， D2 = 1 - ( S2 / S1 ) S4：資料結構項目的數目 D3：與批次處理無關的單元， D3 = 1 - (S3 / S1 ) S5：唯一的資料結構數目 D4：資料結構的大小， D4 = 1 - ( S5 / S4 ) S6：資料結構段的數目 D5：資料結構的封閉性， D5 = 1 - ( S6 / S4 ) S7：單一進入/出口的單元 D6：具有單一入口/出口的單元， D6 = S7 / S1 6 設計結構Ds =  Wi Di i=1 6 其中 0  Wi  1 且  Wi = 1 ，為Di之比重 i=1 0  Di  1 0  Ds  1，值越大，表示設計結構越簡單。可接受的值最小值約為 0.6 18

19. 5.3 缺陷密度 (Defect Density) 此項因素可以提供作為軟體設計與程式製作品質的一項數據。 其輸入參數直接來自設計與Code Inspection的過程，其中缺陷(Defects)可能為需求、設計、程式製作等種類。其運算式為 　　　　　　缺陷總數 　　　　　　＃of 單元 Defect / Unit Defects Discovered 1.5 Defects Corrected 1.0 0.5 Contract Month 4 5 6 7 …... 14 15 16 17 18 19 20 21 CDR 19

20. 5.4　錯誤密度 (Fault Density) 此項因素與缺陷密度很類似，最大的不同點在於此項錯誤密度為發生於測試時的錯誤。同時亦藉以決定是否執行足夠的測試。 其輸入參數直接來自於測試結果。在各階段的發生錯誤之密度值為： Phase Error Introduced (%) Error Detected (%) Analysis 55 18 Design 30 10 Coding & Test 10 50 Operation & Maintenance 5 22 錯誤總數 Fault Density = # of Unit 如系統含許多CSCI則可取平均數! Fault Density Faults Discovered 40 Faults Corrected 30 20 10 Contract Month 19 21 23 25 27 29 31 33 35 37 39 41 43 TRR CDR 20

21. 5.5 測試範圍 (Test Coverage) 此項因素代表從發展者與使用者的立場來判定是否所有的測試都完成。測試包含了單元、CSC 、CSCI 、系統與接收測試。 軟體程式與需求的結合，即產生此項因素，其運算式為 測試的功能　　　測試的軟體結構 TC = ＊　　　　　　　　　＊ 100% 　　　 需求的功能 總軟體結構 Test Coverage Planned 100% Actual 75% 50% 25% Contract Month 31 33 35 37 39 41 43 45 47 49 51 TRR FCA PCA FCR 21

22. 5.6 測試整合 (Test Sufficiency) 此項因素乃依據預估軟體錯誤會留下的結果，來預測軟體整合與系統測試是否足夠的一個有用的工具。換句話說，此項因素即根據錯誤密度因素的經驗值。因此可以做為是否可以接收的一項依據。其輸入值為： PF：錯誤的預估數目 輸出參數為 FP：S/W 整合測試前發現的錯誤 FR(留下的錯誤) = ( PF - FP ) * ( UI / UT ) - FD UI：整合的軟體單元 MAXT(最大的容許度) = C1 * FR UT：CSCI的單元數目 M I NT(最小的容許度) = C2 * FR FD：在測試時發現的錯誤數目 其中 C1 與 C2 為容許度的係數，自行決定。 Faults Encountered 4000 3000 MAXT 2000 Prediction 1000 MINT 31 33 35 37 39 41 43 45 47 49 50 TRR FCA PCA FQR 22

23. 5.7 文件 此項因素乃是藉以判斷是否有足夠的文件伴隨著產品，文件的產生將會影響到軟體的使用性與維護性。 此項因素乃是預測各軟體單元的一致性、簡單性、擴充性等特性。 Document Index (DI) = 其中W1i為文件之比重係數  W1i = 1 W2i為程式之比重係數  W2i = 1 Di為文件產品 Si為Source Listings 6  W1i Di + i =1 6  W2i Si i=1 2 DI 6 5 4 Min - Level 3 2 1 Contract Month 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 PDR CDR 23