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

2、可預見性。本規范采用CMM （軟件過程成熟度模型）的指導 ，吸收RUP、XP、MSF、PSP、TSP 等過程規范指南的思想、 方法及實踐，充分結合xxx技術開發部的實際情況，引入先進的技術、方法、工具，為公司的軟件開發工作提供一部詳細、可操作的過程指南。在本規范的第 一版本中，主要包括管理過程和開發過程兩個部分，管理過程中包括項目管理過程、需求變更管理過程、配置管理過程。對于軟件開發項目中的其它的一些過程將在實踐中逐步補充、完善完善。2項目管理過程規范項目管理過程是對軟件項目過程進行計劃、監控/管理、總結的輔助過程，包括需求、配置、成本、進度、質量和風險等的管理。項目管理過程主要包括三個階段：

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

4、過與立項申請人的溝通、閱讀立項申請 人提交的材料、通過立項申請人與客戶直接交流等方式，了解項目目標、范圍與基本需求； 并形成最初的軟件需求規格說明書；前期負責人會同技術開發部經理以及其它相關人員，制定最初的軟件項目計劃，并組織評審；向立項申請人提交最初的軟件項目計劃；最初的軟件項目計劃通過立項申請人的確認后，項目經理計劃安排需求分析；需求分析完成后，形成正式的 軟件需求說明書，提交立項申請人確認；（需求分析過程參見開發過程規范部分）根據立項申請人確認后的 軟件需求說明書， 項目經理組織進行軟件高層設計，并對 工作任務進行分解，并根據實際需要向技術開發部經理申請資源，組建項目組隊；項目經理根據工

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

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

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

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

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

10、、集成計劃與測試、系統測試、驗收測試與安裝、維護等八個階段。3.2需求分析階段需求分析的主要目的是生成一個正確說明客戶所有需求的文檔。換言之，軟件需求規格（Software Requirement Specification， SRS文檔是該階段的主要輸出。正確的需求分析和確定需求規格對一個項目的成功是非常關鍵的。許多在系統和驗收測試時發現的缺陷是在需求階段產生的。在驗收階段去掉需求階段產生的一個錯誤將比在需求階段本身去掉該錯誤要多花100多倍的費用。很明顯，在執行這階段時，正確地生成具有最少缺陷的SRS是非常必要的。參與人員：項目經理，分析員，立項申請人，客戶，最終用戶;入口準則：項目立項，

11、最初的項目計劃已得到立項申請人的確認。注：這里所說明的需求分析階段是進行開發過程的需求分析階段，在技術開發部出具初 步的項目計劃之前的需求溝通工作，不是該過程規范所定義的。最初的需求溝通工作可以參 考本過程規范。出口準則：立項申請人、客戶在軟件需求規格說明書上簽字確認；輸入：項目立項申請表、最初的項目計劃，需求相關的資料；輸出：經確認的軟件需求規格說明書；活動：整個需求分析過程主要包括以下幾個步驟：首先，項目經理與分析員一塊， 做好需求分析的準備，包括閱讀相關的背景資料，熟悉客戶的實際情況，準備用戶訪談計劃，準備會談問題清單等；然后通過面談、專題討論會等形式與客戶進行溝通，采集需求的詳細內容，

12、 澄清每一個需求點；從而界定出系統的目標和范圍；對所采集和澄清的需求進行分析，構建需求模型，從功能性、非功能性兩個方面進行需求分析，深入領會客戶需求；形成軟件需求規格說明書，建立軟件需求基線，并為軟件需求評審做好準備；由項目經理安排軟件需求評審，協同立項申請人、客戶進行需求評審；立項申請人或客戶在軟件需求規格說明書上確認。相關模板：軟件需求規格說明書3.3高層設計階段高層設計是軟件開發過程中的一個重要階段，在這個階段將從計算機實現的邏輯角度開發針對用戶需求的解決方案。這一解決方案是一個高級的抽象方案。高層設計要設計出各主要部分，并說明他們在技術上如何工作：1）相互間的協作；2）所需外在的硬件和

