在組織中推廣軟體產品線的利器！
本 論 文 在 系 統 實 作 結 束 之 後 ， 將 會 採 用 Jeffrey S. Poulin 所撰寫『 Measuring Software Reuse』一書所提供的量測模型(Poulin，1997)，來量化本論文軟體產品線實作之效益，量測 模型簡述如下。
2.8.1 Reuse Software Instruction (RSI)
由於軟體本身就具有高度複雜性的天性，在計算軟體重用性時，各別組織亦或是個別開 發團隊對於軟體重用性的定義都不同，以至於各家的重用性量測報告都沒有基於同一基準上 作量測而無法比較，所以Poulin 提出了一系列定義，符合定義才被歸納為重用或是不重用軟 體元件，最後被歸納為重用軟體元件之集合，被稱之為RSI。
表 1: 軟體可重用和不可重用元件之定義
Type of reuse Measured?
Maintenance No
Operating System No
High-level language No
Tools No
Multiple uses One time
Commercial off the shelf(COTS) software No
Porting Separately
Application generators Separately
Utility libraries No
Local utility libraries Maybe Project/domain-specific libraries Yes Subclassing, with polymorphism No Subclassing, without polymorphism Yes
Object composition Yes
Parameterized types Yes
Black-box Yes
White-box No
資料來源：[ Poulin，1997]
除了表2.1 所列出之基本定義之外，本論文基於軟體產品線實作之特性，另外再加了三條 定義如下。
１８
1. 組態設定檔
本論文實作在佈署、持久層控制和安全性控制等，有一些組態設定檔，它們雖然不是程 式碼，但仍然或多或少都有被拿來重用，但百分比占整個實作來說是非常些微，故為降 低計算複雜度，本論文不把它們列入LOC(Line of codes)計算。
2. 測試程式
本論文實作採用測試驅動開發，故在商業邏輯方面的程式，幾乎都有相對應的測試程式 碼，所以當產品重用核心資產的軟體元件時，其實同時也省去了開發測試程式碼的資源 ， 故本論文把測試程式碼列為重用軟體元件。
3. 系統架構範本
本論文在核心資產中，有一項是系統架構範本，此範本將會被旗下產品直接複製並修改 ， 是採取白箱重用(White-box reuse)，在表 2.1 中，白箱重用被歸納為不重用軟體元件。
2.8.2 Reuse Metrics Starter Set
Poulin 提供了一個易於使用、了解的量測模型，來讓有興趣的組織來快速使用，稱為 Reuse Metrics Starter Set，包含以下三個部分。
1. 計算重用率(Reuse %)
2. 計算重用節省之成本(Reuse Cost Avoidance)
以上公式包含了一些預設變數，是Poulin 分析各家相關論文和報告歸納出來的數值，組 織可以依自身的實際狀況加以修改，本論文則是採取變數預設值作計算，變數和預設值簡述 如下。
１９
•
RCR(Relative Cost of Reuse)
使用重用軟體元件所花掉的資源是重新開發軟體元件的20%，所以預設值是 0.2。
•
RCWR(Relative Cost of Writing for Reuse)
開發可重用軟體元件所花掉的資源是開發一般軟體元件的1.5 倍。
•
New code cost = $100/LOC
•
Error rate = 1 error/KLOC
•
Error cost = $10K/error
3. 計算投資報酬(Return On Investment)
先計算開發重用軟體元件所花費的額外成本(Additional Development Cost)。
接下來再計算投資報酬如下。
2.8.3 重用率效益分析案例
Poulin 也收集不同公司的重用率效益分析案例，條列如下。
• Nippon Electric Company(NEC)
達到17%之重用率，產生 6.7 倍的生產力和 2.8 倍的品質提昇。
• GTE Corporation
達到14%之重用率，在軟體開發方面，節省一千四百萬元美金。
• Toshiba
達到60%之重用率，每一行程式碼減少 20~30%缺陷發生率。
• Hewlett-Packard(HP)
針對兩個旗下專案作品質改善，使其達到70%之重用率，分別減少 76%和 24%缺陷發生，
增加50%和 40%的生產力，和同樣減少 43%產品進入市場時間。
２０
• Raytheon
使用COBOL 語言達到 60%之重用率，增加 50%的生產力。
２１
第3章 軟體產品線設計與開放原始碼工具之整合
I. Management
標明出管理活動的範圍，涵蓋整個軟體產品線之活動，各項活動運行是否良好端看管理 活動的支援是否充足。
II. Core Asset Development
標明出核心資產開發活動的範圍，涵蓋軟體產品線之(1) ~ (9)活動，通常由核心資產開發 團隊負責維護。
III. Product Development
標明出產品開發活動的範圍，涵蓋軟體產品線之(10) ~ (11)活動，通常由各別產品開發團 隊負責維護。
1. User Requirements
相當於核心資產開發活動的輸入端(2.5.2 節)，輸入類型相當多樣，輸入角色也相當多元，
如客戶、使用者、中高 階主管等 ，負責角色通常是 核心資產開發 團隊 的 SA(System Analyst)，PM(Project Manager)從旁協助，本論文以使用案例(Use Case)作為需求文件的主 軸(Cockburn，2000)；使用 Open Office 為辦公室自動化工具。
2. Domain Model (UML)
基於使用案例使用統一塑模語言(2.4.2 節)為問題領域建造模型，使其產生 Domain-Driven Design(2.3 節)之基礎架構，負責角色仍為核心資產開發團隊的 SA；使用 Jude UML 作為 塑模工具。
3. Domain-Driven Design (UML)
２２