軟件過程規(guī)范示例

1、編者說明:軟件過程管理中的一個很重要的工作就是制定項目、組織的過程規(guī)范，它是軟件開發(fā)組織行動的準則 與指南。該文檔就是一個實際的過程規(guī)范的實例，通過該實例，相信對大家根據(jù)自身情況制定符合要求的 項目過程規(guī)范、組織過程規(guī)范有很好的借鑒作用。1 .總則最大限度提高Q&P（質(zhì)量與生產(chǎn)率），提高 Q&P的可預見性，是每一個軟件開發(fā)機構的最大目標。而Q&P依賴于三個因素：過程、人和技術，因此要實現(xiàn)Q&P的提高，除了加強技術能力，引進、培育更多優(yōu)質(zhì)技術人才之外，規(guī)范、改進機構的過程是一個十分重要的手段。我們希望通過在制定軟件過程規(guī)范標準，并 在軟件開發(fā)實踐中不斷地完善、修訂

2、，提高Q&評口 Q&P的可預見性。本規(guī)范采用CMM（軟件過程成熟度模型）的指導，吸收 RUP XP、MSF PSR TSP等過程規(guī)范指南的思想、 方法及實踐，充分結合 xxx技術開發(fā)部的實際情況，引入先進的技術、方法、工具，為公司的軟件開發(fā)工 作提供一部詳細、可操作的過程指南。在本規(guī)范的第一版本中，主要包括管理過程和開發(fā)過程兩個部分， 管理過程中包括項目管理過程、需求變更管理過程、配置管理過程。對于軟件開發(fā)項目中的其它的一些過 程將在實踐中逐步補充、完善。2 .項目管理過程規(guī)范項目管理過程主要包括三個階段：項目立項與計劃、項目實施、項目關閉。2.1 項目立項與計劃參與人員：技術

3、開發(fā)部指定的項目負責人（包括前期負責人、正式的項目經(jīng)理）、立項申請人、相關最終客戶以及實施該項目的開發(fā)組隊成員；入口準則：接到經(jīng)公司總經(jīng)理或副總經(jīng)理批準的市場部門的軟件開發(fā)立項申請表；出口準則：立項申請人簽字確認了經(jīng)修訂正后的正式軟件項目計劃，并通過工作任務卡下達了開發(fā)任務，開發(fā)工作正式開始；輸入：經(jīng)審批的軟件開發(fā)立項申請表、與需求相關的業(yè)務資料；輸出：軟件項目計劃、軟件需求規(guī)格說明書、開發(fā)任務卡；活動：接到軟件開發(fā)立項申請表后，技術開發(fā)部經(jīng)理指定前期負責人，并告知立項申請人；前期負責人閱讀軟件開發(fā)立項申請表后，通過與立項申請人的溝通、閱讀立項申請人提交的材料、通 過立項申請人與客戶直接交流等

4、方式，了解項目目標、范圍與基本需求；并形成最初的軟件需求規(guī)格說 明書；前期負責人會同技術開發(fā)部經(jīng)理以及其它相關人員，制定最初的軟件項目計劃，并組織評審；向立項申請人提交最初的軟件項目計劃；最初的軟件項目計劃通過立項申請人的確認后，項目經(jīng)理計劃安排需求分析；需求分析完成后，形成正式的軟件需求說明書，提交立項申請人確認；（需求分析過程參見開發(fā)過程 規(guī)范部分）根據(jù)立項申請人確認后的 軟件需求說明書，項目經(jīng)理組織進行軟件高層設計，并對工作任務進行分解，并根據(jù)實際需要向技術開發(fā)部經(jīng)理申請資源，組建項目組隊；項目經(jīng)理根據(jù)工作任務分解，下發(fā)工作任務卡，并協(xié)同組隊成員進行任務估算；注：工作任務包括模塊開發(fā)任務

