精選執(zhí)法案件管理系統(tǒng)開發(fā)管理方案

1、執(zhí)法案件管理系統(tǒng)開發(fā)管理方案目錄1. 引言1.1 編寫此文檔目的此文檔主要為指導(dǎo)執(zhí)法案件管理系統(tǒng)的開發(fā)進(jìn)行統(tǒng)一、規(guī)范的管理。2. 拓普應(yīng)用生命周期管理（）構(gòu)成拓普公司根據(jù)多年的軟件開發(fā)和系統(tǒng)運(yùn)維經(jīng)驗(yàn)， 在軟件開發(fā)過程 管理上采用統(tǒng)一過程管理最佳實(shí)踐， 在運(yùn)行維護(hù)管理上遵從治理的最 佳實(shí)踐，建立了以統(tǒng)一變更控制過程管理、 統(tǒng)一開發(fā)過程管理和運(yùn)維 及問題管理為基礎(chǔ)的拓普應(yīng)用生命周期管理（）體系。將以往單純的 軟件開發(fā)過程管理拓展到整個應(yīng)用的生命周期管理， 在環(huán)節(jié)上包含需 求、設(shè)計、編碼、測試、發(fā)布和維護(hù)等工作，在過程管理上涵蓋了需 求管理、配置管理、變更管理、開發(fā)過程管理和運(yùn)維及問題管理等項 內(nèi)容

2、，其構(gòu)成如下圖所示：匚二)需求提出人員項目啟動項目管理人員開發(fā)/測試組長?打開任務(wù)高層管理人員?測試人員<執(zhí)行測試¥集成構(gòu)建人員1 m-創(chuàng)建基線提出需求開發(fā)人員代碼開發(fā)問題受理人員常普變更控制管理平占受理故障在應(yīng)用開發(fā)項目確立并啟動后，開始進(jìn)入了大規(guī)模軟件開發(fā)階段, 由此，應(yīng)用掀開了其生命周期的序幕，的管理流程如下：應(yīng)用單位業(yè)務(wù)人員與公司分析人員的需求采集過程項目管理人員啟動開發(fā)項目過程管理流程，制定產(chǎn)品開發(fā)計劃配置管理人員啟動配置管理流程，制定配置管理計劃需求管理人員啟動需求管理流程，建立需求跟蹤機(jī)制分析人員依照采集的需求進(jìn)行需求分析測試設(shè)計人員與分析人員協(xié)調(diào)，同步進(jìn)行測試設(shè)

3、計，設(shè)計人員依照需求分析結(jié)果進(jìn)行設(shè)計開發(fā)人員依照設(shè)計進(jìn)行編碼測試人員依照測試設(shè)計進(jìn)行測試按照迭代計劃，重復(fù)執(zhí)行一，直到開發(fā)結(jié)束(11) 集成人員按產(chǎn)品形式進(jìn)行集成(12) 質(zhì)量控制人員進(jìn)行產(chǎn)品質(zhì)量審驗(yàn)(13) 公司將產(chǎn)品發(fā)布到用戶環(huán)境圍運(yùn)維人員在知識庫的支撐下為用戶解答問題(15) 運(yùn)維人員無法處理的問題將以問題報告單的形式記錄在運(yùn)維系統(tǒng)(16) 問題分析人員將問題報告單分類，提取缺陷和需求，申請變更(17) 變更控制委員會審核變更申請，確定變更方案(18) 需求進(jìn)入需求管理流程，然后進(jìn)入由上述流程描述可見，在管理流程中，形成了“需求一開發(fā)一維護(hù)一需求”這樣一個閉環(huán)管理流程，其中的流程控制如下

4、：客戶援霧業(yè)務(wù)部門將應(yīng)用生命周期中的各個工作環(huán)節(jié)和管理過程進(jìn)行了如下的劃分：統(tǒng)一開發(fā)過程管理應(yīng)用項目確立后初始的需求采集和管理需求分析設(shè)計編碼測試發(fā)布統(tǒng)一變更控制管理需求管理，主要針對開發(fā)過程中的需求變化和運(yùn)維過程中產(chǎn)生的 新需求缺陷管理配置管理變更管理、運(yùn)維及問題管理問題解答：運(yùn)維過程中的操作性指導(dǎo)知識管理：將運(yùn)維出現(xiàn)的問題進(jìn)入知識庫 運(yùn)維受理：故障受理和問題報告單受理3. 統(tǒng)一變更控制（）3.1 統(tǒng)一變更控制（）平臺的構(gòu)建統(tǒng)一變更控制（）又叫統(tǒng)一配置管理，是在大量軟件工程實(shí)踐經(jīng) 驗(yàn)和用戶反饋的基礎(chǔ)上提出的第三代配置管理解決方案。 是用于管理 軟件開發(fā)過程（包括從需求到版本發(fā)布）中所有變更的

5、“最佳實(shí)踐” 流程。定義了一個可以立即用于軟件開發(fā)項目的一致并基于活動的變 更管理流程。河南拓普網(wǎng)絡(luò)計算機(jī)工程有限公司采用公司的產(chǎn)品 和 構(gòu)建了 自己的運(yùn)行平臺。 通過 和 的支持， 已成為拓普公司支持統(tǒng)一開發(fā)過 程管理體系和運(yùn)維及問題管理體系的關(guān)鍵組成部分和基礎(chǔ)支撐平臺。通過抽象層次的提升簡化了軟件開發(fā)和系統(tǒng)維護(hù)， 從而使得軟件 開發(fā)團(tuán)隊和運(yùn)維團(tuán)隊從更高的層次根據(jù)活動（）來管理變更。通過， 一個開發(fā)活動可以自動地同其變更集 （封裝了所有用于實(shí)現(xiàn)該活動的 項目工件）相關(guān)聯(lián)，這樣避免了管理人員手動跟蹤所有文件變更。3.2.1 的特點(diǎn)及優(yōu)勢支持軟件開發(fā)和運(yùn)行維護(hù)一體化管理通過工作流程， 將軟件開發(fā)

6、流程和運(yùn)行維護(hù)流程有機(jī)地結(jié)合， 形 成一個可以貫穿應(yīng)用生命周期的統(tǒng)一管理流程。預(yù)定義的工作流程可以直接采用預(yù)定義的工作流程， 快速提升開發(fā)和運(yùn)維組織的軟件配置管理水平；項目的跟蹤和組織項目管理人員可以實(shí)時掌握項目的最新動態(tài)， 合理分配資源和調(diào) 度開發(fā)活動，跟蹤軟件運(yùn)行狀況；協(xié)作自動化通過將許多耗時較多的任務(wù)自動化處理， 使得開發(fā)人員更多地將 注意力集中在更高層次的開發(fā)活動上；輕松管理基線將開發(fā)活動嵌入到各個基線中， 這樣測試人員確切地知道他們將測試什么，而開發(fā)人員則確切地知道其他開發(fā)人員做了什么；支持跨功能開發(fā)組已成為產(chǎn)品中的核心部分， 從而可以將從需求到測試各個階段的 工件（例如需求文檔、設(shè)

7、計模型、應(yīng)用源代碼、測試用例以及及內(nèi)容 等）在框架下進(jìn)行統(tǒng)一集成， 簡化了貫穿整個軟件開發(fā)周期的變更過 程；基于同一代碼構(gòu)件可以進(jìn)行多項目開發(fā)， 簡化了多項目開發(fā)管理， 增大了代碼共享，節(jié)省了開發(fā)資源；可擴(kuò)展性小型團(tuán)隊可以從和開始， 而大型團(tuán)隊可以結(jié)合的高級構(gòu)建管理 （） 功能，以及和跨地域的使用。3.2.2 軟件開發(fā)過程中的變更變更是非常頻繁并且是不可避免的！ 應(yīng)用開發(fā)團(tuán)隊面臨著巨大的挑戰(zhàn)： 一方面市場要求以空前的速度 來開發(fā)高質(zhì)量的軟件應(yīng)用； 另一方面， 軟件應(yīng)用需求隨著開發(fā)環(huán)境和 結(jié)構(gòu)的日趨復(fù)雜而變得更加復(fù)雜；加上分布式開發(fā)、高性能要求、多 平臺、更短和連續(xù)的發(fā)布周期要求， 這些及其他一

