國立中央大學資訊工程學系書報討論主講人：李清雲博士 Lee, Ching-Yun Ph.D.

軟體品保概論 國立中央大學資訊工程學系書報討論主講人：李清雲博士 Lee, Ching-YunPh.D. C.Y.Lee

報告大綱 壹、軟體品質的基本觀念貳、軟體發展流程參、軟體文件的最低需求肆、CMM及推動效益伍、結語 C.Y.Lee

壹、軟體品質的基本觀念 什麼是軟體品質？如何提昇軟體品質？ C.Y.Lee

軟體品質的定義  IEEE STD 729-1983定義：一軟體產品整體的功能與特質滿足其既定規格的程度。  DOD-STD-2168定義：一軟體產品符合其既定需求的程度。  綜合定義： 適用(fitness for use) 滿足需求(meet requirements)： - 功能需求(Function requirement) - 績效需求(Performance requirement) - 品質需求(Quality requirement) C.Y.Lee

軟體品質保證 IEEE 定義：以有計畫(planned)且有系統(systematic)的方法與作為，為產品的品質樹立信心。 ISO 8402定義：品質保證係指為了提供適切之信心以使一項產品或服務滿足所設定之品質需求，而建立之各項必要的規範及系統性之措施。  DOD-STD-2168定義：確保軟體能滿足其被指定的需求。 (換言之：確保軟體能滿足客戶所提出之各項需求規格) C.Y.Lee

軟體籌獲之需求 軟體產品的籌獲者，有權提出下述要求，並明訂於合約中： 要求軟體發展者依據特定的標準(如DOD-STD-2167A、 MIL-STD-498、IEEE/EIA 12207)，建立必要的軟體發展流程(Software Development Process)。或者： 要求軟體發展者證明其自身具備特定的流程能力 (如 ISO 9000、CMM Level 3)。 要求軟體發展者必須繳交相關程式及文件(列入CDRL)。 要求軟體發展者所繳交的文件，符合特定的章節格式。 要求軟體必須滿足特定需求：功能、績效、品質需求。 C.Y.Lee

值得深思的議題 印度的軟體公司，軟體程式員的流動率達30%，可是卻不會有工作銜接的問題，任何人都可以辭職，工作照樣可以持續進行。他們在制度的設計上，是如何做到的？ 美國的武器系統悉皆委託民間公司研發，他們究竟是如何防止洩密或舞弊事件的發生？他們在制度的設計上，是如何做到的？ 軟體品質的持續維持，必須依靠適當的制度，而非依靠特定的個人(超級程式師)。 Gen C.Y.Lee

軟體發展常見的怪現象 人員流動(離職∕調職) = 文件(或程式)遺失？ (如果不能妥善保存，就有可能會發生。) 「文件修改」 = 「文件重新打字」？ (文件紙本歸檔，文件電子檔卻未歸檔。) 「軟體維護」 = 「軟體重新研發」？ (軟體難以維護，乾脆全部程式重寫。) C.Y.Lee

軟體難以維護的原因  文件、程式遺失或殘缺不全；  對於特定的軟體版本，無法獲知完整的「文件清單」；  對於特定的軟體版本，無法獲知完整的「程式清單」； 「文件的記載」與「軟體的實際狀況」不吻合； 「程式的註解」與「程式碼」不吻合； 「程式的註解」語焉不詳；  程式的註解不足(註解率過低) ；  未制訂(或未遵循)程式撰寫風格/規定； 彼此看不懂別人撰寫的程式 自己所寫的程式，過了一年以後，甚至連自己也看不懂  測試紀錄不完整；  問題無法追溯。 “” 表示可以藉由「軟體型態管理」來加以解決。 C.Y.Lee

軟體發展常見的問題  文件及程式的修改，無法回溯其修改原因；  誤用舊版的文件；  文件及程式隨著人員的流動而流失；  無法獲知文件及程式的最新版本狀況及修改情形；  文件的內容與軟體的實際設計不符；  程式的修改沒有正確的分析，造成程式交互影響，而產生錯誤；  程式的修改沒有加以管制，造成版本的混亂；  測試不正確的軟體版本；  安裝不正確的軟體版本；  已經發現問題，卻沒有被追蹤解決。 C.Y.Lee

