V模型

在開發(fā)模型中，測試常常作為亡羊補牢的事后行為，但也有以測試為中心的開發(fā)模型，那就是V模型。V模型只得到軟件業(yè)內(nèi)比較模糊的認可。V模型宣稱測試并不是一個事后彌補行為，而是一個同開發(fā)過程同樣重要的過程，如圖：

V模型是最具有代表意義的測試模型，它是瀑布模型的變種，它在瀑布模型的基礎(chǔ)上加強了測試，反映了測試活動與分析和設(shè)計的關(guān)系。V模型中，左邊下降的是開發(fā)過程階段，右邊上升部分是測試過程的各個階段。V模型的軟件測試策略既包括低層測試又包括了高層測試，低層測試是為了源代碼的正確性，高層測試是為了使整個系統(tǒng)滿足用戶的需求。V模型存在一定的局限性，它僅僅把測試過程作為在需求分析、概要設(shè)計、詳細設(shè)計及編碼之后的一個階段。讓測試工作貫穿于始終。

V模型強調(diào)軟件幵發(fā)的協(xié)作和速度，將軟件實現(xiàn)和驗證有機地結(jié)合起來，在保證較高的軟件質(zhì)M情況下縮短開發(fā)周期。V模型適合企業(yè)級的軟件幵發(fā)，它更淸楚地揭示了軟件開發(fā)過程的特性及其本質(zhì)。

V模型的價值在于它非常明確地表明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系：

• 單元測試的主要目的是針對編碼過程中可能存在的各種錯誤。例如：用戶輸入驗證過程中的邊界值的錯誤。
• 集成測試的主要目的是針對詳細設(shè)計中可能存在的問題，尤其是檢查各單元與其他程序部分之間的接口上可能存在的錯誤。
• 系統(tǒng)測試主要針對概要設(shè)計，檢查系統(tǒng)作為一個整體是否有效地得到運行。例如：在產(chǎn)品設(shè)置中是否達到了預期的高性能。
• 驗收測試通常由業(yè)務(wù)專家或用戶進行，以確認產(chǎn)品能真正符合用戶業(yè)務(wù)上的需要。

迭代與增量的概念

CBSD基于構(gòu)件的模型（構(gòu)件組裝模型/基于構(gòu)件的軟件開發(fā)）

構(gòu)件（Component，組件）是一個具有可重用價值的、功能相對獨立的軟件單元。基于構(gòu)件的軟件開發(fā)（ComponentBased Software Development，CBSD）模型是利用模塊化方法，將整個系統(tǒng)模塊化，并在一定構(gòu)件模型的支持下，復用構(gòu)件庫中的一個或多個軟件構(gòu)件，通過組合手段高效率、高質(zhì)量地構(gòu)造應(yīng)用軟件系統(tǒng)的過程。

基于構(gòu)件的開發(fā)模型融合了螺旋模型的許多特征，本質(zhì)上是演化型的，開發(fā)過程是迭代的。基于構(gòu)件的開發(fā)模型由軟件的需求分析和定義、體系結(jié)構(gòu)設(shè)計、構(gòu)件庫建立（其中構(gòu)件庫包括了構(gòu)件獲取和構(gòu)件管理）、應(yīng)用軟件構(gòu)建、測試和發(fā)布5個階段組成。如圖：

CBSE的構(gòu)件應(yīng)該具備的特征：

1. 可組裝性：所有外部交互必須通過公開定義的接口進行。
2. 可部署性：構(gòu)件總是二進制形式的，能作為一個獨立實體在平臺上運行。
3. 文檔化：用戶根據(jù)文檔來判斷構(gòu)件是否滿足需求。
4. 獨立性：可以在無其他特殊構(gòu)件的情況下進行組裝和部署。
5. 標準化：符合某種標準化的構(gòu)件模型。

CBSE的構(gòu)件的組裝順序：

1. 順序組裝：按順序調(diào)用己經(jīng)存在的構(gòu)件，可以用兩個已經(jīng)存在的構(gòu)件來創(chuàng)造一個新的構(gòu)件。
2. 層次組裝：被調(diào)用構(gòu)件的“提供”接口必須和調(diào)用構(gòu)件的“請求”接口兼容。
3. 疊加組裝：多個構(gòu)件合并形成新構(gòu)件，新構(gòu)件整合原構(gòu)件的功能，對外提供新的接口。

構(gòu)件作為重要的軟件技術(shù)和工具得到了極大的發(fā)展，這些新技術(shù)標準和工具有Microsoft的DCOM/COM，Sun的EJB，OMG的CORBA等。基于構(gòu)件的開發(fā)活動從標識候選構(gòu)件開始，通過搜索已有構(gòu)件庫，確認所需要的構(gòu)件是否已經(jīng)存在，如果已經(jīng)存在，就從構(gòu)件庫中提取出來復用；如果不存在，就采用面向?qū)ο蠓椒ㄩ_發(fā)它。在提取出來的構(gòu)件通過語法和語義檢查后，將這些構(gòu)件通過膠合代碼組裝到一起實現(xiàn)系統(tǒng)，這個過程是迭代的。

基于構(gòu)件的開發(fā)方法使得軟件開發(fā)不再一切從頭開始，開發(fā)的過程就是構(gòu)件組裝的過程，維護的過程就是構(gòu)件升級、替換和擴充的過程，其優(yōu)點是構(gòu)件組裝模型導致了軟件的復用，提高了軟件開發(fā)的效率；構(gòu)件可由一方定義其規(guī)格說明，被另一方實現(xiàn)，然后供給第三方使用；構(gòu)件組裝模型允許多個項目同時開發(fā)，降低了費用，提高了可維護性，可實現(xiàn)分步提交軟件產(chǎn)品。缺點是由于采用自定義的組裝結(jié)構(gòu)標準，缺乏通用的組裝結(jié)構(gòu)標準，引入具有較大的風險；可重用性和軟件高效性不易協(xié)調(diào)，需要精干的、有經(jīng)驗的分析人員和開發(fā)人員，一般的開發(fā)人員插不上手，客戶的滿意度低；過分依賴于構(gòu)件，構(gòu)件庫的質(zhì)量影響著產(chǎn)品質(zhì)量。

RAD模型（快速應(yīng)用開發(fā)模型）

快速應(yīng)用開發(fā)（Rapid Application Development，RAD）模型是一個增量型的軟件開發(fā)過程模型，強調(diào)極短的開發(fā)周期。RAD模型是瀑布模型的一個“高速”變種，通過大量使用可復用構(gòu)件，采用基于構(gòu)件的建造方法贏得快速開發(fā)。如果需求理解得好且約束了項目的范圍，利用這種模型可以很快地創(chuàng)建出功能完善的“信息系統(tǒng)“。其流程從業(yè)務(wù)建模開始，隨后是數(shù)據(jù)建模、過程建模、應(yīng)用生成、測試及反復。瀑布模型和CBSD（Component-Based Software Development基于構(gòu)建的軟件開發(fā)模型）的綜合開發(fā)模型，如圖：

RAD模型各個活動期所要完成的任務(wù)如下：

1. 業(yè)務(wù)建模：以什么信息驅(qū)動業(yè)務(wù)過程運作？要生成什么信息？誰生成它？信息流的去向是哪里？由誰處理？可以輔之以數(shù)據(jù)流圖。
2. 數(shù)據(jù)建模：為支持業(yè)務(wù)過程的數(shù)據(jù)流，找數(shù)據(jù)對象集合，定義數(shù)據(jù)對象屬性，與其他數(shù)據(jù)對象的關(guān)系構(gòu)成數(shù)據(jù)模型，可輔之以E-R圖。
3. 過程建模：使數(shù)據(jù)對象在信息流中完成各業(yè)務(wù)功能。創(chuàng)建過程以描述數(shù)據(jù)對象的增加、修改、刪除、查找，即細化數(shù)據(jù)流圖中的處理框。
4. 應(yīng)用程序生成：利用第四代語言（4GL）寫出處理程序，重用已有構(gòu)件或創(chuàng)建新的可重用構(gòu)件，利用環(huán)境提供的工具自動生成并構(gòu)造出整個應(yīng)用系統(tǒng)。
5. 測試與交付，由于大量重用，一般只做總體測試，但新創(chuàng)建的構(gòu)件還是要測試的。

與瀑布模型相比，RAD模型不采用傳統(tǒng)的第三代程序設(shè)計語言來創(chuàng)建軟件，而是采用基于構(gòu)件的開發(fā)方法，復用已有的程序結(jié)構(gòu)（如果可能的話）或使用可復用構(gòu)件，或創(chuàng)建可復用的構(gòu)件（如果需要的話）。在所有情況下，均使用自動化工具輔助軟件創(chuàng)造。很顯然，加在一個RAD模型項目上的時間約束需要“一個可伸縮的范圍”。如果一個業(yè)務(wù)能夠被模塊化使得其中每一個主要功能均可以在不到三個月的時間內(nèi)完成，那么它就是RAD的一個候選者。每一個主要功能可由一個單獨的RAD組來實現(xiàn)，最后再集成起來形成一個整體。

