引言

喬治亞技術研究所（GTRI）是喬治亞理工學院的非營利研究單位，GTRI的電子系統實驗室(ELSYS)在2003年6月達到CMMI 能力成熟度第3級。電子系統實驗室約有150位工程師和科學家從事與美國國防部標案相關的工作。電子系統實驗室在下列研究領域中，已在美國國內建立了相當的聲譽：單脈衝對策(monopulse countermeasures)、先進的雷達告警接收器設計(advanced radar warning receiver design)、生存能力(survivability)、模擬模式及分析(simulation models and analysis)，以及電子反制（Electronic Counter Measures -ECM）技術發展。

GTRI / ELSYS的核心競爭力，包括電子戰力與航空電子系統軟體、系統工程、可靠性和可維護性的升級、技術插入、過時方案、威脅分析和關鍵任務的軟體。其中多多數專案成員是十人以下，也有部份專案人數只有一或兩個人。

ELSYS已經由施行 "能力成熟度模式軟體品質保證流程(CMM Software Quality Assurance process)" 轉換到 "能力成熟度整合模式流程及品質保證流程領域(CMMI Process and Product Quality Assurance - PPQA)"。本文將分享轉換至能夠完全符合CMMI系統工程 PPQA的過程中所得到經驗及教訓。本文將討論下列重點：

◎準備一個通用的品質保證計畫和時間表，專案/產品可以很容易地依照其特定的需求進行調適(tailor)。

◎延攬或聘請有足夠經驗的品質工程師，管理單位會尊重他們的建議。這些人可以補充專案團隊的技術和管理經驗，並對團隊所付出的心力有明顯的幫助。

◎由品質工程師擔任專案團隊的導師。

◎分析專案和產品風險，以確定最符合成本效益的PPQA策略。

◎有效運用專案團隊的成熟度來減少 PPQA任務和進行流程改善。在您的能力範圍內表揚和獎勵他們對於流程創新或改善的貢獻。

◎集中PPQA於具有較高風險(例如安全或技術)的專案或產品開發活動。

本文所介紹的方法是對小型組織或小型專案有效的實施PPQA，以有限資源生產一流的產品。

小型組織及小型專案

本文中，"小型組織"是指人數在150人以下，專案成員人數在1至25人的情況。通常這種類型的組織能夠提供給PPQA 的資源是受到嚴重限制的，無法為每一個專案指派專任的品質工程師。

一個小型組織的專案成員可能在開發階段缺乏技術規格文件。撰寫需求的人也可能是測試人員、設計者可能是程式開發者。在非常小的組織中，從頭到尾所有的開發活動可能都是由同一個人完成。

這就產生了一個有趣的兩難情況。更重要的是，是要將最起碼的品質保證活動平均分配的所有的專案呢?還是只對部分專案進行較全面的品質保證活動，對部分專案進行較少一些?當團隊中不同的人寫需求、設計、實做(Implement)和測試的工作產品時，會形成一種"內建"的保護制度。如果撰寫需求的這一組人做了很差的工作，設計者可能會抱怨說需求內容過於模糊，或者測試人員會抱怨說這些需求無法測試。同樣的，如果給程式設計師很差的設計，他們可能向管理單位反應這個環節出了問題。然而，如果從開始到結束都由同一個人做所有的事，他們可能以為順著花徑前行，而沒有意識到可能有災難正在形成。

這些專案正是最需要PPQA的，但他們最負擔不起。這是讓PPQA適用於小型專案的最大挑戰。

大型組織指派多位專職的品質工程師給某些專案，但他們仍然可能有一些專案規模是比較小的，資源有限而專案團隊成員需要一人兼任多重角色。大型組織中的小規模專案如果失敗,受到的影響可能不大；而對一個小型組織而言，則可能會產生嚴重的後果。

流程和產品品質保證

根據軟體工程研究所(Software Engineering Institute -SEI )的陳述, "流程和產品品質保證的目的，在於提供成員與管理階層 客觀洞察 流程與相關工作產品 "The purpose of Process and Product Quality Assurance is to provide staff and management with objective insight into processes and associated work products"

對於小型專案而言，這段話中有一個關鍵詞，那就是:客觀，就事論事-Objective。一般來說，非常小的專案中的每個人對該專案所發生的事情都看得很清楚;現在缺少的是一對客觀的眼睛，能從旁觀者清的立場就事論事。大專案本身就有一些來自其他團隊成員的客觀監督。

不論是大型還是小型專案，都應該就專案的技術及流程狀態，對管理單位進行客觀的報告。

規劃

經過多年的經驗，GTRI已確定，準備組織通用的品質保證（QA）計畫，無論是在成本或功能上都是最有效(effective)的。此外在專案開始的時候，使用通用的時程表，其中包括所有組織的標準流程所必須完成的任務。採用資料庫來追?不同的專案或產品的時程及其相關資料。隨著時間的推移，組織流程資產館中就逐漸累積出不同類型專案型態的時程表。大約百分之七十五的專案可以不用改版直接使用通用的品質保證計畫。通用的品質保證計畫也可依特定情況補充有關調適，風險和風險降低策略等事項。