品質成本 提昇品質，必須投入必要的成本 (Quaqlity is not free.) ISO 9000：2000 品質管理系統-要求(QMS，Quality Management Systems-Requirements) ： 管理責任：承諾、顧客為重、品質政策、規劃、審查 資源管理：資源提供、人力資源、基礎架構、工作環境 產品實現：規劃、設計及開發、採購、生產及服務提供 量測、分析與改善：監督及量測、不符合產品之管制、資料分析、改善(持續改善、矯正措施、預防措施) C.Y.Lee

產品顧客需求 ISO 9000 以系統化的作為，來確保品質 ISO 9000：2000 品質管理系統：系統化、文件化  管理責任，資源管理，產品實現，量測、分析與改善品質管理系統之持續改善顧客滿意管理責任量測、分析與改善資源管理產品實現輸入輸出 C.Y.Lee

專案規劃-活動與產品 (1/2) 相關的「活動」(Activities) 與「產品」(Products) ：(MIL-STD-498) (1)階段活動：5.3系統需求分析、5.4系統設計、5.5軟體需求分析、5.6軟體設計、5.7軟體製作與單元測試、5.8單元整合與測試、5.9CSCI鑑定測試、5.10CSCI/HWCI整合與測試、5.11系統整合測試、5.12軟體使用準備、5.13軟體移轉準備。 (2)綜合活動：5.1專案計劃與監督、5.2建立軟體發展環境、5.14軟體構型管理、5.15軟體產品評估、5.16軟體品質保證、5.17矯正行動、5.18聯合技術與管理審查、5.19其它活動。 C.Y.Lee

專案規劃-活動與產品 (2/2) (2)相關產品：系統規格(SSS)、作業概念說明(OCD)、系統設計說明(SSDD)、軟體需求規格(SRS)、界面需求規格(IRS)、軟體發展計畫(SDP)、軟體設計文件(SDD)、界面設計文件(IDD)、資料庫設計文件(DBDD)、原始程式碼(Source Code)、軟體測試計畫(STP)、軟體測試文件(STD)、軟體測試報告(STR)、版本說明文件(VDD)、軟體產品規格(SPS)、軟體使用手冊(SUM)、軟體輸入輸手冊(SIOM)、軟體中心操作員手冊(SCOM)、軔體支援手冊(FSM)、電腦作業手冊(COM)、軟體安裝計畫(SIP)、軟體移轉計畫(STrP)。 成本的考量與約定： SOW (Statements of Works) 工作說明書 CDRL (Contract Data Requirement List) 合約資料需求清單 WBS (Work Breakdown Structure) 工作分解架構 C.Y.Lee

審查，稽核 評估，監控軟體品質的達成軟體品質的達成工程上的作為(DOD-STD-2167A) 軟體發展計畫書(SDP) 品保上的作為(DOD-STD-2168) 軟體品質計畫書(SQPP) 軟體發展管理 (4.1) 召開審查會，審查文件及程式，以找出不符合需要的缺點。並針對各項問題缺失，執行矯正行動。 監控矯正行動。(4.8) 軟體評估。(5.1) 軟體文件評估。(5.2) 發展過程評估。(5.3) 軟體發展館(SDL)評估。(5.4) 非發展軟體評估。(5.5) 非交付軟體評估。(5.6) 軟體工程及測試環境評估。(5.7) 分包商管理評估。(5.8) 支援驗收檢視及交貨。(5.9) 支援正式審查與稽核。(5.10) 軟體工程發展 (4.2) 品質的植入 (Quality is Design-in) 將各項功能需求及品質需求轉換成軟體設計及程式碼。 (參見各項軟體品質因子) Factors 正式鑑定測試 (4.3) 測試軟體以找出不符合規格的錯誤軟體產品評估 (4.4) 評估軟體產品以確保符合合約要求，並找出是否有隱含對品質不利的因素。軟體構型管理 (4.5) 確保軟體的變更在適當的管制下進行，使軟體版本不致失控，並確保軟體變更後，留下完整的記錄。軟體移轉支援 (4.6) 確保軟體開發完成後，得以順利移轉，以進行後續之運作支援。 C.Y.Lee