8、些因素加重了軟件 開發(fā)一直承受的壓力， 實(shí)際上現(xiàn)在許多軟件開發(fā)團(tuán)隊經(jīng)常在能否成功 開發(fā)一個新型應(yīng)用上“賭博” 。由于軟件開發(fā)不同于傳統(tǒng)意義的工程技術(shù)（如建筑、機(jī)械等） ， 市場變化以及技術(shù)上的高速更新都注定了軟件變更是非常頻繁并且 是不可避免的， 可以說變更是軟件開發(fā)的基石。 一方面在軟件開發(fā)環(huán) 境下的內(nèi)部活動以新特性、 新功能增強(qiáng)以及缺陷修復(fù)等方式不停地制 造著變更；另一方面外部因素，例如新操作環(huán)境，新工具的集成，工 程技術(shù)和市場條件的改善等以另一種力量驅(qū)動著變更。管理變更的能力是項目成敗的關(guān)鍵！既然變更是不可避免的， 那么如何管理、 追蹤和控制變更就顯得 尤為重要。 盡管有多種方式可以幫助

9、開發(fā)團(tuán)隊提高變更處理能力， 但 其中最重要的一點(diǎn)是整個團(tuán)隊的協(xié)作性， 這是因?yàn)橐砸环N可重復(fù)和可 預(yù)測的方式進(jìn)行高質(zhì)量軟件的開發(fā)需要一組開發(fā)人員相互協(xié)作。 隨著 系統(tǒng)變得越來越大和越來越復(fù)雜， 盡管個人生產(chǎn)率依然十分重要， 但 是決定項目成敗更多的是作為一個整體的開發(fā)團(tuán)隊的生產(chǎn)率。而軟件開發(fā)團(tuán)隊的生產(chǎn)率很大程度上是由其相互協(xié)作和組織活 動的能力決定的， 并且開發(fā)團(tuán)隊的成功同其如何高效地響應(yīng)不斷變化 的環(huán)境因素緊密相連。對在競爭激烈的市場下想占有一席之地的開發(fā)團(tuán)隊而言拒絕變 更無疑是行不通的，只有積極面對變更，采取有效的工具、方法和流 程有機(jī)地管理、追蹤和控制變更才是保證開發(fā)團(tuán)隊成功的關(guān)鍵。 另外

10、， 由于各種因素的變更， 原來采用的工具、 方法和流程也會隨著組織的成長和不停變化的需求而逐步演化， 因此對軟件開發(fā)團(tuán)隊來說另一個 關(guān)鍵的成功因素是其擴(kuò)展能力。3.2.3 統(tǒng)一變更控制管理隨著開發(fā)團(tuán)隊的成長、 產(chǎn)品發(fā)布周期的加速以及對軟件資產(chǎn) （包 括代碼、文檔等） 控制的加強(qiáng)，對基于第三代配置管理工具和過程的 需要變得越來越大。軟件的統(tǒng)一變更管理（）通過，以及所提供的開 發(fā)平臺實(shí)現(xiàn)了貫穿整個軟件開發(fā)周期的配置管理過程， 即基于活動對 軟件構(gòu)件和項目進(jìn)行變更管理。3.2.4 活動和工件隨著軟件系統(tǒng)和開發(fā)團(tuán)隊在規(guī)模和復(fù)雜性上的不斷增長， 對開發(fā) 團(tuán)隊來說如何圍繞周期性的版本發(fā)布來合理地組織開發(fā)活

11、動以及高 效地管理用于實(shí)現(xiàn)這些活動的工件變得日益重要?；顒樱ǎ┛梢允窃?現(xiàn)有產(chǎn)品中修復(fù)一個缺陷或者新加一個增強(qiáng)功能。工件（）可以是在 開發(fā)生命周期中涉及的任何東西，例如需求文檔，源代碼，設(shè)計模型 或者測試腳本等。 實(shí)際上軟件開發(fā)過程就是軟件開發(fā)團(tuán)隊執(zhí)行活動并 生產(chǎn)工件。集成了由提供的變更請求活動管理和提供的工件管理功能。 集成了提供的活動管理能力和提供的工件管理功能，如下圖所示：If Al T325活動管理中的活動管理是由提供的，是一個高度靈活和可擴(kuò)展的缺陷及變更跟蹤系統(tǒng)，它可以捕獲和跟蹤所有的變更請求（例如產(chǎn)品缺陷、增 強(qiáng)請求、文檔變動等）。在中這些變更均以活動出現(xiàn)。為活動的跟蹤和管理提供了

12、可定制的工作流， 這使得開發(fā)團(tuán)隊可以更容易地：將活動分配給某個具體的開發(fā)人員標(biāo)識同活動相關(guān)的優(yōu)先級、當(dāng)前狀態(tài)和其他信息（如負(fù)責(zé)人、估計工期、影響程度等）自動產(chǎn)生查詢、報告和圖表根據(jù)開發(fā)團(tuán)隊或開發(fā)過程需求可以靈活地調(diào)整工作流引擎：如果開發(fā)團(tuán)隊需要快速部署，那么也可以不進(jìn)行定制，直接使用預(yù)定義的 變更過程、表單和相關(guān)規(guī)則；當(dāng)開發(fā)團(tuán)隊需要在預(yù)定義的過程上進(jìn)行 定制時，可以使用對他們的變更過程的各個方面包括缺陷和變更請求 的狀態(tài)轉(zhuǎn)移生命周期，數(shù)據(jù)庫字段，用戶界面（表單）布局，報告， 圖表和查詢等進(jìn)行定制。貫穿整個開發(fā)過程用于管理和跟蹤缺陷和其他變更的一個高效工作流對于滿足當(dāng)今高質(zhì)量標(biāo)準(zhǔn)及緊迫的產(chǎn)品工期

13、的需要是非常重要的。提升了這些變更的抽象層次以便可以從活動的角度來觀察變更， 然后工作流引擎將活動同相關(guān)的開發(fā)工件連接在一起。提供了一個現(xiàn) 成的過程框架用于缺陷和變更跟蹤工作流，如下圖所示Qow326工件管理提供了一個軟件工件管理（）框架，開發(fā)團(tuán)隊可以使用這一框架來管理貫穿項目生命周期的所有工件。 將基礎(chǔ)框架同中的活動管理結(jié)合在一起，從而提供了對工件和活動的集成管理。提供了：安全的工件存儲和版本化并行開發(fā)基礎(chǔ)框架無限分支能力和強(qiáng)大的合并功能自動代碼共享 用于選擇正確工件版本的工作空間管理 完全的可延展性從小型本地項目工作組到大型全球分布式開發(fā) 團(tuán)隊另外，提供了靈活的的基礎(chǔ)框架，通過使用靈活的元

14、數(shù)據(jù)，如標(biāo) 簽、分支、屬性、觸發(fā)器（）和超級鏈接（）等，開發(fā)團(tuán)隊可以定制 他們自己的過程。由此可見， 不同開發(fā)團(tuán)隊和項目可以通過使用不同的策略， 開發(fā) 團(tuán)隊可以從這種靈活性中受益。 而是基于一個經(jīng)過驗(yàn)證的、 成功的開 發(fā)過程，因此為希望快速啟動高效的開發(fā)團(tuán)隊也可以直接使用這一過 程來自動實(shí)現(xiàn)項目策略。具體在以下六個方面提供了開發(fā)過程。3.1.6.1 的六個過程領(lǐng)域在六個具體領(lǐng)域提供了所定義的過程： 開發(fā)人員在共享及公共代碼工件上的隔離和協(xié)作； 將一起開發(fā)、集成和發(fā)布的相關(guān)工件組按構(gòu)件（）進(jìn)行組織； 在項目里程碑創(chuàng)建構(gòu)件基線 （）并根據(jù)所建立的質(zhì)量標(biāo)準(zhǔn)來提升 基線；將變更組織為變更集（） ；將活

