軟體產業是一項人力與知識密集的產業 (Birk, et. al., 1999)，軟體發展更是 一個知識不斷創新的過程，因此造就軟體知識的多樣化且快速的成長。軟體發展 的過程需經歷多個不同的階段 (phase)、活動 (activity) 與產物 (artifact)，需要眾 人的參與分工合作才得以完成，不同於生產與製造的程序，一旦決定了生產與製 造的流程，生產線的工程人員只要依照規定執行，毋須任何進一步的決策；軟體 發展過程中的許多決策需仰賴眾人的集思廣益，例如：公司得選擇要開發何種產 品、專案管理者得挑選合適的成員並選擇適用的發展程序、方法與應用的技術、
設計師得依需求選擇合適的演算法、程式撰寫人員得決定使用的函數與變數、測 試人員得設計一系列的測試個案…等，因此軟體發展可說是一項設計類的程序 (design type process)。
上述對於選擇的決定與問題的解決，大多仰賴個人所累積的知識與經驗。當 開發的軟體專案越來越龐大且複雜時，團隊成員的溝通與分工合作就顯得格外重 要。每個成員提供自己的知識與經驗也敞開心胸學習他人的知識與經驗，正如同 俗諺所云：三個臭皮匠勝過一個諸葛亮。因此，如何做好知識的管理，加速知識 傳遞與學習的過程，縮短軟體開發的時程，提高軟體的品質，進而降低軟體開發 的成本並加快產品上市的時間…等，便成為軟體產業一項重要的議題。
然而解決上述之問題，交通大學系統模擬實驗室廖元誠先生於 2003 年提出
4
一套軟體開發平台(Software Workbench)[9]，此平台之架構圖如圖 2-1 所示:
支援工具集，軟體發展者撰寫程式碼、編譯與連結的相關開發工具集，
Software W
提出整合開發流程、CASE 工具、軟體知識、再利 管理的整合軟體發展環境架構
結合軟體開發流程、CASE 工具
管理，以及自動化輔助等概念，我們提出軟體發展環境的構想，協助軟
6
體發展者與專案管理者以更效率的方式進行軟體專案開發與人員專長
Software Workbench 在整合工具與軟體
軟體開發的「人員能力」進行了初步之管理，但在 Software Workbench 之部 分只有簡單之人員能力評鑑，因此若在多專長的搜尋上並無法達到效果，且除此 之外，Software Workbench 只提供了一個開發平台，若今天人員之能不足以完成 工作，則平台也無相關之工作或是機制來幫助人員能力的提昇。因此本研究希望 能在軟體開發平台(Software Workbench)之上再建構新增「更完整的能力評鑑機 制」及「專長管理機制」及「人員能力提昇的輔助機制」等以更實質的剛度來幫 助軟體系統的開發。
2
直接或間接地影響所發展軟體的成敗，能力管理的相關研究主要有Bill Curtis, William E. Hefley, Sally Miller等人提出的P-CMM(Capability Maturity Model for Software ) 以及Watts S. Humphrey提出的Personal Software Process – PSP 與Team Software Process – TSP ，及由Philips的Ronald Begeer與Niloy Banerjee所提出的 Leadership Approach。而接下來我們將分別針對此四者來進行討論。
7
2.2.1. P-CMM
美隆大學（Carnegie-Mellon University）的軟體工 程學
著於
1993 1986 年 11 月，美國卡內基
院（Software Engineering Institute, SEI），在 Mitre 公司的協助下開始發展一 個可以幫助軟體開發者改善軟體流程的流程成熟架構（Process Maturity
Framework）。1987 年 6 月，SEI 發表了軟體流程成熟架構的簡要描述，接 當年 9 月出版了基本成熟度之問卷，提供一個工具用以指出軟體業者軟體流程需 要改善的領域。經過了四年的使用經驗與努力，於 1991 年 SEI 正式發表
CMM1.0，並於 1992 年 4 月辦理座談會，綜合超過 400 位軟體專家意見，於 年發表 CMM1.1 修正版，歷史沿革如圖 2-2 所示。SW-CMM 主要是針對軟體生 產流程發展出來，作為全面品質管理與流程改善的架構；換言之，軟體能力成熟 模式（Software Capability Maturity Model, SW-CMM）主要將全面品質管理應用 到軟體開發與維護，用以提昇組織的軟體開發的管理能力以達到成本、時程、功 能與品質等目標。
圖表 2-2P-CMM 演進圖
8
軟體組織為了要持續改善 把所有的改善工作集中在三 個相
立 他們的開發效能，可以
關方面，亦即「人員」、「流程」以及「技術」。過去這些軟體組織藉由 SW-CMM 的幫助，已經在他們的軟體開發流程過程當中，達成各種具成本效益與持續改善 之實務工作。然而，許多的軟體組織卻發現到，在他們實行這些持續改善工作時，
同時也必須要對他們在管理、培養及運用其軟體開發維護人員的方式上，作一些 重要的改變，而這些改變是在軟體能力成熟度模式所沒有完全考慮到的。迄今，
這些軟體組織所做的改善工作仍是著重在「流程」或者是「技術」上而不是在「人 員」身上。1988 年 SEI 首次於學術研討會中提出對評估人員能力成熟度模式
（People Capability Maturity Model, P-CMM）之研究議題，1993 年 7 月正式成 P-CMM 的諮詢委員會，著手起草 P-CMM 模式內容，並於 1995 年 9 月正式公布 P-CMM 1.0 版，並於 2001 年 7 月發佈 P-CMM 2.0。P-CMM 和 SW-CMM 類似，
均是一個循序漸進的改善方向，讓一個軟體組織由混亂、不一致地執行工作，轉 變為成熟、有制度並持續地改善人員知識技能發展的境界。
圖表 2-3P-CMM 分級圖
圖 2-3 所示是 P-CMM 模式之五個成熟度等級與 20 個關鍵程序領域(Key
9
Process Areas, KPAs)。而在此將先針對 P-CMM 各個等級進行介紹:
2. 重覆等級(Repeatable):在此一成熟度等級的組織，其主要的目標就是 建立一套去執行基本勞動力實務的責任及訓練，確保在每一個單位中
組織也會為每個人去規劃其生涯發展策略。
4. 管理等級(Managed):屬於此一成熟度等級的組織，重要的特徵就是能 夠去「量化」得知其勞動力目前的能力，進而去「預測」出未來在開 發力能力與各種績效調整之趨勢；同時也發展出一套機制，藉由具有 擁有高軟體開發能力的團隊，更有效率地去部署其各種能力。
5. 最佳等級(Optimizing):強調持續地個人能力改進是處於此一成熟度等 級組織的主要特徵，提供的顧問輔導訓練更可以進一步幫助發展個人
１．Develop capabilities:此類別之 KPA 主題為改善人員發展程式之能力，
建立完整訓練、學習、溝通及顧問機制，來幫助提昇使用者之能力。
２．Building team & Culture:包括小組之溝通及小組的建立機制等和工作 分配等團隊合作的機制與流程。
３．Motivating and managing performance：此部分之 KPA 主要是進行軟 體人員量化能力的管理及如為達成量化所建立的機制的實施等。
４．Shaping the workforce：此部分則是幫助建立整個工作團隊(workforce) 機制的建立，其包括組織的能力管理，團隊建立的計劃，及人員挑選的 機制等。
在此將 P-CMM 之 KPA 整理成表 2-1:
Process Categories
11
Maturity Levels
Theme 1:
Developing Capabilities
Theme 2:
Building Teams and
Culture
Theme 3:
Motivating and managing performance
Theme 4:
Shaping the workforce
MATURITY LEVEL 5:
Optimizing
Coaching Personal Competency Development
Continuous Workforce Innovation
MATURITY LEVEL 4:
Managed
Mentoring
Team Building Quantitative Performance management Team-Based Practices
Organizational Capability Management
MATURITY LEVEL 3:
Defined
Competency Development Knowledge and Skills Analysis
Participatory Culture
Competency-Based Practices
Career Development
Workforce Planning
MATURITY LEVEL 2:
Repeatable
Training Communication
Communication Coordination
Compensation Performance Management Work Environment
Staffing
每一個 KPA 均有不同之目標（Goal）和達成目標所需之工作（Practice）, 因如表 2-2 示。而在達到了所有的目標之後則完成了此 KPA，而人員在完成了 等級中所有的 KPA 之後將會達到下一個能力成熟度等級。而所有人員之能力 將會被視為整個組織之能力。(如圖 2-4)。
13
表格 2-2 Staffing 之 Goal 與 Practice 定義表
圖表 2-4P-CMM 能力提昇機制
透過 P-CMM 之幫助，企業可以獲得之優點有：(1)描述出人才在軟體開發上 之成熟度 (2)持續的對人員能力提升發展提供明確的指示 (3)設定當前改善活動 的優先順序 (4)整合人才能力提升發展與開發流程之改善 (5)建立優質之軟體工 程文化。
2.2.2. PSP
PSP (Personal Software Process) 是一種可用於控制、管理和改進軟體開發流 程之自我持續改進過程，是一個包括軟體發展表格、指南和規程的結構化框架。
PSP 與 具體的技術(如不同程式設計語言或工具或者設計方法)是相互獨立，PSP
14
的原則能夠應用到幾乎任何的軟體工程任務之中。PSP 為提供了下列原則:(1)幫 助軟體工程師作出更精確的軟體開發計劃。(2)提供軟體工程師爲改善軟體品質 所要採取的步驟。(3)建立度量軟體流程改善的基準。(4)提出流程的改變與軟體 工程師能力的關係。同樣的 PSP 也類似 P-CMM 以 KPA 之方式來進行改善。PSP 之流程主要分為 4 種。
圖表 2-5PSP 分級圖
(1) 基本流程建立 PSP0/PSP0.1:
PSP0 的目的是建立個人軟體流程之基礎，工程師學習使用 PSP 的各種表 格採集專案的有關資料，通常包括計劃、開發以及維護三個階段，並作一些 必要的記錄，如軟體發展時間，缺失類別數和排除缺的失數等，用作爲測量 人員在 PSP 過程的基準。
PSP0.1 增加了程式寫作標準、程式規模度量和流程改善建議等三個 KPA，其中流程改善建議表格用於隨時記錄過程中存在的問題、解決問題的 措施以及改進過程的方法，以幫助軟體發展人員了解軟體品質和流程之重要。
(2) 個人專案管理 PSP1/PSP1.0:
15
PSP1 的重點是專案管理，引用 PROBE（PROxy Based Estimating）之估 進行設計覆查(design review )及程式覆查(code review)，以便及早發現缺失，
以減少缺失造成之損失。
PSP2.1 則論述設計模板(design template)，介紹設計方法，並提供了設計 模板、但 PSP 並不強調選用什麽設計方法，而強調設計準則和驗證技術。
（一）個人專案管理能力：
PSP 制定了一套完整之專案資料記錄格式，其包括，專案設計、實作的 文件、程式行數、時間等記錄。讓使用者能針對自我的表現來進行能力 調整之工作。
（二）軟體品質控制機制：
PSP 針對軟體品質來進行控制，包括程式碼覆查(code review)機制的建 立，和軟體缺失之記錄及統計來量化軟體品質，因此使用者之品質能力 表現有了一定之比較標準。
而為了完成上述兩種概念，因此，PSP 也設計了其專案流程機制及專案資料 回饋機制，見圖 2-6：
圖表 2-6 PSP process flow
雖然圖中之流程為 Waterfall 但 PSP 並不是一個 Waterfall 的流程，PSP 的流 程可以被整合入 TSP 之流程之中，而 PSP 規定其軟體開發所必需之流程，並在 對於每個流程所要進行之工作有詳盡的定義和工作指示，及要完成之資料收集。
雖然圖中之流程為 Waterfall 但 PSP 並不是一個 Waterfall 的流程，PSP 的流 程可以被整合入 TSP 之流程之中，而 PSP 規定其軟體開發所必需之流程，並在 對於每個流程所要進行之工作有詳盡的定義和工作指示，及要完成之資料收集。