增量開發

增量，是強調軟體在發布不同的版本時，每次都多發布一點點，是軟體功能數量漸增地發布的過程。

基本介紹

• 中文名：增量開發
• 外文名：Incremental development
• 定義：一種常用的軟體開發過程思想
• 時間：20世紀70年代早期
• 提出者：Mills

定義

增量開發，又叫增量式開發，是軟體工程當中，一種常用的軟體開發過程思想。其中增量是指在軟體開發過程中，先開發主要功能模組，再開發次要功能模組，逐步完善，最終開發出符合需求的軟體產品。比如，需要開發一個類似WORD的軟體，應該首先開發出檔案管理（保存、讀取檔案）、基本編輯功能、列印等，而其它不太常用的功能可以最後開發。增量式開發，就是首先把大型程式分解成若干小的模組，然後對每個模組按照某種過程模型進行開發，最後把這些模組逐步集成為完整的軟體產品。

採取增量式開發，會傾向於創建更小的方法和更具內聚性的類。你不是等埋頭盲目地一次性編寫一大堆代碼。相反，你會經常評估代碼質量，並不時地進行許多小調整。而不是一次修改許多東西。

來源

增量式開發是20世紀70年代早期由Mills提出的。但直到80年代末，當Mills和他的助手們的淨室論文和專項報告開始出現的時候才獲得認同。Fred Brooks描述了增量式開發方法的深刻影響，針對該方法在軟體實踐方面的作用，給出了影響廣泛的評論：“沒有銀彈：軟體工程的本質和偶然性。”

Brooks的觀察在工業實踐中得到了證實。增量式開發有助於早期的和連續的質量評估、用戶反饋和方便的開發進度的過程改進。增量式設計方法避免了在開發周期中部件集成之後風險的繼承。而且增量式開發允許在整修開發周期過程中需求變化的系統協調。

增量式開發的技術基礎是引用透明性特徵。在軟體開發的前後，這種特徵要求規範及其實現定義了同樣的數學函式。當擁有了這種特徵時，設計就能顯示出與它的規範的一致性。

大的軟體系統由各個部分組成。系統各個部分組成的方式對項目的成功有重要的影響。增量式自頂向下的開發途徑表現為軟體系統的已開發和已測試部分作為功能累積子集的序列。在最早增量中開發了一個小系統，然後把功能添加到每一個後續增量中直到系統完成。這種軟體系統的控制增長方式有利於客房、管理者，同樣有利於技術人員。

優點

進展的可見性

利用增量式開發，每一步增量實現了一個或多個最終用戶功能。每一步增量包含所有早期的已開發的功能集加上一些新的功能；系統在逐步累積的增量中增長。例如，在早期增量結束時，開發者很有信心地說：系統的20%已100%完成了，而不是推測系統已完成了20%。

智慧型控制

增量式開發通過引用透明性，實現了整個系統開發過程中的智慧型控制。當在後續增量待實現的函式的子規範被嵌入當前增量流程邏輯中時，這種特性，即等式的等量替換令人滿意。當擁有引用透明性時，一個系統的部件無需回溯就能根據其子規範得以實現。無需重做前期增量。這裡策略有利於在一個完整系統中對每個增量進行正確性驗證。

增量系統集成

淨室增量式開發允許在整修開發生命期引用透明的用戶函式增量的連續集成。因為每一步增量設計基於一個已驗證的子規範和前期增量已測試的接口，因此幾乎沒有更深的設計和接口錯誤。較好的定義增量貫穿於整修系統開發過程，系統在良好定義的增量中深化。測試和驗證工作始於開發周期早期。

連續質量反饋貫穿統計過程控制

已在淨室中實踐的增量式開發為統計過程控制提供了基礎。每一個淨室增量都是過程的一個完整周期，包含規範、開發和新的用戶函式的驗證，加上到目前為止所有已工作的測試。作為統計過程控制的典型，把過程的每一次反覆的性能度量與性能目標相比較，以決定是否過程一直在控制之下(即：是否正如所期望的那樣發生)。