軟體發展 計畫書貳、軟體發展流程 (DOD-STD-2167A) 系統需求分析系統設計軟體需求分析軟體初步設計軟體細部設計編碼與元件測試軟體組件整合測試軟體型態項目測試系統整合與測試系統規格初稿系統規格軟體測試描述 (測試個案) 軟體測試描述 (測試程序) 系統/ 子系統規格文件軟體測試計畫書軟體測試報告軟體設計文件 (初步設計) 軟體設計文件 (細步設計) 軟體需求規格初稿軟體需求規格原始程式碼已更新之原始程式碼交付產品版本說明文件界面需求規格原始程式碼列表界面設計文件初稿界面設計文件界面需求規格初稿軟體產品規格運作及支援文件發展型態審查與稽核功能/實體型態稽核系統設計審查系統規格審查初步設計審查關鍵設計審查測試備便審查系統需求審查產品基準配置基準基準功能基準 C.Y.Lee

軟體發展流程的一般需求(DOD-STD-2167A)(1/2) 功能項目一般需求項目 • 確保分包合約產品符合主合約要求 • 依據合約，與IV&V承包者相互溝通 • 建立並維護SDL之正常運作 • 實施矯正行動過程 • 準備各項問題報告及變更報告 • 履行合乎合約要求的軟體發展過程 • 執行/支援各項審查與稽核 • 準備軟體發展計畫嚴格遵循之 • 貫徹風險管理程序 • 遵行合約安全需求軟體發展管理 • 以文件記錄各需求項目的可追溯性 • 採用必要的或經核准的高階語言 • 實施設計與程式撰寫標準 • 建立各CSCI、CSC及CSU之SDF • 監管各項處理資源的運用及儲備容量的運用情形 • 採用系統化及有正式文件記錄的軟體發展方法 • 建立軟體工程環境 • 識別並分析出各項潛在危害條件 • 考量非發展軟體的使用 • 將各CSCIs劃分成CSCs及CSUs 軟體工程發展 • 在目的電腦執行正式鑑定測試(FQT) • 準備軟體測試計畫，嚴格遵循之 • 建立軟體測試環境(STE)，測試STE 中的各個項目 • 確立FQT各項活動的獨立性 • 以文件記錄各需求項目到測試個案之間的可追遡性正式鑑定測試 C.Y.Lee

軟體發展流程的一般需求(DOD-STD-2167A)(2/2) 功能項目一般需求項目 • 準備及保存歷次之產品評估記錄 • 採用各項評估準則 • 評估各交付產品 • 確立各產品評估活動獨立性 • 內部協調交付前各交付項目的最後一次產品評估軟體產品評估 • 準備及撰寫下列工作之計畫文件，並履行之：型態識別、型態管制、型態狀況記錄 • 準備記錄交付項目的儲存處置與交付之方法程序之文件並履行之 • 準備各項針對基準變更的ECPs及 SCNs 軟體型態管理 • 在指定的支援境之中進行安裝與檢測並依合約要求提供與訓練與後續支援 • 按照合約的要求準備與等文件 • 使用官方硬體及軟體以提供可再產生及可維護的程式碼 • 準備將交付軟體移轉到支援階段的各項計畫軟體移轉支援 C.Y.Lee

程過展發目項態型體硬 SDR SSR PDR CDR CDR FCA FCA PCA FQR PCA PDR TRR 軟體型態項目發展過程「系統發展過程」與「軟體發展過程」硬體型態項目測試製造細步設計初步設計硬體需求分析系統規劃系統整合與測試運作測試與評估生產與部署系統需求分析系統設計 SRR 軟體需求分析初步設計細步設計程式撰寫與軟體單元測試軟體組件整合測試軟體型態項目測試發展型態功能基準配置基準產品基準 C.Y.Lee

軟體產品驗證流程 系統分析與設計系統整合與測試軟體型態項目測試軟體需求分析系統需求審查系統設計審查軟體初步設計軟體組件整合測試軟體規格審查審查 Review for Defect 測試 Test for Error 軟體細部設計軟體單元測試初步設計審查發展流程驗證流程程式撰寫關鍵設計審查 C.Y.Lee

