spl

軟體產品線是指具有一組可管理的公共特性的軟體密集性系統的合集，這些系統滿足特定的市場需求或任務需求，並且按預定義的方式從一個公共的核心資產集開發得到。

這個定義和任何產品線的傳統定義相一致——滿足特定市場或任務需求的、具有一組公共的、可管理特性的系統集合。但是它增加了一些內容，即在軟體產品線中增加了系統開發方式上的一些限制。為什麼？因為軟體產品線的系統，需要按照指定方式進行公共資產集的開發，與獨立開發、從零開始開發、隨機開發等方式相比較，可以獲得顯著的生產經濟效益。正是由此產生的經濟效益，才使軟體產品線更具吸引力。

軟體產品線針對特定領域中的一系列具有公共特性的軟體系統，試圖通過對領域（commonality）共性和可變性（var iability）的把握構造一系列領域核心資產，從而使特定的軟體產品可以在這些核心資產基礎上按照預定義的方式快速、高效地構造出來。

軟體產品線工程主要包括領域工程、應用系統工程和產品線管理三個方面。其中，領域工程是其中的核心部分，它是領域核心資產（包括領域模型、領域體系結構、領域構件等）的生產階段；應用系統工程面向特定應用需求，在領域核心資產的基礎上面向特定應用需求實現應用系統的定製和開發；而產品線管理則從技術和組織兩個方面為軟體產品線的建立和長期發展提供管理支持。

如何提高生產的經濟效益呢？首先每個產品都由來自公共資產庫中的組件組成，然後按照預先定義的變化機制，如參數化或繼承，對這些組件進行必要的裁剪，添加任何必須的新組件，根據一個產品線範圍內的公共架構來組裝這些組件。於是，構建一個產品（系統）主要工作是組裝和繁衍，而不是創造；主要的活動是集成而不是編程。每條軟體產品線都有一個預先定義的指南或計劃，用來定義確切的產品構建方法。

有很多種方法初看起來和軟體產品線似乎很類似。因此，您可能要問：“軟體產品線不就是X的一個新名稱嗎？”儘管我們很想讓您能在以前的知識和經驗基礎之上有新的發展，但是我們更想從一開始就不要令你錯誤地把軟體產品線等同於一些它們所不是的東西。描述“它不是什麼”往往和描述“它們是什麼”一樣有意義。在談及軟體產品線時，我們不是指上下文中所提及的任何一種情況。

誤區一：偶然的小粒度重用

重用，作為降低開發成本，提高質量的軟體策略已經不是新方法，軟體產品線肯定涉及到重用，事實上是最高級別的重用。那麼區別何在呢？以前的重用主要是指相對較小的代碼塊的重用，也就是小粒度重用。有些機構已經建成了包含演演算法、模式、對象和組件的可重用庫。軟體開發人員寫的任何東西幾乎都要放到庫里，然後鼓勵（有時是要求）其他開發人員使用庫里所提供的東西而不是創建自己的版本。不幸的是在很多情況下，查找這些小模塊以及將其集成到一個系統中所花費的時間比重新開發他們更長。文檔，倘若有的話，可以說明模塊創建的情況，卻不能說明如何對模塊進行集成或進行適應性的修改。小粒度的重用的成功依賴於軟體工程師是否喜歡使用庫里的內容、庫中的內容對工程師需要的適應性，以及能夠成功將庫中內容進行改寫並集成到系統的其他部分。如果這些條件都滿足，則採取重用，但它具有偶然性，並非總能發生。

在軟體產品線方法中，重用是有計劃的、能夠實現的和強制的（機會主義的對立面）。資產庫包括從一開始就花費大量成本進行開發的各類產品——即需求、領域建模、軟體架構、性能模型、測試用例和組件。所有資產都為重用而設計，並且為了能重用與多個系統進行了優化。軟體產品線的重用是全面的、有計劃的、有經濟效益的。

誤區二：利用重用的單系統開發

