QP,
品質規劃(Quality Planning)、品質保證(Quality Assurance)與品質控制(Quality Control)在台灣的工作環境中，除非有一定規模或一定制度的公司，遵循一定的品質作業規則，不然很難體會軟體專案中品質管理的程序與作業。最最簡單的一個問句：「您們工作團隊，是否有程式撰寫作業準則或者變數編碼規則？」這也是國珍與東豪同學對於軟體專案品質管理的疑問？我們是否真正的重視與落實品質管理？還是它只是一個空頭的名詞，以讓公司可向客戶多爭取點專案的經費？
【軟體專案管理】書本上將軟體品質定義為：軟體產品整體的功能和特性滿足既定需求的能力。更白話一點的說，就像日本的Mint(經營情報研究會)所著，周明憲所譯的【軟體工程實務】所寫的：「(1)正確的運作。(2)不會當機。(3)容易使用。(4)回應快速。(5)易於維護。(6)易於移轉。」這些要求可概括的區分為功能性與非功能性的要求；就過程而言，就如Deutach與Willis(1988)所分別的程序品質(Process Quality)與產品品質(Product Quality)。
目前，對於專案一般認知的”triple constraint” - scope, schedule, cost，目前很多的討論與研究中已經把”quality”或”performance”抽離出來成為第四個constraint。就肥蝦的觀點，原本的專案管理三角形(Project Management Triangle)，可以畫成【圖一】
那何為「Quality或Performance？」因為品質不能空口說白話，品質需要有一定的定義與Metric可以供測量。記得九十三年六月至十二月被賣到資策會資訊工程所作「電子化政府共通作業平台規劃專案」，每一篇徵求建議書(RFP)都會提到作業需求、功能需求、界面需求、環境需求(內含非功能需求)。這些需求有時會定義出下限，如非功能需求中列示了：「可利用率達99.95%，一般作業時間：2秒，尖峰作業時間: 3秒線上，同時維持200使用者之滿載，負荷10分鐘以上。」這些要求，不管是對於user或vendor來說，都是要達到的水準。為了達到此要求，vendor必須於建議書中定義出一些方法、規範、公式、標準、容忍誤差，以及必要的作業方法與管理流程。整體系統的架構規劃與設計，當然就需要以這些要求為Base，這也是肥蝦會把Quality畫在下方直線的原因。因為品質水準是要花錢的，就是PMBOK中所說的”Cost of Quality”。
品質的規劃與管控學說與理論相對於其它的專案管理知識領域，算是相對的成熟與穩定，PMBOK 2008年的改版相較於2004年版是修正不多，下表為PMBOK 2008對於Quality規劃、保證與控制的ITTO。
| 8.1Plan Quality | The process of identifying quality requirements and/or standards for the project and product, and documenting how the project will demonstrate compliance. | | | |
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| 8.2Perform Quality Assurance | The process of auditing the quality requirements and the results from quality control measurements to ensure appropriate quality standards and operational definitions are used. |
| | |
| | | | ||
| | | | ||
| | | | ||
| 8.3Perform Quality Control | The process of monitoring and recording results of executing the quality activities to access performance and recommend necessary changes. | | | |
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
| | | |
從上表可知，QP重點為產出Metric與Checklist，以為後續QA與QC所遵從的基準。
品質保證與品質控制，對於不熟悉品質管理的人來說，有時還真讓人搞不清楚！根據ISO 9000的定義：品質保證(Quality Assurance)為「All those planned and systematic activities implemented to provide adequate confidence that an entity will fulfill requirements for quality.」；品質控制(Quality Control)為「The operational techniques and activities that are used to fulfill requirements for quality.」我肥蝦是如此加以區別：「品質保證重點為在實作的過程採行正確的方法(do the right thing)，品質控制為檢測結果的正確性(do the thing right)。」針對ISO 9000對於QA與QC的差別，可以整理如下表：
| | 品質保證(Quality Assurance) | 品質控制(Quality Control) |
| 強調重點 | (1)Process (2)Proactive (3)Staff function (4)Prevent defects | (1)Product (2)Reactive (3)Line function (4)Find defects |
| 採用方法 | (1)Quality Audit (2)Defining Process (3)Selection of tools (4)Training | (1)Walkthrough (2)Testing (3)Inspection (4)Checkpoint review |
目前學理一再強調的預防重於治療的觀點下，當然品質保證的重要性優於品質控制，就如那書中強調的：「軟體品質保證人員是推動品質管理的核心角色。」但說句實話，在臺灣現有的軟體開發環境下，能作好品質控制就不容易了，那有多餘的經費與時程去作QA。
記得上週去一家算是國際品牌本土化的銀行核心軟體系統商開會，會中一個資深的系統開發副總說：「客戶都質疑建議書上寫的專案組織架構人手不夠，在臺灣那家公司不是拿到案子，有錢就有人。」像這種逐案而居的心態，如何有效的提升人力平均水平，落實嚴謹的程式開發準則？因此，專案經理或者公司，不得不儘量作好品質控制，品質保證，唉！想想就好。
就算是品質控制，一些理論書籍中也強調要有一定的程序與測試類別，如【圖二】的測試步驟與測試階段。
有那幾家公司會在系統分析與設計之時就作好測試案例？有誰真得去找品質測試人員來作黑箱測試？能叫系統開發人員(系統分析師與程式設計師)作作照劇本演練的單元測試就算不錯了！那來作什白箱、黑箱、灰箱的測試呢？又有誰會真得會逐步進行單元、整合、系統與平行測試？這些都是要錢、要時間的。
測試階段與所謂的確認與驗證要如何對應呢？也許有人會像我一樣在接觸確認(Verification)與驗證(Validation)之時把QA與QC搞得一團模糊！直到公司的順淵兄上了外面的訓練課程－「軟體品質專案管理」，不吝跟肥蝦分享了他在課堂上的收穫，其中就有測試階段與確認與驗證的對應關係，肥蝦整理成下表：
| 項目 | 定義 | 測試階段 |
| 確認(Verification) | 確保軟體的發展過程中，每一階段符合前一階段之結果(Do the things right) | 單元測試、整合測試 |
| 驗證 (Validation) | 確保最終產品功能及特性符合其相關規格及需求所要求之水準(Do the right things) | 系統測試、驗收測試 |
這基夲上是先驗證再驗認，因此所謂的測試階段，都是針對結果，而不是對實作的過程作檢測。因此我把這些測試都歸類於PMBOK 中8.3Perform Quality Control 中的Inspection，僅是因為對於層級、範圍與滿足標的不同，作了不同的區別，單元測試、整合測試針對的滿足標的是系統分析與設計後的規範；系統測試、驗收測試的滿足標的是系統分析與設計的來源－使用者需求。
如此一來，肥蝦便可將軟體工程的確認(Verification)與驗證(Validation)融入PMBOK的QA與QC，以及5.4Verify Scope。就不會像當初肥蝦於參加PMBOK的認證課程中被授課老師混淆了品管與專管，攪得一團亂。QA是過程，產出的delivery要經QC因為軟體的QC要作確認(Verification)與驗證(Validation)所以產生了Validated Deliverables ，確認符合了使用者的需求，再經過5.4Verify Scope中客戶的劃押，就是Accepted Deliverables了。以上當然是肥蝦的見解與看法，因此以下的理解也是依此而發，若認為肥蝦對此認知有誤，當然以下就不需要瀏覽了！也許那一天，肥蝦也會再次發現現有的認知有誤呢！
肥蝦整理了一下手頭上有的一些資料，先前順淵兄分享的「軟體確認與驗證(Software Verification and Validation)」簡報資料，以及經濟部工業局所頒布的九十六年度提升資訊軟體品質計畫，環境建立分項中的「流程改善量化績效度量指標操作型定義」。
其實要將QC分為確認(Verification)與驗證(Validation)，是要作到『早期發現、早期治療』。但說實話要靠這些測試階段作到如此的期望，那就只能設法將軟體專案的開發設定了一些milestones，定義每個milestones所要交付的delivery。這其中最常用的就是依據軟體生命週期來定義milestones ，而最常聽人說及的就是V Model。【圖三】就是V Model的示意圖：
其中左邊為開發階段的活動，右邊為對應的測試階段。開發階段由上到下，測試階段由下到上，因此為了真要作到『早期發現、早期治療』，就需要在開發階段之時作好QA的工作。就像炯佑同學在第八週所舉例的X通公司所承作的國O部的專案，在整合測試或系統測試，才發現一些功能性或非功能性需求達不到客戶明載於合約或徵求建議書的要求時，那可真得來不及了！
對於QC或QA所可依據的Metric或Checklist，經濟部工業局九十六年度所頒布的「流程改善量化績效度量指標操作型定義」可以參考。該文件提出了六個構面22個量測指標，肥蝦整理呈於下表中：
| 構面 | 量測指標 |
| 成本 | 工時預估誤差率(Effort Estimate Error Rate, EEE) 軟體規模單位工時(Software Scale Unit Effort, SSUE) 軟體缺失檢測單位工時(Defect Find Effort, DFdE) 軟體缺失修復單位工時(Defect Fix Effort, DFxE) 需求變動單位工時(Requirement Change Unit Cost, RCUC) |
| 時程 | 時程預估誤差率(Schedule Estimate Error Rate, SEE) 準時結案率(On-Time Delivery Rate, OTDR) 軟體專案規模單位時間(Software Scale Unit Time, SSUT) 里程碑達成率(Milestone Achievement Rate, MAR) |
| 品質 | 缺失密度(Defect Density, DD) 缺失移除率(Defect Removal Rate, DRR) 需求穩定性(Requirement Stability, RS) 軟體交付後之瑕疵率(Software Failure Rate, SFR) 功能完成率(Function Completion Rate, FCR) |
| 客戶滿意度 | 客戶滿意程度(Customer Satisfy Level, CSL) 客訴次數(Count of Customer Complain, CCC) 客戶回流率(Customer Turnover Rate, CTR) |
| 投資報酬率 | 得標率(Successful Bid Rate, SBR) 獲利率(Return On Investment, ROI) |
| 員工 | 離職率(Turnover Rate, TR) 教育訓練支出比率(Education & Training Expense Rate, ETER) 員工生產力(Employee Productivity, EP) |
當然以上的構面或者指標是否足夠，當然是見人見智，但肥蝦是以為政府能有此用心，也算是不錯了。現在當紅的度量指標，當然非EVM(Earned Value Management)莫屬了，這已經在課程的第八週由第五組的同學簡報過了。但以肥蝦認知，種種的指標都是呈現出一種結果，重要的是背後的理論、假設與限制，專案經理與公司千萬不能沉迷於數字，一心喊說數字管理，卻忘了數字的意義與範圍、限制。更更重要的還是公司能否把專案管理融入組織與文化之中！不然指標也可以做假的。
沒有留言:
張貼留言