軟體型態管理 型態管理任務  型態識別(其目的為)： (1)說明專案計畫所使用的基準，基準間的關係及如何建立每一基準(基準管理)。 (2)說明文件、程式碼、媒體之識別與修改記錄的方法。 (3)界定每一軟體型態項目及所屬軟體組件與軟體元件之識別方法。  型態管制(其任務為)： (1)建立軟體型態項目修改之程序及方法。 (2)建立軟體(文件、程式、媒體)之儲存、處理及交付程序。  型態狀況記錄：版本說明文件(VDD) C.Y.Lee

基準關係及組成基準文件 系統規格功能基準介面需求規格軟體需求規格配置基準軟體測試計畫軟體測試文件軟體測試結果軟體設計文件介面設計文件原始程式碼程式目的碼發展型態可執行碼產品規格產品基準 C.Y.Lee

計畫管制室(PMO) 軟體型態館 A1 B1 C1 A0 B0 C0 目的平台 (Target Platform) 拷貝 (Copy) 拷貝 (Copy) 安裝 (Install) 軟體發展單位軟體發展館 A0 B0 C0 簽入 (Check-in) 簽出 (Check-out) 個人工作區 A0 A1 B0 B1 C0 C1 拷貝 (Copy) 整合測試區 A1 B1 C1 不同層級的軟體型態館 C.Y.Lee

「軟體品保」與「軟體工程制度」 重要觀念：「軟體品保」是「軟體工程制度」不可分割的一部份。 若欲執行「軟體品保」，則必先建立「軟體工程制度」。 若未建立「軟體工程制度」，而欲執行「軟體品保」，其結果必然是困難重重、事倍功半。 C.Y.Lee

DOD-STD-2167A 與 DOD-STD-2168 • DOD-STD-2167A(Quality Design-in， Defense System Software Development)： Create a process that will procedure the designed quality in the software produce during development. • DOD-STD-2168(Quality Assessment)： Create a process to provide an independent assessment of whether designed quality has been achieved. C.Y.Lee

品質的植入 (Quality is Design-in) 大部份的軟體問題，均在需求分析與設計階段已發生，但直到整合測試階段才發現。問題愈晚發現，所耗費的改正成本愈高。 軟體品質需求必須視為整體系統需求的一部份，以便軟體品質能在發展過程中設計進去。 人員應給予必要之訓練，使具備品質的技術與能力。 軟體發展必須有一套程序與方法。 應明確訂定品質需求。 C.Y.Lee

軟體品保相關重點工作項目 程序稽核，主要稽核內容： 基本發展流程(發展環境、發展方法、發展工具、品質履歷表) 構型管理流程(型態館、型管工具、型管程序) 軟體測試流程(測試環境與工具、測試個案與方法、測試涵蓋率) 問題追蹤管制流程(問題反映、問題追蹤、問題矯正) 文件審查，主要審查內容： 必要的軟體文件(SDP、SRS/IRS、STD/STR、VDD、SPS) 軟體需求追溯 程式碼品質評估，主要評估內容： 程式碼風格 軟體品質量指標(軟體可維護度) C.Y.Lee

軟體品保作業程序與執行頻率(1/3) 執行頻率軟體品保作業程序符合2168條款之要求 1.品質目標與權責 -目標與權責規劃 -管理審查 4.1, 4.2, 4.9, 4.10, 4.11 持續進行一年一次 4.3, 4.4, 4.5 2.軟體品質工作規劃持續進行視對象而定 3.軟體品質評估 4.6 4.7 4.軟體品質記錄每次評估時 5.矯正行動 -追蹤管制 -趨勢分析 4.8 發現問題時 6.軟體評估 -軟體設計評估 -程式碼評估 -軟體測試見證 5.1 每月一次每月一次每次測試時 C.Y.Lee