RAD模型通過大量使用可復用構(gòu)件加快了開發(fā)速度，對信息系統(tǒng)的開發(fā)特別有效。但是像所有其他軟件過程模型一樣，RAD方法也有其缺陷：

• 并非所有應(yīng)用都適合RAD。RAD模型對模塊化要求比較高，如果有哪一項功能不能被模塊化，那么建造RAD所需要的構(gòu)件就會有問題；如果高性能是一個指標，且該指標必須通過調(diào)整接口使其適應(yīng)系統(tǒng)構(gòu)件才能贏得，RAD方法也有可能不能奏效。
• 開發(fā)者和客戶必須在很短的時間完成一系列的需求分析，任何一方配合不當都會導致RAD項目失敗。
• RAD只能用于信息系統(tǒng)開發(fā)，不適合技術(shù)風險很高的情況。當一個新應(yīng)用要采用很多新技術(shù)或當新軟件要求與已有的計算機程序有較高的互操作性時，這種情況就會發(fā)生。

統(tǒng)一過程（RUP/UP）

RUP的特點

1. 用例驅(qū)動：需求分析、設(shè)計、實現(xiàn)和測試等活動都是用例驅(qū)動的。
2. 以體系結(jié)構(gòu)為中心：包括系統(tǒng)的總體組織和全局控制、通信協(xié)議等。是一個多維的結(jié)構(gòu)，會采用多個視圖來描述。
3. 迭代與增量：把整個項目開發(fā)分為多個迭代過程。在每次選代中，只考慮系統(tǒng)的一部分需求，進行分析、設(shè)計、實現(xiàn)、測試和部署等過程;每次迭代是在己完成部分的基礎(chǔ)上進行的，每次增加一些新的功能實現(xiàn)，以此進行下去，直至最后項目的完成。

RUP中有4個階段

統(tǒng)一軟件開發(fā)過程定義了四種開發(fā)階段，它們按照過程順序分別是起始階段，細化階段，構(gòu)建階段和交付階段，其中在構(gòu)建階段主要產(chǎn)生的文檔有設(shè)計模型。

初始階段：項目藍圖文檔（核心需求，關(guān)鍵特征，主要約束），用例模型，項目計劃

細化階段：完成架構(gòu)設(shè)計，淘汰高風險元素

構(gòu)造階段：UML模型，測試用例

交付階段：可運行的軟件產(chǎn)品，用戶手冊，用戶支持計劃。

RUP中有9個核心工作流

RUP的工作流程分為兩部分：核心工作流程與核心支持工作流程。核心工作流程（在項目中的流程）包括業(yè)務(wù)需求建模、分析設(shè)計、實施、測試、部署；核心支持工作流程（在組織中的流程）包括環(huán)境、項目管理、配置與變更管理。

RUP軟件開發(fā)生命周期是一個二維的軟件開發(fā)模型，RUP中有9個核心工作流，如下：

1. 業(yè)務(wù)建模：理解待開發(fā)系統(tǒng)所在的機構(gòu)及其商業(yè)運作，確保所有參與人員對待開發(fā)系統(tǒng)所在的機構(gòu)有共同的認識，評估待開發(fā)系統(tǒng)對所在機構(gòu)的影響。
2. 需求：定義系統(tǒng)功能及用戶界面，使客戶知道系統(tǒng)的功能，使開發(fā)人員理解系統(tǒng)的需求，為項目預算及計劃提供基礎(chǔ)。
3. 分析與設(shè)計：把需求分析的結(jié)果轉(zhuǎn)化為分析與設(shè)計模型。
4. 實現(xiàn)：把設(shè)計模型轉(zhuǎn)換為實現(xiàn)結(jié)果，對開發(fā)的代碼做單元測試，將不同實現(xiàn)人員開發(fā)的模塊集成為可執(zhí)行系統(tǒng)。
5. 測試：檢查各子系統(tǒng)之間的交互、集成，驗證所有需求是否均被正確實現(xiàn)，對發(fā)現(xiàn)的軟件質(zhì)量上的缺陷進行歸檔，對軟件質(zhì)量提出改進建議。
6. 部署：打包、分發(fā)、安裝軟件，升級舊系統(tǒng)；培訓用戶及銷售人員，并提供技術(shù)支持。
7. 配置與變更管理：跟蹤并維護系統(tǒng)開發(fā)過程中產(chǎn)生的所有制品的完整性和一致性。
8. 項目管理：為軟件開發(fā)項目提供計劃、人員分配、執(zhí)行、監(jiān)控等方面的指導，為風險管理提供框架。
9. 環(huán)境：為軟件開發(fā)機構(gòu)提供軟件開發(fā)環(huán)境，即提供過程管理和工具的支持。

敏捷開發(fā)方法

XP極限編程

XP是一種輕量（敏捷）、高效、低風險、柔性、可預測、科學而且充滿樂趣的軟件開發(fā)方式。與其他方法論相比，其最大的不同在于：

1. 以代碼驅(qū)動的規(guī)則，其重要的文檔是源代碼。
2. 在更短的周期內(nèi)，更早地提供具體、持續(xù)的反饋信息。
3. 迭代地進行計劃編制，首先在最開始迅速生成一個總體計劃，然后在整個項目開發(fā)過程中不斷地發(fā)展它。
4. 依賴于自動測試程序來監(jiān)控開發(fā)進度，并及早地捕獲缺陷。
5. 依賴于口頭交流、測試和源程序進行溝通。
6. 倡導持續(xù)的演化式的設(shè)計。
7. 依賴于開發(fā)團隊內(nèi)部的緊密協(xié)作。
8. 盡可能達到程序員短期利益和項目長期利益的平衡。

四大價值觀：

• 溝通，加強面對面溝通
• 簡單，不過度設(shè)計
• 反饋，及時反饋
• 勇氣，接受變更的勇氣

XP是一種近螺旋式的開發(fā)方法，它將復雜的開發(fā)過程分解為一個個相對比較簡單的小周期:通過積極的交流、反饋以及其他一系列的方法，開發(fā)人員和客戶可以非常清楚開發(fā)進度、變化待解決的問題和潛在的困難等，并根據(jù)實際情況及時地調(diào)整開發(fā)過程。

XP提倡測試先行，為了將以后出現(xiàn)bug的幾率降到最低。

XP一些對費用控制嚴格的公司中的使用，非常有效。

水晶方法

水晶系列方法與XP方法一樣，都有以人為中心的理念，但在實踐上有所不同。其目的是發(fā)展一種提倡“機動性的”方法，包含具有共性的核心元素，每個都含有獨特的角色、過程模式、工作產(chǎn)品和實踐。

水晶方法：探索了用最少紀律約束而仍能成功的方法，從而在產(chǎn)出效率與易于運作上達到一種平衡。

開放式源碼

開放式源碼：程序開發(fā)人員在地域上分布很廣【其他方法強調(diào)集中辦公】。

并列爭求法

并列爭球法（SCRUM）是一種迭代的增量化過程，把每段時間（如30天）一次的迭代稱為一個“沖刺”（Sprint），并按需求的優(yōu)先級別來實現(xiàn)產(chǎn)品，多個自組織和自治的小組并行地遞增實現(xiàn)產(chǎn)品。

并列爭求法（SCRUM）：明確定義了的可重復的方法過程，側(cè)重于項目管理。。

特征驅(qū)動開發(fā)方法

特征驅(qū)動開發(fā)方法（FDD）是一個迭代的開發(fā)模型。認為有效的軟件開發(fā)需要3個要素：人、過程和技術(shù)。有5個核心過程：開發(fā)整體對象模型、構(gòu)造特征列表、計劃特征開發(fā)、特征設(shè)計和特征構(gòu)建。定義了6種關(guān)鍵的項目角色：項目經(jīng)理、首席架構(gòu)設(shè)計師、開發(fā)經(jīng)理、主程序員、程序員和領(lǐng)域?qū)＜摇?/p>

功用驅(qū)動開發(fā)方法（FDD）：編程開發(fā)人員分成兩類：首席程序員和“類”程序員。

ASD方法

ASD方法：其核心是三個非線性的、重疊的開發(fā)階段：猜測、合作與學習。

動態(tài)系統(tǒng)開發(fā)方法

動態(tài)系統(tǒng)開發(fā)方法（DSDM）：倡導以業(yè)務(wù)為核心。

逆向工程

逆向工程的特點是從已有的程序中抽取數(shù)據(jù)結(jié)構(gòu)，體系結(jié)構(gòu)和程序設(shè)計信息。

它的流程為：現(xiàn)有系統(tǒng) → 逆向工程 → 考慮新需求 → 正向工程 → 新系統(tǒng)。

軟件的逆向工程是一個恢復設(shè)計的過程，從現(xiàn)有的程序中抽取數(shù)據(jù)，體系結(jié)構(gòu)和過程設(shè)計信息。逆向工程的完備性可以用在某一個抽象層次上提供信息的詳細程度來描述，在大多數(shù)情況下，抽象層次越高，完備性就越低。

領(lǐng)域級抽象級別最高，完備性最低，實現(xiàn)級抽象級別最低，完備性最高。

與逆向工程相關(guān)的概念有重構(gòu)、設(shè)計恢復、再工程和正向工程：