5、、其它任務（如安裝）；模塊開發(fā)任務主要包括：詳細設計、編碼和單元 測試任務估算完成后，組隊成員向項目經(jīng)理提交個人進度安排（以甘特圖的形式表示），項目經(jīng)理根據(jù)每個組隊成員的個人進度安排修訂軟件項目計劃（必須包括總的計劃甘特圖），并提交立項申請人確認；立項申請人確定后，項目經(jīng)理根據(jù)軟件項目計劃基線，補充工作任務卡，下發(fā)到每個組隊成員，開發(fā) 工作開始。項目立項與計劃過程的工作流程如下圖所示：圖表1項目立項與計劃工作流程圖相關模板：軟件需求規(guī)格說明書、軟件項目計劃、工作任務卡說明：如果計劃確認、需求確認未通過，立項申請人與項目經(jīng)理進行協(xié)商，進行修正，無法達成共識的，提交部門經(jīng)理、總經(jīng)理協(xié)調(diào)；2.2 項

6、目實施參與人員：項目經(jīng)理，項目組成員；入口準則：項目計劃基線已建立，并通過立項申請人確定，帶有工作進度要求的工作任務卡已下發(fā)到每個項目成員；出口準則：立項申請人在驗收報告上簽字確認；輸入：軟件需求規(guī)格說明書、軟件項目計劃、工作任務卡；輸出：經(jīng)驗收測試的可交付的程序、源代碼及相關文檔?；顒樱涸陂_發(fā)期間，項目成員每周需上交一份 時間日志、缺陷日志，每天向項目經(jīng)理匯報工作任務進度； 在開發(fā)期間，項目經(jīng)理負責填寫項目進度周報報于技術開發(fā)部經(jīng)理、立項申請人（格式不同，交予立 項申請人的只需周報的第一頁，報予技術開發(fā)部經(jīng)理的項目進度周報的第二頁為“跟蹤甘特圖”）；項目經(jīng)理必須根據(jù)實際的進度情況，及時調(diào)整項

7、目計劃，若發(fā)現(xiàn)進度延誤，需采取措施。相關模板：軟件項目計劃、開發(fā)任務卡、時間日志、缺陷日志、項目進度周報2.3 項目關閉參與人員：技術開發(fā)部經(jīng)理或經(jīng)理助理、項目經(jīng)理，項目組成員、立項申請人、相關客戶、公司總經(jīng)理、公司副總經(jīng)理;入口準則：立項申請人在驗收報告上確認；出口準則：形成項目總結，完成項目績效考核，項目數(shù)據(jù)存入“過程數(shù)據(jù)庫”；輸入：時間日志、缺陷日志、項目開發(fā)計劃；輸出：項目總結、已完成的項目績效考核表、過程數(shù)據(jù)庫中的該項目記錄；活動：項目經(jīng)理主持召開項目總結會，交流項目實施過程中的心得體會，對項目實施中的成功處、不足處進行總結，并由項目經(jīng)理形成項目總結；由技術開發(fā)部經(jīng)理組織對該項目進行

8、績效考核，并填寫相應的項目績效考核表；項目經(jīng)理組織所有成員對項目過程中的文檔、源程序等資料進行整理、歸檔；由項目經(jīng)理根據(jù)過程數(shù)據(jù)庫的需要，整理相應的數(shù)據(jù)，提交技術開發(fā)部經(jīng)理，存入過程數(shù)據(jù)庫。相關模板：項目總結、項目績效考核表3 .開發(fā)過程規(guī)范開發(fā)過程是提煉用戶需求，設計、構建和測試滿足這些需求的軟件并最終將其交付給客戶的過程。是軟件 過程中的主體過程之一。當開發(fā)新的應用或計劃為現(xiàn)有的應用進行重要的增強時，需使用本規(guī)范所定義的 開發(fā)過程執(zhí)行。項目管理過程是對開發(fā)過程進行計劃、監(jiān)控/管理、總結的輔助過程，但由于項目管理是保證進度、質(zhì)量的重要手段，因此在軟件項目中也是十分重要的過程之一。而需求管理過

