版本 <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.5 實現階段 7
3. 管理過程規範部分 7
3.1 概述 7
3.2 接受專案 8
3.3 重新評估專案範圍和風險（對於較大專案） 8
3.4 制定開發計畫 8
3.5 迭代開發管理 9
3.6 監控專案的實施 9
3.7 結束專案 10
軟體開發過程規範
本規範的目的是使整個軟體產品開發及專案工程階段清晰，要求明確，任務具體，便於規範化、系統化及工程化。有利於提高軟體生命週期的控制及管理，提高所開發軟體的質量，縮短開發時間，減少開發和維護費用，使軟體開發活動更科學、更有成效。
本規範面向產品生命週期的所有相關人員，包括管理人員、開發人員、質管人員。
具有軟體開發管理職能的人員要求熟知專案開發的各階段過程和各階段過程相應的規範。
適用於產品開發生命週期中的除產品提交外的其他全部過程；規範分為兩部分：技術過程規範和管理過程規範，分別適用於軟體開發過程中的技術性活動和管理性活動。
本規範所採用的軟體開發過程模型為簡化的rup開發過程模型；軟體開發過程是體系結構為中心，用例驅動和風險驅動相結合的過程迭代。
開發過程包括多次迭代，每次迭代的目標和側重點不同；較早的迭代側重於業務建模和需求建模；而後的迭代則側重於分析設計和編碼。
本規範中將軟體開發的整個技術過程分為四個順序實施的階段，分別為業務建模階段、需求階段、分析設計階段和實現階段。在對技術過程規範的描述，按階段內部的活動和產物對四個階段分別說明。
在本規範中對階段內活動的說明，是按順序性活動和持續性活動兩類分別進行說明。對於順序性活動是按該階段中活動的總體順序進行的描述，而在實際工作中，從各活動的具體實施的細節來看，各活動之間的順序是不斷交叉變化的。對於持續性活動主要是對貫穿該階段過程始終的技術活動進行說明。
規範中所提到的可選文件是指在其所屬階段，可根據具體情況靈活掌握，開發團隊自主決定是否開發的文件產物。而提交文件則是指在專案開發過程中必須開發的文件產物，但可根據具體專案情況，在軟體開發計畫中明確規定是否要形成正式文件並提交。
規範中各階段提到的技術評審，具體參見《評審規範》中所對應技術性評審的詳細描述。
1) 開始初步調研，獲取初始業務需求，進行問題定義，形成《業務概覽》並建立《術語表》；
2) 制定《調研記錄表冊》，實施詳細的業務調研，建立初始的業務用例模型和《業務用例規格》；
3) 分析業務過程，取出可以實現自動化的用例，分析業務部門和實體物件，形成初始的業務物件模型；
4) 根據初始業務物件模型和初始業務用例模型，分析並提取與系統實現相關的用例和模型， 建立系統域模型；
5) 精化域模型中的初始用例，詳細描述業務流程，分析業務規則，建立精化的業務用例模型，形成《業務規則》和《業務用例規格》；
6) 精化域模型中的初始物件，進行詳細的物件描述，分析物件職責和物件間關係，建立精化的業務物件模型，形成《業務物件縱覽》；
7) 分析業務上的非功能性需求，形成《增補業務規格》；
8) 應用業務物件，實現業務用例，制定《業務用例實現規格》，以驗證業務物件與業務用例的正確性，根據驗證結果，修正業務物件、業務用例及相關文件；
9) 彙總《業務規則》《業務用例規格》《業務物件縱覽》《增補業務規格》和《業務用例實現規格》形成《業務架構文件》。
10) 《業務概覽》在業務建模階段，根據對專案理解的不斷加深，隨時進行改進；
11) 《術語表》的更新維護；
12) 《業務概覽》
13) 《術語表》
14) 《調研記錄表冊》
15) 《業務架構文件》其附件包括：《業務規則》《業務用例規格》《業務物件縱覽》《增補業務規格》和《業務用例實現規格》
16) 《目標組織評價》
17) 《業務概覽》
18) 《術語表》
19) 《專案調研表冊》
20) 《業務架構文件》
21) 《業務規則》
22) 《業務用例規格》
23) 《業務物件縱覽》
24) 《增補業務規格》
25) 《業務用例實現規格》
26) 《目標組織評價》
27) 業務用例模型評審
28) 業務物件模型評審
29) 界定系統範圍，明確委託方需求，形成《專案概覽》（系統）《術語表》；
30) 定義系統角色，根據《業務用例規格》，分析業務用例，將其轉換為系統初始用例，並開始系統原型介面的開發；
31) 結合《增補業務規格》，細緻分析用例資源條件，形成初始《增補規格》，同時剔除無法實現的初始用例，形成初始《用例規格》；
32) 為初始用例分析劃分優先順序、分析依賴性，建立初始用例模型，結合初始《增補規格》形成初始《軟體需求規格》，為子系統分析或包、元件分析奠定基礎；
33) 精化初始用例模型中的用例，詳細描述系統互動過程，建立精化的用例模型，《用例規格》；
34) 根據初始《增補規格》和《業務規則》，進一步深入分析系統的非功能性需求，形成《增補規格》；
35) 彙總《用例規格》《增補規格》形成《軟體需求規格》。
36) 《專案概覽》（系統）在需求階段，根據對專案理解的不斷加深，隨時進行改進；
37) 《術語表》的更新維護；
38) 通過快速原型的開發、試用、修改，與客戶和使用者交流以不斷獲取系統需求，並形成《使用者原型介面描述》。
39) 《專案概覽》（系統）
40) 《術語表》
41) 《需求規格說明》其附件包括：《用例規格》《增補規格》
42) 《使用者原型介面描述》
43) 《使用者介面風格說明》
44) 《委託方需求》
45) 《使用者手冊》（初稿）
46) 《專案概覽》（系統）
47) 《需求規格說明》
48) 《術語表》
49) 《用例規格》
50) 《增補規格》
51) 《使用者原型介面描述》
52) 需求評審
53) 根據《系統需求規格》進行體系結構分析設計，確定系統軟體架構，形成配置圖和《軟體架構文件》；
54) 根據《需求規格說明》和系統軟體架構，進一步擴充套件業務物件模型，建立分析物件模型，明確系統物件的職責；
55) 根據業務物件，及業務物件之間的關係，結合分析物件和系統軟體架構，進行資料庫的分析設計，建立資料模型，完成資料庫設計工作，形成《資料模型縱覽》；
56) 應用分析物件實現系統用例，以驗證分析物件的正確性，並根據驗證結果，修正分析物件模型；
57) 彙總分析物件模型和基於分析物件的用例實現，形成《分析模型縱覽》；
58) 根據分析物件模型，結合使用者原型介面和資料模型，進行系統類設計，建立設計類模型和構件圖；
59) 實施系統類的詳細設計，確定類的屬性、方法及引數型別、可見性等，並將用例分配給物件類，形成基於設計類的用例實現；
60) 彙總設計類模型和基於設計類的用例實現，形成《設計模型縱覽》，為下一步系統的實現明確工作任務。
無。61) 《軟體架構文件》
62) 《分析模型縱覽》
63) 《設計模型縱覽》
64) 《資料模型縱覽》
無。65) 《軟體架構文件》
66) 《分析模型縱覽》
67) 《設計模型縱覽》
68) 《資料模型縱覽》
69) 軟體架構評審
70) 設計評審
71) 根據《設計類模型》，按照類的詳細設計和構件圖，結合用例的實現優先順序，確定系統《實現模型》，並根據系統體系結構進行系統整合設計，形成《整合模型》；
72) 根據《實現模型》進行元件編碼實現；
73) 根據《整合模型》對系統編碼實現的元件進行系統整合實現；
74) 編制《使用者手冊》，製作並整合系統幫助，完成客戶或使用者所需要的其他文件。
無。75) 《實現模型》
76) 《整合設計》
77) 《使用者手冊》
78) 《實現模型》
79) 《整合設計》
80) 《使用者手冊》
81) **評審
在本規範中，對軟體開發過程的管理，採用階段性規劃。具體為根據軟體開發過程中的技術過程，明確開發階段，主要依據技術過程規範所描述的技術過程階段劃分；而後，將各階段根據專案的具體情況和實施要求，劃分為利於監控管理的乙個或多個迭代過程。
本規範對於專案的計畫和進度安排，採用由粗到細、由簡到繁的方式，首先制定描述軟體開發過程總體階段和迭代的軟體開發計畫，而後根據所劃分的迭代過程，在每個迭代開始時，對該迭代過程進行詳細的任務分配和進度規劃。
本規範中所提到的《軟體開發計畫》，包含了開發計畫、質量管理計畫、技術支援計畫等多項內容，但主要以開發計畫為主，其他計畫視具體專案、團隊情況確定是否制定。
在本規範中風險管理貫穿整個軟體開發過程，包括《風險列表》的更新維護、風險的跟蹤管理。
對本規範中的各開發計畫的具體實施說明，可參見《專案監控管理辦法》相關說明。
規範中各階段提到的管理評審，具體參見《評審規範》中所對應管理性評審的詳細描述。
82) 根據《專案概覽》標識和評估風險，制定《風險列表》；
83) 分析專案風險，制定風險防範和解決措施，形成《風險管理計畫》；
84) 分析可行性和商業價值，制定《商業案例》；
85) 《風險列表》
86) 《風險管理計畫》
87) 《商業案例》
88) 專案批准評審
89) 根據《專案概覽》和對專案進一步深入了解，重新標識和評估風險，改進《風險列表》；
90) 根據修正專案風險，重新分析專案可行性和商業價值，改進《商業案例》；
91) 修正的《風險列表》
92) 修正的《商業案例》
無。93) 根據不斷修正維護的《風險列表》，完善風險防範和解決措施，改進《風險管理計畫》；
94) 根據《商業案例》中說明的專案的開發要求，結合資源和風險狀況，建立專案工作分析結構（wbs），明確開發階段和迭代次數，同時完成其他開發相關的計畫內容，形成《軟體開發計畫》。
95) 修正的《風險管理計畫》
96) 《軟體開發計畫》
97) 開發計畫評審
98) 根據《軟體開發計畫》，結合具體的開發狀況和資源獲取情況，確定在乙個迭代期間的開發任務，進度安排，形成《迭代計畫》，並更新《軟體開發計畫》；
99) 按照《迭代計畫》，將工作任務形成《任務單》，描述任務要求，明確開發人員職責；
100) 根據本次迭代開發的完成情況和提交的成果，對該迭代開發過程進行分析評價，形成《迭代評價》，並根據實際情況，提出《變更請求》。
101) 修正的《軟體開發計畫》
102) 《迭代計畫》
103) 《任務單》
104) 《變更請求》
105) 迭代計畫評審
106) 迭代評價標準評審
107) 迭代評價評審
108) 在專案開發過程中隨時監控專案的狀態，了解專案的進展，特別是根據《風險列表》，跟蹤風險，及時發現問題，並根據監控結果，及時更新、維護《風險列表》；
軟體開發過程及規範複習
一 外包的型別 1 ito 資訊科技外包 強調技術領域的外包。2 bpo 業務流程外包 強調業務流程，解決業務效果和運營效益的問題。3 kpo 知識流程外包 注重高階的研發活動外包。二 發展服務外包的優點 1 提公升產業結構 2 有利於轉變對外 的增長方式，形成新的出口支撐點 3 有利於提高利用外資...
軟體開發過程管理流程
吉林林業資訊科技有限責任公司 2012年9月 目錄1 編寫背景 3 2 編寫目的 3 3 名詞解釋 3 4 適用範圍 3 5 公司各部門職責及關係 3 5.1 專案管理委員會 3 5.2 專案管理部與總工辦 3 5.3 公司各部門主要職責 3 5.3.1 公司董事會 3 5.3.2 總經理辦公室 3...
規範軟體開發過程 軟體配置管理實踐
2010 05 19 網路 隨著軟體系統的規模 複雜度日益上公升，軟體開發過程管理已經成為保證軟體系統開發效率 質量 成本的關鍵性因素。作為軟體開發過程中質量保障的重要組成部分，行之有效的軟體配置管理 以下簡稱scm，software configuration management 能夠顯著提高軟...