編者說明：
軟體過程管理中的乙個很重要的工作就是制定專案、組織的過程規範，它是軟體開發組織行動的準則與指南。該文件就是乙個實際的過程規範的例項，通過該例項，相信對大家根據自身情況制定符合要求的專案過程規範、組織過程規範有很好的借鑑作用。
1.總則
最大限度提高q&p（質量與生產率），提高q&p的可預見性，是每乙個軟體開發機構的最大目標。而q&p依賴於三個因素：過程、人和技術，因此要實現q&p的提高，除了加強技術能力，引進、培育更多優質技術人才之外，規範、改進機構的過程是乙個十分重要的手段。
我們希望通過在制定軟體過程規範標準，並在軟體開發實踐中不斷地完善、修訂，提高q&p和q&p的可預見性。
本規範採用cmm（軟體過程成熟度模型）的指導，吸收rup、xp、msf、psp、tsp等過程規範指南的思想、方法及實踐，充分結合***技術開發部的實際情況，引入先進的技術、方法、工具，為公司的軟體開發工作提供一部詳細、可操作的過程指南。在本規範的第一版本中，主要包括管理過程和開發過程兩個部分，管理過程中包括專案管理過程、需求變更管理過程、配置管理過程。對於軟體開發專案中的其它的一些過程將在實踐中逐步補充、完善。
2.專案管理過程規範
專案管理過程主要包括三個階段：專案立項與計畫、專案實施、專案關閉。
2.1 專案立項與計畫
參與人員：技術開發部指定的專案負責人（包括前期負責人、正式的專案經理）、立項申請人、[相關最終客戶]以及實施該項目的開發組隊成員；
入口準則：接到經公司總經理或副總經理批准的市場部門的《軟體開發立項申請表》；
出口準則：立項申請人簽字確認了經修訂正後的正式《軟體專案計畫》，並通過《工作任務卡》下達了開發任務，開發工作正式開始；
輸入：經審批的《軟體開發立項申請表》、與需求相關的業務資料；
輸出：《軟體專案計畫》、《軟體需求規格說明書》、《開發任務卡》；
活動：接到《軟體開發立項申請表》後，技術開發部經理指定前期負責人，並告知立項申請人；
前期負責人閱讀《軟體開發立項申請表》後，通過與立項申請人的溝通、閱讀立項申請人提交的材料、通過立項申請人與客戶直接交流等方式，了解專案目標、範圍與基本需求；並形成最初的《軟體需求規格說明書》；
前期負責人會同技術開發部經理以及其它相關人員，制定最初的《軟體專案計畫》，並組織評審；
向立項申請人提交最初的《軟體專案計畫》；
最初的《軟體專案計畫》通過立項申請人的確認後，專案經理計畫安排需求分析；
需求分析完成後，形成正式的《軟體需求說明書》，提交立項申請人確認；（需求分析過程參見開發過程規範部分）
根據立項申請人確認後的《軟體需求說明書》，專案經理組織進行軟體高層設計，並對工作任務進行分解，並根據實際需要向技術開發部經理申請資源，組建專案組隊；
專案經理根據工作任務分解，下發《工作任務卡》，並協同組隊成員進行任務估算；
注：工作任務包括模組開發任務、其它任務（如安裝）；模組開發任務主要包括：詳細設計、編碼和單元測試
任務估算完成後，組隊成員向專案經理提交《個人進度安排》（以甘特圖的形式表示），專案經理根據每個組隊成員的《個人進度安排》修訂《軟體專案計畫》（必須包括總的計畫甘特圖），並提交立項申請人確認；
立項申請人確定後，專案經理根據軟體專案計畫基線，補充《工作任務卡》，下發到每個組隊成員，開發工作開始。
專案立項與計畫過程的工作流程如下圖所示：
圖表 1 專案立項與計畫工作流程圖
相關模板：
《軟體需求規格說明書》、《軟體專案計畫》、《工作任務卡》
說明： 如果計畫確認、需求確認未通過，立項申請人與專案經理進行協商，進行修正，無法達成共識的，提交部門經理、總經理協調；
2.2 專案實施
參與人員：專案經理，專案組成員；
入口準則：專案計畫基線已建立，並通過立項申請人確定，帶有工作進度要求的《工作任務卡》已下發到每個專案成員；
出口準則：立項申請人在《驗收報告》上簽字確認；
輸入：《軟體需求規格說明書》、《軟體專案計畫》、《工作任務卡》；
輸出：經驗收測試的可交付的程式、源**及相關文件。
活動：在開發期間，專案成員每週需上交乙份《時間日誌》、《缺陷日誌》，每天向專案經理匯報工作任務進度；
在開發期間，專案經理負責填寫《專案進度週報》報於技術開發部經理、立項申請人（格式不同，交予立項申請人的只需週報的第一頁，報予技術開發部經理的專案進度週報的第二頁為「跟蹤甘特圖」）；
專案經理必須根據實際的進度情況，及時調整專案計畫，若發現進度延誤，需採取措施。
相關模板：
《軟體專案計畫》、《開發任務卡》、《時間日誌》、《缺陷日誌》、《專案進度週報》
2.3 專案關閉
參與人員：技術開發部經理或經理助理、專案經理，專案組成員、立項申請人、[相關客戶、公司總經理、公司副總經理]；
入口準則：立項申請人在《驗收報告》上確認；
出口準則：形成《專案總結》，完成專案績效考核，專案資料存入「過程資料庫」；
輸入：《時間日誌》、《缺陷日誌》、《專案開發計畫》；
輸出：《專案總結》、已完成的《專案績效考核表》、過程資料庫中的該專案記錄；
活動：專案經理主持召開專案總結會，交流專案實施過程中的心得體會，對專案實施中的成功處、不足處進行總結，並由專案經理形成《專案總結》；
由技術開發部經理組織對該專案進行績效考核，並填寫相應的《專案績效考核表》；
專案經理組織所有成員對專案過程中的文件、源程式等資料進行整理、歸檔；
由專案經理根據過程資料庫的需要，整理相應的資料，提交技術開發部經理，存入過程資料庫。
相關模板：
《專案總結》、《專案績效考核表》
3.開發過程規範
開發過程是提煉使用者需求，設計、構建和測試滿足這些需求的軟體並最終將其交付給客戶的過程。是軟體過程中的主體過程之一。當開發新的應用或計畫為現有的應用進行重要的增強時，需使用本規範所定義的開發過程執行。
專案管理過程是對開發過程進行計畫、監控/管理、總結的輔助過程，但由於專案管理是保證進度、質量的重要手段，因此在軟體專案中也是十分重要的過程之一。而需求管理過程與配置管理過程則是次重要的輔助過程，需求管理過程是乙個需求變更管理的過程，以對變更進行統一的管理；配置管理過程的最重要工作就是版本控制，使得開發過程中的各種交付物能夠有機地形成乙個個整體。
因此以上四個過程是交織進行的，均是為成功完成軟體專案的保障過程。
3.1 過程總述
現在比較通行的開發過程模型包括：瀑布模型、演化模型、原型模型、螺旋模型等。根據公司的專案特點、隊伍規模、組隊情況等實際因素，決定選擇最為簡單、易於掌握的瀑布模型為基礎，根據公司特點，進行合理的修改，使其成為公司本階段的軟體開發過程。
正如下圖所示，本規範將整個開發過程分為：需求分析、高層設計、詳細設計、編碼和單元測試、整合計畫與測試、系統測試、驗收測試與安裝、維護等八個階段。
圖表 2 開發過程總圖
注：srs：軟體需求規格 hld：高層設計 dd：詳細設計
src：** ut plan：單元測試計畫
注：「歸檔」在配置管理過程統一說明。
3.2 需求分析階段
需求分析的主要目的是生成乙個正確說明客戶所有需求的文件。換言之，軟體需求規格（software requirement specification，srs）文件是該階段的主要輸出。正確的需求分析和確定需求規格對乙個專案的成功是非常關鍵的。
許多在系統和驗收測試時發現的缺陷是在需求階段產生的。在驗收階段去掉需求階段產生的乙個錯誤將比在需求階段本身去掉該錯誤要多花100多倍的費用。很明顯，在執行這階段時，正確地生成具有最少缺陷的srs是非常必要的。
參與人員：專案經理，[分析員]，立項申請人，[客戶，終端使用者]；
入口準則：專案立項，最初的專案計畫已得到立項申請人的確認。
注：這裡所說明的需求分析階段是進行開發過程的需求分析階段，在技術開發部出具初步的專案計畫之前的需求溝通工作，不是該過程規範所定義的。最初的需求溝通工作可以參考本過程規範。
出口準則：立項申請人、[客戶]在《軟體需求規格說明書》上簽字確認；
輸入：《專案立項申請表》、最初的《專案計畫》，需求相關的資料；
輸出：經確認的《軟體需求規格說明書》；
活動：整個需求分析過程主要包括以下幾個步驟：
圖表 3 需求分析階段活動總圖
首先，專案經理與分析員一塊，做好需求分析的準備，包括閱讀相關的背景資料，熟悉客戶的實際情況，準備使用者訪談計畫，準備會談問題清單等；
然後通過面談、專題討論會等形式與客戶進行溝通，採集需求的詳細內容，澄清每乙個需求點；從而界定出系統的目標和範圍；
對所採集和澄清的需求進行分析，構建需求模型，從功能性、非功能性兩個方面進行需求分析，深入領會客戶需求；
形成《軟體需求規格說明書》，建立軟體需求基線，並為軟體需求評審做好準備；
由專案經理安排軟體需求評審，協同立項申請人、[客戶]進行需求評審；
立項申請人[或客戶]在《軟體需求規格說明書》上確認。
相關模板：
《軟體需求規格說明書》
3.3 高層設計階段
高層設計是軟體開發過程中的乙個重要階段，在這個階段將從計算機實現的邏輯角度開發針對使用者需求的解決方案。這一解決方案是乙個高階的抽象方案。高層設計要設計出各主要部分，並說明他們在技術上如何工作：
1）相互間的協作；2）所需外在的硬體和軟體環境；3）內在環境。也就是說，高層設計確定了組成產品的構件，定義了每個構件的功能任務，並且定義了構件間的介面及構件到執行環境的外部介面。
參與人員：專案經理，專案組員（設計團隊）；
入口準則：《軟體需求規格說明書》已通過立項申請人的確認；
出口準則：形成高層設計，實現任務分解，所有的問題得到解決；
輸入：《軟體需求說明書》
輸出：《高層設計說明書》（功能與資料庫設計）、詳細設計、編碼、文件和使用者介面標準；
活動：制定詳細設計、編碼、文件和使用者介面的標準；
根據專案特點擊擇執行的目標平台和開發工具；
制定軟體的體系結構，定義邏輯和物理的物件模型，包括確定類、類的屬性、類方法、類之間的關係和物件間的動態互動。若採用結構化設計，則該活動應為功能設計；
從需求規格說明書中的資料模型中得到物理資料庫結構，進行物理資料庫設計：包括確定表/記錄型別、域和其他部分。
生成高層設計說明書，並組織設計評審。
公司軟體發布過程規範
編制 審核 日期 2006 11 7 版本 編號 密級 修改歷史 目錄1.目標 4 2.發布流程 4 2.1.補丁發布流程 4 2.2.主版本發布流程 6 2.3.產品實施流程 9 2.4.vss管理流程 10 3.相關資料 11 軟體的發布過程，需要形成有序的良性迴圈。否則，各環節流轉中容易發生相...
軟體開發過程規範
版本 1.0 修訂歷史紀錄 目錄1.前言 3 1.1 目的 3 1.2 物件 3 1.3 要求 3 1.4 適用範圍 3 1.5 軟體開發過程模型 3 1.6 開發過程劃分 3 2.技術過程規範部分 3 2.1 概述 3 2.2 業務建模階段 4 2.3 需求階段 5 2.4 分析設計階段 6 2....
規範軟體開發過程 軟體配置管理實踐
2010 05 19 網路 隨著軟體系統的規模 複雜度日益上公升，軟體開發過程管理已經成為保證軟體系統開發效率 質量 成本的關鍵性因素。作為軟體開發過程中質量保障的重要組成部分，行之有效的軟體配置管理 以下簡稱scm，software configuration management 能夠顯著提高軟...