9、程與配置管理過程則是次重要的輔 助過程，需求管理過程是一個需求變更管理的過程，以對變更進行統(tǒng)一的管理；配置管理過程的最重要工 作就是版本控制，使得開發(fā)過程中的各種交付物能夠有機地形成一個個整體。因此以上四個過程是交織進行的，均是為成功完成軟件項目的保障過程。3.1 過程總述現(xiàn)在比較通行的開發(fā)過程模型包括：瀑布模型、演化模型、原型模型、螺旋模型等。根據(jù)公司的項目特點、隊伍規(guī)模、組隊情況等實際因素，決定選擇最為簡單、易于掌握的瀑布模型為基礎，根據(jù)公司特點，進行 合理的修改，使其成為公司本階段的軟件開發(fā)過程。正如下圖所示，本規(guī)范將整個開發(fā)過程分為：需求分析、高層設計、詳細設計、編碼和單元測試、集成計

10、 劃與測試、系統(tǒng)測試、驗收測試與安裝、維護等八個階段。圖表2 開發(fā)過程總圖注：SRS軟件需求規(guī)格 HLD :高層設計DD :詳細設計SRC :代碼 UT Plan :單元測試計劃注：“歸檔”在配置管理過程統(tǒng)一說明。3.2 需求分析階段需求分析的主要目的是生成一個正確說明客戶所有需求的文檔。換言之，軟件需求規(guī)格（SoftwareRequirement Specification , SRS文檔是該階段的主要輸出。正確的需求分析和確定需求規(guī)格對一個項 目的成功是非常關鍵的。許多在系統(tǒng)和驗收測試時發(fā)現(xiàn)的缺陷是在需求階段產(chǎn)生的。在驗收階段去掉需求 階段產(chǎn)生的一個錯誤將比在需求階段本身去掉該錯誤要多花1

11、00多倍的費用。很明顯，在執(zhí)行這階段時，正確地生成具有最少缺陷的 SRS是非常必要的。參與人員：項目經(jīng)理，分析員,立項申請人，客戶，最終用戶;入口準則：項目立項，最初的項目計劃已得到立項申請人的確認。注：這里所說明的需求分析階段是進行開發(fā)過程的需求分析階段，在技術開發(fā)部出具初步的項目計劃之前 的需求溝通工作，不是該過程規(guī)范所定義的。最初的需求溝通工作可以參考本過程規(guī)范。出口準則：立項申t#人、客戶在軟件需求規(guī)格說明書上簽字確認;輸入：項目立項申請表、最初的項目計劃，需求相關的資料；輸出：經(jīng)確認的軟件需求規(guī)格說明書；活動：整個需求分析過程主要包括以下幾個步驟： 圖表3需求分析階段活動總圖首先，項

12、目經(jīng)理與分析員一塊，做好需求分析的準備，包括閱讀相關的背景資料，熟悉客戶的實際情況，準備用戶訪談計劃，準備會談問題清單等；然后通過面談、專題討論會等形式與客戶進行溝通，采集需求的詳細內(nèi)容，澄清每一個需求點；從而界定 出系統(tǒng)的目標和范圍；對所采集和澄清的需求進行分析，構建需求模型，從功能性、非功能性兩個方面進行需求分析，深入領會 客戶需求；形成軟件需求規(guī)格說明書，建立軟件需求基線，并為軟件需求評審做好準備；由項目經(jīng)理安排軟件需求評審，協(xié)同立項申請人、客戶進行需求評審；立項申請人或客戶在軟件需求規(guī)格說明書上確認。相關模板：軟件需求規(guī)格說明書3.3 高層設計階段高層設計是軟件開發(fā)過程中的一個重要階段

13、，在這個階段將從計算機實現(xiàn)的邏輯角度開發(fā)針對用戶需求的解決方案。這一解決方案是一個高級的抽象方案。高層設計要設計出各主要部分，并說明他們在技術上如何工作：1）相互間的協(xié)作；2）所需外在的硬件和軟件環(huán)境；3）內(nèi)在環(huán)境。也就是說，高層設計確定了組成產(chǎn)品的構件，定義了每個構件的功能任務，并且定義了構件間的接口及構件到運行環(huán)境的外部接口。參與人員：項目經(jīng)理，項目組員（設計團隊）；入口準則：軟件需求規(guī)格說明書已通過立項申請人的確認；出口準則：形成高層設計，實現(xiàn)任務分解，所有的問題得到解決；輸入：軟件需求說明書輸出：高層設計說明書（功能與數(shù)據(jù)庫設計）、詳細設計、編碼、文檔和用戶接口標準；活動：制定詳細設計

