一.概述???????????????????

軟件開發過程(software development process)描述了構造、部署以及維護軟件的方式。統一過程[JBR99]已經成為一種流行的構造面向對象系統的迭代軟件開發過程。特別是Rational統一過程是對統一過程的詳細精化，并且已經被廣泛采納。

迭代開發是軟件開發過程和大多數其他現代方法中的關鍵實踐。在這種生命周期方法中，開發被組織成一系列固定的短期（如三個星期）小項目，稱為迭代；每次迭代都產生經過測試、集成并可執行的局部系統。每次迭化都具有各自的需求分析、設計、實現和測試活動。

過程制品和時限樣例（s：開始時間，r:精化時間）

二. 需求調研

(1).了解需求

人??? 員：

項目經理，分析員（2名），客戶。

地??? 點：

客戶辦公地點。

工作要點：

著重了解客戶的整體業務功能和各業務相關的部門與職務和人員信息。基本了解業務流程與主要業務要求。

文???檔：

生成《需求調研表》。

規 ???則：

1、調研人員數量不應少于2人，在需求調研過程中應保證人員穩定性。

2、調研人員應著重了解業務的整體性，應控制客戶講述的內容。

3、調研人員應以多聽少說為主。

4、調研人員應對各業務相關部門和人員都進行交流，以保證對各方面人員需求有全方面了解。

(2).需求整理

人??? 員：

項目經理，分析員（2名）。

地??? 點：

公司會議室 。

工作要點：

調研人員進行討論，并詳細整理編寫《需求調研表》。劃分各業務層次與業務關系，找出各業務主要相關人員與系統要求。整理各業務主流程。

文??? 檔：

編寫《需求調研表》。

規??? 則：

1、調研人員整理系統整體業務功能，并基本了解業務流程和業務需求重點。

2、進行討論記錄不明確的業務。

(3).需求確認

人??? 員：

項目經理，分析員（2員），各業務客戶。

地??? 點：

客戶辦公地點。

工作要點：

向客戶講述調研人員所理解的業務和流程。由客戶進行確認和補充，調研人員進行記錄。客戶確認后在《需求調研表》相關業務部分簽字。客戶非確認業務返回第2步。

文??? 檔：

編寫《需求調研表》。

規??? 則：

1、需求確認應有業務主要相關人員簽字。

2、調研人員應多講，讓客戶多了解調研人員對業務理解的正確。

3、同一業務可能需要進行多次需求確認。

三.系統分析

分析強調是的對問題和需求的調查研究，不是解決方案。例如需要一個新的在線交易系統，那么，應該如何使用它，它應該具有哪些功能？

“分析”一詞含義廣泛，最好加以限制，如需求分析（對需求的調查研究）或需求對象分析（對領域對象的調查研究）。

概括為：做正確的事（分析）。

在進行系統分析過程中用例分析、領域模型分析、基本路徑分析、用例文檔各活動應相互交差進行的，相交補充與完善的進行。

?(1).用例分析

用例就是需求，主要是說明系統如何工作的功能性或行為性需求。

人??? 員：

分析員（3員）

工作要點：

使用UML技術編寫用例圖，分析出系統用例、系統參與者和其相互之間關系。

文??? 檔：

UML《系統用例圖》。

規??? 則：

1、正確區分參與者，主要參與者應是直接與系統進行交互的人員。

2、系統用例是待開發系統中所有要實現的所有功能,應包括用戶業務功能和系統維護功能等。

3、執行者：在系統之外，透過系統邊界與系統進行有意義交互的任何事物。

執行者要點

系統外—必須和它交互。

系統邊界—責任邊界，非物理邊界。

有意義交互—屬于目標系統的責任。

任何事物—人、外系統、外部因素、時間。

4、用例要點

價值結果—有意義的目標。

系統執行—價值結果由系統生成。

執行者可見—業務語言，用戶觀點。

一組用例實例—用例的料度。

?(2).領域模型分析

領域模型是對領域的概念類或現實世界的可視代表示。領域模型也稱為概念模型。

人??? 員：

分析員（3員）

工作要點：

使用UML技術編寫領域模型類圖。確定與當前迭代相關的概念類。創建初始的領域模型。為模型建立適當的屬性和關聯。

文??? 檔：

UML《領域模型》類圖。

規??? 則：

?????? 1、對現實世界的可視代表示。

(3).基本路徑分析

基本路徑用于描述用例的處理流程。

人??? 員：

分析員（3員）

工作要點：

使用UML時序圖技術對每個用例進行系統流程的建模。

文??? 檔：

UML《基本路徑》

規??? 則：