• 重構(gòu)（restructuring），重構(gòu)是指在同一抽象級別上轉(zhuǎn)換系統(tǒng)描述形式。
• 設(shè)計恢復（design recovery），設(shè)計恢復是指借助工具從已有程序中抽象出有關(guān)數(shù)據(jù)設(shè)計、總體結(jié)構(gòu)設(shè)計和過程設(shè)計等方面的信息。
• 逆向工程（reverse engineering），逆向工程是分析程序，力圖在比源代碼更高抽象層次上建立程序的表示過程，逆向工程是設(shè)計的恢復過程。
• 正向工程（forward engineering），正向工程是指不僅從現(xiàn)有系統(tǒng)中恢復設(shè)計信息，而且使用該信息去改變或重構(gòu)現(xiàn)有系統(tǒng)，以改善其整體質(zhì)量。
• 再工程（re-engineering），再工程是對現(xiàn)有系統(tǒng)的重新開發(fā)過程，包括逆向工程、新需求的考慮過程和正向工程三個步驟。

凈室軟件工程CSE

凈室即無塵室，潔凈室，也就是一個受控污染級別的環(huán)境。

使用盒結(jié)構(gòu)規(guī)約（或形式化方法）進行分析和設(shè)計建模，并且強調(diào)將正確性驗證而不是測試，作為發(fā)現(xiàn)和消除錯誤的主要機制。

使用統(tǒng)計的測試來獲取認證被交付的軟件的可靠性所必須的出錯率信息。它是一種強調(diào)正確性的數(shù)學驗證和軟件可靠性的認證的軟件工程模型，其目標和結(jié)果具有非常低的出錯率。

技術(shù)手段：

• 統(tǒng)計過程控制下的增量式開發(fā)：控制迭代

• 基于函數(shù)的規(guī)范和設(shè)計：盒子結(jié)構(gòu)

  定義3種抽象層次：行為視圖（黑盒）=>> 有限狀態(tài)機視圖（狀態(tài)盒）=>> 過程視圖（明盒）

• 正確性驗證：凈室工程的核心

• 統(tǒng)計測試和軟件認證：使用統(tǒng)計學原理，總體太大時必須采用抽樣方法

缺點：

• 太理論化，正確性驗證的步驟比較困難且耗時。
• 開發(fā)小組不進行傳統(tǒng)的模塊測試，這是不現(xiàn)實的。
• 脫胎于傳統(tǒng)軟件工程，不可避免帶有傳統(tǒng)軟件工程的一些弊端。

需求工程

相關(guān)需求工程還可以參考：系分 - 需求工程

軟件需求是指用戶對系統(tǒng)在功能、行為、性能、設(shè)計約束等方面的期望。

需求開發(fā)（主線，目標）

需求分類

需求分類

1. 業(yè)務(wù)需求，業(yè)務(wù)需求是指反映企業(yè)或客戶對系統(tǒng)高層次的目標要求，通常來自項目投資人、購買產(chǎn)品的客戶、客戶單位的管理人員、市場營銷部門或產(chǎn)品策劃部門等。通過業(yè)務(wù)需求可以確定項目視圖和范圍。
2. 用戶需求，用戶需求描述的是用戶的具體目標，或用戶要求系統(tǒng)必須能完成的任務(wù)。也就是說，用戶需求描述了用戶能使用系統(tǒng)來做些什么。通常采取用戶訪談和問卷調(diào)查等方式，對用戶使用的場景（scenarios）進行整理，從而建立用戶需求
3. 系統(tǒng)需求，系統(tǒng)需求是從系統(tǒng)的角度來說明軟件的需求，包括功能需求、非功能需求和設(shè)計約束等。

質(zhì)量功能部署QFD

它是一種將用戶要求轉(zhuǎn)化成軟件需求的技術(shù)，其目的是最大限度地提升軟件工程過程中用戶的滿意度。為了達到這個目標，QFD將軟件需求分為三類，分別是常規(guī)需求、期望需求和意外需求。

1. 基本需求，也叫常規(guī)需求，用戶認為系統(tǒng)應(yīng)該做到的功能或性能，實現(xiàn)越多用戶會越滿意。
2. 期望需求，用戶想當然認為系統(tǒng)應(yīng)具備的功能或性能，但并不能正確描述自己想要得到的這些功能或性能需求。如果期望需求沒有得到實現(xiàn)，會讓用戶感到不滿意。
3. 意外需求，意外需求也稱為興奮需求，是用戶要求范圍外的功能或性能（但通常是軟件開發(fā)人員很樂意賦予系統(tǒng)的技術(shù)特性），實現(xiàn)這些需求用戶會更高興，但不實現(xiàn)也不影響其購買的決策。

需求獲取

• 用戶訪談是最基本的一種需求獲取手段，其形式包括結(jié)構(gòu)化和非結(jié)構(gòu)化兩種。結(jié)構(gòu)化是指事先準備好一系列問題，有針對地進行；而非結(jié)構(gòu)化則是只列出一個粗略的想法，根據(jù)訪談的具體情況發(fā)揮。最有效的訪談是結(jié)合這兩種方法進行，畢竟不可能把什么都一一計劃清楚，應(yīng)該保持良好的靈活性。
  用戶訪談具有良好的靈活性，有較寬廣的應(yīng)用范圍。但是，也存在著許多困難，例如，用戶經(jīng)常較忙，難以安排時間；面談時信息量大，記錄較為困難；溝通需要很多技巧，同時需要系統(tǒng)分析師具有足夠的領(lǐng)域知識等。另外，在訪談時，還可能會遇到一些對于企業(yè)來說比較機密和敏感的話題。因此，這看似簡單的技術(shù)，也需要系統(tǒng)分析師具有豐富的經(jīng)驗和較強的溝通能力。

• 問卷調(diào)查與用戶訪談相比，問卷調(diào)查可以在短時間內(nèi)，以低廉的代價從大量的回答中收集數(shù)據(jù)；問卷調(diào)查允許回答者匿名填寫，大多數(shù)用戶可能會提供真實信息；問卷調(diào)查的結(jié)果比較好整理和統(tǒng)計。但是問卷調(diào)查最大的不足就是缺乏靈活性，其他缺點還有：

  ① 雙方未見面，系統(tǒng)分析師無法從用戶的表情等其他動作來獲取一些更隱性的信息，用戶也沒有機會立即澄清對問題有含糊或錯誤的回答。

  ② 用戶有可能在心理上會不重視一張小小的表格，不認真對待，從而使得反饋的信息不全面。

  ③ 調(diào)查表不利于對問題進行展開的回答，無法了解一些細節(jié)問題。

  ④ 回答者的數(shù)量往往比預期的要少，無法保證用戶會回答問題或進一步說明所有問題。

• 抽樣調(diào)查/采樣是指從種群中系統(tǒng)地選出有代表性的樣本集的過程，通過認真研究所選出的樣本集，可以從整體上揭示種群的有用信息。對于信息系統(tǒng)的開發(fā)而言，現(xiàn)有系統(tǒng)的文檔（文件）就是采樣種群。當開始對一個系統(tǒng)做需求分析時，查看現(xiàn)有系統(tǒng)的文檔是對系統(tǒng)有初步了解的最好方法。但是，系統(tǒng)分析師應(yīng)該查看哪些類型的文檔，當文檔的數(shù)據(jù)龐大，無法一一研究時，就需要使用采樣技術(shù)選出有代表性的數(shù)據(jù)。采樣技術(shù)不僅可以用于收集數(shù)據(jù)，還可以用于采集訪談用戶或者是采集觀察用戶。在對人員進行采樣時，上面介紹的采樣技術(shù)同樣適用。通過采樣技術(shù)，選擇部分而不是選擇種群的全部，不僅加快了數(shù)據(jù)收集的過程，而且提高了效率，從而降低了開發(fā)成本。另外，采樣技術(shù)使用了數(shù)理統(tǒng)計原理，能減少數(shù)據(jù)收集的偏差。
  但是，由于采樣技術(shù)基于統(tǒng)計學原理，樣本規(guī)模的確定依賴于期望的可信度和已有的先驗知識，很大程度上取決于系統(tǒng)分析師的主觀因素，對系統(tǒng)分析師個人的經(jīng)驗和能力依賴性很強，要求系統(tǒng)分析師具有較高的水平和豐富的經(jīng)驗。

• 聯(lián)合需求計劃（JRP）

  JRP是一種相對來說成本較高的需求獲取方法，但也是十分有效的一種。它通過聯(lián)合各個關(guān)鍵用戶代表、系統(tǒng)分析師、開發(fā)團隊代表一起，通過有組織的會議來討論需求。通常該會議的參與人數(shù)為6～18人，召開時間為1～5小時。
  JRP的主要意圖是收集需求，而不是對需求進行分析和驗證。實施JRP時應(yīng)把握以下主要原則：

  ① 在JRP實施之前，應(yīng)制訂詳細的議程，并嚴格遵照議程進行。

  ②按照既定的時間安排進行。

  ③盡量完整地記錄會議期間的內(nèi)容。

  ④在討論期間盡量避免使用專業(yè)術(shù)語。

  ⑤充分運用解決沖突的技能。

  ⑥會議期間應(yīng)設(shè)置充分的間歇時間。

  ⑦鼓勵團隊取得一致意見。

  ⑧保證參加JRP的所有人員能夠遵守事先約定的規(guī)則。