14、、編碼、文檔和用戶接口的標準；根據(jù)項目特點選擇運行的目標平臺和開發(fā)工具；制定軟件的體系結構，定義邏輯和物理的對象模型，包括確定類、類的屬性、類方法、類之間的關系和對象間的動態(tài)交互。若采用結構化設計，則該活動應為功能設計；從需求規(guī)格說明書中的數(shù)據(jù)模型中得到物理數(shù)據(jù)庫結構，進行物理數(shù)據(jù)庫設計：包括確定表/記錄類型、域和其他部分。生成高層設計說明書，并組織設計評審。相關模板：高層設計說明書3.4 詳細設計階段 在詳細設計階段，高層設計階段開發(fā)出的整體應用被分成幾個模塊（或構件）和程序。為每個程序（或構 件）進行邏輯設計，然后歸檔作為程序規(guī)格，同時為每個程序（或構件）生成一個單元測試計劃。詳細設 計階

15、段的重要活動包括通用例程和程序的確定、框架程序的開發(fā)以及用于提高生產(chǎn)率的實用程序和工具的 開發(fā)。在詳細設計階段負責每個程序、模塊（或構件）的內(nèi)部設計，確定其程序流程，并且可以通過使用設計語 言、圖形流程圖（如活動圖、狀態(tài)圖）等，或通過簡單地寫敘述而將設計文檔化。參與人員：每個模塊（或構件）的任務承擔人；入口準則：高層設計說明書已通過評審；出口準則：完成詳細設計，所有的問題得到解決，詳細設計與單元測試計劃文檔化；輸入：軟件需求規(guī)格說明書、高層設計說明書、詳細設計標準輸出：詳細設計說明書、單元測試計劃活動：將高層設計中的每個程序（或構件）細分成小的組件；對每個小組件進行詳細設計，包括確定調(diào)用方法、

16、輸入和輸出、程序邏輯、數(shù)據(jù)結構等；根據(jù)組件的邏輯，制定單元測試計劃，包括確定單元測試環(huán)境、測試用例、測試數(shù)據(jù)等；向項目經(jīng)理（或高層設計者）提交詳細設計與單元測試計劃；相關模板：詳細設計說明書、單元測試計劃剪裁說明：對一些小項目，詳細設計階段的活動1、2可以省略。3.5 編碼和單元測試在編碼子階段，根據(jù)詳細設計用編程語言編寫所需的程序。這個階段根據(jù)合適的編碼規(guī)范產(chǎn)生源代碼、可 執(zhí)行代碼以及數(shù)據(jù)庫（如果使用了數(shù)據(jù)庫）。這個階段的輸出是隨后測試和驗證的主體。而單元測試子階 段則是根據(jù)詳細設計階段所制定出來的單元測試計劃進行測試，驗證每一個組件正確、可用。參與人員：每個模塊（或構件）的任務承擔人；入口

17、準則：詳細設計說明書已通過批準，編碼規(guī)范已建立；出口準則：成功執(zhí)行所有單元測試計劃中的測試用例；輸入：軟件需求規(guī)格說明書、高層設計說明書、詳細設計說明書、單元測試計劃編碼、 用戶接口標準；輸出：測試數(shù)據(jù)、源代碼、可執(zhí)行代碼、單元測試報告活動：根據(jù)詳細設計，按照編碼、用戶接口規(guī)范編寫程序；對程序進行代碼復查、編譯、調(diào)試，直到程序運行通過，符合詳細設計的要求；根據(jù)單元測試計劃進行單元測試，生成單元測試報告。相關模板：單元測試報告3.6 集成計劃與測試集成是把設計階段制定的，已通過單元測試的模塊構建成一個完整軟件結構的系統(tǒng)方法。可采用很多方式 進行集成，集成計劃必須指定模塊集成的順序。在該階段，同時