15、動管理和工件管理集成在一起；按項目來組織軟件開發(fā)并支持多項目之間的代碼共享；3.1.6.2 開發(fā)人員的隔離和協(xié)作開發(fā)人員需要相互隔離的工作環(huán)境以隔離彼此的工作， 避免其他 組成員的變更潛在地影響其工作的穩(wěn)定性。 提供了兩種方式來訪問工 件的正確版本并在私有工作空間中在這些工件上進(jìn)行工作。 這兩種方 式是靜態(tài)視圖和獨(dú)特的基于的動態(tài)視圖， 它們可以據(jù)本地或網(wǎng)絡(luò)使用 而分別進(jìn)行實(shí)施。靜態(tài)視圖為開發(fā)人員提供了在斷開網(wǎng)絡(luò)連接的情況下進(jìn)行工作 的靈活性，另外開發(fā)人員也可以容易地將他們的工作同開發(fā)主線進(jìn)行 同步。動態(tài)視圖則通過一個獨(dú)特的虛擬文件系統(tǒng)（）來實(shí)現(xiàn)，它使得 開發(fā)人員可以透明地訪問正確工件的正確版本

16、而無需將這些工件版 本復(fù)制到本地硬盤驅(qū)動器上。 另外由于動態(tài)視圖可以實(shí)時進(jìn)行自動更 新，因此緊密工作在同一分支上的開發(fā)團(tuán)隊無需手動更新 / 復(fù)制文件 即可立即看到其他人員所做的變動。 不管使用何種方式， 開發(fā)人員都 可以并行工作在多個發(fā)布版本上。 例如，一個開發(fā)人員工作在發(fā)布版 本 2 上，同時他也可以修復(fù)發(fā)布版本 1 中的一個缺陷， 而不用擔(dān)心自 己的兩個活動涉及的代碼互相干擾或受其他開發(fā)人員的干擾。隔離不穩(wěn)定的變更對于將錯誤最小化是非常關(guān)鍵的， 但是將所有 的變更集成到一個所有開發(fā)團(tuán)隊成員均可訪問的公共工作區(qū)域卻是 團(tuán)隊開發(fā)環(huán)境下的一個基本要求。 今天基于構(gòu)件的軟件開發(fā)方法論的 廣泛應(yīng)用以

17、及代碼變更頻率和幅度的增加都要求開發(fā)團(tuán)隊能經(jīng)常和 較早地將各個開發(fā)人員的工作進(jìn)行集成。 以便在盡早解決可能出現(xiàn)的 問題。使用，開發(fā)團(tuán)隊可以實(shí)現(xiàn)多種項目策略來同時進(jìn)行工作的隔離和 協(xié)作。通過強(qiáng)大的分支和合并功能可以支持大規(guī)模的并行開發(fā)。在中可以根據(jù)不同用途來建立分支， 如開發(fā)人員分支， 新特性分 支、缺陷修復(fù)分支、新需求分支等等，從而開發(fā)團(tuán)隊可以根據(jù)需要建 立適于自身情況的分支模型， 靈活實(shí)現(xiàn)軟件配置管理流程。 但對于希 望能快速利用成熟的軟件開發(fā)流程的開發(fā)團(tuán)隊而言， 則提供了一個直 接可用的分支模型。 實(shí)際上在中， 在分支基礎(chǔ)上對其在更高層次上進(jìn) 行了抽象，從而形成了一個新概念流（） 。流表示

18、一個私有或共享的 工作空間，它定義了項目版本的一致配置并在項目中的隔離和有效協(xié) 作之間提供了一種平衡。熟悉的讀者可以將流理解為開發(fā)人員分支， 中既有為每個開發(fā)人員配置的私有開發(fā)流， 同時為負(fù)責(zé)集成所有交付 工作的集成人員配置的公共集成流（圖 3）。由于緊密結(jié)合了活動管 理，因此其他分支用途，如特性分支、缺陷修復(fù)分支等將作為活動出 現(xiàn)并附加到相應(yīng)的工作流中。提供了公共集成工作區(qū)和私有工作區(qū)， 如下圖所示：亠 ±WOE a私有開發(fā)流為開發(fā)人員提供了相互隔離的工作空間，該空間在最開始由滿足一定質(zhì)量標(biāo)準(zhǔn)的公共工件進(jìn)行初始化。 開發(fā)人員使用這些 私有工作空間來進(jìn)行工件的變更， 構(gòu)建和測試。當(dāng)開

19、發(fā)人員對他們的 變更感到滿意時，他們可以將這些變更交付（）到公共集成流上。為 了使開發(fā)人員同其他人員的進(jìn)度同步，開發(fā)人員也可以用來自項目公 共集成流上最新的穩(wěn)定基線來變基（）他們的私有工作流。使用，開 發(fā)人員可以選擇什么時候進(jìn)行交付和變基。實(shí)際上項目集成流充當(dāng)了所有開發(fā)人員的所有變更的協(xié)調(diào)點(diǎn)。為了更好地協(xié)調(diào)所有開發(fā)人員的變更集成，引入了基線（）的概念作為 對項目進(jìn)度的度量?；€是一次構(gòu)建（）或配置的抽象表示，它實(shí)際 上是構(gòu)件的一個版本，而構(gòu)件是相關(guān)工件的集合。項目開發(fā)團(tuán)隊在開 發(fā)過程期間不斷地創(chuàng)建和提升基線。隨著不同開發(fā)人員交付變更給集 成流，他們交付的變更將被逐一收集到項目基線中。 隨著基線

20、的構(gòu)建、 測試和批準(zhǔn)，它們可以被逐步提升到不同的基線級別?；€提升級別具有兩方面的功能： 第一，它使項目經(jīng)理或項目管理人員可以建立軟件質(zhì)量標(biāo)準(zhǔn)。 由于當(dāng)基線達(dá)到某種預(yù)定義的質(zhì)量標(biāo) 準(zhǔn)時就可以被標(biāo)以某種基線級別，因此項目經(jīng)理可以設(shè)置項目策略， 標(biāo)識出在哪一個基線級別（如 " 通過測試的 "）開發(fā)人員可以執(zhí)行變基 操作。第二，基線提升級別就具體的開發(fā)人員應(yīng)該如何同其所開發(fā)的 工件進(jìn)行交互提供了指導(dǎo)。 例如，根據(jù)某條基線通過某些冒煙測試的 時間可以幫助測試人員確定什么時候開始測試。3.1.6.3 構(gòu)件基線第二個過程領(lǐng)域是將工件組織為構(gòu)件。 在第二代配置管理中， 大 多以文件版本形

21、式來管理所有的文件， 當(dāng)一個復(fù)雜項目中包含成千個 文件上萬個版本時， 整個項目的開發(fā)控制將變得相當(dāng)復(fù)雜， 因此對眾 多的文件進(jìn)行合理分類以呈現(xiàn)系統(tǒng)的設(shè)計要素可以大大簡化項目開 發(fā)控制。通過將多個工件組織為構(gòu)件 （在中構(gòu)件指一個的根目錄或的某個 第一層子目錄） 從而擴(kuò)展了軟件工件管理的版本控制能力， 并且還提 供了用于自動化構(gòu)件管理的工具和過程。 即用基線對構(gòu)件而不是構(gòu)件 中眾多的版本進(jìn)行標(biāo)識， 然后用這一基線作為新的開發(fā)起點(diǎn)并更新開 發(fā)人員的工作空間。構(gòu)件基線是在標(biāo)簽 （）的基礎(chǔ)上結(jié)合活動管理所做的擴(kuò)展，即您 可以知道一個構(gòu)件基線中包含了哪些開發(fā)活動， 例如一條基線可能包 含了三個開發(fā)活動，