您正在開發一個新的系統，它與您以前做過的系統很相似。您可以藉助於以前的工作，做一些必要的修改、增加一些內容，形成新的產品。那麼您所做的就是所謂的“克隆並擁有”。毫無疑問，您充分利用了以前的工作並取得經濟效益；您已經重用了另一個系統的一部分，但是現在您有兩個完全不同的系統，而不是從同一庫中構建起兩個系統。您需要像維護兩個完全分離的實體那樣維護這兩個系統，這又是一個特別的重用。

這種方法和軟體產品線方法有兩點主要區別。首先，軟體產品線重用的資產是明確為重用而設計的。其次，產品線被視為一個整體，而不是可以區別對待和維護的多個產品。在成熟的產品線組織中，多個產品的概念已經消失。每個產品是核心資產的一個簡單定製，只有核心資產才被認真的設計並隨時間演進，只有核心資產才是組織的傑出智力財產。

誤區三：僅僅基於組件的開發

軟體產品線依賴於基於組件開發的形式，涉及到的要素很多。基於組件開發的典型定義是指從內部庫或是市場選擇組件來構建產品。儘管軟體產品線中的產品確實是由組件組成的，但這些組件都是由產品線架構指定的，且按預定義的方式組裝，如在組件中採用內置變體機制，以便將其用於指定的產品。該定義來自於架構和生產計劃，而不是標準的基於組件的開發。在產品線中，組件通常是在資產庫中進行演進和維護的。而在基於組件的開發中，若有任何變化，一般都是通過編寫代碼來完成，其變化部分通常都是分別維護的。單獨的基於組件的開發常常缺乏技術和組織管理方面的支持，而這點對軟體產品的成功非常重要。

誤區四：僅有一個可配置的架構

設計參考架構和面向對象框架是為了能重用於多個系統，並且必須可以重新配置。重用架構的各種結構是個很好的方法，因為架構對任何系統而言都至關重要，而且構建代價較高。產品線架構的設計必須支持產品線中個產品間的不同（變化），因此它必須是可配置的。但是，即便產品線架構很重要，也只是產品線資產庫中的一項資產。

誤區五：單個產品的發布和版本

組織要定期發布新產品和退出產品的新版本，每個新版本的發布一般都是通過使用以前版本的架構、組件、測試計劃和其他要素來構建。為什麼軟體產品線有所不同呢？首先，在產品線中同時存在多個產品，每個產品都有其自己的發布和版本周期。因此，必須在更廣的上下文環境中考慮單個產品的演進——也就是說，產品線是作為一個整體來演進的。其次，在單個產品的上下文環境中，產品一旦被更新，通常不可逆——即認為早期產品生產中的任何東西都不再有價值。但是在產品線中，產品的早期版本仍被認為具有市場潛力，並很容易地作為產品家族中的一個可生存成員保留下來：畢竟它如同其他產品的其他版本一樣，是核心資產的一個實例。

誤區六：僅有一套技術標準

許多組織建立一套標準來限制軟體工程師選擇集成到系統中的組件的種類和來源。他們審查架構和評審設計以確保遵循了這些標準。例如，開發人員能夠從兩種確定的資料庫和兩種確定的網頁瀏覽器中進行選擇，但是必須使用一種指定的中間件或電子數據表產品（需要時）。技術標準可提高協同能力，降低商業組件的維護和支持費用。一個正在推行產品線的組織可能也擁有這樣的技術標準，產品線架構和組件都需要遵循這些標準，但是這些標準僅僅是輸入到軟體產品線中的約束條件。

業界軟體產品線開發模式的平台產品

目前，業界從事軟體產品線研究並應用於軟體生產領域的公司主要有東軟集團，東軟自主研發的UniEAP業務基礎平台產品，就是一款面向軟體產品線開發模式的業務基礎平台，它充分體現了面向軟體產品線的開發模式，由開發框架、公共構件和方法學組成的，通過多層次、結構化的基礎架構、組件及相關開發工具，用於支撐應用軟體快速構造、支撐業務開發的全面解決方案。該解決方案的目標是使應用軟體的設計與開發人員能夠通過構件復用和構件裝配等手段，快速完成應用軟體的構造。當用戶的需求發生變化時，可以將對開發的影響降至最低，最終達到業務專家通過簡單的配置就可滿足用戶需求的目的。