18、進行測試，以發(fā)現(xiàn)與接口相關的缺陷。集 成按照集成計劃中制定的順序進行，并執(zhí)行每個集成階段的相應測試用例。集成計劃描述了集成順序、額 外需要的軟件、測試環(huán)境和資源需求。集成計劃與集成測試計劃通常一起完成。參與人員：項目經(jīng)理，集成團隊；入口準則：經(jīng)批準的高層設計說明書；出口準則：集成計劃和集成測試計劃經(jīng)過評審和授權；輸入：高層設計說明書、源程序輸出：集成計劃、集成測試計劃活動：確定集成所需的環(huán)境，包括硬件的物理特性、通信和系統(tǒng)軟件、使用模式等； 決定集成規(guī)程，確定將要集成的關鍵模塊，集成的順序，需要測試的接口等； 開發(fā)集成測試計劃，確定測試用例和執(zhí)行用例的規(guī)程，確定測試數(shù)據(jù)，確定期望輸出等。 相關

19、模板：集成計劃、集成測試計劃剪裁說明：對一些小項目，集成計劃與測試階段可以省略。3.7 系統(tǒng)測試系統(tǒng)測試是依據(jù)需求規(guī)格驗證軟件產(chǎn)品有效性的活動。這個階段是為了發(fā)現(xiàn)那些只有通過測試整個系統(tǒng)才 能暴露的缺陷。就像外部接口、性能、安全、配置敏感性、共存、恢復以及可靠性等屬性只有在這個階段 才能判斷其是否有效。可以使用具有不同測試目的的一系列測試來驗證所有系統(tǒng)元素都已經(jīng)正確地集成， 系統(tǒng)能夠執(zhí)行所有功能并滿足所有非功能需求。系統(tǒng)測試開始之前，必須在系統(tǒng)測試計劃階段詳細地制定 計劃。系統(tǒng)測試計劃工作從需求分析結束后就可以開始，一直到編碼時結束。參與人員：項目經(jīng)理，系統(tǒng)測試團隊；入口準則：經(jīng)確認的軟件需求

20、規(guī)格說明書和經(jīng)批準的高層設計說明書；出口準則：系統(tǒng)測試計劃經(jīng)過評審和授權，成功執(zhí)行所有系統(tǒng)測試計劃中的測試用例；輸入：軟件需求規(guī)格說明書、高層設計說明書輸出：系統(tǒng)測試計劃、系統(tǒng)測試報告活動：決定所需的測試環(huán)境；決定系統(tǒng)測試的規(guī)程，包括：確定測試特性，如用戶接口、軟硬件接口、通信接口、主要業(yè)務過程；確定 不需要測試的重要特性以及不測試的原因；確定關鍵測試；開發(fā)測試用例，包括確定每個測試用例以及執(zhí)行它的規(guī)程，確定每個輸入、輸出數(shù)據(jù)的要求，確定預期的 結果。相關模板：系統(tǒng)測試計劃、系統(tǒng)測試報告剪裁說明：對一些小項目，系統(tǒng)測試階段可以省略，直接準備驗收測試，在驗收測試之前，開發(fā)組隊按驗 收測試計劃做一

21、次沒有立項申請人、客戶參加的預測試。3.8 驗收測試與安裝驗收測試和安裝階段的主要任務是將軟件產(chǎn)品集成到它的操作環(huán)境中，并在這個環(huán)境中經(jīng)受測試，以確保 它按需求執(zhí)行。這個階段包括兩個基本任務：使軟件得以驗收和客戶處安裝軟件。驗收指的是由立項申請 人、客戶根據(jù)早期準備的驗收報告而進行正式的測試，并對測試結果進行分析，以確定系統(tǒng)是否滿 足驗收準則。當分析結果滿足驗收測試時，用戶接受軟件。安裝指的是把接受的軟件置于實際產(chǎn)品環(huán)境中。注：驗收報告應附有驗收測試計劃參與人員：項目經(jīng)理，安裝團隊、立項申請人、客戶;入口準則：成功地完成了系統(tǒng)測試（或成功地完成了驗收預測試）；出口準則：立項申請人或客戶在驗收報

