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

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

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

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

二. 需求調研

(1).了解需求

人??? 員：

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

地??? 點：

客戶辦公地點。

工作要點：

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

文???檔：

生成《需求調研表》。

規(guī) ???則：

1、調研人員數(shù)量不應少于2人，在需求調研過程中應保證人員穩(wěn)定性。

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

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

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

(2).需求整理

人??? 員：

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

地??? 點：

公司會議室 。

工作要點：

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

文??? 檔：

編寫《需求調研表》。

規(guī)??? 則：

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

2、進行討論記錄不明確的業(yè)務。

(3).需求確認

人??? 員：

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

地??? 點：

客戶辦公地點。

工作要點：

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

文??? 檔：

編寫《需求調研表》。

規(guī)??? 則：

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

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

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

三.系統(tǒng)分析

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

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

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

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

?(1).用例分析

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

人??? 員：

分析員（3員）

工作要點：

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

文??? 檔：

UML《系統(tǒng)用例圖》。

規(guī)??? 則：

1、正確區(qū)分參與者，主要參與者應是直接與系統(tǒng)進行交互的人員。

2、系統(tǒng)用例是待開發(fā)系統(tǒng)中所有要實現(xiàn)的所有功能,應包括用戶業(yè)務功能和系統(tǒng)維護功能等。

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

執(zhí)行者要點

系統(tǒng)外—必須和它交互。

系統(tǒng)邊界—責任邊界，非物理邊界。

有意義交互—屬于目標系統(tǒng)的責任。

任何事物—人、外系統(tǒng)、外部因素、時間。

4、用例要點

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

系統(tǒng)執(zhí)行—價值結果由系統(tǒng)生成。

執(zhí)行者可見—業(yè)務語言，用戶觀點。

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

?(2).領域模型分析

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

人??? 員：

分析員（3員）

工作要點：

使用UML技術編寫領域模型類圖。確定與當前迭代相關的概念類。創(chuàng)建初始的領域模型。為模型建立適當?shù)膶傩院完P聯(lián)。

文??? 檔：

UML《領域模型》類圖。

規(guī)??? 則：

?????? 1、對現(xiàn)實世界的可視代表示。

(3).基本路徑分析

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

人??? 員：

分析員（3員）

工作要點：

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

文??? 檔：

UML《基本路徑》

規(guī)??? 則：

1、主要對系統(tǒng)業(yè)務進行建模。

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

3、一般系統(tǒng)可分為三層：界面層，業(yè)務層，數(shù)據(jù)層。

(4).編寫用例文檔

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

人??? 員：

分析員（3員）

工作要點：

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

文??? 檔：

《用例文檔》

規(guī)??? 則：

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

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

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

(5).編寫體驗界面

體驗界面是系統(tǒng)分析基本完成后對系統(tǒng)界面建模。

人??? 員：

分析員（3員）

工作要點：

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

文??? 檔：

《體驗界面源代碼》

規(guī)??? 則：

1、對系統(tǒng)分析的每個用戶進行界面建模。

2、體驗界面應包括真實系統(tǒng)的所有界面。

(6).用戶體驗調查

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

人??? 員：

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

工作要點：

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

文??? 檔：

《體驗調查表》

規(guī)??? 則：

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

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

?????? 3、對分析不足之處，需返回到以上各環(huán)節(jié)重新分析。

四.系統(tǒng)設計

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

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

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

(1).框架設計

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

人??? 員：

分析員，設計員。

工作要點：

實現(xiàn)語言，軟件分布方式，系統(tǒng)邏輯結構，重點技術的測試。

文??? 檔：

《框架設計》

規(guī)??? 則：

1、對系統(tǒng)中技術可能行測試。

2、系統(tǒng)層次不益過多。

3、各層間交互技術應簡單、穩(wěn)定。

(2).類圖設計

人??? 員：

設計員

工作要點：

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

文??? 檔：

UML《類圖設計》

規(guī)??? 則：

1、對系統(tǒng)不同層次的類進行設計。

2、一般系統(tǒng)可分解成：界面層、業(yè)務層，數(shù)據(jù)層、數(shù)據(jù)控制層。

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

業(yè)務層：負責進行用戶業(yè)務操作。

數(shù)據(jù)層：系統(tǒng)中需要進行處理的各種信息。

數(shù)據(jù)控制層：負責對系統(tǒng)信息進行持久化操作。

3、近可能實現(xiàn)偽代碼。

(4).路徑設計

人??? 員：

設計員，測試員。

工作要點：

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

文??? 檔：

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

規(guī)??? 則：

?????? 1、以實現(xiàn)程序流程出發(fā)進行設計。

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

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

(5).數(shù)據(jù)庫設計

人??? 員：

設計員

工作要點：

根據(jù)設計出的數(shù)據(jù)類圖，進行數(shù)據(jù)庫模型設計。

文??? 檔：

《數(shù)據(jù)庫模型》

規(guī)??? 則：

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

五.實現(xiàn)

?(1).開發(fā)

人??? 員：

程序員，設計員

工作要點：

由程序員對系統(tǒng)設計對各程序進行代碼開發(fā)。在開發(fā)中對設計出現(xiàn)的最大設計問題進行修改。

第一步實現(xiàn)各層類接口。

第二步各層代碼可同時進行開發(fā)。

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

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

第五步業(yè)務測試。

文??? 檔：

?????? 代源碼

規(guī)??? 則：

?????? 1、程序員與設計員協(xié)同開發(fā)，對設計問題進行修改。

需求調研表

用例文檔