22、如的修復(fù)、 用戶登錄界面漢化以及新增打印特性 的支持。對于包含多個構(gòu)件的復(fù)雜系統(tǒng)， 提供了基于多個構(gòu)件的組合基線， 即多個構(gòu)件之間可以建立依賴關(guān)系，一旦底層構(gòu)件的基線發(fā)生變化， 例如生成一條新基線， 其上層構(gòu)件相應(yīng)地也自動建立起一條基線， 該 基線自動包含底層構(gòu)件基線。例如，一個較為復(fù)雜的系統(tǒng)包含“數(shù)據(jù) 庫訪問”，“業(yè)務(wù)邏輯處理”和“前端圖形界面”三個構(gòu)件，其中“前 端圖形界面”構(gòu)件依賴于“業(yè)務(wù)邏輯處理” 構(gòu)件，而“業(yè)務(wù)邏輯處理” 構(gòu)件依賴于“數(shù)據(jù)庫訪問”構(gòu)件。這樣當(dāng)“數(shù)據(jù)庫訪問”構(gòu)件發(fā)生了 變化并新建了一條新基線后，在“業(yè)務(wù)邏輯處理”構(gòu)件和“前端圖形 界面”構(gòu)件各自動建立了一條新基線。 這樣

23、上層構(gòu)件的最新基線可以 自動跟蹤底層構(gòu)件的最新基線。構(gòu)件管理的自動化對于高效無誤地開發(fā)可能包含數(shù)千個源代碼 工件（還有其他相關(guān)的工件，如內(nèi)容，設(shè)計模型，需求說明和測試腳 本等）的復(fù)雜軟件系統(tǒng)而言意義重大。3.1.6.4 構(gòu)件基線提升項目開發(fā)團(tuán)隊的成員工作在一個項目（）中，項目經(jīng)理通過配置 軟件構(gòu)件從而使項目成為由構(gòu)件構(gòu)成的體系結(jié)構(gòu)。 大多數(shù)組織將管理 的構(gòu)件設(shè)計為可以反映出他們軟件體系結(jié)構(gòu)的方式， 即將所有相關(guān)工 件按體系結(jié)構(gòu)組織為有意義的子系統(tǒng)， 進(jìn)而放入不同的構(gòu)件中。 用構(gòu) 件可以直接對軟件體系結(jié)構(gòu)建模，如下圖所示：Adlm irtl wtmlSon如上節(jié)所描述的，開發(fā)人員在交付變更到公共

24、集成流時可以周期 性地更新他們私有開發(fā)流中的構(gòu)件。然后開發(fā)團(tuán)隊可以根據(jù)開發(fā)過程 的當(dāng)前階段和質(zhì)量級別對構(gòu)件進(jìn)行評級。 項目策略確定了在開發(fā)人員 變基之前構(gòu)件基線必須達(dá)到的質(zhì)量級別以及其他開發(fā)團(tuán)隊成員（如測試人員）應(yīng)該如何同構(gòu)件基線交互。在稍后會對項目以及項目策略做 更多描述。提供了五種預(yù)定義的基線級別，它們包括被拒絕（） ，初 始（），通過構(gòu)建（），通過測試（）和已發(fā)布（）。另外，允許開發(fā) 團(tuán)隊用他們自己的命名規(guī)范和提升策略對這些預(yù)定義基線級別進(jìn)行 定制。3.165 變更集第四個過程領(lǐng)域是將獨(dú)立的工件變更組織為可作為整體進(jìn)行交付、跟蹤和管理的變更集中。由于通常當(dāng)開發(fā)人員工作在一個活動（例 如缺

25、陷修復(fù)）上時，他們很少只修改一個文件，因此用變更集可以表 示用以完成某個具體活動的工件的所有變更， 例如為修改一個編號為 63的缺陷變動了 50個目錄/文件的 120個版本，則缺陷 63 的變更集 為相關(guān)的 120 個文件 /目錄版本。當(dāng)開發(fā)人員同時工作在多個變更請 求上的需要使得這一過程更加復(fù)雜。 例如，一個開發(fā)人員在進(jìn)行一個 新發(fā)布版本的開發(fā)， 這時由于當(dāng)前發(fā)布版本的一個錯誤要求他不得不 中斷當(dāng)前的開發(fā)工作轉(zhuǎn)而去修復(fù)這一缺陷， 這樣該開發(fā)人員必須在同 一工件上進(jìn)行兩種不同的變更， 一種是在未來發(fā)布版本中的增強(qiáng)功能 變更，另一種是在前一發(fā)布版本中修復(fù)缺陷的變更。通過將同一個開發(fā)活動相關(guān)的所有

26、變更收集到一個變更集中， 簡 化了管理多個工件變更或者多個工件版本的過程。 圍繞具體的開發(fā)活 動來進(jìn)行工作組織， 同時還確保已完成的活動包含所有必要工件上發(fā) 生的所有變更。3.1.6.6 活動和工件管理第五個過程領(lǐng)域是通過使用一個可將活動及其相關(guān)工件集鏈接 起來的自動化工作流將活動管理和工件管理集成起來。 這給了開發(fā)團(tuán) 隊極大的靈活性來為不同類型活動的管理指定不同的工作流。 提供了 最常用活動類型的預(yù)定義工作流， 包括缺陷修復(fù)和增強(qiáng)請求。 工作流 如下圖所示：開發(fā)團(tuán)隊還可以使用這一模塊來對這些預(yù)定義過程進(jìn)行定制， 項 目經(jīng)理或者項目管理人員可以用它來創(chuàng)建所有需要的活動類型，包括缺陷修復(fù)，增強(qiáng)功

27、能請求，文檔變動以及網(wǎng)站變動等。使用的圖形用 戶界面，項目經(jīng)理也可以定義字段，表單以及每個記錄類型的狀態(tài)轉(zhuǎn) 移。為了方便開發(fā)人員更容易地標(biāo)識活動和項目代碼庫中工件間的 關(guān)系，自動將活動和其相關(guān)的變更集鏈接起來。 當(dāng)在一個項目中工作 時，開發(fā)人員所交付的是活動（見開發(fā)人員隔離和協(xié)作一節(jié)）而不是 文件形式的工件。類似的，當(dāng)開發(fā)人員變基時，他們根據(jù)新構(gòu)件基線 提供的活動（而不是文件形式的工件）來重審將要在他們的私有開發(fā) 流中接收的變更內(nèi)容。這樣，開發(fā)人員不僅可以看到所有相關(guān)工件完 整的版本歷史，而且可以看到實(shí)現(xiàn)每個變更的所有活動。 這給了開發(fā) 團(tuán)隊一個項目是如何從一個階段演進(jìn)到下一個階段演進(jìn)的全面視

28、圖， 當(dāng)需要標(biāo)識出一個工件版本的變更是如何影響另一個版本時，這一優(yōu)點(diǎn)所帶來的價值是無法估計的使用一致、可重復(fù)的用于活動管理的過程，通過活動管理和工件管理的集成可以幫助開發(fā)團(tuán)隊減少錯誤， 開發(fā)人員還可以避免許多通 常需要手工作業(yè)的單調(diào)工作，從而更有效率地完成開發(fā)任務(wù)。 可以將 活動和相關(guān)的工件鏈接起來，如下圖所示:3.167 項目和項目策略中的項目可以和實(shí)際軟件開發(fā)中的各種項目對應(yīng)，每個項目包含一個集成工作流和若干個私有開發(fā)流， 項目可由一組構(gòu)件構(gòu)成。這里 需要強(qiáng)調(diào)的是一個構(gòu)件可以被多個項目共享， 進(jìn)而項目A中的開發(fā)人 員可以對一個構(gòu)件進(jìn)行修改，創(chuàng)建新的構(gòu)件基線；而項目B的開發(fā)人 員可以參照同一