需求分析

需求分析：一個好的需求應(yīng)該具有無二義性、完整性、一致性、可測試性、確定性、可跟蹤性、正確性、必要性等特性，因此，需要分析人員把雜亂無章的用戶要求和期望轉(zhuǎn)化為用戶需求，這就是需求分析的工作。

需求分析的任務(wù)：

1. 繪制系統(tǒng)上下文范圍關(guān)系圖
2. 創(chuàng)建用戶界面原型
3. 分析需求的可行性
4. 確定需求的優(yōu)先級
5. 為需求建立模型
6. 創(chuàng)建數(shù)據(jù)字典
7. 使用QFD（質(zhì)量功能部署)

結(jié)構(gòu)化分析方法 - SA

結(jié)構(gòu)化分析方法SA的核心是數(shù)據(jù)字典。圍繞這個核心有三個層次的模型，分別是數(shù)據(jù)模型，功能模型，行為模型（狀態(tài)模型）。

結(jié)構(gòu)化分析的步驟如下：

1. 分析業(yè)務(wù)情況，做出反映當前物理模型的數(shù)據(jù)流圖（Data Flow DiagramDFD）。
2. 推導出等價的邏輯模型的DFD。
3. 設(shè)計新的邏輯系統(tǒng)，生成數(shù)據(jù)字典和基元描述。
4. 建立人機接口，提出可供選擇的目標系統(tǒng)物理模型的DFD。
5. 確定各種方案的成本和風險等級，據(jù)此對各種方案進行分析。
6. 選擇一種方案。
7. 建立完整的需求規(guī)約。

結(jié)構(gòu)化分析方法SA是數(shù)據(jù)流和控制流，常用手段是數(shù)據(jù)流圖（DFD）和數(shù)據(jù)字典。

SA - 數(shù)據(jù)字典DD

數(shù)據(jù)字典是需求分析建立模型的核心。是為數(shù)據(jù)流圖中的每個數(shù)據(jù)流、文件、加工，以及組成數(shù)據(jù)流或文件的數(shù)據(jù)項做出說明。

數(shù)據(jù)字典有4類條目：數(shù)據(jù)流、數(shù)據(jù)項、數(shù)據(jù)存儲和基本加工。包括了數(shù)據(jù)元素，數(shù)據(jù)結(jié)構(gòu)，數(shù)據(jù)流，加工邏輯和外部實體。如下圖：

SA - 數(shù)據(jù)流圖DFD

數(shù)據(jù)流圖DFD是用數(shù)據(jù)流圖表示功能模型，DFD說明系統(tǒng)所完成功能，從數(shù)據(jù)傳遞和加工的角度，利用圖形符號通過逐層細分描述系統(tǒng)的各個部件的功能和數(shù)據(jù)在他們之間傳遞的情況，來說明系統(tǒng)所完成的功能。如下圖：

其中，DFD還會有“頂層DFD圖”和“0層DFD圖”。

如上圖，有如下幾種“圖元”描述：

另附一個錯誤的DFD圖，如下：

如上圖錯誤：

• 加工3.1.2有輸入但是沒有輸出，稱之為“黑洞”。
• 加工3.1.3有輸出但沒有輸入。稱之為“奇跡”。
• 加工3.1.1中輸入不足以產(chǎn)生輸出，我們稱之為“灰洞”。

SA - 狀態(tài)轉(zhuǎn)換圖STD

用狀態(tài)轉(zhuǎn)換圖表示行為模型，STD通過描述系統(tǒng)的狀態(tài)和引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件，來表示系統(tǒng)的行為，指出做為特定事件的結(jié)果將執(zhí)行哪些動作。如下圖：

SA - E-R圖/實體聯(lián)系圖

ER圖主要描述實體屬性，以及實體之間的關(guān)系。另外，ER模型是結(jié)構(gòu)化時代的模型與產(chǎn)物，在面向?qū)ο蠛蚒ML中是沒有的。如下圖：

什么是弱實體？

舉例說明：在人事管理系統(tǒng)中，職工子女的信息就是以職工的存在為前提的，子女實體是弱實體，子女與職工的聯(lián)系是一種依賴聯(lián)系。所以，職工是實體，也可以成為強實體。

強實體與弱實體的聯(lián)系只能是1：1或1：N。

面向?qū)ο蟮姆治龇椒?- OOA

OOA大致上遵循如下5個基本步驟：

1. 確定對象和類。這里所說的對象是對數(shù)據(jù)及其處理方式的抽象，它反映了系統(tǒng)保存和處理現(xiàn)實世界中某些事物的信息的能力。類是多個對象的共同屬性和方法集合的描述，它包括如何在一個類中建立一個新對象的描述。
2. 確定結(jié)構(gòu)。結(jié)構(gòu)是指問題域的復雜性和連接關(guān)系。類成員結(jié)構(gòu)反映了泛化-特化關(guān)系，整體-部分結(jié)構(gòu)反映整體和局部之間的關(guān)系。
3. 確定主題。主題是指事物的總體概貌和總體分析模型。
4. 確定屬性。屬性就是數(shù)據(jù)元素，可用來描述對象或分類結(jié)構(gòu)的實例，可在圖中給出，并在對象的存儲中指定。
5. 確定方法。方法是在收到消息后必須進行的一些處理方法:方法要在圖中定義，并在對象的存儲中指定。對于每個對象和結(jié)構(gòu)來說，那些用來增加、修改、刪除和選擇的方法本身都是隱含的（雖然它們是要在對象的存儲中定義的，但并不在圖上給出），而有些則是顯示的。

OOA - UML

OOA需求分析的UML（統(tǒng)一建模語言，與平臺和語言無關(guān)）由基本構(gòu)造塊，規(guī)則和公共機制構(gòu)成。

UML中的概念

• 類是描述具有相同屬性、方法、關(guān)系和語義的對象的集合，一個類實現(xiàn)一個或多個接口。
• 接口是指類或構(gòu)件提供特定服務(wù)的一組操作的集合，接口描述了類或構(gòu)件的對外的可見的動作。
• 構(gòu)件是物理上或可替換的系統(tǒng)部分，它實現(xiàn)了一個接口集合。提供一組接口的實現(xiàn)，是組成事物的元素。
• 包是用于把元素組織成組的通用機制，它一個構(gòu)件的抽象化的概念，是把類元按照一定的規(guī)則分成組（或稱為模塊）。
• 用例是描述一系列的動作，產(chǎn)生有價值的結(jié)果。
• 協(xié)作定義了交互的操作，是一些角色和其它事物一起工作，提供一些合作的動作，這些動作比事物的總和要大。
• 節(jié)點是一個物理元素，它在運行時存在，代表一個可計算的資源，通常占用一些內(nèi)存和具有處理能力。

OOA - UML 4+1視圖

現(xiàn)有的UML，再有的UML視圖

UML采用4+1視圖來描述軟件和軟件的開發(fā)過程，其中進程視圖繪制了所設(shè)計的并發(fā)與同步結(jié)構(gòu)；部署視圖表示軟件到硬件的映射和分布結(jié)構(gòu)；UML中的類圖可以用來表示4+1視圖中邏輯視圖；最終形成用例視圖，用來得到需求分析模型。

“4+1”視圖模型是從不同的視角、使用多個并發(fā)的視圖來組織軟件架構(gòu)的描述。

“4+1”視圖模型具有普遍適用性，實踐證明能在許多大型項目中成功運用。

OOA - 用例模型與分析模型

在OOA的需求分析中，圖的應(yīng)用是經(jīng)常被用到的。大部分的以用例模型和分析模型的建立為主線，其中用例模型采用用例圖來構(gòu)建，分析模型用類型表示。其它細節(jié)情況，也可以建立其它交互圖。

案例分析中，用例圖和類圖，經(jīng)?？嫉?/p>

需求分析工具

使用用例建模系統(tǒng)需求

用例建模來源于面向?qū)ο蠼＜夹g(shù)，但該技術(shù)也在非對象開發(fā)環(huán)境中比較流行，用例建模技術(shù)對傳統(tǒng)的系統(tǒng)分析和設(shè)計工具進行了補充，例如數(shù)據(jù)建模和過程建模， 也提供了架構(gòu)決策和用戶界面設(shè)計決策的基礎(chǔ)。

用例建模促進并鼓勵了用戶參與，具有如下優(yōu)點：

• 提供了捕捉功能需求的工具。
• 有助于將系統(tǒng)分解為更易于管理的小塊。
• 提供了與用戶以及其他關(guān)心系統(tǒng)的關(guān)聯(lián)人員進行交流的工具。
• 輔助估計項目范圍、投入和進度。
• 提供了需求跟蹤的工具。
• 提供了確定數(shù)據(jù)對象或?qū)嶓w的起點。
• 提供了設(shè)計用戶和系統(tǒng)接口的功能規(guī)格說明。

為了決定用例的重要性，項目經(jīng)理或者系統(tǒng)分析員將填寫用例分級和評估矩陣，并使用來自關(guān)聯(lián)人員和開發(fā)團隊的輸入構(gòu)造用例依賴關(guān)系圖。

