成功的軟體開發過程
迭代,進化和敏捷
介紹
相對於順序或“瀑布”生命週期,迭代和進化式開發(iterative and evolutionary development)對部分系統及早地引入了編程和測試,並重複這一迴圈。這種方式通常會在還沒有詳細定義所有需求的情況下假設開發開始,同時使用反饋來明確和改進演化中的規格說明。
反覆式開發法是UP和大多數其他現代方法中的關鍵實踐。在這種生命週期方法中,開發被組織成一系列固定的短期(如三個星期)小項目,稱為迭代(iteration);每次迭代都產生經過測試、整合並可執行檔局部系統。每次迭代都具有各自的需求分析、設計、實現和測試活動。
樣本
1. 在第一次迭代之前,召開明確為2天的需求工作會議,該會議的出席人員包括業務人員和開發人員(包括首席架構師)。
l 在第一天上午,只進行high-level的需求分析,例如只確定用例和特性的名稱,以及關鍵的非功能性需求。注意:這種分析絕不可能是完美的。
l 通過諮詢首席架構師和業務人員,從high-level 列表中選擇10%-20%比例的用例準備進行詳細的分析,選擇的依據為具有重要的架構意義;具有高業務價值;具有高風險。
l 在剩下的一天半內,對選出的用例的功能和非功能性需求進行詳細的分析。
2. 在第一次迭代之前,召開反覆項目計劃會議,對細化好的用例,在特定時間內進行設計、構造(Build)和測試。要注意的是,因為其中包含大量的工作,所以並不是在第一次迭代中就要構造(Build)出全部的已經細化的用例。
3. 在三到四周內完成第一次迭代
l 在開始的兩天內,開發人員和其他成員進行分組的建模和設計工作,在首席架構師(或專案經理)的帶領和指導下,在足夠大的白板上畫出UML的草圖並用數位相機記錄。
[注意:UML只是用於交流和理解設計,並不是必要並且必須細化到能夠產生代碼的地步的那種UML文檔。]
l 然後,剩餘的時間幾乎全部用於編程、測試和整合工作,開發人員應將建模草圖作為其靈感的起點,並且要清楚這些模型是局部並且概念模糊的。
l 進行大量的測試,包括單元測試,驗收測試,負載測試和可用性測試等。
l 在結束前一周確認能夠完成初始的迭代目標,否則縮小迭代的範圍,將次要目標置回工作清單中。
l 在最後一周的星期二,Check In全部代碼,並整合和測試所有代碼,建立迭代的基準。
l 星期三上午,向外部示範此局部系統,展示早期可視進展,同時要求反饋。
4. 在第一次迭代即將結束時,召開第二次需求工作會,對上一次會議的所有材料進行複查和精化。再選擇具有重要架構意義和高業務價值的另外一定比例的用例,用1到2天對其進行詳細分析。等這項工作完成後,會詳細記錄下大概40%的用例和非功能性需求。
5. 於周五上午,舉行下一迭代的反覆項目計劃會議。
6. 以相同步驟進行第二次迭代。
7. 反覆進行4次迭代和五次需求工作會,這樣在第4次迭代結束時,基本上已經記錄了大概80%-90%的需求,但是很可能只實現了其中的40%左右。
注意:需求集是基於反饋和進化的,因此其品質遠高於純粹依靠推測而得出的瀑布式規格說明。
8. 用UP的術語來說就是細化階段的結束,以後基本不再需要什麼需求工作會議,需求已經穩定了。正式進入UP術語的構造階段!接下來是一系列為期三周的迭代,在最後一周的周五的反覆項目計劃會上選擇適宜的下一步工作。
9. 待項目全部完成後,進行Beta測試和移交。
UP項目開發的四個主要階段
1. 初始(Inception):
大體上的構想,業務案例、範圍和模糊評估。
2. 細化(Elaboration):
已精化的構想、核心架構的迭代實現、高風險的解決、確定大多數的需求。
3. 構造(Construction):
對遺留下來的風險較低和比較簡單的元素進行迭代實現,準備部署。
4. 移交(Transition):
進行Beta測試和部署。
用例
資料來源:
l 《UML和模式應用》(第三版) (<<Applying UML and Patterns –An Introduction to Object-Oriented Analysis and Design and Iterative Development>>)