29、構(gòu)件以及該構(gòu)件在項目 A中生成的基線，但不能對該 構(gòu)件進(jìn)行任何改動。因而項目從代碼級提供了軟件共享及重用的良好 基礎(chǔ)。部分原有開發(fā)人員既可以加入該項目進(jìn)行原有1.0版的錯誤修復(fù)，又可以互不干擾地在原有項目中進(jìn)行 2.0版的需求分析。在項目上另一個突出特點(diǎn)是不同項目中的開發(fā)流之間可以進(jìn)行 跨項目的工作交付。 即一個項目可以將一條構(gòu)件基線中包含的工件交 付給另一個項目， 也可以將一個開發(fā)流上的活動變更集交付給另一個 項目?？梢钥闯鲰椖繌囊粋€更高層次上支持了傳統(tǒng)意義上基于分支的 并行開發(fā)， 這對于軟件開發(fā)組織從面向項目到面向產(chǎn)品的轉(zhuǎn)變， 合理 利用軟件開發(fā)人力資源， 改善軟件產(chǎn)品體系結(jié)構(gòu)從而支持更為

30、復(fù)雜的 軟件開發(fā)具有重大意義。由于同一代碼構(gòu)件上多項目開發(fā)的引入， 相應(yīng)地加入了多種項目 策略來進(jìn)行支持， 用戶可以根據(jù)需要靈活定義項目策略。 例如上面提 到的基線級別，可以定義只有基線級別提升到“”才能作為其他開發(fā) 工作流的推薦基線。另外， 對于多項目間的代碼交付和共享，還可以 定義是否允許接受其他項目的變更等。 除了項目一級的策略以外， 在 工作流一級也有類似的訪問策略， 如某個工作流是否允許接受來自本 項目或其他項目的工作流上的變更， 是否允許向本項目或其他項目的 工作流交付變更等等。3.1.6.8 對開發(fā)團(tuán)隊和運(yùn)維團(tuán)隊的支持成功的軟件配置管理需要同時重視人的活動和得到整個開發(fā)團(tuán) 隊的全

31、體接受。 如果開發(fā)團(tuán)隊成員不能或不采用方法論的話， 實(shí)現(xiàn)將 會失敗。拓普公司多年來從成功的軟件開發(fā)團(tuán)隊和自身的軟件開發(fā)中 吸取最佳實(shí)踐經(jīng)驗(yàn)， 將作為一個可為開發(fā)團(tuán)隊采用的優(yōu)化過程來進(jìn)行 設(shè)計。的功能已全部嵌入到統(tǒng)一開發(fā)過程管理（， ）中，是在軟件開 發(fā)的各個生命周期應(yīng)用最佳軟件開發(fā)經(jīng)驗(yàn)的一個實(shí)用框架。 軟件開發(fā) 團(tuán)隊通過直接訪問并通過， 和的工具專家可以得到關(guān)于過程及其詳細(xì) 描述。通過使開發(fā)人員可以完成下面的工作而簡化了他們的工作： 將運(yùn)維與開發(fā)通過需求的傳遞和跟蹤，有機(jī)地結(jié)合起來 快速準(zhǔn)確地訪問正確工件的正確版本在他們的工作空間中相互隔離地進(jìn)行各自的工作， 但可以選擇什 么時候交付自己的工作

32、及接收其他人員的變更使用項目策略來標(biāo)識什么時候質(zhì)量達(dá)到了可以接受的級別從而 可以在自己的私有工作空間中接收其他人員的變更從他們自己的桌面透明地訪問工具。 使用可同他們最常使用的工 具（如）進(jìn)行集成的工具來進(jìn)行他們的工作在開發(fā)活動上沒有附加不 適當(dāng)約束或增加工作時間自動而透明地將變更集同活動進(jìn)行集成自動進(jìn)行活動的跟蹤、管理和報告。另外，還減輕了項目經(jīng)理的負(fù)擔(dān)，從而項目經(jīng)理可以 通過一個預(yù)定義的生命周期工作流在任何時間標(biāo)識一個具體活 動的狀態(tài)用統(tǒng)一的報告來監(jiān)控最新的項目狀態(tài)將精力集中在高優(yōu)先級或緊急的事件（活動）上確定工作負(fù)載并平衡任務(wù)分配3.1.6.9 對應(yīng)用生命周期的支持到現(xiàn)在為止， 本文主要

33、集中在源代碼和其相關(guān)工件上， 如對象文 件和頭文件等。但是使用時貫穿生命周期的變更也可以由非開發(fā)人員 進(jìn)行管理， 這樣就最佳實(shí)現(xiàn)了統(tǒng)一變更管理的全部好處。 這些非開發(fā) 人員包括分析人員，設(shè)計人員、測試人員、運(yùn)維人員甚至最終用戶。 相應(yīng)的工件包括他們在相關(guān)領(lǐng)域產(chǎn)生的工件， 例如分析人員所創(chuàng)建的 需求文檔和用例（），設(shè)計人員所建立的設(shè)計模型和用例，測試人員 建立的測試腳本，測試數(shù)據(jù)和測試結(jié)果，問題報告單，等等。為了高效地通信和協(xié)作工作， 開發(fā)團(tuán)隊成員需要有效地共享這些 工件。包含有一個集成平臺， 通過這一公共平臺可以訪問貫穿多個領(lǐng) 域的所有類型的開發(fā)工件， 提供了一個用于管理貫穿應(yīng)用生命周期的 信

34、息共享的過程層。非軟件開發(fā)人員（如分析人員、設(shè)計人員以及測 試人員）可以應(yīng)用原理象控制代碼變更一樣來控制他們生產(chǎn)的工件 （如需求文檔，用例，設(shè)計模型，測試腳本及測試數(shù)據(jù)、 問題報告單）。 工作流引擎強(qiáng)化了活動管理， 另外一致的工作流使得所有的團(tuán)隊成員 都可以容易地標(biāo)識優(yōu)先級，而提供的工作列表（）特性可以使每個人 均可從他們的桌面透明訪問待進(jìn)行的工作（活動）列表，從而容易地 標(biāo)識出他們下一步需要進(jìn)行的工作。同樣構(gòu)件基線是新工作（分析、 設(shè)計、開發(fā)及測試） 的基礎(chǔ)并指導(dǎo)團(tuán)隊成員什么時候更新他們工作空 間。開發(fā)團(tuán)隊成員在生命周期的不同階段產(chǎn)生不同的工件， 如下圖所 示：Onhir Oriliiw P

35、toswl3.1610來自分析的工件分析人員扮演著定義項目范圍的重要角色， 分析人員需要確定解 決方案是什么以及系統(tǒng)邊界。在分析期間這些專業(yè)人員創(chuàng)建了多種不 同的工件來幫助解釋說明所建議的解決方案， 這些工件包括需求文檔， 用例以及可視化模型。開發(fā)團(tuán)隊在整個開發(fā)過程中不斷使用這些工件 來管理項目變更是必不可少的。成功的項目依賴于正確的需求管理。高效的需求管理包括減少開 發(fā)的進(jìn)度風(fēng)險和系統(tǒng)的不穩(wěn)定性，以及跟蹤需求變更。項目管理，風(fēng) 險評估以及相關(guān)評估標(biāo)準(zhǔn)的產(chǎn)生都依賴于需求管理和需求的可追溯 性即開發(fā)團(tuán)隊以一種規(guī)范過程接受變更并審查需求變更的歷史。通過需求管理的工具的應(yīng)用，軟件開發(fā)團(tuán)隊可以使來創(chuàng)建