1、項目經(jīng)理使用稱為用例分級和評估矩陣，決定用例的優(yōu)先級。該矩陣使用6個標準按1 ~ 5級評估用例。6個標準是：

• 對架構(gòu)設(shè)計的重要影響。
• 容易實現(xiàn)但包含重要功能。
• 包含有風險、時間緊迫或復雜的功能。
• 需要大量的研究或者新的、有風險的技術(shù)。
• 包含主要的業(yè)務(wù)功能。
• 將增加或者減少費用。

2、有些用例依賴于其他用例，其中一個用例使系統(tǒng)處于一種狀態(tài)，該狀態(tài)是另一個用例的前置條件。我們使用用例依賴關(guān)系圖建模這種依賴關(guān)系。用例依賴關(guān)系圖具有以下優(yōu)點：

• 系統(tǒng)事件及其狀態(tài)的圖形化表述有利于對系統(tǒng)功能的理解。
• 有助于確定遺漏的用例。
• 通過描述哪個用例更關(guān)鍵并需要最高優(yōu)先權(quán)，有助于推動項目管理。

數(shù)據(jù)建模與分析

數(shù)據(jù)建模是一種為數(shù)據(jù)庫定義業(yè)務(wù)需要的技術(shù)，因為數(shù)據(jù)模型最終要實現(xiàn)成數(shù)據(jù)庫，所以數(shù)據(jù)建模有時稱為數(shù)據(jù)庫建模。下圖是一個簡單的數(shù)據(jù)模型，稱為實體關(guān)系圖。

數(shù)據(jù)建模的系統(tǒng)概念：

• 實體
• 屬性（數(shù)據(jù)類型、域、默認值）（鍵）
• 關(guān)系

如何構(gòu)造數(shù)據(jù)模型？

• 獲取實體。
• 構(gòu)造上下文數(shù)據(jù)模型：包含基本業(yè)務(wù)實體及它們之間的自然關(guān)系。
• 基于鍵的數(shù)據(jù)模型：確定每個實體的鍵。
• 泛化層次體系：父實體、子實體。
• 具有完整屬性的數(shù)據(jù)模型。
• 分析數(shù)據(jù)模型：規(guī)范化（第一范式、第二范式、第三范式）。
• 將數(shù)據(jù)需求映射到地點：數(shù)據(jù)–地點–CRUD矩陣。

過程建模

過程建模源自傳統(tǒng)的軟件工程方法，可能的過程模型包括程序結(jié)構(gòu)圖、邏輯流程圖或決策表。本節(jié)重點介紹系統(tǒng)分析的過程模型，即數(shù)據(jù)流圖。 數(shù)據(jù)流圖是一種描述通過系統(tǒng)的數(shù)據(jù)流以及系統(tǒng)實施的工作或處理過程的工具。同義詞包括泡式圖、轉(zhuǎn)換圖和過程模型。

過程建模的系統(tǒng)概念：

• 外部代理：常見的同義詞包括外部實體。
• 數(shù)據(jù)存儲：是一個數(shù)據(jù)的“倉庫”，同義詞包括文件和數(shù)據(jù)庫。
• 過程：即處理，是在輸入數(shù)據(jù)流或條件上執(zhí)行，或者對輸入數(shù)據(jù)流或條件做出響應(yīng)的工作，同義詞是轉(zhuǎn)換。分解圖、層次圖。注意避免過程中三種常見的錯誤：1）有輸入沒有輸出，黑洞；2)有輸出但沒有輸入，奇跡；3)輸入不足以產(chǎn)生輸出，灰洞（如輸入一個雇員地址，輸出一張財務(wù)報表）。
• 數(shù)據(jù)流：所有的過程至少都有一個輸入流和一個輸出流。數(shù)據(jù)流是過程與系統(tǒng)環(huán)境之間的通信。在數(shù)據(jù)流圖中，有時需要描述分支的數(shù)據(jù)流或合并的數(shù)據(jù)流。分支的數(shù)據(jù)流是一個分成多個數(shù)據(jù)流的數(shù)據(jù)流，表示一個數(shù)據(jù)流的所有或者部分路由到不同目的地。合并的數(shù)據(jù)流是多個數(shù)據(jù)流合并成一個數(shù)據(jù)流后的數(shù)據(jù)流。合并的數(shù)據(jù)流指示了不同來源的數(shù)據(jù)流可以合并成一個報文供后續(xù)處理。

如何構(gòu)造過程模型：

• 構(gòu)造上下文數(shù)據(jù)流圖：0號數(shù)據(jù)流圖。
• 構(gòu)造系統(tǒng)功能分解圖。
• 事件響應(yīng)或用例清單：構(gòu)建分解圖后，下一步是確定系統(tǒng)必須響應(yīng)什么業(yè)務(wù)事件，（外部事件、時序事件、狀態(tài)事件）。發(fā)現(xiàn)并確定事件和響應(yīng)的更成功的方法之一是用例的技術(shù)。用例分析是確定并建模業(yè)務(wù)事件、誰觸發(fā)事件以及系統(tǒng)如何響應(yīng)事件的過程。
• 事件分解圖：把事件處理過程增加到分解圖中。
• 事件圖：以分解圖為提綱，可以為每個事件過程繪制一個事件圖。
• 構(gòu)造系統(tǒng)圖：從原始的上下文圖中的單個過程“爆炸”出來，在單張圖中顯示了系統(tǒng)的所有事件，顯示了子系統(tǒng)的所有事件。 構(gòu)造基本圖：具有較復雜的事件圖的事件過程應(yīng)該擴展成一個更詳細的基本數(shù)據(jù)流圖，每個基本過程都是內(nèi)聚的，也就是說僅完成一件事。
• 完成規(guī)格說明：對以上完成的數(shù)據(jù)流圖中的每個數(shù)據(jù)流、數(shù)據(jù)存儲和基本過程進行描述，并寫進資料庫中。對于過程內(nèi)部的邏輯描述，我們可以使用結(jié)構(gòu)化英語（自然英語+編程邏輯），用于說明過程模型中的基本過程的內(nèi)部邏輯。但許多過程是由復雜的條件組合的（即業(yè)務(wù)策略），使用結(jié)構(gòu)化英語不容易表達，此時可以使用決策表。

面向?qū)ο蠓治雠c建模

面向?qū)ο蠓治錾婕暗蕉x信息系統(tǒng)的靜態(tài)和動態(tài)行為模型，而非定義數(shù)據(jù)和過程模型（這是傳統(tǒng)開發(fā)方法的特點）。對象的標識，對象的數(shù)據(jù)部分（屬性），對象的行為。

需求定義（形成需求規(guī)格）

需求定義的過程也就是形成需求規(guī)格說明書SRS的過程，通常有兩種需求定義的方法，分別是嚴格定義方法和原型方法。

嚴格定義法的特點：所有需求都能夠被嚴格定義；開發(fā)人員和用戶之間能夠準確而清晰的交流；采用圖形文字能夠充分體現(xiàn)最終系統(tǒng)。

原型法：并非所有的需求都能在開發(fā)前被準確的說明；項目參加者之間通常存在交流上的困難；需要實際的可供用戶參與的系統(tǒng)模型；有合適的系統(tǒng)開發(fā)環(huán)境；反復是完全需要和值得提倡的，需求一旦確定就應(yīng)該遵從嚴格的方法。

需求確認與驗證

需求規(guī)格說明書SRS的需求驗證也稱為需求確認，其活動是為了確定以下幾個方面的內(nèi)容：

1. SRS正確地描述了預期的、滿足項目干系人需求的系統(tǒng)行為和特征。
2. SRS中的軟件需求是從系統(tǒng)需求、業(yè)務(wù)規(guī)格和其他來源中正確推導而來的。
3. 需求是完整的和高質(zhì)量的。
4. 需求的表示在所有地方都是一致的。
5. 需求為繼續(xù)進行系統(tǒng)設(shè)計、實現(xiàn)和測試提供了足夠的基礎(chǔ)。

需求驗證包括了需求評審和需求測試。

需求評審包括了：正式評審和非正式評審。需求驗證是需要做用戶簽字確認，但往往實施起來比較困難，因為需求驗證時簽字就要負責任，它是驗收的標準之一（此時的規(guī)格說明書SRS就是需求基線）。需求的評審需要用戶的參與。

需求測試，不是運行類的測試而是設(shè)計測試用例進行測試，比如告訴你輸入是什么輸出是什么，所以更加接近于想像性測試，它是驗證方向?qū)Σ粚υ摬辉撟龅倪^程。需求測試僅僅是基于文本需求進行“概念”上的測試。然而，以功能需求為基礎(chǔ)（SA方法）或者從用例派生出來（OO方法）的測試用例，可以使項目干系人更清楚地了解系統(tǒng)的行為。雖然沒有在系統(tǒng)上執(zhí)行測試用例，但是涉及測試用例的簡單動作可以解釋需求的許多問題。這種測試用例通常稱為概念測試用例，即不是真正執(zhí)行的測試用例，它們可以發(fā)現(xiàn)SRS中的錯誤、二義性和遺漏，還可以進行模型分析，以及作為用戶驗收測試的基礎(chǔ)。在正式的系統(tǒng)測試中，還可以將它們細化成測試用例。