1、主要對系統業務進行建模。

2、編寫時應包括各個層次類的建模。

3、一般系統可分為三層：界面層，業務層，數據層。

(4).編寫用例文檔

用例文檔是指對與系統用例編寫的文本文檔。用與補充時序圖無法描述業務流程中各節點詳細情況。

人??? 員：

分析員（3員）

工作要點：

指對每個用例圖中的用例，使用文檔方式詳細主參與者與系統之間的交互情況。

文??? 檔：

《用例文檔》

規??? 則：

1、針對與系統用例圖中每一個用例，都應包括一個用例文檔。

2、主要用于描述人與系統間的交互過程和系統的處理結果。

3、用例文檔中包括的內容有：用例編號、用例名稱、執行者、前置條件、后置條件、涉眾利益、基本路徑、擴展路徑、字段列表、業務規則、非功能需求、設計約束。

(5).編寫體驗界面

體驗界面是系統分析基本完成后對系統界面建模。

人??? 員：

分析員（3員）

工作要點：

快速使用開發工具對所待開發系統的人機操作界面進行建模。用戶可以通過體驗界面了解到待開發系統的每個業務操作情況。

文??? 檔：

《體驗界面源代碼》

規??? 則：

1、對系統分析的每個用戶進行界面建模。

2、體驗界面應包括真實系統的所有界面。

(6).用戶體驗調查

用戶體驗調查是將系統分析出各制品與用戶進行交流，用戶可在此階段重新整理需求，發覺出新的潛在需求。

人??? 員：

項目經理、分析員（3員）

工作要點：

以用戶體驗界面為主，向用戶介紹本系統最終可實現的功能和業務操作流程，引導用戶發現法潛在需求。并對用戶的反饋信息進行記錄和整理。可重新對系統分析不足之處進行修改。

文??? 檔：

《體驗調查表》

規??? 則：

?????? 1、對用戶體驗調查需要多次重復進行。

?????? 2、詳細記錄用戶反饋信息。

?????? 3、對分析不足之處，需返回到以上各環節重新分析。

四.系統設計

設計強調的是滿足需求的概念上的解決方案（在軟件方面和硬件方面），而不是其實現。最終，設計可以實現，而實現（如代碼）則表達了真實和完整的設計。

與“分析”相同，對“設計”一詞最好也加以限制，如面向對象設計或數據庫設計。

概括為：正確地做事（設計）。

(1).框架設計

框架設計首先決定了整個結構。

人??? 員：

分析員，設計員。

工作要點：

實現語言，軟件分布方式，系統邏輯結構，重點技術的測試。

文??? 檔：

《框架設計》

規??? 則：

1、對系統中技術可能行測試。

2、系統層次不益過多。

3、各層間交互技術應簡單、穩定。

(2).類圖設計

人??? 員：

設計員

工作要點：

以分析階段中的類圖為藍本，從源代碼實現語言出發，進行類圖設計。

文??? 檔：

UML《類圖設計》

規??? 則：

1、對系統不同層次的類進行設計。

2、一般系統可分解成：界面層、業務層，數據層、數據控制層。

界面層：負責與用戶進行交互。

業務層：負責進行用戶業務操作。

數據層：系統中需要進行處理的各種信息。

數據控制層：負責對系統信息進行持久化操作。

3、近可能實現偽代碼。

(4).路徑設計

人??? 員：

設計員，測試員。

工作要點：

以分析階段的《基本路徑》為藍本，從實現語言出發，對業務操作中類的操作流程進行設計。測試員根據操作流程編寫測試用例文檔。

文??? 檔：

UML《設計路徑》，《測試用例》

規??? 則：

?????? 1、以實現程序流程出發進行設計。

?????? 2、對業務中各種業務情況進行設計。

?????? 3、測試員需編寫測試用例

(5).數據庫設計

人??? 員：

設計員

工作要點：

根據設計出的數據類圖，進行數據庫模型設計。

文??? 檔：

《數據庫模型》

規??? 則：

?????? 1、數據庫設計中各表和表關系應與類圖中各類和類關系進行對映。

五.實現

?(1).開發

人??? 員：

程序員，設計員

工作要點：

由程序員對系統設計對各程序進行代碼開發。在開發中對設計出現的最大設計問題進行修改。

第一步實現各層類接口。

第二步各層代碼可同時進行開發。

第三步在代碼編寫過程中編寫單元測試代碼。

第四步進行各層單元測試。

第五步業務測試。

文??? 檔：

?????? 代源碼

規??? 則：

?????? 1、程序員與設計員協同開發，對設計問題進行修改。

需求調研表

用例文檔