UniEAP業務基礎平台的面向軟體產品線的內容，主要體現在其核心框架產品 UniEAP Platform ，它是東軟針對各行業事業部及軟體產品研發部門提出的基於軟體產品線的解決方案開發平台。軟體產品線的開發方法指導軟體開發者採用資產復用而非重複開發的方式來進行軟體生產。遵循軟體產品線兩階段的開發原則，將開發過程劃分為：“領域工程”與“應用工程”兩個階段。領域工程建立了公共產品線基礎，主要是用來發現產品中主要的共性與變化點，實現了產品的組合策劃。應用工程是在平台基礎之上開發單個的系統。由於開發中的大部分人力成本和技術複雜因素都轉移到領域工程中，因而提高了軟體的開發效率。

在領域工程階段，領域開發人員以產品線架構為指導，開發或復用軟體產品線核心資產；在應用工程階段，應用開發人員通過復用核心資產、業務配置和定製開發構建本領域產品。此外還支持以產品線方法構建應用的業務基礎平台，其目標主要致力於幫助行業事業部及軟體產品研發部門有效地進行業務資產的積累及復用，進而提高軟體項目的生產效率，降低軟體項目的開發成本，提升面向特定業務領域的核心競爭力。

實施軟體產品線工程的基本原則

軟體產品線工程能夠在開發成本和產品上市時間方面極大地改善軟體開發過程。在軟體復用方面達到了空前未有的高水平。產品線工程基於四個主要概念：可變性管理是產品線工程最核心的概念。產品線工程最核心的思想就是可變性管理，正是基於可變性模型來確定需求、建模並實現產品線工程中的公共與變化量；產品線與一般性產品最大的差別就是它把戰略視角從單個合同轉到整個業務領域的長期策略上來，要使產品線工程與商務策略達成一致；參考架構在產品線工程中有著關鍵的作用。人們已經意識到，復用若想取得真正的成功就必須對不同的產品採用一種公共的架構；產品線工程劃分成領域工程與應用工程二部分，這就把為復用的開發與復用著的開發分離開來。

1）可變性管理（Variability management）。軟體產品線工程致力於支持一系列的產品。這些產品會支持不同的、個性化的用戶或者側重點完全不同的市場劃分。可變性是軟體產品線工程中最關鍵的概念。軟體產品線工程並不是去理解每個單個系統而是關注整體及在這些單個系統中的變化。在整個軟體產品線工程中要定義、表示、探索、實現、演進可變性，也就是管理可變性。

2）商業中心（Business-centric）。傳統的軟體開發關注的是單個系統，而產品線工程總是強調的是整個市場。只有當產品線基礎能夠長期提供充分的手段支持新產品有效地投放到市場，產品線工程才能夠獲得功。因而，要以經濟的觀點考慮單個產品與產品線的關係，對單個產品的決策要與更大的產品線聯繫在一起。這種強大的聯繫表明，最重要的是要理解產品線啟動的業務目標。通常業務目標是降低人力/成本，加快上市速度；或者與質量相關，如提高可靠性或者改善可用性。這些特定目標給我們提供了產品線工作決策的基礎，以確定需求是否要實現、是作為整個產品線的需求或作為特定產品的來實現。這些目標同時幫助我們明確投入的平衡點在那裡。

3）架構中心（Architecture-centric）。從技術上來講，軟體開發必須利用單個系統間的相似性。軟體產品線工程是以公共的產品線架構（或者稱參考實現）為基礎的，因而經常稱之為以架構為中心。與其它重用方法相比，公共架構的中心角色是產品線工程成功的主要因素。為給不同組件提供一個一致的描述，以通用的介面開發、裝配並應用於不同的產品，就要在領域工程中設計參考架構。通用的架構對所有在不同的產品中使用的組件定義了單一的環境，這就保證了對相類似的功能不需要開發多個組件只需要考慮它們的工作環境。

4）兩個生命周期（Two-life-cycle approach）。軟體產品線工程是由領域工程和應用工程構成。這二種工程，在理想的情況下，只是基於平台松耦合和同步。因而，形成了完全不同的生命周期模型。領域工程與應用工程的區別是產品線工程的一個關鍵特性。