下表提供了組織通用品質保證計畫的實例。一般來說，品質保證計畫需要與其他用途的計劃一致。其引言部分包括：文件辨識稱謂，範圍，概述，引用的文件和組織結構。此外，它應該有與組織的標準流程一致的任務事項。



品質工程師

兼具良好的管理和技術資歷條件的品質工程師將產生顯著的加值效果。在GTRI，品質工程師須有計算機科學或是工程技術學位， 以及有實際開發及專案管理經驗。除了熟悉該組織所制定的工程流程以外，他也必須了解專案規劃和風險管理。儘管他們的任務是代表組織對專案進行獨立的監督， 他們有能力進行技術和管理工作。

高素質的品質工程師改善了專案團隊的能力，因為他們對專案團隊增加了一對獨立的眼睛。他們出席會議，審查專案文件，並瞭解該小組正在做什麼事情。他們不僅可以幫助發現問題，他們可以提供有價值的建議和諮詢意見，因為專案團隊認同他們具有這樣的資格。品質工程師能夠參與多個專案，提供了另一個有價值的服務 - 他們可以共享技術訊息，這些是僅做"打勾勾 (checking-the-boxes)"的人永遠做不到的。這也有助於避免產品之間需求或資源共享的衝突。通常，品質工程師可以提供解決方案給有類似問題的專案團隊。

指導

單純僅是課堂學習並不足以培養一個人的實作能力。小型組織通常期待員工透過自學及其他專案成員非正式的指導。品質工程師處很適合於判斷誰需要接受指導，以培養符合組織標準及流程的實作能力。

評估品質風險

為了能夠將稀有寶貴的品質保證資源適當地分配給各專案，首先要確定風險最高的部份。有些因素需要加以考慮。

一、人員

一個專案團隊的知識能力和工作習慣， 在決定資源的分配時是有價值的。如果知道團隊成員大致上都能遵守該組織所制定的流程 - 也能夠做到其他相關的重要事項 - 將品質保證資源分配到其他較不符合條件的專案團隊，會是更為有效的安排。簡單來說，在違反組織流程紀錄中尋找可能會違反的人，是比較有意義的。

另一個人員因素是團隊成員的技術經驗水準的。沒有經驗的開發人員通常會比那些老兵更需要仔細檢查。如果品質工程師訓練有素，有能力做如同作者一般的技術工作，他們可以定期對工作成果進行採樣，若發現有問題，可以及時提出警告。在任何情況下，對缺乏經驗的開發人員的工作應進行足夠的和適當的同仁審查;適當的品質保證活動應進行驗證，的確有安排和完成這些審查。

二、開發階段

在理想的情況下，每一個專案或產品的全部專案生命週期過程中都加入既定的流程，以便讓品質保證活動能夠驗證工作產品/產品的產出是正確的。

然而，如果缺乏足夠的資源不斷的進行驗證，對於開發過程中關鍵階段的產出物仍需要進行驗證，例如，要求，設計，開發和測試階段。

毫無疑問的，能夠在一開始就有正確的書面需求文件是比較好的，但如果無法做到，最好能夠在這些需求被用來作為設計基礎之前，而不是事後，發現和糾正問題。同樣的，一個有問題的設計應是在實作程式前就被發現和調整。

如果能夠讓品質工程師參與專案開發活動的品質保證預算有限，最好能夠將品保活動的時間安排在關鍵階段，而不是集中在一個單一的階段。一組堅若磐石的需求是一個良好的開端，但如果整個品質保證預算用於發展專案的需求，而在設計階段誤入歧途，這不是一個好的權衡。

三、失敗成本

有時候，如果一個產品失敗，失敗的代價可能超過開發所花的成本。例如，某些較大的產品系統的關鍵元件的成敗可能決定於小型專案的成敗。

名譽損失或團隊的士氣也是一個重要的考慮因素。但有時一個小產品失敗，不會造成組織嚴重的後果。如果兩個專案產生問題的可能性差不多，但其中之一如果失敗會對組織產生重大影響，那麼對這個專案投入更多的資源是有意義的。

四、熟悉專題的領域

如果產品使用新技術進行開發，將在陌生的環境進行開發，或遇到該組織從來沒有遇到過的問題時，這些情況也較其他沒有挑戰的專案適合增派品質保證資源。

如果它是一個新產品，但是與先前產品的功能和範圍非常類似，它帶來的風險應該比不熟悉的情況低。然而，專案團隊的經驗需要考慮。即使產品本身類似於組織的既有產品，但是如果專案團隊並沒有同類產品的直接經驗，風險可能仍然很高。