13、軟件環 境；3）內在環境。也就是說，高層設計確定了組成產品的構件，定義了每個構件的功能任 務，并且定義了構件間的接口及構件到運行環境的外部接口。參與人員：項目經理，項目組員（設計團隊）；入口準則：軟件需求規格說明書已通過立項申請人的確認；出口準則：形成高層設計，實現任務分解，所有的問題得到解決；輸入：軟件需求說明書輸出：高層設計說明書（功能與數據庫設計）、詳細設計、編碼、文檔和用戶接口標準；活動：制定詳細設計、編碼、文檔和用戶接口的標準；根據項目特點選擇運行的目標平臺和開發工具；制定軟件的體系結構，定義邏輯和物理的對象模型，包括確定類、類的屬性、類方法、 類之間的關系和對象間的動態交互。若采用

14、結構化設計，則該活動應為功能設計；從需求規格說明書中的數據模型中得到物理數據庫結構，進行物理數據庫設計： 包括確定表/記錄類型、域和其他部分。生成高層設計說明書，并組織設計評審。相關模板：高層設計說明書3.4詳細設計階段在詳細設計階段，高層設計階段開發出的整體應用被分成幾個模塊（或構件）和程序。為每個程序（或構件）進行邏輯設計，然后歸檔作為程序規格，同時為每個程序（或構件）生成一個單元測試計劃。詳細設計階段的重要活動包括通用例程和程序的確定、框架程序的開發以及用于提高生產率的實用程序和工具的開發。在詳細設計階段負責每個程序、模塊（或構件）的內部設計，確定其程序流程，并且可 以通過使用設計語言、

15、圖形流程圖（如活動圖、狀態圖）等，或通過簡單地寫敘述而將設計 文檔化。參與人員：每個模塊（或構件）的任務承擔人；入口準則：高層設計說明書已通過評審；出口準則：完成詳細設計，所有的問題得到解決，詳細設計與單元測試計劃文檔化；輸入：軟件需求規格說明書、高層設計說明書、詳細設計標準輸出：詳細設計說明書、單元測試計劃活動：將高層設計中的每個程序（或構件）細分成小的組件；對每個小組件進行詳細設計， 包括確定調用方法、輸入和輸出、程序邏輯、數據結構等; 根據組件的邏輯，制定單元測試計劃，包括確定單元測試環境、 測試用例、測試數據等; 向項目經理（或高層設計者）提交詳細設計與單元測試計劃；相關模板：詳細設計

16、說明書、單元測試計劃剪裁說明：對一些小項目，詳細設計階段的活動1、2可以省略。3.5編碼和單元測試在編碼子階段，根據詳細設計用編程語言編寫所需的程序。這個階段根據合適的編碼規范產生源代碼、可執行代碼以及數據庫（如果使用了數據庫）。這個階段的輸出是隨后測試和驗證的主體。而單元測試子階段則是根據詳細設計階段所制定出來的單元測試計劃進行測 試，驗證每一個組件正確、可用。參與人員：每個模塊（或構件）的任務承擔人；入口準則：詳細設計說明書已通過批準，編碼規范已建立；出口準則：成功執行所有單元測試計劃中的測試用例；輸入：軟件需求規格說明書、高層設計說明書、詳細設計說明書、單元 測試計劃編碼、用戶接口標準；

17、輸出：測試數據、源代碼、可執行代碼、單元測試報告活動：根據詳細設計，按照編碼、用戶接口規范編寫程序；對程序進行代碼復查、編譯、調試，直到程序運行通過，符合詳細設計的要求；根據單元測試計劃進行單元測試，生成單元測試報告。相關模板：單元測試報告3.6集成計劃與測試集成是把設計階段制定的，已通過單元測試的模塊構建成一個完整軟件結構的系統方法。 可采用很多方式進行集成，集成計劃必須指定模塊集成的順序。在該階段，同時進行測試， 以發現與接口相關的缺陷。 集成按照集成計劃中制定的順序進行，并執行每個集成階段的相應測試用例。集成計劃描述了集成順序、額外需要的軟件、測試環境和資源需求。集成計劃與集成測試計劃通