需求管理（支持，保障）

在軟件需求工程中，需求管理貫穿于整個過程中，它的最基本的任務(wù)就是明確需求，并使項目團隊和用戶達成共識，即建立需求基線。另外，還要建立需求跟蹤能力聯(lián)系鏈，確保所有用戶需求都被正確地應(yīng)用，并且在需求發(fā)生變更時，能夠完全地控制其影響范圍，始終保持產(chǎn)品與需求的一致性。

需求管理是可重復級的一個關(guān)鍵過程域，其目標是為軟件需求建立一個基線，供軟件開發(fā)及其管理使用，使軟件計劃、產(chǎn)品和活動與軟件需求保持一致。從軟件需求工程的角度來看，需求管理包括在軟件開發(fā)過程中維持需求一致性和精確性的所有活動，包括控制需求基線，保持項目計劃與需求一致，控制單個需求和需求文檔的版本情況，管理需求和聯(lián)系鏈之間的聯(lián)系，或管理單個需求和項目其他可交付物之間的依賴關(guān)系，跟蹤基線中需求的狀態(tài)。

定義需求基線

需求開發(fā)的結(jié)果應(yīng)該有項目視圖和范圍文檔、用例文檔和SRS，以及相關(guān)的分析模型。經(jīng)評審批準，這些文檔就定義了開發(fā)工作的需求基線。這個基線在用戶和開發(fā)人員之間就構(gòu)成了軟件需求的一個約定，它是需求開發(fā)和需求管理之間的橋梁。

基線是一個軟件配置管理的概念，它幫助開發(fā)人員在不嚴重阻礙合理變化的情況下來控制變化。根據(jù)IEEE的定義，基線是指已經(jīng)通過正式評審和批準的規(guī)約或產(chǎn)品，它可以作為進一步開發(fā)的基礎(chǔ)，并且只能通過正式的變更控制系統(tǒng)進行變化。在軟件工程范圍內(nèi)，基線是軟件開發(fā)中的里程碑，其標志是有一個或多個軟件配置項的交付，且已經(jīng)經(jīng)過正式技術(shù)評審而獲得認可。例如，SRS文檔通過評審，其中的錯誤已經(jīng)被發(fā)現(xiàn)并糾正，則就變成了一個基線。根據(jù)國家標準《計算機軟件配置管理計劃規(guī)范》（GB/T 12505-1990）的規(guī)定，基線可以分為功能基線、指派基線和產(chǎn)品基線三種，通過評審后的SRS（軟件需求規(guī)格說明書）屬于指派基線。

需求的狀態(tài)

在需求狀態(tài)的變化中，項目管理人員首先需要關(guān)注的是那些被拒絕和被丟棄的需求。因為這些需求有可能是應(yīng)該被接受和并被實現(xiàn)的需求，如果不是通過有管理的處理過程，就有可能因為疏忽而被遺漏。同時，也應(yīng)關(guān)注被交付的需求，因為可交付物是項目的成果體現(xiàn)，而可交付物的主要內(nèi)容就是對需求的實現(xiàn)。

需求變更管理

CCB，變更控制委員會，也成配置控制委員會

要讓變更有序進行，首先需要有一個統(tǒng)一的單位來負責，這個單位一般叫變更控制委員會（Change
Control Board），也叫配置控制委員會（Configuration Control
Board）。CCB由項目干系人中有代表性的人員組成，人數(shù)沒有限制，一個人也可以。CCB有能力在管理上做出承諾，對建議的配置項變更做出評價、審批及監(jiān)督已批準變更的實施。CCB是決策機構(gòu)，一般不參與具體的變更執(zhí)行工作。

需求變更管理過程

1. 問題分析和變更描述。當提出一份變更提議后，需要對該提議做進一步的問題分析，檢查它的有效性，從而產(chǎn)生一個更明確的需求變更提議。
2. 變更分析和成本計算。當接受該變更提議后，需要對需求變更提議進行影響分析和評估。變更成本計算應(yīng)該包括對該變更所引起的所有改動的成本，例如修改需求文檔、相應(yīng)的設(shè)計、實現(xiàn)等工作成本。一旦分析完成并且被確認，應(yīng)該進行是否執(zhí)行這一變更的決策。
3. 變更實現(xiàn)。當確定執(zhí)行該變更后，需要根據(jù)該變更的影響范圍，按照開發(fā)的過程模型執(zhí)行相應(yīng)的變更。在計劃驅(qū)動過程模型中，往往需要回溯到需求分析階段開始，重新作對應(yīng)的需求分析、設(shè)計和實現(xiàn)等步驟;在敏捷開發(fā)模型中，往往會將需求變更納入到下一次迭代的執(zhí)行過程中。

常見的需求變更策略：

1. 所有需求變更必須遵循變更控制過程。
2. 對于未獲得批準的變更，不應(yīng)該做設(shè)計和實現(xiàn)工作。
3. 變更應(yīng)該由項目變更控制委員會決定實現(xiàn)哪些變更。
4. 項目風險承擔者應(yīng)該能夠了解變更的內(nèi)容。
5. 絕不能從項目配置庫中刪除或者修改變更請求的原始文檔。
6. 每一個集成的需求變更必須能跟蹤到一個經(jīng)核準的變更請求，以保持水平可追蹤性。

需求風險

帶有風險的做法有：①無足夠用戶參與。②忽略了用戶分類。③用戶需求的不斷增加。④模凌兩可的需求。⑤不必要的特征。⑥過于精簡的SRS。⑦不準確的估算。

變更產(chǎn)生的原因：①外部環(huán)境的變化。②需求和設(shè)計做的不夠完整。③新技術(shù)的出現(xiàn)。④公司機構(gòu)重組造成業(yè)務(wù)流程的變化。

需求跟蹤

SRS中的每個軟件配置項的需求到其涉及的系統(tǒng)（或子系統(tǒng)）需求都要具有雙向可追蹤性。所謂雙向跟蹤，包括正向跟蹤和反向跟蹤，正向跟蹤是指檢查SRS中的每個需求是否都能在后繼工作成果中找到對應(yīng)點；反向跟蹤也稱為逆向跟蹤，是指檢查設(shè)計文檔、代碼、測試用例等工作成果是否都能在SRS中找到出處。

系統(tǒng)設(shè)計

相關(guān)系統(tǒng)設(shè)計還可以參考：系分 - 系統(tǒng)設(shè)計

系統(tǒng)設(shè)計是系統(tǒng)分析的延伸與拓展。系統(tǒng)分析階段解決“做什么”的問題，而系統(tǒng)設(shè)計階段解決“怎么做”的問題。同時，它也是系統(tǒng)實施的基礎(chǔ)，為系統(tǒng)實施工作做好鋪墊。合理的系統(tǒng)設(shè)計方案既可以保證系統(tǒng)的質(zhì)量，也可以提高開發(fā)效率，確保系統(tǒng)實施工作的順利進行。

系統(tǒng)設(shè)計階段又稱為物理設(shè)計階段，它是信息系統(tǒng)開發(fā)過程中一個非常重要的階段。其任務(wù)是根據(jù)系統(tǒng)規(guī)格說明書中規(guī)定的功能要求，考慮實際條件，具體設(shè)計實現(xiàn)邏輯模型的技術(shù)方案，也就是設(shè)計新系統(tǒng)的物理模型，為下一階段的系統(tǒng)實施工作奠定基礎(chǔ)。

系統(tǒng)設(shè)計的主要內(nèi)容包括概要設(shè)計和詳細設(shè)計。概要設(shè)計又稱為系統(tǒng)總體結(jié)構(gòu)設(shè)計，它是系統(tǒng)開發(fā)過程中很關(guān)鍵的一步，其主要任務(wù)是將系統(tǒng)的功能需求分配給軟件模塊，確定每個模塊的功能和調(diào)用關(guān)系，形成軟件的模塊結(jié)構(gòu)圖，即系統(tǒng)結(jié)構(gòu)圖。在概要設(shè)計中，將系統(tǒng)開發(fā)的總?cè)蝿?wù)分解成許多個基本的、具體的任務(wù)，為每個具體任務(wù)選擇適當?shù)募夹g(shù)手段和處理方法的過程稱為詳細設(shè)計。根據(jù)任務(wù)的不同，詳細設(shè)計又可分為多種，例如，網(wǎng)絡(luò)設(shè)計、代碼設(shè)計、輸入/輸出設(shè)計、處理流程設(shè)計、數(shù)據(jù)存儲設(shè)計、用戶界面設(shè)計、安全性和可靠性設(shè)計等。

軟件設(shè)計

軟件設(shè)計包括體系結(jié)構(gòu)設(shè)計、接口設(shè)計、數(shù)據(jù)設(shè)計和過程設(shè)計。

• 結(jié)構(gòu)設(shè)計，定義軟件系統(tǒng)各主要部件之間的關(guān)系，開發(fā)一個模塊化的程序結(jié)構(gòu)，并表示出模塊間的控制關(guān)系。
• 數(shù)據(jù)設(shè)計，將模型轉(zhuǎn)換成數(shù)據(jù)結(jié)構(gòu)的定義。高質(zhì)量數(shù)據(jù)設(shè)計將改善程序結(jié)構(gòu)和模塊劃分，降低過程復雜性。
• 接口設(shè)計（人機界面設(shè)計），軟件內(nèi)部、軟件和操作系統(tǒng)間以及軟件和人之間如何通信。
• 過程設(shè)計，系統(tǒng)結(jié)構(gòu)部件轉(zhuǎn)換成軟件的過程描述。

