軟體產品線
出自 MBA智库百科(https://wiki.mbalib.com/)
軟體產品線（Software Product Line）
目錄 |
軟體產品線是指具有一組可管理的公共特性的軟體密集性系統的合集，這些系統滿足特定的市場需求或任務需求，並且按預定義的方式從一個公共的核心資產集開發得到。
因為軟體產品線的系統，需要按照指定方式進行公共資產集的開發，與獨立開發、從零開始開發、隨機開發等方式相比較，可以獲得顯著的生產經濟效益。正是由此產生的經濟效益，才使軟體產品線更具吸引力。
首先每個產品都由來自公共資產庫中的組件組成，然後按照預先定義的變化機制，如參數化或繼承，對這些組件進行必要的裁剪，添加任何必須的新組件，根據一個產品線範圍內的公共架構來組裝這些組件。於是，構建一個產品（系統）主要工作是組裝和繁衍，而不是創造；主要的活動是集成而不是編程。每條軟體產品線都有一個預先定義的指南或計劃，用來定義確切的產品構建方法。
軟體產品線依賴於基於組件開發的形式，涉及到的要素很多。基於組件開發的典型定義是指從內部庫或是市場選擇組件來構建產品。儘管軟體產品線中的產品確實是由組件組成的，但這些組件都是由產品線架構指定的，且按預定義的方式組裝，如在組件中採用內置變體機制，以便將其用於指定的產品。該定義來自於架構和生產計劃，而不是標準的基於組件的開發。在產品線中，組件通常是在資產庫中進行演進和維護的。而在基於組件的開發中，若有任何變化，一般都是通過編寫代碼來完成，其變化部分通常都是分別維護的。單獨的基於組件的開發常常缺乏技術和組織管理方面的支持，而這點對軟體產品的成功非常重要。
軟體產品線工程能夠在開發成本和產品上市時間方面極大地改善軟體開發過程。在軟體復用方面達到了空前未有的高水平。產品線工程基於四個主要概念：可變性管理是產品線工程最核心的概念。產品線工程最核心的思想就是可變性管理，正是基於可變性模型來確定需求、建模並實現產品線工程中的公共與變化量；產品線與一般性產品最大的差別就是它把戰略視角從單個合同轉到整個業務領域的長期策略上來，要使產品線工程與商務策略達成一致；參考架構在產品線工程中有著關鍵的作用。人們已經意識到，復用若想取得真正的成功就必須對不同的產品採用一種公共的架構；產品線工程劃分成領域工程與應用工程二部分，這就把為復用的開發與復用著的開發分離開來。
1）可變性管理（Variability management）。軟體產品線工程致力於支持一系列的產品。這些產品會支持不同的、個性化的用戶或者側重點完全不同的市場劃分。可變性是軟體產品線工程中最關鍵的概念。軟體產品線工程並不是去理解每個單個系統而是關註整體及在這些單個系統中的變化。在整個軟體產品線工程中要定義、表示、探索、實現、演進可變性，也就是管理可變性。
2）商業中心（Business-centric）。傳統的軟體開發關註的是單個系統，而產品線工程總是強調的是整個市場。只有當產品線基礎能夠長期提供充分的手段支持新產品有效地投放到市場，產品線工程才能夠獲得功。因而，要以經濟的觀點考慮單個產品與產品線的關係，對單個產品的決策要與更大的產品線聯繫在一起。這種強大的聯繫表明，最重要的是要理解產品線啟動的業務目標。通常業務目標是降低人力/成本，加快上市速度；或者與質量相關，如提高可靠性或者改善可用性。這些特定目標給我們提供了產品線工作決策的基礎，以確定需求是否要實現、是作為整個產品線的需求或作為特定產品的來實現。這些目標同時幫助我們明確投入的平衡點在那裡。
3）架構中心（Architecture-centric）。從技術上來講，軟體開發必須利用單個系統間的相似性。軟體產品線工程是以公共的產品線架構（或者稱參考實現）為基礎的，因而經常稱之為以架構為中心。與其它重用方法相比，公共架構的中心角色是產品線工程成功的主要因素。為給不同組件提供一個一致的描述，以通用的介面開發、裝配並應用於不同的產品，就要在領域工程中設計參考架構。通用的架構對所有在不同的產品中使用的組件定義了單一的環境，這就保證了對相類似的功能不需要開發多個組件只需要考慮它們的工作環境。
4）兩個生命周期（Two-life-cycle approach）。軟體產品線工程是由領域工程和應用工程構成。這二種工程，在理想的情況下，只是基於平臺松耦合和同步。因而，形成了完全不同的生命周期模型。領域工程與應用工程的區別是產品線工程的一個關鍵特性。
- 誤區一：偶然的小粒度重用
重用，作為降低開發成本，提高質量的軟體策略已經不是新方法，軟體產品線肯定涉及到重用，事實上是最高級別的重用。以前的重用主要是指相對較小的代碼塊的重用，也就是小粒度重用。有些機構已經建成了包含演算法、模式、對象和組件的可重用庫。軟體開發人員寫的任何東西幾乎都要放到庫里，然後鼓勵（有時是要求）其他開發人員使用庫里所提供的東西而不是創建自己的版本。不幸的是在很多情況下，查找這些小模塊以及將其集成到一個系統中所花費的時間比重新開發他們更長。文檔，倘若有的話，可以說明模塊創建的情況，卻不能說明如何對模塊進行集成或進行適應性的修改。小粒度的重用的成功依賴於軟體工程師是否喜歡使用庫里的內容、庫中的內容對工程師需要的適應性，以及能夠成功將庫中內容進行改寫並集成到系統的其他部分。如果這些條件都滿足，則採取重用，但它具有偶然性，並非總能發生。
在軟體產品線方法中，重用是有計劃的、能夠實現的和強制的（機會主義的對立面）。資產庫包括從一開始就花費大量成本進行開發的各類產品——即需求、領域建模、軟體架構、性能模型、測試用例和組件。所有資產都為重用而設計，並且為了能重用與多個系統進行了優化。軟體產品線的重用是全面的、有計劃的、有經濟效益的。
- 誤區二：利用重用的單系統開發
這種方法和軟體產品線方法有兩點主要區別。首先，軟體產品線重用的資產是明確為重用而設計的。其次，產品線被視為一個整體，而不是可以區別對待和維護的多個產品。在成熟的產品線組織中，多個產品的概念已經消失。每個產品是核心資產的一個簡單定製，只有核心資產才被認真的設計並隨時間演進，只有核心資產才是組織的傑出智力財產。
- 誤區三：僅僅基於組件的開發
軟體產品線依賴於基於組件開發的形式，涉及到的要素很多。基於組件開發的典型定義是指從內部庫或是市場選擇組件來構建產品。儘管軟體產品線中的產品確實是由組件組成的，但這些組件都是由產品線架構指定的，且按預定義的方式組裝，如在組件中採用內置變體機制，以便將其用於指定的產品。該定義來自於架構和生產計劃，而不是標準的基於組件的開發。在產品線中，組件通常是在資產庫中進行演進和維護的。而在基於組件的開發中，若有任何變化，一般都是通過編寫代碼來完成，其變化部分通常都是分別維護的。單獨的基於組件的開發常常缺乏技術和組織管理方面的支持，而這點對軟體產品的成功非常重要。
- 誤區四：僅有一個可配置的架構
設計參考架構和麵向對象框架是為了能重用於多個系統，並且必須可以重新配置。重用架構的各種結構是個很好的方法，因為架構對任何系統而言都至關重要，而且構建代價較高。產品線架構的設計必須支持產品線中個產品間的不同（變化），因此它必須是可配置的。但是，即便產品線架構很重要，也只是產品線資產庫中的一項資產。
- 誤區五：單個產品的發佈和版本
組織要定期發佈新產品和退出產品的新版本，每個新版本的發佈一般都是通過使用以前版本的架構、組件、測試計劃和其他要素來構建。為什麼軟體產品線有所不同呢？首先，在產品線中同時存在多個產品，每個產品都有其自己的發佈和版本周期。因此，必須在更廣的上下文環境中考慮單個產品的演進——也就是說，產品線是作為一個整體來演進的。其次，在單個產品的上下文環境中，產品一旦被更新，通常不可逆——即認為早期產品生產中的任何東西都不再有價值。但是在產品線中，產品的早期版本仍被認為具有市場潛力，並很容易地作為產品家族中的一個可生存成員保留下來：畢竟它如同其他產品的其他版本一樣，是核心資產的一個實例。
- 誤區六：僅有一套技術標準
許多組織建立一套標準來限制軟體工程師選擇集成到系統中的組件的種類和來源。他們審查架構和評審設計以確保遵循了這些標準。例如，開發人員能夠從兩種確定的資料庫和兩種確定的網頁瀏覽器中進行選擇，但是必須使用一種指定的中間件或電子數據表產品（需要時）。技術標準可提高協同能力，降低商業組件的維護和支持費用。一個正在推行產品線的組織可能也擁有這樣的技術標準，產品線架構和組件都需要遵循這些標準，但是這些標準僅僅是輸入到軟體產品線中的約束條件。