18、常一起完成。參與人員：項目經理，集成團隊；入口準則：經批準的高層設計說明書；出口準則：集成計劃和集成測試計劃經過評審和授權；輸入：高層設計說明書、源程序輸出：集成計劃、集成測試計劃活動：確定集成所需的環境，包括硬件的物理特性、通信和系統軟件、使用模式等；決定集成規程，確定將要集成的關鍵模塊，集成的順序，需要測試的接口等；開發集成測試計劃，確定測試用例和執行用例的規程，確定測試數據，確定期望輸出等。相關模板：集成計劃、集成測試計劃剪裁說明：對一些小項目，集成計劃與測試階段可以省略。3.7系統測試系統測試是依據需求規格驗證軟件產品有效性的活動。這個階段是為了發現那些只有通過測試整個系統才能暴露的缺

19、陷。就像外部接口、性能、安全、配置敏感性、共存、恢復以 及可靠性等屬性只有在這個階段才能判斷其是否有效。可以使用具有不同測試目的的一系列測試來驗證所有系統元素都已經正確地集成，系統能夠執行所有功能并滿足所有非功能需求。系統測試開始之前，必須在系統測試計劃階段詳細地制定計劃。系統測試計劃工作從需求分析結束后就可以開始，一直到編碼時結束。參與人員：項目經理，系統測試團隊；入口準則：經確認的軟件需求規格說明書和經批準的高層設計說明書；出口準則：系統測試計劃經過評審和授權， 成功執行所有系統測試計劃中的測試用例；輸入：軟件需求規格說明書、高層設計說明書輸出：系統測試計劃、系統測試報告活動：決定所需的測

20、試環境；決定系統測試的規程，包括：確定測試特性，如用戶接口、軟硬件接口、通信接口、主要業務過程；確定不需要測試的重要特性以及不測試的原因；確定關鍵測試；開發測試用例，包括確定每個測試用例以及執行它的規程，確定每個輸入、輸出數據的要求，確定預期的結果。相關模板：系統測試計劃、系統測試報告剪裁說明：對一些小項目，系統測試階段可以省略，直接準備驗收測試，在驗收測試之前，開發組隊按驗收測試計劃做一次沒有立項申請人、客戶參加的預測試。3.8驗收測試與安裝驗收測試和安裝階段的主要任務是將軟件產品集成到它的操作環境中，并在這個環境中經受測試，以確保它按需求執行。 這個階段包括兩個基本任務：使軟件得以驗收和客

21、戶處安裝軟件。驗收指的是由立項申請人、客戶根據早期準備的驗收報告而進行正式的測試， 并對測試結果進行分析， 以確定系統是否滿足驗收準則。當分析結果滿足驗收測試時，用戶接受軟件。安裝指的是把接受的軟件置于實際產品環境中。注：驗收報告應附有驗收測試計劃參與人員：項目經理，安裝團隊、立項申請人、 客戶;入口準則：成功地完成了系統測試（或成功地完成了驗收預測試）；出口準則：立項申請人或客戶在驗收報告上簽署確認意見；輸入：軟件需求說明書、測試后的軟件和驗收報告輸出：簽署了確認意見的驗收報告和安裝后的軟件；活動：根據軟件需求說明書，編寫驗收報告；與立項申請人、客戶一起按驗收報告執行驗收測試，包括：在驗收環

22、境下安裝軟 件、進行實況運行、協助客戶進行驗收測試、改正驗收缺陷、更新文檔以反映所有變更、獲 得客戶的驗收確認；執行安裝，包括：在產品環境下安裝軟件、搭建產品環境、載入軟件和數據、進行實況 運行、修改安裝缺陷、執行用戶培訓。相關模板：驗收報告3.9維護維護支持階段是指已安裝的應用得到支持，直至其在生產環境中穩定運行的階段。參與人員：項目經理，系統安裝人員；入口準則：軟件在生產中運行；出口準則：合同中指定的維護支持階段終止；輸入：安裝后的應用、用戶文檔和軟件維護申請表；4需求變更管理過程規范需求變更，這是個永恒的真理。需求變更的一個重要原因是系統周圍的世界在變化，從而要求系統適應這個變化。 在項