22、告上簽署確認意見；輸入：軟件需求說明書、測試后的軟件和驗收報告輸出：簽署了確認意見的驗收報告和安裝后的軟件；活動：根據(jù)軟件需求說明書，編寫驗收報告；與立項申請人、客戶一起按驗收報告執(zhí)行驗收測試，包括：在驗收環(huán)境下安裝軟件、 進行實況運行、 協(xié)助客戶進行驗收測試、改正驗收缺陷、更新文檔以反映所有變更、獲得客戶的驗收確認；執(zhí)行安裝，包括：在產(chǎn)品環(huán)境下安裝軟件、搭建產(chǎn)品環(huán)境、載入軟件和數(shù)據(jù)、進行實況運行、修改安裝缺 陷、執(zhí)行用戶培訓。相關模板：驗收報告3.9 維護維護支持階段是指已安裝的應用得到支持，直至其在生產(chǎn)環(huán)境中穩(wěn)定運行的階段。參與人員：項目經(jīng)理，系統(tǒng)安裝人員；入口準則：軟件在生產(chǎn)中運行；出口

23、準則：合同中指定的維護支持階段終止；輸入：安裝后的應用、用戶文檔和軟件維護申請表；4 .需求變更管理過程規(guī)范需求變更，這是個永恒的真理。需求變更的一個重要原因是系統(tǒng)周圍的世界在變化，從而要求系統(tǒng)適應這個變化。在項目生命周期的任何時候或者項目結束之后都可以有需求變更。與其希望變更不會來臨，不如 希望初始的需求在某種程度上做得很好而使得沒有變更需求，最好是項目準備時想到對付這些變更，以防變更真的到來。不管做多少準備和計劃都不可能阻止變更，說項目在需求凍結后再開始不過是個神話罷了。4.1 過程總述需求變更管理過程定義了一系列活動，當有新的需求或?qū)ΜF(xiàn)有需求進行變更（我們可以稱它們都是需求變 更）時就會

24、執(zhí)行這些活動。需求變更可以在項目執(zhí)行的任何一個點上發(fā)生。需求變更會影響項目進度，甚 至會影響已經(jīng)生產(chǎn)出來的產(chǎn)品。越是在生命周期后期的需求變更，對項目的影響越嚴重。不可控的需求變 更導致對成本、進度以及項目質(zhì)量的負面影響，這些極可能嚴重危害項目成功的概念。需求變更管理過程用來控制需求變更并減少他們對項目的影響。這個目標需要理解需求變更請求的隱含意義，以及變更帶來的總影響。同樣，也需要立項申請人、客戶意識到變更對項目影響的后果，使得可以友好地將變更反映到協(xié)商好的條款中。需求變更管理過程，從某種程序上說，試圖保證在需求變更影響下 項目依然可以成功。需求變更管理有兩個方面，一方面與立項申請人、客戶就怎

25、樣處理變更達成一致，一方面是實際進行變更的過程。處理變更的整體方法必須與立項申請人、客戶達成一致。一般來說，它制定怎樣進行變更請求，當需要正式的批準時，為處理變更估計留出冗余空間等等。在整個方法的背景下，當需求變更到來時，需要執(zhí)行需求變更管理過程。4.2 過程規(guī)范參與人員：項目經(jīng)理，立項申請人、客戶、開發(fā)團隊；注：項目經(jīng)理對將變更納入項目中所需的過程執(zhí)行負主要責任。立項申請人、客戶以及開發(fā)隊伍也需要 參與這個過程。入口準則：收到立項申請人提交的需求變更請求單出口準則：變更已列入新的軟件需求說明書，并體現(xiàn)在新的軟件項目計劃中；輸入：需求變更請求單輸出：根據(jù)需求變更請求單，在充分協(xié)商與的基礎上，提

26、交新的軟件需求說明書，并提交軟件 項目計劃變更表；活動：記錄需求變更請求，記錄項中應包括變更請求數(shù)、變更的簡要描述、變更的影響、變更請求的狀態(tài)和關鍵 數(shù)據(jù)；分析變更請求對工作的影響；估計變更請求需要的工作量；修改項目計劃，重新估計交付時間；對總的成本花費的影響進行估計；將修改過的項目計劃提交立項申請人，并獲得確認。相關模板：項目計劃變更表5 .配置管理過程規(guī)范軟件項目在其執(zhí)行過程會產(chǎn)生大量的工件，包括各種文檔、程序、數(shù)據(jù)和手冊。所有這些工件都是易于改 變的。這是軟件一個獨有的特點。正如“需求變更管理”章節(jié)中所述，在軟件項目中，在項目執(zhí)行過程中 的任何時候，需求本身都會發(fā)生變更。為避免項目在變更