軟件架構(gòu)設(shè)計

軟件架構(gòu) = 軟件體系結(jié)構(gòu)

架構(gòu)設(shè)計就是需求分配，即將滿足需求的職責分配到組件上。

相關(guān)架構(gòu)設(shè)計還可以參考：軟件架構(gòu)設(shè)計

用戶界面設(shè)計/人機界面設(shè)計

以上三條原則由著名用戶界面設(shè)計專家Theo Mandel博士所創(chuàng)造，通常稱之為人機交互的“黃金三原則”。另外，在設(shè)計用戶界面時，還需要保證界面的合理性和獨特性，有效進行組合，注重美觀與協(xié)調(diào)；恰到好處地提供快捷方式，注意資源協(xié)調(diào)等。

結(jié)構(gòu)化設(shè)計

結(jié)構(gòu)化設(shè)計（Structured Design，SD）是一種面向數(shù)據(jù)流的方法，它以SRS和SA階段所產(chǎn)生的數(shù)據(jù)流圖和數(shù)據(jù)字典等文檔為基礎(chǔ)，是一個自頂向下、逐步求精和模塊化的過程。SD方法的基本思想是將軟件設(shè)計成由相對獨立且具有單一功能的模塊組成的結(jié)構(gòu)，分為概要設(shè)計和詳細設(shè)計兩個階段，其中概要設(shè)計的主要任務(wù)是確定軟件系統(tǒng)的結(jié)構(gòu)，對系統(tǒng)進行模塊劃分，確定每個模塊的功能、接口和模塊之間的調(diào)用關(guān)系；詳細設(shè)計的主要任務(wù)是為每個模塊設(shè)計實現(xiàn)的細節(jié)。

概要設(shè)計

概要設(shè)計又稱為系統(tǒng)總體結(jié)構(gòu)設(shè)計，它是系統(tǒng)開發(fā)過程中很關(guān)鍵的一步，其主要任務(wù)是將系統(tǒng)的功能需求分配給軟件模塊，確定每個模塊的功能和調(diào)用關(guān)系，形成軟件的模塊結(jié)構(gòu)圖，即系統(tǒng)結(jié)構(gòu)圖。

系統(tǒng)結(jié)構(gòu)圖（Structure Chart，SC）又稱為模塊結(jié)構(gòu)圖，它是軟件概要設(shè)計階段的工具，反映系統(tǒng)的功能實現(xiàn)和模塊之間的聯(lián)系與通信，包括各模塊之間的層次結(jié)構(gòu)，即反映了系統(tǒng)的總體結(jié)構(gòu)。

人們在解決復雜問題時使用的一個很重要的原則，就是將它分解成多個小問題分別處理，在處理過程中，需要根據(jù)系統(tǒng)總體要求，協(xié)調(diào)各業(yè)務(wù)部門的關(guān)系。在SD中，這種功能分解就是將系統(tǒng)劃分為模塊，模塊是組成系統(tǒng)的基本單位，它的特點是可以自由組合、分解和變換，系統(tǒng)中任何一個處理功能都可以看成一個模塊。

模塊的四個要素：

• 輸入和輸出，模塊的輸入來源和輸出去向都是同一個調(diào)用者，即一個模塊從調(diào)用者那兒取得輸入，進行加工后再把輸出返回調(diào)用者。
• 處理功能，指模塊把輸入轉(zhuǎn)換成輸出所做的工作。
• 內(nèi)部數(shù)據(jù)，指僅供該模塊本身引用的數(shù)據(jù)。
• 程序代碼，指用來實現(xiàn)模塊功能的程序。

前兩個要素是模塊的外部特性，即反映了模塊的外貌；后兩個要素是模塊的內(nèi)部特性。在結(jié)構(gòu)化設(shè)計中，主要考慮的是模塊的外部特性，其內(nèi)部特性只做必要了解，具體的實現(xiàn)將在系統(tǒng)實施階段完成。

在SD方法中，系統(tǒng)由多個邏輯上相對獨立的模塊組成，在模塊劃分時需要遵循如下原則：

• 保持模塊大小適中
• 盡可能減少調(diào)用的深度，寬度也不宜過高
• 扇入/扇出系數(shù)合理，多扇入少扇出，單入口單出口
• 模塊的作用域應(yīng)該在模塊內(nèi)，功能應(yīng)該是可預測的
• 模塊獨立性原則（高內(nèi)聚，低耦合）

內(nèi)聚類型與耦合類型

面向?qū)ο蟮脑O(shè)計

面向?qū)ο蟮脑O(shè)計OOD是面向?qū)ο蟮姆治鯫OA的延續(xù)，其基本思想包括抽象、封裝和可擴展性，其中可擴展性主要通過繼承和多態(tài)來實現(xiàn)。在OOD中，數(shù)據(jù)結(jié)構(gòu)和在數(shù)據(jù)結(jié)構(gòu)上定義的操作算法封裝在一個對象之中。由于現(xiàn)實世界中的事物都可以抽象出對象的集合，所以O(shè)OD方法是一種更接近現(xiàn)實世界、更自然的系統(tǒng)設(shè)計方法。

類的分類

對象問的關(guān)系有：組合，聚合，繼承等

Use-A依賴關(guān)系

IS-A繼承關(guān)系

IS-PART-OF聚合（組合一種），聚合對應(yīng)的語義是“is a member of”

設(shè)計原則

在OOD中，可維護性的復用是以設(shè)計原則為基礎(chǔ)的。常用的OOD中原則包括單一原則、幵閉原則、里氏替換原則、依賴倒置原則、組合/聚合復用原則、接口隔離原則和最少知識原則等。這些設(shè)計原則首先都是面向復用的原則，遵循這些設(shè)計原則可以有效地提高系統(tǒng)的復用性，同時提高系統(tǒng)的可維護性。

• 單一職責原則，設(shè)計目的單一的類。
• 開放-封閉原則，對擴展開放，對修改封閉。即盡量在不修改原有代碼的情況下進行擴展。
• 里氏替換原則，子類可以替換父類（父類可以替換成子類），程序的行為沒有變化。軟件實體如果使用的是一個基類對象，那么一定適用于其子類對象，而且覺察不出基類對象和子類對象的區(qū)別。
• 依賴倒置原則，抽象不應(yīng)該依賴于細節(jié)，細節(jié)要依賴于抽象，而不是具體實現(xiàn)。針對接口編程，不要針對實現(xiàn)編程。
• 組合/聚合復用原則，又稱為合成復用原則，要盡景使用組合/聚合關(guān)系，少用繼承。
• 接口隔離原則，使用多個專門的接口，而不使用單一的總接口。
• 最少知識原則，也稱為迪米特法則，是指一個軟件實體應(yīng)當盡可能少地與其他實體發(fā)生相互作用。

軟件測試

相關(guān)軟件測試還可以參考：系分 - 系統(tǒng)測試與維護

• 盡早、不斷的進行測試
• 程序員避免測試自己設(shè)計的程序
• 既要選擇有效、合理的數(shù)據(jù),也要選擇無效、不合理的數(shù)據(jù)
• 修改后應(yīng)進行回歸測試
• 尚未發(fā)現(xiàn)的錯誤數(shù)量與該程序已發(fā)現(xiàn)錯誤數(shù)成正比

測試類型

測試階段

系統(tǒng)測試

軟件調(diào)試

測試是發(fā)現(xiàn)錯誤，調(diào)試是找出錯誤的代碼和原因。

調(diào)試需要確定錯誤的準確位置；確定問題的原因并設(shè)法改正；改正后要進行回歸測試。

調(diào)試的方法有：蠻力法、回溯法（從出錯的地方開始，向回找）、原因排除法（找出所有可能的原因，逐一進行排除，具體包括演繹法、歸納法、二分法）。

軟件度量

軟件的兩種屬性：外部屬性指面向管理者和用戶的屬性，可直接測量，一般為性能指標。內(nèi)部屬性指軟件產(chǎn)品本身的的屬性，如可靠性等，只能間接測量。

McCabe度量法：又稱為環(huán)路復雜度，假設(shè)有向圖中有向邊數(shù)為m，節(jié)點數(shù)為n，則此有向圖的環(huán)路復雜度為m-n+2。

注意m和n代表的含義不能混淆，可以用一個最簡單的環(huán)路來做特殊值記憶此公式，另外，針對一個程序流程圖，每一個分支邊（連線）就是一條有向邊，每一條語句（語句框）就是一個頂點。

遺留系統(tǒng)演化策略

遺留系統(tǒng)（Legacy System）是指任何基本上不能進行修改和演化以滿足新的變化了的業(yè)務(wù)需求的信息系統(tǒng)。