軟體品保作業程序與執行頻率(2/3) 軟體品保作業程序符合2168條款之要求執行頻率文件發行時 7.軟體文件評估 5.2 8.軟體發展過程評估 -軟體發展管理 -軟體工程 -軟體鑑定測試 -軟體型態管理 -矯正行動 -文件及媒體之分發 -儲存、處理及交貨 -其他 5.3 5.3.1 5.3.2 5.3.3 5.3.4 5.3 .5 5.3 .6 5.3 .7 5.3 .8 半年一次半年一次三個月一次每月一次每月一次每月一次兩月一次依合約規定 5.4 9.軟體發展館評估三個月一次 C.Y.Lee

軟體品保作業程序與執行頻率(3/3) 執行頻率軟體品保作業程序符合2168條款之要求 5.5 10.非發展軟體評估軟體變更時 11.非交付軟體評估 5.6 軟體變更時環境變更時 5.7 12.軟體工程與測試環境評估 13.分包商管理 -分包商行動評估 -分包商需求評估 5.8 兩月一次兩月一次每次交貨時 14支援準備工作評估 -驗收檢視 -交貨準備 5.9 15.參與正式審查與稽核 5.10 每次審查時 C.Y.Lee

參、軟體文件的最低需求 為什麼需要撰寫文件？文件化有何好處？ C.Y.Lee

為什麼需要撰寫文件？文件化有何好處？ 經驗的累積、傳承：文件化之後，可使得前人的工作經驗得以累積、傳承，避免因為人員的流動而造成智慧經驗的流失。 一致性、標準化的考量：文件化可以促進作業的一致性及標準化，不會因人、因時、因地而異。 註：知識管理(Knowledge Management) (1999年由「哈佛企管評論」所提出的新概念) – 知識可分為外顯的知識及內隱的知識。「外顯的知識」可以透過書面文件的撰寫來展現、累積與傳承；「內隱的知識」則需透過資料探勘(Data Mining)的技術來分析、發掘。 C.Y.Lee

台積公司的知識管理(1/2) 張忠謀接受遠見專訪時就說：「我最深惡痛絕的就是把資訊據為己有的人，他們害怕別人獲取資之後，自己的地址會受到動搖。」(註：害怕被別取而代之) 組織的知識管理，就是組織內的經驗、知識可以有效記錄、分類、儲存、擴散以及更新的過程。 台積就是要做到More Communication, No Complain (多溝通、少抱怨)；要多做溝通，把一些歧見化解。 知識管理的一個重要特色，是組織中要能將知識儲存、標準化、建檔，同時知識要能在組織內擴散出去，讓沒有經驗的人來接手時，只要參考各種有關的工作知識存檔，就可立即上線。…藉由討論、分享將每個人的工作經驗以電腦編碼儲存，使得台積的新人很快就可以踏著前人的汗水前進。 (摘自「張忠謀與台積的知識管理」，天下遠見出版公司，2000年6月) C.Y.Lee

台積公司的知識管理(2/2) 在台積的人事考項目中，能不能將自已的工作經驗記錄、編碼、儲存，並與人分享經驗，是重要項目之一。 台積為了保固知識，有一個安全的防範措施：每一份資料都各自存在兩個不同建築物的電腦內。(資料異地備援) 台積有形的智慧資本是專利、資料、客戶檔案、製程技術、做事的方法以及營業機密等。 知識管理需要領導人的願力：張忠謀一直相信，領袖最重要的任務是承載願景。張忠謀說：「領袖是願景的容物。」 台積之所以能不斷累積組織知識，並立即轉型成功，主因是張忠謀強勢導引台積人一定要熱愛學習，要台積成為一個「學習型組織」(又稱為「知識型組織」)。 C.Y.Lee

必要的軟體文件 軟體發展計畫書(SDP) 軟體需求規格(SRS) 、介面需求規格(IRS) - 「配置基準」(Allocation Baseline) 軟體測試報告(SRS) - 內含測試個案、測試結果 版本說明文件(VDD) - 是每一個凍結版本需有一份版本說明文件 軟體產品規格(SPS) - 於「工程發展階段」結束前撰寫，視為「產品基準」(Product Baseline)： (SRS, SDD, VDD) C.Y.Lee