27、時失控，正確控制和管理變更是很必要的。配置 管理（Configuration Management , CM又稱為軟件配置管理，是項目管理中專用于關注系統(tǒng)地控制項目 進行中發(fā)生的變更的那些部分，由用來識別機構軟件產(chǎn)品并控制其修改的一系統(tǒng)活動構成。配置管理需要滿足項目基本目標之一：為客戶提交高質(zhì)量的軟件產(chǎn)品。這個提交的產(chǎn)品，包括各種資源以 及構成資源或目標代碼的目標文件，還包括以這些文件來構建工作系統(tǒng)的腳本以及相關文檔。在項目中， 資源和文檔通常以很多獨立文件的方式來維護。當項目進展時，文件發(fā)生了改變，產(chǎn)生了不同的版本。在種情況下，即使將項目的各部分組合起來，構建 成系統(tǒng)，也是很困難的任務，怎樣

28、保證合并的是源程序的正確版本以及沒有遺漏任何源程序？還有，怎樣 保證傳送的文檔的版本是正確的，該版本和最終交付的軟件是一致？對于這類型的情況，必須正確跟蹤軟 件開發(fā)過程中的各種中間產(chǎn)品、其版本以及軟件產(chǎn)品的版本。沒有這些信息，交付最終系統(tǒng)就成為繁重的 任務。這個活動不是由開發(fā)過程完成的，而需要一個獨立的過程，那就是配置管理過程。5.1 配置管理的目標配置管理過程，需要達到以下目標：能夠隨時給出程序的最新版本；能夠處理并發(fā)的文檔、程序的更新/修改請求；能夠根據(jù)需要撤消程序的修改；能夠有效防止未授權的程序員對文檔、程序進行變更或刪除；能夠有效地顯示變更的情況。5.2 配置管理過程規(guī)范配置管理過程包

29、括兩個主要階段：配置管理計劃、實施配置管理。5.2.1 配置管理計劃參與人員：項目經(jīng)理，配置管理團隊；入口準則：軟件需求規(guī)格說明書已經(jīng)確認；出口準則：完成項目配置管理計劃；輸入：軟件需求規(guī)格說明書輸出：配置管理計劃活動：識別配置項，配置項的典型例子包括需求規(guī)格、設計文檔、源代碼、測試計劃、測試腳本、測試規(guī)程、測試數(shù)據(jù)、項目使用的編碼、用戶接口規(guī)范、驗收報告等；定義為配置項命名和編號的計劃：如果使用CM工具，那么有時由工具處理版本編號，否則，在項目中必須明確地進行版本編號；定義CM所需的目錄結構；定義訪問控制；定義變更控制規(guī)程；確定CM工作人員的責任和權利；定義跟蹤配置項狀態(tài)的方法；定義備份制度

30、定義發(fā)布制度；確定將配置項轉移到基線的原則。相關模板：軟件配置管理計劃5.2.2 實施配置管理參與人員：項目經(jīng)理，配置管理團隊、開發(fā)項目組隊成員；入口準則：軟件配置管理計劃已批準，項目開始；出口準則：項目結束；輸入：軟件配置管理計劃活動：接受變更請求；Check out需要變更、修改的配置項，并進行修改；Check in變更、修改過的配置項。6 .附件附件包括各種文檔模板與工作指南。所有附件以單獨的文檔形式存儲，文檔名為xxxx模板、xxxx工作指南。具體包括：6.1 文檔模板6.1.1 項目管理類軟件項目計劃模板、工作任務卡模板、時間日志模板、缺陷日志模板、項目進度周報 模板、項目總結模板、項目績效考核表模板、項目計劃變更表模板、軟件配置管理計劃6.1.2 開發(fā)過程類軟件需求規(guī)格說明書模板、高層設計說明書模板、詳細設計說明書模板、單元測試計劃模 板、單元測試報告模板、集成計劃模板、集成測試計劃模板、集成測試報告模板、系 統(tǒng)測試計劃模板、系統(tǒng)測試報告模板、驗收測試報告模板。6.2 工作指南軟件需求分析工作指南