對遺留系統(tǒng)評價的目的是為了獲得對遺留系統(tǒng)的更好的理解，這是遺留系統(tǒng)演化的基礎(chǔ)，是任何遺留系統(tǒng)演化項目的起點。主要評價方法包括度量系統(tǒng)技術(shù)水準、商業(yè)價值和與之關(guān)聯(lián)的企業(yè)特征，其結(jié)果作為選擇處理策略的基礎(chǔ)。

• 改造策略，高水平、高價值區(qū)，即遺留系統(tǒng)的技術(shù)含量較高，本身還有極大的生命力。系統(tǒng)具有較高的業(yè)務(wù)價值，基本上能夠滿足企業(yè)業(yè)務(wù)運作和決策支持的需要。這種系統(tǒng)可能建成的時間還很短，稱這種遺留系統(tǒng)的演化策略為改造。改造包括系統(tǒng)功能的增強和數(shù)據(jù)模型的改造兩個方面。系統(tǒng)功能的增強是指在原有系統(tǒng)的基礎(chǔ)上增加新的應(yīng)用要求，對遺留系統(tǒng)本身不做改變；數(shù)據(jù)模型的改造是指將遺留系統(tǒng)的舊的數(shù)據(jù)模型向新的數(shù)據(jù)模型的轉(zhuǎn)化。
• 繼承策略，低水平、高價值區(qū)，即遺留系統(tǒng)的技術(shù)含量較低，已經(jīng)滿足企業(yè)運作的功能或性能要求，但具有較高的商業(yè)價值，目前企業(yè)的業(yè)務(wù)尚緊密依賴該系統(tǒng)。稱這種遺留系統(tǒng)的演化策略為繼承。在開發(fā)新系統(tǒng)時，需要完全兼容遺留系統(tǒng)的功能模型和數(shù)據(jù)模型。為了保證業(yè)務(wù)的連續(xù)性，新老系統(tǒng)必須并行運行一段時間，再逐漸切換到新系統(tǒng)上運行。
• 集成策略，高水平、低價值區(qū)，即遺留系統(tǒng)的技術(shù)含量較高，但其業(yè)務(wù)價值較低，可能只完成某個部門（或子公司）的業(yè)務(wù)管理。這種系統(tǒng)在各自的局部領(lǐng)域里工作良好，但對于整個企業(yè)來說，存在多個這樣的系統(tǒng)，不同的系統(tǒng)基于不同的平臺、不同的數(shù)據(jù)模型，形成了一個個信息孤島，對這種遺留系統(tǒng)的演化策略為集成。
• 淘汰策略，低水平、低價值區(qū)，即遺留系統(tǒng)的技術(shù)含量較低，且具有較低的業(yè)務(wù)價值。對這種遺留系統(tǒng)的演化策略為淘汰，即全面重新開發(fā)新的系統(tǒng)以代替遺留系統(tǒng)。完全淘汰是一種極端性策略，一般是企業(yè)的業(yè)務(wù)產(chǎn)生了根本變化，遺留系統(tǒng)已經(jīng)基本上不再適應(yīng)企業(yè)運作的需要；或者是遺留系統(tǒng)的維護人員、維護文檔資料都丟失了。經(jīng)過評價，發(fā)現(xiàn)將遺留系統(tǒng)完全淘汰，開發(fā)全新的系統(tǒng)比改造舊系統(tǒng)從成本上考慮更合算。

新舊系統(tǒng)的轉(zhuǎn)換策略

在實施新舊系統(tǒng)轉(zhuǎn)換時，轉(zhuǎn)換的策略通常有三種：

• 直接轉(zhuǎn)換策略，適用于新系統(tǒng)不太復雜或現(xiàn)有系統(tǒng)完全不能使用的場合，新系統(tǒng)在轉(zhuǎn)換之前必須經(jīng)過詳細而嚴格的測試。
• 并行轉(zhuǎn)換策略，新系統(tǒng)和現(xiàn)有系統(tǒng)并行工作一段時間，經(jīng)過這段時間的試運行后，再用新系統(tǒng)正式替換下現(xiàn)有系統(tǒng)。
• 分段轉(zhuǎn)換策略，分段轉(zhuǎn)換策略也稱為逐步轉(zhuǎn)換策略，這種轉(zhuǎn)換方式是直接轉(zhuǎn)換方式和并行轉(zhuǎn)換方式的結(jié)合，采取分期分批逐步轉(zhuǎn)換。一般比較大的系統(tǒng)采用這種方式較為適宜，它能保證平穩(wěn)運行，費用也不太高；或者現(xiàn)有系統(tǒng)比較穩(wěn)定，能夠適應(yīng)自身業(yè)務(wù)發(fā)展需要，或新舊系統(tǒng)轉(zhuǎn)換風險很大（例如，在線訂票系統(tǒng)、銀行的中間業(yè)務(wù)系統(tǒng)等），也可以采用分段轉(zhuǎn)換策略。分段轉(zhuǎn)換策略的優(yōu)點是，新舊系統(tǒng)的轉(zhuǎn)換震動比較小，用戶容易接受。但由于是采用漸進方式，導致新舊系統(tǒng)的轉(zhuǎn)換周期過長，同時由于需求的變化，給新系統(tǒng)的穩(wěn)定造成比較大的影響。而且，分段轉(zhuǎn)換策略對系統(tǒng)的設(shè)計和實現(xiàn)都有一定的要求，在轉(zhuǎn)換過程中，需要開發(fā)新舊系統(tǒng)之間的接口，還需要制訂階段性的轉(zhuǎn)換目標和計劃。

數(shù)據(jù)轉(zhuǎn)換和遷移

數(shù)據(jù)遷移的主要方法大致有三種，分別是系統(tǒng)切換前通過工具遷移、系統(tǒng)切換前采用手工錄入和系統(tǒng)切換后通過新系統(tǒng)生成。

數(shù)據(jù)遷移的實施可以分為三個階段，分別是數(shù)據(jù)遷移前的準備、數(shù)據(jù)轉(zhuǎn)換與遷移和數(shù)據(jù)遷移后的校驗。其中準備工作要做好以下7個方面的工作：

1. 待遷移數(shù)據(jù)源的詳細說明，包括數(shù)據(jù)的存放方式、數(shù)據(jù)量和數(shù)據(jù)的時間跨度。
2. 建立新舊系統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)字典，對現(xiàn)有系統(tǒng)的歷史數(shù)據(jù)進行質(zhì)量分析，以及新舊系統(tǒng)數(shù)據(jù)結(jié)構(gòu)的差異分析。
3. 新舊系統(tǒng)代碼數(shù)據(jù)的差異分析。
4. 建立新舊系統(tǒng)數(shù)據(jù)庫表的映射關(guān)系，對無法映射字段的處理方法。
5. 開發(fā)或購買、部署ETL工具。
6. 編寫數(shù)據(jù)轉(zhuǎn)換的測試計劃和校驗程序。
7. 制定數(shù)據(jù)轉(zhuǎn)換的應(yīng)急措施。

在數(shù)據(jù)遷移完成后，需要對遷移后的數(shù)據(jù)進行校驗。數(shù)據(jù)遷移后的校驗是對遷移質(zhì)量的檢查，同時數(shù)據(jù)校驗的結(jié)果也是判斷新系統(tǒng)能否正式啟用的重要依據(jù)。可以通過以下兩種方式對遷移后的數(shù)據(jù)進行校驗：

1. 對遷移后的數(shù)據(jù)進行質(zhì)量分析。
2. 新舊系統(tǒng)查詢數(shù)據(jù)對比檢查。

影響軟件可維護性的因素

• 【可理解性】是指通過閱讀源代碼和相關(guān)文檔，了解軟件的功能和如何運行的容易程度。

• 【可修改性】是指修改軟件的難易程度。

• 【可測試性】是指驗證軟件程序正確的難易程度。

  可測試性好的軟件，通常意味著軟件設(shè)計簡單，復雜性低。因為軟件的復雜性越大，測試的難度也就越大。

• 【可靠性】一個軟件的可靠性越高，需要維護的概率就會越低。

• 【可移植性】是指將軟件從一個環(huán)境移植到新的的環(huán)境下正確運行的難易程度。

  軟件運行環(huán)境的變化是軟件維護的一種常見情形，可移植性好的軟件會降低維護的概率

軟件維護類型

軟件的維護并不只是修正錯誤，為了滿足用戶提出的增加新功能，修改現(xiàn)有功能以及一般性的改進要求和建議，需要進行完善性維護，他是軟件維護的重要組成部分。

• 改正性維護【修BUG】：也稱正確性維護，指改正在系統(tǒng)開發(fā)階段已發(fā)生而系統(tǒng)測試階段尚未發(fā)現(xiàn)的錯誤【修正bug、錯誤】。
• 適應(yīng)性維護【應(yīng)變】：指使應(yīng)用軟件適應(yīng)環(huán)境變化【外部環(huán)境、數(shù)據(jù)環(huán)境】而進行的修改。
• 完善性維護【新需求】：擴充功能和改善性能而進行的修改。
• 預防性維護【針對未來】：為了適應(yīng)未來的軟硬件環(huán)境的變化，應(yīng)主動增加預防性的新的功能，以使系統(tǒng)適應(yīng)各類變化而不被淘汰。如將專用報表功能改成通用報表生成功能，以適應(yīng)將來報表格式的變化。