36、、管理 和跟蹤分析工件，例如需求屬性、需求說明和管理計劃，以及用例模 型，術(shù)語表以及涉眾（）請求。項目以同管理代碼相似的方式管理需求， 此外還將這些需求工件包含在構(gòu)件基線中。 這樣分析人員不僅知道哪些活動構(gòu)成了一條構(gòu)件 基線中的工件，還知道哪些需求指導(dǎo)著這些工件的開發(fā)。3.1.6.11 來自設(shè)計的工件設(shè)計人員對系統(tǒng)基礎(chǔ)結(jié)構(gòu)建模并使用用例和設(shè)計模型進(jìn)一步細(xì) 化系統(tǒng)定義。 通過設(shè)計工件對系統(tǒng)進(jìn)行抽象， 可以減少整個系統(tǒng)的復(fù) 雜性。在實(shí)際開發(fā)過程中經(jīng)常會出現(xiàn)這樣一種情況： 一些開發(fā)團(tuán)隊不能 繼續(xù)使用一些設(shè)計模型， 因?yàn)檎降木幋a工作已經(jīng)開始。 這是一個錯 誤，因?yàn)檫@些設(shè)計模型在幫助規(guī)劃整個工作， 另

37、外對于協(xié)助新的組成 員快速上手， 度量正在進(jìn)行中的變更請求的影響， 以及評估整個項目 風(fēng)險都非常有價值。 由設(shè)計工具提供的雙向工程功能可以幫助開發(fā)團(tuán) 隊保持當(dāng)前編碼進(jìn)度和這些模型之間的同步， 而確保模型與代碼是最 新的。在項目中，構(gòu)件基線包含模型工件和代碼工件。比較 / 合并特性 的緊密集成使得開發(fā)團(tuán)隊可以盡可能方便地在設(shè)計模型的同時進(jìn)行 編碼。這時中的變更集（參見變更集部分）可以擴(kuò)展到模型元素，這 樣變更集便包含了代碼工件上的變更以及模型工件上的變更。 交付（） 和變基（）操作（參見活動和工件管理部分） ，使得多個設(shè)計人員可 以在模型上同時工作， 如同開發(fā)人員并發(fā)工作在代碼上一樣。 并行開

38、發(fā)過程中模型和代碼之間的交互，如下圖所示：13.1612 來自測試的工件傳統(tǒng)的開發(fā)方法將測試工作放到開發(fā)的末期，在編碼工作之后進(jìn) 行。成功的構(gòu)件開發(fā)團(tuán)隊都體會到單元測試（）對于項目成功是非常 重要的，使用單元測試就是不將構(gòu)件的質(zhì)量保證放到集成階段，而是預(yù)先對單元、子系統(tǒng)和系統(tǒng)進(jìn)行測試。所有這些并發(fā)測試產(chǎn)生了大量的測試工件包括測試需求、測試腳 本、測試數(shù)據(jù)和大量的測試結(jié)果。測試工具為開發(fā)團(tuán)隊提供了可持續(xù) 地生產(chǎn)高質(zhì)量軟件工件所需的集成框架。 借助，開發(fā)團(tuán)隊可以并發(fā)地 管理他們的測試工件和相關(guān)的開發(fā)工件。今天，大多數(shù)開發(fā)團(tuán)隊都意識到將這些測試工件和構(gòu)件基線集成 到一起的好處。在項目中，可以在一條構(gòu)

39、件基線中包含所有的代碼工 件以及相關(guān)的測試需求，測試程序和測試數(shù)據(jù)。這樣前面描述的變更集就可以擴(kuò)展到測試用例，測試腳本和測試 數(shù)據(jù)。集成的活動和工件管理將活動的整個范圍從對代碼變更的測試 校驗(yàn)活動到由其活動描述的變更集鏈接起來。3.1.6.13 來自運(yùn)維的工件使用時，貫穿應(yīng)用生命周期的變更可以由非開發(fā)人員進(jìn)行管理， 這樣就最佳實(shí)現(xiàn)了統(tǒng)一變更管理的全部好處。 這些非開發(fā)人員包括分 析人員，設(shè)計人員、測試人員、運(yùn)維人員甚至最終用戶。來自運(yùn)行維 護(hù)的工件主要是問題報告單和衍生出來的需求。一個用于管理貫穿應(yīng)用生命周期的信息共享的過程層。 非軟件開 發(fā)人員（如分析人員、設(shè)計人員以及測試人員）可以應(yīng)用原理

40、象控制 代碼變更一樣來控制他們生產(chǎn)的工件 （如需求文檔，用例，設(shè)計模型， 測試腳本及測試數(shù)據(jù)、問題報告單） 。提供了成功的項目依賴于正確的需求管理。 高效的需求管理包括 減少開發(fā)的進(jìn)度風(fēng)險和系統(tǒng)的不穩(wěn)定性， 以及跟蹤需求變更。 項目管 理，提供了對來自運(yùn)行維護(hù)的工件主要是問題報告單和衍生出來的需 求的管理， 并將這些工件統(tǒng)一納入需求管理之中， 通過需求管理的工 具的應(yīng)用，軟件開發(fā)團(tuán)隊可以使來創(chuàng)建、管理和跟蹤分析工件，例如 需求屬性、需求說明和管理計劃， 以及用例模型，術(shù)語表以及涉眾 （） 請求。3.2 需求管理3.2.1 需求管理概述3.2.1.1 需求管理的目標(biāo)系統(tǒng)開發(fā)團(tuán)隊之所以管理需求，是

41、因?yàn)樗麄兿胱岉椖揩@得成功。滿足項目需求即為成功打下了基礎(chǔ)。 若無法管理需求， 達(dá)到目標(biāo)的幾 率就會降低。 以下最近收集的證據(jù)很有說服力： 從 歷年的 證實(shí)， 導(dǎo)致項目失敗的最重要的原因與需求有關(guān)。 的 報導(dǎo)了該公司的一項 研究，該公司對多個項目作調(diào)查后發(fā)現(xiàn)， 百分之七十四的項目是失敗 的，既這些項目不能按時按預(yù)算完成。 其中提到最多的導(dǎo)致項目失敗 的原因就是“變更用戶需求” 。避免失敗就是一個很充分的理由。 提高項目的成功率和需求管理 所帶來的其他好處同樣也是理由。 的 報告進(jìn)一步證實(shí)了與成功項目 關(guān)系最大的因素是良好的需求管理。理解需求管理的第一步就是對什么是需求管理達(dá)成共識。 把需 求定義

42、為“ （正在構(gòu)建的 ）系統(tǒng)必須符合的條件或具備的功能” 。電氣和 電子 工程師 學(xué) 會使 用的 定義 與此類 似 。 著 名 的需 求工 程設(shè) 計 師 和 H. 提出了一個包容且更為精練的定義， 它特指軟件方面 ，但 不僅僅限于軟件：“軟件需求可定義為： 用戶解決某一問題或達(dá)到某一目標(biāo)所需的 軟件功能。 系統(tǒng)或系統(tǒng)構(gòu)件為了滿足合同，規(guī)約，標(biāo)準(zhǔn)或其他正式 實(shí)行的文檔而必須滿足或具備的軟件功能。 ”由于需求是正在構(gòu)建的系統(tǒng)必須符合的事務(wù)， 而且符合某些需求 決定了項目的成功或失敗，因此找出需求是什么，將它們記下來，進(jìn) 行組織，并在發(fā)生變化時對它們進(jìn)行追蹤，這些活動都是有意義 的。 換句話說，需求管

43、理就是：一種獲取，組織并記錄系統(tǒng)需求的 系統(tǒng)化方案，以及一個使客戶與項目團(tuán)隊對不斷變更的系統(tǒng)需求達(dá)成并保持一致的過程。這個定義與 與 以及 的“軟件需求工程”的定義相似。需求工 程包括獲取，分析，規(guī)定，驗(yàn)證和管理軟件需求，而 "軟件需求管理 " 則是對所有相關(guān)活動的規(guī)劃和控制。這里介紹的以及 提出的需求管 理定義包括了所有這些活動。 它們的區(qū)別主要在于這里選用了 “管理” 這個詞，而不是“工程” 。管理這個詞更合適用來描述所有涉及到的 活動，并且它準(zhǔn)確地強(qiáng)調(diào)了追蹤變更以保持涉眾與項目團(tuán)隊之間共識 的重要性?！耙觥边@個詞可定義為團(tuán)隊用來獲取或發(fā)現(xiàn)涉眾請求，確定 請求后隱藏的