淨室軟體小組常使用在測試中的開發性能度量作為過程控制的標準。通常使用的度量包括每千行代碼的錯誤數、失效的間隔時間(MTTF)、可靠性及可信性。其他過程控制方法或許依賴於所管理的事務，而不是產品的質量。進度一致性一、預算一致性瑟整體計畫的一致性等等，都是按增量的實際性能與目標性能相比較而言。淨室增量度量依據的標準描述了過程控制的具體級別，要按計畫繼續該項目，開發小組要求此級別。如果標準不符合，開發小組能從增量中檢測執行數據，確定問題所在，必要時調整項目計畫，修改軟體開發過程，避免此類問題的再次發生。例如，如果增量的測試提示過程失去控制(如：質量標準不符合)，開發者們應停止測試，返回設計階段，如果過程是在控制之下，下一歨增量工作才能繼續。

統計過程控制(Statistical Process Control ,SPC)是為數據悼念和分析提供較好的開發技術的成熟的工程實踐。豐富的方法和工具支持是希望從事更高實踐的設計者可利用的。然而，SPC的基本實踐要求少量的投資和努力就能產生充足的回報。統計過程控制套用的基本任務很簡單：每一過程周期的性能度量，比較實際性能與預先定義的目標性能，確定不可接受偏差的原因，以及通過過程改變改進將來的性能。

例如，如果一個淨室小組開發的一個產品在測試中習慣於每千行代碼有三個或更少失效，那么一個增量每千行有5個失效或許認為是不可接收的偏差。在調查中，小組或許發現失效是由錯誤引起的，實際上在驗證過程中錯誤才能被發現，不能證實代碼改變的正確性。從這種分析中，小組認識到直到所有錯誤代碼的改變被驗證為正確之前這種驗證不視為完整的。小組相應地修改驗證過程，決心在將來的增量設計中避免因不正確的補丁而引起的失效。以這種方式，每步增量中產生的反饋用於改進下一歨增量過程。

統計過程控制的能力取決於針對正在進行的計畫性能與實際性能的對比檢驗。確定造成不可接受的偏差的原因，制定專門過程改進措施，以重新獲得控制或改善控制。淨室軟體小組實踐這些基本原理，並加以發展。每個淨室增量都是針對完善的期望來測試，任何失效都被認為是不可接受的。仔細分析由錯誤發生的失效與開發過程的關係，錯誤的來源是什麼？為什麼在小組評審中錯誤被忽視？如何改進過程避免相同錯誤站起來重犯？淨室軟體小組真誠地追求完美，統計過程控制是衡量和提高小組成果的工程規範。

用戶使用中不斷的功能反饋

增量式開發有助於用戶對一個進貨系統的執行功能做出儘早的不斷的反饋，必要時允許改變。因為增量執行於系統環境並代表了用戶功能的子集，早期的增量能通過用戶對系統功能性和實用性的檢測來反饋。這種反饋有助於避免開發出失效的系統和建立用戶可接受的最終產品。

變更的適應性

在系統需求和項目環境中增量式開發允許不可避免變更的系統適應性。在每一步增量完成時，系統需求的積累變更所產生的影響能根據當前規範和增量設計來評估。如果變更與將來增量想到獨立，則通常與現已存在的增量開發計畫相合併，並對進度和資源進行可能的調整。如果變更影響已完成的增量，自頂向下修改系統開發，通常重用絕大多數已存在的增量代碼(通常是全部)，按照要求的進度和資源來進行相應調整。

進度與資源管理

項目資源在增量式開發全過程中能在可控制的方式下分配。可用進度是決定待開發的增量數據和其規模的一個因素。在短進度中，小規模增量將有助於在增量交付與認證組之間維持充分的時間段，允許一個有序的測試過程。然而，這將給項目開發小組設計和實現更大、更複雜的增量帶來更多負擔。進度和複雜性的折衷能夠反映增量式開發計畫。另外，從後續增量得到的反饋，為過程和產品性能的目標度量提供了管理，以允許在開發和測試中對不足和意外收穫的適應。