五、找到專案風險

品質工程師的工作是確保該專案的風險已被評估和記錄。

此外，在分配資源的時候應考慮品質風險因素。在ELSYS，專案應負責品質保證的資金財源(funding)。如果專案缺乏足夠的資金，那麼企業的資源宜用於保證專案受到足夠的監督。在評估了品質和技術風險之後，應當執行和監督風險減緩計畫。

將流程制度化

在完美的世界就沒有必要進行品質保證活動，人人會有資格做他們的工作，他們會做得很好，每個人都將按照該組織的程序開發產品。這個世界，不幸的是，並非十全十美，也不是完全不完美，每個開發人員都需要一個專職品質工程師坐在他們旁邊觀看他們的一切。現實情況是介於兩者之間。

利用良好的流程開發出優秀的產品的最有效(The most effective)的方法是，創造一個環境，在這個環境中專案團隊希望遵循這些流程，而不是因為他們不得不這樣做。因此，改善開發流程的最有效的方法是從下往上，而不是從上而下。

人們在工作時因為做自己的錯誤而嘗到苦果，他們能夠識別那些本來可以避免的途徑，而採取更好的流程。最積極的人能夠主動依照專案的特質，將組織的標準流程調適成為符合他們真正的需要。

品質工程師是管理階層 "在戰壕裡" 的代表，能夠看出流程改進應該更廣泛地分佈，普遍適用於組織中，且應據以調整既定的流程。


組織需要辨識出哪些"明星球員"利用現有的流程並改善這些流程，以及哪些人雖未必能夠改善流程，但都有切實遵守。這些人應該受到表揚，獎勵，並鼓勵他們繼續這樣做。他們成為其他開發人員的榜樣，鼓勵他們為遵循標準流程的以及進行創新。當專案團隊自願積極主動遵循組織的流程， 制度化即開始形成， 品質保證的需要即隨之降低，減少了對稀有資源的需求。


務實的考量

專案成果的責任落在專案經理和那些高層管理人員的肩膀上。因此，品質工程師，有責任把應關注重視的事項傳達給專案經理，以及如有需要，高階管理人員。

品質工程師擔任該組織的良知，而不是警察。高層管理必須對流程和政策採取具體立場支持品質工程師。高階管理人員必須以尊重品質工程師所提出的意見，流程的調適應在有意義時得到允許。有必要的差異應經過核准。

產品品質應當始終成為指導原則，而不是誰在負責。因此，品質工程師應當指導專案組成員，聽取他們的考量，以確保使用最好的品質流程來產生最優質的產品。確保有一個雙向的溝通管道。

總結

流程和產品品質保證是專案團隊，以及管理階層在專案的開發製作過程中，能夠洞察所使用的流程以及產出的工作產品。小型專案依照其本質，更需要PPQA，但他們往往最負擔不起。

顯然，儘可能有效地使用資源，對小型專案是很重要的，因為他們容許錯誤的幅度也低於較大的專案。

如果正在執行PPQA的人員，在技術上有資格能力做他們進行監測類型的工作，他們可以比那些無法勝任的人更有效地履行其任務。相較於不清楚自己所監督工作的人，他們更可能較早發現產品的問題。

進行 PPQA規劃活動花費的時間, 在小型專案活動比例上是比大型專案多的。所以最好儘可能簡化規劃程序。使用通用的計畫和時間表的模板可以幫助減少PPQA規劃活動所需的時間。

在決定如何分配稀有的PPQA資源給專案時，必須進行風險評估，以決定哪些專案需要更多的資源。專案團隊成員的技術經驗水準，他們對流程遵守情況的紀錄，以及他們對正在開發的特定類型產品的熟悉度等都必須列入考慮。還必須考慮每個專案如果失敗對組織產生的潛在成本，再確定應分配給專案的 PPQA資源。

如果在組織中大多數開發人員在一段時間內只從事一個專案。為多個小型專案執行 PPQA的人員就處於一個特殊地位，可以加強溝通聯繫。

他們可以幫助專案小組之間迅速傳遞重要技術的信息，還可以幫助確定一個專案的專家團隊的專業知識可能也對另外一個團隊非常有價值。

即使採行小量的PPQA活動，PPQA的存在仍提醒專案團隊，他們需依流程來開發自己的產品，這些工作產品必須符合一些既定標準。他們成為開發團隊心中遵守有關程序的"小聲音"。

參考資料

MAKING PROCESS AND PRODUCT QUALITY ASSURANCE (PPQA)
WORK ON SMALL PROJECTS; 5TH ANNUAL CMMI TECHNOLOGY CONFERENCE AND USER GROUP; NOVEMB E R 1 5 ， 2 0 0 5; by Jean Swank， Jeanne Balsam， Lee Sheiner， and Mark Pelle grini

SEI. CMMI For Development Version 1.2，2007