23、目生命周期的任何時候或者項目結束之后都可以有需求變 更。與其希望變更不會來臨，不如希望初始的需求在某種程度上做得很好而使得沒有變更需 求，最好是項目準備時想到對付這些變更，以防變更真的到來。不管做多少準備和計劃都不可能阻止變更，說項目在需求凍結后再開始不過是個神話罷了。4.1過程總述需求變更管理過程定義了一系列活動，當有新的需求或對現有需求進行變更（我們可以稱它們都是需求變更）時就會執行這些活動。需求變更可以在項目執行的任何一個點上發生。 需求變更會影響項目進度， 甚至會影響已經生產出來的產品。越是在生命周期后期的需求變更，對項目的影響越嚴重。不可控的需求變更導致對成本、進度以及項目質量的負面

24、影響， 這些極可能嚴重危害項目成功的概念。需求變更管理過程用來控制需求變更并減少他們對項目的影響。這個目標需要理解需求變更請求的隱含意義，以及變更帶來的總影響。同樣，也需要立項申請人、客戶意識到變更對項目影響的后果，使得可以友好地將變更反映到協商好的條款中。需求變更管理過程， 從某種程序上說，試圖保證在需求變更影響下項目依然可以成功。需求變更管理有兩個方面， 一方面與立項申請人、客戶就怎樣處理變更達成一致，一方面是實際進行變更的過程。 處理變更的整體方法必須與立項申請人、客戶達成一致。一般來說，它制定怎樣進行變更請求，當需要正式的批準時， 為處理變更估計留出冗余空間等等。在整個方法的背景下，當

25、需求變更到來時，需要執行需求變更管理過程。4.2過程規范參與人員：項目經理，立項申請人、客戶、開發團隊；注：項目經理對將變更納入項目中所需的過程執行負主要責任。立項申請人、客戶以及開發隊伍也需要參與這個過程。入口準則：收到立項申請人提交的需求變更請求單出口準則：變更已列入新的軟件需求說明書，并體現在新的軟件項目計劃中；輸入：需求變更請求單輸出：根據需求變更請求單，在充分協商與的基礎上， 提交新的軟件需求說明書， 并提交軟件項目計劃變更表；活動：記錄需求變更請求，記錄項中應包括變更請求數、變更的簡要描述、變更的影響、變更請求的狀態和關鍵數據；分析變更請求對工作的影響；估計變更請求需要的工作量；修

26、改項目計劃，重新估計交付時間；對總的成本花費的影響進行估計；將修改過的項目計劃提交立項申請人，并獲得確認。相關模板：項目計劃變更表5. 配置管理過程規范軟件項目在其執行過程會產生大量的工件，包括各種文檔、程序、數據和手冊。所有 這些工件都是易于改變的。 這是軟件一個獨有的特點。 正如“需求變更管理” 章節中所述， 在軟件項目中， 在項目執行過程中的任何時候， 需求本身都會發生變更。 為避免項目在變更 時失控，正確控制和管理變更是很必要的 。 配置管理( Configuration Management ，CM) 又稱為軟件配置管理，是項目管理中專用于關注系統地控制項目進行中發生的變更的那些 部

27、分，由用來識別機構軟件產品并控制其修改的一系統活動構成 。配置管理需要滿足項目基本目標之一： 為客戶提交高質量的軟件產品。 這個提交的產品， 包括各種資源以及構成資源或目標代碼的目標文件， 還包括以這些文件來構建工作系統的腳 本以及相關文檔。在項目中，資源和文檔通常以很多獨立文件的方式來維護。當項目進展時， 文件發生了改變，產生了不同的版本。在種情況下，即使將項目的各部 分組合起來， 構建成系統， 也是很困難的任務， 怎樣保證合并的是源程序的正確版本以及沒 有遺漏任何源程序？還有， 怎樣保證傳送的文檔的版本是正確的， 該版本和最終交付的軟件 是一致？對于這類型的情況， 必須正確跟蹤軟件開發過程中的各種中間產品、 其版本以及軟 件產品的版本。 沒有這些信息， 交付最終系統就成為繁重的任務。 這個活動不是由開發過程 完成的，而需要一個獨立的過程，那就是配置管理過程。5.1 配置管理的目標配置管理過程，需要達到以下目標：能夠隨時給出程序的最新版本； 能夠處理