反覆包含形成一個產品發行版本的開發活動(穩定、可運作的產品版本)及使用此發行版本的其他任何必要的外圍元素。 因此,在某種意義上,開發反覆就是一次歷經所有規範的完整過程:至少經過需求、分析與設計、實作及測試。
本質上就像一個小型的瀑布式專案一樣。必須注意評估準則是在規劃每一個反覆時建立。 發行版本具有可展示的規劃能力。反覆的持續時間視專案的規模和本質而定, 不過,根據反覆的整合建置計劃的規定,每一個反覆有可能建構多個建構版本。 這是遵循 Rational Unified Process (RUP)
建議的持續整合方法的結果:形成單元測試元件之後就進入整合,然後產生建構版本並提交整合測試。 如此,整合軟體的功能會隨著反覆的進行而茁壯,最後達到規劃反覆時所設定的目標。
有人可能認為每一個建構版本可以視為一個迷你的反覆過程,只是所需的規劃和評量的嚴謹性有所不同。 有些專案可能較適合且方便每天固定建立建構版本,但除非是在非常小型的單人專案中,否則這些並不能代表 RUP 所定義的反覆。
即使在小型的多人專案中(例如,有五人建構 10,000 行程式碼),也很難在一週之內完成一個反覆期間。 如需相關解釋,請參閱 準則:軟體開發計劃。
傳統上,專案都安排成依序經過每一個規範,且只經過一次。形成瀑布式生命週期:
在稍後的實作階段,當第一次建置產品和開始測試時,這通常會形成整合「堆積」。 在分析、設計及實作各處隱藏的問題終於浮現,專案慢慢陷於停頓,開始漫長的錯誤修正過程。
變通的(風險較低)做法是多次歷經不同的開發規範、更深入了解需求、打造堅固的架構、逐漸提升開發組織的品質,最後實現一系列更完整的實作成果。 這稱為反覆式生命週期。流程規範每歷經一次稱為一個反覆。
因此,就開發觀點而言,軟體生命週期是一連串的反覆,軟體在其中漸進地開發。 每一個反覆最後會產生可執行產品的發行版本。這個產品可能只是完整願景的一部分,但在某些工程或使用者層面上很有用。
每一個發行版本會伴隨著支援工作成果:版本說明、使用者文件、計劃等,以及更新版的系統模型。
如稍早所述,此反覆式方法的主要結論是隨著時間經過,工作成果會不斷地茁壯和趨於成熟,如下圖所示。
資訊集經歷各開發階段的演進。
次要里程碑
每一個反覆結束時即完成一個次要里程碑,反覆的結果根據此特定反覆的客觀成功準則來評定。
|