軟體需求規格 (SRS) - 軟體品質因素 外部特性 (由客戶的觀點看) 內部特性 (由發展者及維護者的觀點看) 軟體品質因素(Software Quality Factors)： • 正確性(Correctness)：軟體滿足其指定需求的程度 • 可閱讀性(Readability)：程式或文件閱讀容易的程度 • 可靠性(Reliability)：軟體與其應執行功能間一致性的程度 • 可維護性(Maintainability)：軟體找出並更正一錯誤所需要付出的程度 • 效率性(Efficiency)：軟體執行其指定功能時最低消耗的電腦時間及記憶體資源的程度 • 可移植性(Portability)：軟體由一硬體或軟體境轉移到其它環境時所需要付出的程度 • 彈性(Flexibility)：可變更性，加強或修改軟體以滿足新需求時，所需要付出的程度 • 可測試性(Testability)：驗證軟體正確的執行其功能，所需要付出的程度 • 可再用性(Reusability)：軟體能夠被使用在多個應用中的程度 Back15 C.Y.Lee

軟體需求規格(SRS) - 鑑定需求 鑑定需求(Qualification Provisions)：定義一組鑑定方法，並指明在第3章每一需求所用的鑑定方法，以確符合需求。鑑定方法可包括： (1)展示(Demonstration)：CSCI或部份CSCI之操作，藉著觀察功能操作而不需要使用儀器、特別測試設備或後續分析。 (2)測試(Test)：使用儀器其他特別測試設備來蒐集資料，供作爾後之分析。 (3)分析(Analysis)：處理由其他鑑定方法得到的聚集資料。例如測試結果的濃縮、解釋或延伸。 (4)檢視(Inspection)：CSCI程式碼、文件等之目視檢查。 (5)特殊鑑定方法(Special Qualification Methods)：對CSCI的任何特別鑑定方法，諸如特殊工具、技術、程序、公共設施與接受限制。 C.Y.Lee

軟體需求規格文件中的「需求追溯性」 驗證交互參考對照表(VCRM)：(SSS  SRS) (Verification Cross Reference Matrix) ：軟體需求名稱、軟體需求名稱、鑑定方法(D/T/A/I/S) 需求追溯性對照表(RTM)：(SRS  SDD) (Requirement Traceability Matrix) ：軟體需求名稱、軟體單元名稱 測試評估對照表(TEM)：(SRS  STR) (Test & Evaluation Matrix) ：軟體需求規格、軟體測試個案、測試層級、測試結果等 C.Y.Lee

軟體問題追溯 前述三表VCRM、RTM、TEM可以用來達成軟體問題之追溯對應ISO9001：2000條款「7.5.3鑑別與追溯性」 (由最終產品之問題，追溯生產過程及原物料之問題) 當軟體發生問題時，如何追溯問題根源？ (一)原始的軟體需求規格是如何定義的 – 需求規格的定義是否有不足或遺漏？ (二)當初的軟體是如何設計的 – 軟體計設計是否有不足或遺漏？ – 相關的「軟體單元」是哪些？ (三)當初的軟體是如何測試的 – 「軟體測試個案」是否有不足或遺漏？ C.Y.Lee

軟體後續維護之問題 • 在欠缺完整文件/記錄的情況下，如何進行問題追溯與軟體維護？ 由原設計開發者開解決 – 如果原設計開發者已經離職，怎麼辦？ 進行「逆向工程」(Reverse Engineering) – 由程式碼來反推軟體「設計」與「需求規格」 – 軟體的維護成本，遠超初次開發的成本通常都是因為「正向工程」沒有做好，才會需要「逆向工程」！ C.Y.Lee

版本說明文件 (VDD) 「版本說明文件」是用以說明該軟體版本凍結之後的版本相關資訊，包括： 本次的系統版別 歷次系統版本的功能異動情形 全軟體部檔案的名稱清單及簡要說明 作業環境之限制：例如適用於何種電腦機型、適用於何種作業系統、所需的主體記憶體數量、所需的硬體空間等等。 軟體系統的安裝步驟及說明 對應的文件(含文件編號、版別)。例如：系統規格書、軟體需求規格，軟體設計文件、軟體試試文件、使用手冊等等 其它注意事項 C.Y.Lee