44、真正需要， 以及為滿足這些需要對系統(tǒng)提出的一組適當(dāng) 需求。需求管理問題 一個目的在于確保系統(tǒng)符合人們對其期望的流程 面臨著哪些困難呢 當(dāng)它真正在實(shí)際項目實(shí)施時，困難就暴露出來了。下面列出了更多與需求有關(guān)的問題： 需求不總是顯而易見的，而且它可來自各個方面。 需求并不總 是容易用文字明白無誤地表達(dá)。 存在不同種類的需求，其詳細(xì)程度 各不相同。 如果不加以控制，需求的數(shù)量將難以管理。 需求相互之 間以及與流程的其他可交付工件之間以多種方式相關(guān)聯(lián)。 需求有唯 一的特征或特征值。例如，它們既非同等重要， 處理的難度也不同。 需 求涉及眾多相關(guān)利益責(zé)任方， 這意味著需求要由跨職能的各組人員來 管理。 需

45、求發(fā)生變更。 需求可能對時間敏感。 當(dāng)這些問題與需求管 理和處理技能不足以及缺乏易用工具等情況一同出現(xiàn)時， 許多團(tuán)隊都對管理好需求不抱希望了。 已經(jīng)開發(fā)出指導(dǎo)團(tuán)隊提高需求管理技能 和流程的專業(yè)技術(shù)， 并使用相應(yīng)的工具使得上述的流程和專業(yè)技術(shù)得 以實(shí)現(xiàn)。3.2.1.2 需求捕獲從上述的分析可以看出，需求的捕獲是需求管理的基礎(chǔ)和前提。 在這里，將介紹一種為業(yè)界所廣泛采用并經(jīng)驗(yàn)證的需求捕獲方法， 即 用例模型。 用例模型是系統(tǒng)既定功能及系統(tǒng)環(huán)境的模型，并作為客 戶和開發(fā)人員之間的契約。用例模型用作分析， 設(shè)計和測試活動的基本輸入。 用例是貫穿整 個系統(tǒng)開發(fā)的一條主線。同一個用例模型即為需求工作流程的

46、結(jié)果， 可當(dāng)作分析設(shè)計工作流程以及測試工作流程的輸入使用。參與者 ()和 用例()是用例模型中的主要元素。用例圖用于顯示包含參與者和用例的用例模型示例。 系統(tǒng)建模有 許多種方法，每種建模方法可以滿足不同的目的。然而，用例模型最 重要的作用是將系統(tǒng)行為傳達(dá)給客戶或最終用戶。 可能與該系統(tǒng)交互 的用戶和任何其他系統(tǒng)都是參與者。 由于參與者代表了系統(tǒng)用戶， 它 們協(xié)助界定系統(tǒng)并提供十分明確的系統(tǒng)用途說明。 編寫用例依據(jù)參與 者的需求來進(jìn)行。這樣就確保該系統(tǒng)成為用戶期望得到的系統(tǒng)。參與者和用例都是通過將客戶需求及潛在用戶當(dāng)作重要的信息 查找到的。找到這些用例和參與者后，應(yīng)對它們作簡要說明。在詳細(xì) 說明

47、這些用例之前， 客戶應(yīng)復(fù)審該用例模型以核實(shí)所有的用例和參與者都已經(jīng)找到，并且它們可以提供客戶所需要的東西。 在迭代開發(fā) 環(huán)境中， 您可以選擇用例的子集以便在每個迭代中詳細(xì)描述。 參與者 和用例找到后， 需要詳細(xì)說明每個用例的事件流。 這些說明指出系統(tǒng) 與參與者交互的方式以及在各個獨(dú)立用例中系統(tǒng)執(zhí)行的有關(guān)操作。最后，對已完成的用例模型 （包括用例說明 ）進(jìn)行復(fù)審，開發(fā)人員 和客戶使用該模型對系統(tǒng)應(yīng)執(zhí)行的操作達(dá)成一致意見。3.2.1.3 需求管理模型在需求管理的流程中， 需求的捕獲手段固然重要， 但在需求的捕 獲和需求最終成型的過程中， 我們會面臨各種和需求相關(guān)的信息和資 料（也可以把這些信息籠統(tǒng)

48、地稱做 "需求 "），如何發(fā)現(xiàn)這些信息之間的 關(guān)系并有效組織，更為關(guān)鍵。 需求類型 在中，我們采用一種金字塔 方式的管理辦法，來組織和管理我們獲取的信息乃至最終的需求。為了建立一個真正滿足客戶需求的系統(tǒng)， 項目團(tuán)隊首先必須確定 系統(tǒng)要解決的問題。然后， 團(tuán)隊必須確定涉眾，從中獲得業(yè)務(wù)和用戶 需要，對其進(jìn)行描述，并區(qū)分它們的優(yōu)先級。從這一組高層期望或需 求出發(fā)，對產(chǎn)品或系統(tǒng)特性集達(dá)成一致意見。而后，由產(chǎn)品特性來抽 取軟件需求，在我們的模型中，軟件需求是以用例模型的方式來描述。 從測試的角度來看， 測試項一定來自于軟件需求， 即軟件需求中確定 了哪些需求項，測試就要根據(jù)這些需求

49、項來制定和實(shí)現(xiàn)。系統(tǒng)越大越復(fù)雜， 出現(xiàn)的需求類型就越多。 一個需求類型不過是 指需求的一個類。 通過確定需求類型， 團(tuán)隊可以把大量需求組織成意義明確且更容易管理的組。 在一個項目中建立不同類型的需求有助于 團(tuán)隊成員對變更請求進(jìn)行分類，并使相互之間的溝通更為清楚明確。 從上述的分析中我們可以看到， 通常，一類需求可以細(xì)分即分解成其 他類型的需求。這里，我們就把需求分解為幾種類型，并在他們之間 建立相應(yīng)的關(guān)聯(lián)。 業(yè)務(wù)規(guī)則和前景聲明包括高層次的需求， 團(tuán)隊可以 從中導(dǎo)出用戶需要， 特性和產(chǎn)品需求類型。 用例和其他建模形式驅(qū)動 設(shè)計需求，該需求可分解為軟件需求， 并可以用分析設(shè)計模型來說明。 測試需求

50、源于軟件需求， 它被分解為具體的測試過程。 如果既定項目 中有成百上千個， 甚至上萬個需求實(shí)例時， 對需求進(jìn)行分類可以使項 目更容易管理。上述的這些需求類型同時保存在對應(yīng)的文檔和數(shù)據(jù)庫 中。3.2.1.4 應(yīng)用需求類型通過定義需求類型， 以及他們之間的關(guān)系， 我們就建立了一個需 求管理模型的框架。當(dāng)然， 我們建立這樣的一個模型，是為了方便我 們使用需求， 為了達(dá)到這一目的， 我們還需要在此基礎(chǔ)上添加相應(yīng)的 內(nèi)容。 需要對各種需求類型添加它們的屬性，以便于對需求進(jìn)行查 詢等管理手段。比如，可以針對用戶需要，確定該需要的必要性，優(yōu) 先級，確定性等屬性。在實(shí)際的項目中，就可以確定這些屬性的值， 而后

51、根據(jù)這些實(shí)際屬性值來安排項目的進(jìn)度表等。 或是在項目進(jìn)度緊 急時，確定哪些需求是可以延期完成， 而哪些是必須完成的， 等等。需求的追蹤性 其次，可以根據(jù)不同需求的導(dǎo)出情況，在不同的需求之間建立追蹤關(guān)系。譬如，用戶需要決定了要構(gòu)建產(chǎn)品的特性， 產(chǎn)品的特性又決定了產(chǎn)品的軟件需求， 等。在這些不同類型的需求之 間建立關(guān)聯(lián)， 一旦其中的某些需求發(fā)生變化， 就可以確定它可能帶來 的影響，從而制定相應(yīng)的策略。3.2.2 需求管理的工作流程3.2.2.1 問題分析問題分析可以通過了解問題及涉眾的最初需要， 并提出高層解決 方案來實(shí)現(xiàn)。它是為找出 "隱藏在問題之后的問題 "而進(jìn)行的推理和分