肆、CMM及推動效益 軟體能力成熟度模式(CMM) –起源 1986年11月美國卡內基-美隆大學(Carnegie-Mellon Univ.，CMU)的「軟體工程研究所」(Software Eng. Institute，SEI)開始致力於軟體發展過程改進之成熟度架構的研究。  1987年9月SEI針對「軟體發專案的自我改進」及「軟體承包商的選定」等課題，發展出「軟體能力成熟度模式」(Capability Maturity Model for Software, SW-CMM)  1991年9月美國空軍總部通知軟體承包商：「所有參加競標空軍軟體系統的軟體發展公司，皆必須證明其具有CMM第三階層的成熟度」。 C.Y.Lee

軟體能力成熟度模式(CMM) – 架構 階層名稱專案發展能力注重之焦點關鍵過程範圍 Level 5 能預測風險， 持續改進的發展 缺點預防措施最佳層並隨時調適至過程 技術變更管理 (Optimizing) 最佳化。 過程變更管理 Level 4 已使用統計方 產品及過程之品質定量過程管理管理層法，進行組織 可預測的發展過程 軟體品質管理 (Managed) 性分析。 訓練計畫 組織過程定義 群際協調 軟體產品工程 同僚審查 整合性軟體管理 組織過程焦點 Level 3 「軟體發展之經 工程化(標準化、一定義層驗法則」及「正致性)的發展過程。 (Defined) 式的發展過程」皆已被定義。 軟體品質管理 軟體專案規劃 軟體型態管理 軟體轉包合約管理 需求管理 軟體專案追蹤與監督 Level 2 時程及成本控 專案的管理重複層制等經驗法則 規律的的發展過程 (Repeatable) 已建立。 Level 1 毫無章法的發英雄式主義， (無) 啟始層展過程。以一當十。 (Initial) C.Y.Lee

CMM的推動效益 軟體能力成熟度模式(CMM) –起源 目前世界上成熟度最高的「洛克希德馬丁公司」(F-16戰鬥機製造商)在連續五年改善軟體發展流程後，該公司軟體的瑕疵降低90%，上市時間增快40%，開發成本降低75%。 一個成熟度高的軟體公司，其產品的瑕疵，比不成熟的公司少了1/3以上。 「修改錯誤的時間」約佔「整體軟體發展時間」的50%，錯誤發現的愈晚，修改的成本就愈高。因此，嚴謹的流程能夠縮短開發時程，軟體發展成熟度每提昇一級，就可以降低5%到10%的開發成本。 全球化、國際化、與世界接軌。 C.Y.Lee

國內CMM的推動狀況(92/10) 資策會：CMMI Level 2 碩網公司： CMMI Level 3 三商電腦公司(92/04/19)： CMMI Level 2 推動的起源：錯失商機(失去500萬美元的專案)。 推動的效益：92 年度因CMMI獲得26億元之公共工程專案。 工研院電通所(92/09/04)： CMMI Level 2 • 全球CMM/CMMI Level 2通過率最低的「流程領域」為CM(型態管理) (低於70%)。 • 導入、推動CMM/CMMI是一種「組織工作文化」的改造。 C.Y.Lee

伍、結語 推行軟體品保的幾點建議： 主管的重視與支持 配合推動軟體工程制度的建立 對於品質的要求，宜逐步漸進 全員參與，持續改善  Do the thing right. Do the right thing.  It suits my needs. Wish C.Y.Lee

值得深思的部份 達成目標績效要件 • 達成目標的兩個要件(影響績效的兩個要件)：改善制度研發技術生產技術生產技術行銷技術等適當的方法不會做適當的方法 + + 原因人執行的意願 (口見、願) 企業精神企業文化團隊形成溝通協調等不想做氣執行的意願 (主動、用心) • 不會做沒有能力 • 訓練值得深思的部份 • 不想做沒有動機 • 創造動機、強化驅力激勵主動做、結果好、能力再現；擴散、創造團隊環境。 Back7 C.Y.Lee

Back Back C.Y.Lee

國立中央大學資訊工程學系書報討論主講人：李清雲博士 Lee, Ching-Yun Ph.D.