52、 析。問題分析期間，將對 "什么是面臨實(shí)際問題 "和"誰是涉眾 "等問題 達(dá)成一致。而且， 您還要從業(yè)務(wù)角度界定解決方案，以及制約該解決 方案的因素。 您應(yīng)該已經(jīng)對項目進(jìn)行過商業(yè)理由分析， 這將便于您更 好地預(yù)計能從構(gòu)建中的項目中得到多少投資回報。3.2.2.2 理解涉眾需要需求來自各個方面，比如來自客戶，合作伙伴，最終用戶或是某 領(lǐng)域的專家。 您需要掌握如何準(zhǔn)確判斷需求應(yīng)來源于哪方面， 如何接 近這些來源并從中獲取信息。 提供這些信息主要出處的個人在本項目 中稱為涉眾。 如果您正在開發(fā)一個在您公司內(nèi)部使用的信息系統(tǒng)， 那 么在開發(fā)團(tuán)隊中應(yīng)包括具有最終用

53、戶經(jīng)驗(yàn)和業(yè)務(wù)領(lǐng)域?qū)I(yè)知識的人 員。通常討論將在業(yè)務(wù)模型這一級上展開， 而不是在系統(tǒng)這一級上展 開。如果正在開發(fā)一個要在市場上出售的產(chǎn)品， 那么您可以充分調(diào)動 營銷人員，以便更好地了解該市場中用戶的需要。 獲取需要的活動 可使用這樣一些技巧 :訪談，集體討論，概念原型設(shè)計，問卷調(diào)查和 競爭性分析等。 獲取結(jié)果可能是一份圖文并茂的請求或需要列表， 并 按相互之間的優(yōu)先級列出。3.2.2.3 定義系統(tǒng)定義系統(tǒng)指的是解釋涉眾需求， 并整理為對要構(gòu)建系統(tǒng)的意義明 確的說明。在系統(tǒng)定義的初期要確定以下內(nèi)容 :需求構(gòu)成，文檔格式， 語言形式，需求的具體程度 （需求量及詳細(xì)程度 ），需求的優(yōu)先級和預(yù) 計工作量

54、 （不同人在不同的實(shí)踐中通常對這兩項內(nèi)容的看法大不相同 ）， 技術(shù)和管理風(fēng)險以及最初規(guī)模。 系統(tǒng)定義活動還可包括與最關(guān)鍵的涉 眾請求直接聯(lián)系的初期原型和設(shè)計模型。 系統(tǒng)定義的結(jié)果是用自然語 言和圖解方式表達(dá)的系統(tǒng)說明。3.2.2.4 管理項目規(guī)模為使項目高效運(yùn)作， 應(yīng)仔細(xì)根據(jù)所有涉眾的需求確定優(yōu)先級， 并 對項目規(guī)模進(jìn)行管理。有的開發(fā)人員僅僅重視所謂的 "復(fù)活節(jié)彩蛋 "（即 開發(fā)人員感興趣或覺得有挑戰(zhàn)性的特性 ），而不是及早將精力投入降 低項目風(fēng)險或提高應(yīng)用程序構(gòu)架穩(wěn)定性方面， 這已使太多的項目蒙受 損失。為確保盡早解決或降低項目中的風(fēng)險， 應(yīng)以遞增的方式開發(fā)系 統(tǒng)。要慎重

55、選擇需求，以確保每次增加都能緩解項目中的已知風(fēng)險。 要達(dá)到目的，您需要和項目的涉眾協(xié)商每次迭代的范圍。通常，這要求具備管理項目各個階段的期望結(jié)果的良好技能除了控制開發(fā)過程本身， 您還需控制需求的來源， 并控制項目可 交付工件的外觀。 改進(jìn)系統(tǒng)定義 系統(tǒng)的詳細(xì)定義應(yīng)能讓涉眾理解， 同意并認(rèn)可。 它不僅需要具備所有功能， 而且應(yīng)符合法律或法規(guī)上的 要求，符合可用性，可靠性，性能，可支持性和可維護(hù)性。感覺構(gòu)建 過程復(fù)雜的系統(tǒng)就應(yīng)該有復(fù)雜的定義， 這是一種常見的錯誤看法。 這 會給解釋項目和系統(tǒng)的目的造成困難。 人們可能印象深刻， 但他們會 因不甚理解而無法給出建議。應(yīng)該致力于我們認(rèn)為用例方法是傳達(dá)系

56、統(tǒng)目的和定義系統(tǒng)細(xì)節(jié)的一種行之 有效的方法， 它常與簡單的可視化原型結(jié)合使用。 用例有助于為需求 提供一個環(huán)境，利用它可生動地說明系統(tǒng)使用的方式。系統(tǒng)詳細(xì)定義的另一個構(gòu)件是說明系統(tǒng)采用的測試方式。 測試計 劃及要執(zhí)行測試的定義將會說明要核實(shí)哪些系統(tǒng)功能。3.2.2.5 管理需求變更定義需求時無論怎樣謹(jǐn)慎小心， 也總會有可變因素。 變更的需求 之所以變得難以管理， 不僅是因?yàn)橐粋€變更了的需求意味著要花費(fèi)或 多或少的時間來實(shí)現(xiàn)某一個新特性， 而且也因?yàn)閷δ硞€需求的變更很 可能影響到其他需求。 應(yīng)確保賦予需求一個有彈性的結(jié)構(gòu)， 使它能適 應(yīng)變更，并且確保使用可追蹤性鏈接可以表達(dá)需求與開發(fā)生命周期的

57、其他工件之間的依賴關(guān)系。 管理變更包括建立基線， 確定需要追蹤的 重要依賴關(guān)系， 建立相關(guān)項之間的可追蹤性， 以及變更控制等活動。3.2.3 需求管理的原則與實(shí)現(xiàn)我們將需求工程分為需求開發(fā)和需求管理。 需求開發(fā)包括對一個 軟件項目需求的獲取、分析、規(guī)格說明及驗(yàn)證。典型需求開發(fā)的結(jié)果 應(yīng)該有項目視圖和范圍文檔、 用例文檔、 軟件需求規(guī)格說明及相關(guān)分 析模型。經(jīng)評審批準(zhǔn)，這些文檔就定義了開發(fā)工作的需求基線。這個 基線在客戶和開發(fā)人員之間就構(gòu)筑了計劃產(chǎn)品功能需求和非功能需 求的一個約定。工程項目可能會有其它的約定，例如可交付性、約束 條件、進(jìn)度安排、預(yù)算及合同約定等。但這些均超出了本書范圍。需求約定

58、是需求開發(fā)和需求管理之間的橋梁， 需求管理包括在工 程進(jìn)展過程中維持需求約定集成性和精確性的所有活動， 如下圖所示 需求管理強(qiáng)調(diào)：控制對需求基線的變動。保持項目計劃與需求一致。 控制單個需求和需求文檔的版本情況。 管理需求和聯(lián)系鏈之間的聯(lián)系或管理單個需求和其它項目可交 付品之間的依賴關(guān)系。跟蹤基線中需求的狀態(tài)。323.1 需求管理和過程能力成熟度模型過程能力成熟度模型對需求管理是一個有用的指導(dǎo)。位于賓夕法尼亞洲匹茲堡市的卡內(nèi)基梅隆大學(xué)所屬的軟件工程研究所提出了軟 件過程能力成熟度模型的概念。是在軟件開發(fā)機(jī)構(gòu)中被廣泛地用來指 導(dǎo)過程改進(jìn)工作的模型。該方法描述了軟件處理能力的五個成熟級別。 處于一級的組織典型地以非正式的方式管理項目進(jìn)度，要獲得成功， 主要依靠天才從業(yè)者和管理者的英雄史詩般的奮斗。處于更高成熟度 級別的組織把具有