第一篇：軟件項目開發管理流程

研發中心項目開發管理流程

1，新項目開發管理流程

按照項目管理規范，項目管理分為：項目啟動—》項目計劃—》項目執行—》項目控制—》項目結尾。5個階段。根據該管理流程和我公司實際情況，將新項目開發的管理流程制定如下圖：

1.1 項目立項

項目立項階段，首先由的項目經理編寫《項目立項報告》。

研發項目立項報告模板.doc

1.2 立項評審

《項目立項報告》編寫完成后，交由項目管理委員會進行立項評審，評審通過后由副總經理簽字確認立項。確定需求分析和項目設計階段的時間和人員安排。

1.3 需求分析

需求分析階段，需要與用戶交流，雙方對軟件需求取得共同理解基礎上達成的協議。編寫并完成軟件需求說明書：也稱軟件規格說明書。

軟件需求說明書模板.doc

1.4 系統設計階段

常規的系統設計需要依次完成《概要設計說明書》，《詳細設計說明書》。以下是文檔的簡要說明：

概要設計說明書：該說 明書是概要設計階段的工作 成果，它應說明功能分配、模 塊劃分、程序的總體結構、輸 入輸出以及接口設計、運行設 計、數據結構設計和出錯處理 設計等，為詳細設計奠定基礎。

概要設計說明書.doc

詳細設計說明書：著重 描述每一模塊是怎樣實現的，包括實現算法、邏輯流程等。詳細設計說明書.doc

詳細設計說明書編寫完成后，項目經理應該依次編寫安排項目開發工作計劃。工作計劃安排可以根據項目經理的習慣進行工作計劃編寫。建議采用project。附件為綜合考務平臺的工作計劃安排，可以供參考：

考試考務綜合管理平臺工作計劃.mpp。并且確定里程碑，以便在后期項目執行過程中，對其進行確認。對于大項目，建議按照項目設計流程，先進行概要設計，再到詳細設計。但是對于特殊項目（項目周期較短，小項目），可以講概要設計和詳細設計階段合二為一，編寫功能，接口方案。但是值得注意的是，該方案中，仍然需要涵蓋項目模塊功能，用戶權限和各模塊實現邏輯，接口等。

項目設計開發方案.docx。

1.5 項目設計評審

設計階段完成后，項目經理填寫《項目設計評審表》，將相關文檔交由項目管理委員會進行項目設計評審。通過評審后，方可進行編碼工作。

項目設計評審表.docx

1.6 編碼和測試用例編寫階段

項目編碼階段，項目經理需要對項目執行情況進行控制和監督，其中包括（項目輸入，項目輸出，里程碑）。如果由于特殊情況，如：需求變化，人員臨時調配，或者其他原因導致的項目范圍和時間，計劃等變更，項目經理應該及時填寫變更申請。并提交給項目管理委員會。作為之后項目輸出驗證的重要依據項目變更申請書.doc。

在此階段，測試人員應該根據《需求說明書》，《概要設計》和《詳細設計說明書》的內容，編寫相應的《測試用例》。1.7 測試階段

編碼完成后，應該移交測試組進行相關測試工作。按照測試流程，需要提交《測試申請表》。測試人員在接收到《測試申請》后，應該與研發人員討論《測試用例》的相關內容，確定測試時間，開始程序測試。并在測試工作完成后，編寫對應的《測試報告》。

1.8 結項評審與驗證

項目負責人和測試負責人分別填寫《項目結項評審表》，交由項目管理委員會進行評審。評審通過后，由研發中心副總經理進行發布確認。

項目結項評審驗證表.doc

1.9 新產品發布

編寫《用戶手冊》。方可進行新產品發布。

2，舊項目升級開發管理流程

舊項目的升級，依照如下流程：

2.1項目升級需求分析

項目需求分析，需要收集用戶在產品使用過程中，已經技術人員在調試過程中的反饋作為需求分析的輸入。并填寫對應的項目升級需求報告表。項目升級需求報告表.doc

2.2 升級評審

將《升級需求報告》交由項目管理委員會，評審通過后，進行升級設計。2.2項目升級設計

項目負責人，根據需求報告和升級具體情況，編寫升級開發方案。項目升級開發方案.docx。并安排整改工作計劃。

2.3 項目升級設計評審

升級開發方案完成后，填寫《項目設計評審表》，交由項目管理委員會評審。

2.4 編碼

按照項目升級開發方案進行編碼設計，如果編碼工作中，發生特殊情況需要變更計劃，或者項目范圍等，同樣需要提交《變更申請》，作為項目驗證的基礎。同樣，此階段，測試人員應該編寫或者修改相關測試用例。

2.5 測試

編碼完成后，應該移交測試組進行相關測試工作。按照測試流程，需要提交《測試申請表》。測試人員在接收到測試申請后，應該與研發人員討論《測試用例》的相關內容，確定測試時間，開始程序測試。并在測試工作完成后，編寫對應的《測試報告》。

2.6 升級輸出評審

項目負責人和測試負責人分別填寫《項目結項評審表》，交由項目管理委員會進行評審。評審通過后，由副總經理進行發布確認后。

第二篇：軟件項目開發工作流程

軟件項目開發工作流程

一、簡述

對于一個新項目，從可行性研究到產品交貨整個生存階段將經歷如下十大流程：

1、項目可行性研究階段

2、立項階段

3、需求分析階段

4、開發策劃階段

5、設計階段

6、編碼實現階段

7、測試階段

8、驗收階段

9、產品交付使用

10、維護階段

二、項目組基本組成及崗位職責

新項目立項時會成立項目組，不同的項目組成員有不同的職責，一個項目組成員也可以身兼多職，但不可身兼全職。

a項目負責人：負責項目的管理、組織、對技術、進度、質量全面負責。b質量保證人員：負責質量保證工作計劃的落實和軟件的質量保證。

C配臵管理人員：負責本項目的配臵管理工作，對本項目的文檔、程序是否符合規程文件的要求進行形式化的檢查。

D分析人員：主要負責本項目的需求分析工作。E設計人員：主要負責本項目的設計工作。

F程序員：按設計要求和有關標準進行編程工作。

G測試人員：負責單元測試、組合測試和總裝測試工作。H文檔人員：負責本項目有關文檔的編寫工作。

I產品經理：協助進行產品研制計劃制定、產品發布與產品推廣等,在產品開發中，充分代表用戶的利益，提供建議,負責在產品功能與出品日期二者之間的權衡;負責產品市場營銷、產品銷售和市場推廣過程。（通常由營銷部門或中試部門人員擔任）

三、軟件開發流程

3．1 可行性研究階段

如果是公司自主開發項目，可行性研究通常是由公司技術負責人根據公司產品規劃和市場需求，在要開展新項目前通過部門負責人指定人員進行的前期調研工作，可行性研究負責人員對產品的市場需求、技術發展、市場定位、功能需求、經濟效益、進度需求、風險分析等進行可行性研究，提供產品立項建議，擬制可行性研究報告，由部門負責人指定營銷部門配合可行性分析人員，技術負責人協助安排。可行性分析完畢后由總工辦組織對可行性研究報告進行評審，評審通過后，總工辦組織進行立項工作。

如果是系統集成部外接的系統集成項目，在系統集成部與客戶簽訂合同之前，均應對將簽項目進行資源、技術、市場的可行性分析，可行性分析通過后、簽訂合同前由總工辦組織相關人員對合同條款進行評審，評審通過后，總工辦組織進行立項工作。

本階段提交的文檔：項目可行性研究任務書（技術負責人或部門負責人下達）

項目可行性研究報告（可行性研究人員編寫）

系統集成項目合同 質量記錄：可行性分析評審報告 3．2立項階段

可行性分析評審通過后，由開發部門經理下達立項任務，指定相關人員填寫立項申請報告報批。報批通過后，由部門經理與技術負責人協商，下達開發任務書，經技術負責人審核確認后，報公司批準。批準立項后項目進度應以立項申請報告中的階段進度為準，如果進度要調整，需填寫進度調整申請報告報批。本階段提交的文檔：項目立項申請報告

開發任務書

3．3 需求分析階段

承辦單位根據交辦單位提出的技術要求和相應的軟件任務書以及其它有關文件，與交辦單位協作，確定詳細的軟件需求，該階段完成的軟件需求規格說明經審定和批準后將作為整個軟件開發工作的基礎列入配臵管理的基線，在本階段可利用快速原型法使比較含糊的具有不確定性的軟件需求（主要是功能）明確化。能給本公司開發的軟件的“需求基線”確定提供一個討論、進一步完善的基礎。在本階段，由產品經理負責，其他人員配合，編寫產品規格說明書，此說明書面向最終用戶和領導，主要描繪產品的形狀以及功能、性能、功能特性、性能特性。由項目經理負責編寫系統技術方案書，描述公司初次使用的技術的詳細解決方案。本階段完畢后對需求分析進行評審，出具需求分析評審報告。本階段提交的文檔：軟件需求規格說明書。

原型分析說明書

產品規格說明書

系統技術方案書

質量記錄：

需求分析評審報告

提交的軟件：產品的原型（注：如果時間有限，可以只編寫原型分析說明書而不作原型）

3．4開發策化階段 根據項目要求和軟件需求，由配臵人員配合項目經理編寫本項目的質量保證計劃、配臵管理計劃和項目綜合計劃。在配臵管理計劃中，應列明本項目需提交的各階段文檔的名稱，在項目各階段完成后，項目組需列表說明要移交的文檔，將此表與各文檔一并向總工辦移交。在制定計劃時，應為計劃、設計、測試、改錯、再測試、變更、以及編制文檔留出足夠的時間。不應使用突擊的辦法來完成項目。

本階段涉及的文檔：軟件質量保證計劃

配臵管理計劃

項目綜合計劃

3．5設計階段 3．5．1概要設計

根據軟件需求規格說明建立軟件總體結構和模塊間的關系，確定各模塊功能，定義各功能模塊的接口，設計全局數據庫和數據結構，在概要設計明確后，可以對綜合計劃進一步細化，填寫項目進度預計。概要設計需經過評審。本階段涉及的文檔：產品概要設計說明書

數據庫設計說明

項目進度預計 質量記錄： 評審報告 3．5．2詳細設計

對概要設計中產生的功能模塊進行過程描述設計，設計功能模塊的內部細節，包括算法和數據結構，為編寫源代碼提供必要的說明。詳細設計需要經過評審。本階段涉及的文檔：軟件詳細設計說明書

測試計劃 質量記錄： 評審報告 3．6編碼實現階段

根據軟件詳細設計說明、對各程序模塊進行編碼、調試、靜態分析和單元測試，驗證程序單元與設計說明的一致性。本階段涉及的文檔：項目進度月報

項目周計劃和周總結

項目開發人員周計劃

工作日志

每周例會記錄

配臵項更改申請單 3．6 測試階段

3．6．1 軟件單元測試

按詳細設計的結構，根據軟件單元測試計劃，依照將經過單元測試的底層程序單元逐步組裝成子項目直到開發項目的過程，對軟件進行測試。本階段涉及的文檔：測試計劃

測試設計

測試問題報告單 參考文檔：北京世紀科怡軟件開發操作指導書中的“測試階段操作指導書”

3．6．2組裝測試

根據軟件需求規格說明書中定義的全部功能和性能要求及組裝測試計劃，對軟件進行組裝測試，以確定整個軟件是否滿足軟件需求，是否可以提交總裝測試。

軟件組裝測試計劃（含測試用例設計）的編制工作和軟件組裝測試環境的研制、組建工作，應從軟件需求分析階段起與軟件開發同步展開。本階段涉及的文檔：測試計劃

測試設計

測試問題報告單

3．7 中試階段

項目組開發的軟件產品經中試部驗收后提交中試部中試，中試部根據需求分析報告,從用戶的角度出發對產品的功能、性能進行中試。本階段涉及的文檔：中試計劃

中試問題報告單

3．7 驗收交付

對完成中試的軟件進行檢查、審查和評審，確定軟件是否達到了軟件任務書的要求。驗收通過的軟件可以向軟件交辦單位交付。項目經理及項目組人員應在此階段完成項目總結，項目經理提交項目開發總結報告，項目組成員提交個人工作總結報告。

本階段涉及的文檔：驗收報告

項目開發總結報告

個人工作總結報告

3．8 軟件維護

對軟件的維護包括針對軟件運行過程中發現的問題而進行的改正性維護，針對不同任務對軟件提出不需求而進行的改善性維護，以及可能出現的由于軟件運行環境的改變而進行的適應性維護。本階段涉及的文檔：軟件問題匯總表

維護報告

四、項目開發文件的審批

? 可行性研究報告及立項申請、項目開發計劃及項目開發總結、確認計劃及確認報告、驗收計劃及驗收報告由技術負責人審批。? 項目組人員編寫的其他文件由項目經理審批。

五、各階段共同的任務要求 5．1編寫文檔

在軟件開發過程的各個階段，都要求完成相應的文檔編寫工作。本文檔的前面部分已給出了在軟件自上而下周期各個階段中的文檔編制情況。軟件文檔從形式上來看，大致可分為兩類： a． 開發過程中填寫的各種圖表，稱為工作表格； b． 應編制的技術資料或技術管理資料，稱為文檔或文件。按照文檔產生和使用的范圍，軟件文檔大致可分為三類： a． 開發文檔：這類文檔是在軟件開發過程中，作為軟件開發人員前一階段工作成果的體現和后一階段工作依據的文檔。包括軟件需求說明書、數據庫設計說明書、概要設計說明書、詳細設計說明書、可行性研究報告、項目開發計劃。b． 管理文檔：這類文檔是在軟件開發過程中，由軟件開發人員制定的需提交人員的一些工作計劃或工作報告。使管理人員能夠通過這些文檔了解軟件開發項目安排、進度、資源使用和成果等。包括項目開發計劃、測試計劃、測試報告、開發進度月報、項目周計劃周總結及項目開發總結等。c． 用戶文檔：這類文檔是軟件開發人員為用戶準備的有關該軟件使用、操作、維護的資料。包括用戶手冊、操作手冊、維護修改建議、軟件需求說明書。

項目各階段完畢后需把本階段相關文檔列表向總工辦移交。

5．2驗證與評審

軟件評審是保證軟件產品質量的重要手段，必須納入軟件開發過程，并把評審通過作為一個軟件階段完成的標志，進而轉入下一個開發階段。軟件評審包括有正式評審(即評審)、內部評審兩種形式。正式評審是軟件項目組上級技術主管主持的評審。內部評審以由項目負責人組織、開發人員相互檢查為基本方式。

就整個軟件開發過程而言，至少要進行可行性分析、軟件需求評審、設計評審、軟件驗證和確認評審、管理評審等五個方面的評審和檢查工作。

第三篇：軟件項目設計和開發評審流程

軟件項目設計和開發評審流程目的設計和開發評審的目的是由一組有資格的人員對軟件設計和開發的輸出進行評價，以判斷確定設計和開發的輸出能否實現軟件產品預先定義的規格，同時通過評審標識出與規格和標準的偏差。它向管理部門提供充足的證據以證明

1）設計和開發的輸出符合了其規格要求；

2）設計和開發的輸出是否滿足相關法律、法規以及企業標準的要求；

3）軟件產品的更改得到了恰當地實施；

4）軟件產品的更改只對那些規格發生了更改的系統區域有影響，沒有引入新的問題。2 范圍

本規范適應于對軟件設計和開發的輸出以及設計與開發的更改進行評審。角色和職責

3.1 主審人。主審人是技術評審的指揮人員，負責評審活動的組織、結論、書面報告和問題跟蹤。

3.2 評審專家。評審專家應由滿足要求的技術人員擔任，負責向評審組成員提出自己的評審意見和建議。

3.3 質量保證人員：

3.4 記錄員。會議記錄人員。

3.5 顧客和用戶代表。必要時，由主審人確定能夠充當顧客和用戶代表的角色。

3.6 相關領導和部門管理人員。評審時機

按《產品開發計劃》所策劃的的評審檢查點進行。因臨時變更引起的突發性的評審隨時進行。評審的基本要求

a）設計和開發評審應分級進行。公司級的項目應進行公司級評審；業務部門級的項目一般進行業務部門級評審；

b）設計和開發評審視具體情況可一次進行，也可分段進行；

c）評審結論應明確；

d）評審資料應及時歸檔。評審依據

a）合同、技術協議書、需求規格說明書和設計任務書；

b）有關標準、規范和質量保證文件。評審內容

評審的內容可根據產品設計的研制周期、技術難度、復雜程度以及使用方的要求有所側重和適當的增減，但應滿足對設計結果進行評審的要求。主要內容：

a）設計方案正確性、先進性、可行性和經濟性；

b）系統組成、系統要求及接口協調的合理性；

c）系統與各子系統間技術接口的協調性；

d）采用設計準則、規范和標準的合理性；

e）系統可靠性、維修性、安全性要求是否合理；

f）關鍵技術的落實解決情況；

g）編制的質量計劃是否可行。評審方式評審方式有會簽評審和會議評審兩種。

第四篇：軟件項目開發工作流程

軟件項目開發工作流程

一、簡述

對于一個新項目，從可行性研究到產品交貨整個生存階段將經歷如下十大流程：

1、項目可行性研究階段

2、立項階段

3、需求分析階段

4、開發策劃階段

5、設計階段

6、編碼實現階段

7、測試階段

8、驗收階段

9、產品交付使用

10、維護階段

二、項目組基本組成及崗位職責

新項目立項時會成立項目組，不同的項目組成員有不同的職責，一個項目組成員也可以身兼多職，但不可身兼全職。

a項目負責人：負責項目的管理、組織、對技術、進度、質量全面負責。b質量保證人員：負責質量保證工作計劃的落實和軟件的質量保證。

C配臵管理人員：負責本項目的配臵管理工作，對本項目的文檔、程序是否符合規程文件的要求進行形式化的檢查。

D分析人員：主要負責本項目的需求分析工作。

E設計人員：主要負責本項目的設計工作。

F程序員：按設計要求和有關標準進行編程工作。

G測試人員：負責單元測試、組合測試和總裝測試工作。

H文檔人員：負責本項目有關文檔的編寫工作。

I產品經理：協助進行產品研制計劃制定、產品發布與產品推廣等,在產品開發中，充分代表用戶的利益，提供建議,負責在產品功能與出品日期二者之間的權衡;負責產品市場營銷、產品銷售和市場推廣過程。（通常由營銷部門或中試部門人員擔任）

三、軟件開發流程

3．1 可行性研究階段

如果是公司自主開發項目，可行性研究通常是由公司技術負責人根據公司產品規劃和市場需求，在要開展新項目前通過部門負責人指定人員進行的前期調研工作，可行性研究負責人員對產品的市場需求、技術發展、市場定位、功能需

求、經濟效益、進度需求、風險分析等進行可行性研究，提供產品立項建議，擬制可行性研究報告，由部門負責人指定營銷部門配合可行性分析人員，技術負責人協助安排。可行性分析完畢后由總工辦組織對可行性研究報告進行評審，評審通過后，總工辦組織進行立項工作。

如果是系統集成部外接的系統集成項目，在系統集成部與客戶簽訂合同之前，均應對將簽項目進行資源、技術、市場的可行性分析，可行性分析通過后、簽訂合同前由總工辦組織相關人員對合同條款進行評審，評審通過后，總工辦組織進行立項工作。本階段提交的文檔：項目可行性研究任務書（技術負責人或部門負責人下達）項目可行性研究報告（可行性研究人員編寫）

系統集成項目合同

質量記錄：可行性分析評審報告

3．2立項階段

可行性分析評審通過后，由開發部門經理下達立項任務，指定相關人員填寫立項申請報告報批。報批通過后，由部門經理與技術負責人協商，下達開發任務書，經技術負責人審核確認后，報公司批準。批準立項后項目進度應以立項申請報告中的階段進度為準，如果進度要調整，需填寫進度調整申請報告報批。本階段提交的文檔：項目立項申請報告

開發任務書

3．3 需求分析階段

承辦單位根據交辦單位提出的技術要求和相應的軟件任務書以及其它有關文件，與交辦單位協作，確定詳細的軟件需求，該階段完成的軟件需求規格說明經審定和批準后將作為整個軟件開發工作的基礎列入配臵管理的基線，在本階段可利用快速原型法使比較含糊的具有不確定性的軟件需求（主要是功能）明確化。能給本公司開發的軟件的“需求基線”確定提供一個討論、進一步完善的基礎。在本階段，由產品經理負責，其他人員配合，編寫產品規格說明書，此說明書面向最終用戶和領導，主要描繪產品的形狀以及功能、性能、功能特性、性能特性。由項目經理負責編寫系統技術方案書，描述公司初次使用的技術的詳細解決方案。本階段完畢后對需求分析進行評審，出具需求分析評審報告。

本階段提交的文檔：軟件需求規格說明書。

原型分析說明書

產品規格說明書

系統技術方案書

質量記錄：需求分析評審報告

提交的軟件：產品的原型（注：如果時間有限，可以只編寫原型分析說明書而不作原型）

3．4開發策化階段

根據項目要求和軟件需求，由配臵人員配合項目經理編寫本項目的質量保證計劃、配臵管理計劃和項目綜合計劃。在配臵管理計劃中，應列明本項目需提交的各階段文檔的名稱，在項目各階段完成后，項目組需列表說明要移交的文檔，將此表與各文檔一并向總工辦移交。在制定計劃時，應為計劃、設計、測試、改錯、再測試、變更、以及編制文檔留出足夠的時間。不應使用突擊的辦法來完成項目。

本階段涉及的文檔：軟件質量保證計劃

配臵管理計劃

項目綜合計劃

3．5設計階段

3．5．1概要設計

根據軟件需求規格說明建立軟件總體結構和模塊間的關系，確定各模塊功能，定義各功能模塊的接口，設計全局數據庫和數據結構，在概要設計明確后，可以對綜合計劃進一步細化，填寫項目進度預計。概要設計需經過評審。

本階段涉及的文檔：產品概要設計說明書

數據庫設計說明

項目進度預計

質量記錄：評審報告

3．5．2詳細設計

對概要設計中產生的功能模塊進行過程描述設計，設計功能模塊的內部細節，包括算法和數據結構，為編寫源代碼提供必要的說明。詳細設計需要經過評審。本階段涉及的文檔：軟件詳細設計說明書

測試計劃

質量記錄：評審報告

3．6編碼實現階段

根據軟件詳細設計說明、對各程序模塊進行編碼、調試、靜態分析和單元測試，驗證程序單元與設計說明的一致性。

本階段涉及的文檔：項目進度月報

項目周計劃和周總結

項目開發人員周計劃

工作日志

每周例會記錄

配臵項更改申請單

3．6 測試階段

3．6．1 軟件單元測試

按詳細設計的結構，根據軟件單元測試計劃，依照將經過單元測試的底層程序單元逐步組裝成子項目直到開發項目的過程，對軟件進行測試。

本階段涉及的文檔：測試計劃

測試設計

測試問題報告單

參考文檔：北京世紀科怡軟件開發操作指導書中的“測試階段操作指導書”

3．6．2組裝測試

根據軟件需求規格說明書中定義的全部功能和性能要求及組裝測試計劃，對軟件進行組裝測試，以確定整個軟件是否滿足軟件需求，是否可以提交總裝測試。

軟件組裝測試計劃（含測試用例設計）的編制工作和軟件組裝測試環境的研制、組建工作，應從軟件需求分析階段起與軟件開發同步展開。

本階段涉及的文檔：測試計劃

測試設計

測試問題報告單

3．7 中試階段

項目組開發的軟件產品經中試部驗收后提交中試部中試，中試部根據需求分析報告,從用戶的角度出發對產品的功能、性能進行中試。

本階段涉及的文檔：中試計劃 中試問題報告單

3．7 驗收交付

對完成中試的軟件進行檢查、審查和評審，確定軟件是否達到了軟件任務書的要求。驗收通過的軟件可以向軟件交辦單位交付。項目經理及項目組人員應在此階段完成項目總結，項目經理提交項目開發總結報告，項目組成員提交個人工作總結報告。

本階段涉及的文檔：驗收報告

項目開發總結報告

個人工作總結報告

3．8 軟件維護

對軟件的維護包括針對軟件運行過程中發現的問題而進行的改正性維護，針對不同任務對軟件提出不需求而進行的改善性維護，以及可能出現的由于軟件運行環境的改變而進行的適應性維護。

本階段涉及的文檔：軟件問題匯總表

維護報告

四、項目開發文件的審批

? 可行性研究報告及立項申請、項目開發計劃及項目開發總結、確認計劃及確

認報告、驗收計劃及驗收報告由技術負責人審批。

? 項目組人員編寫的其他文件由項目經理審批。

五、各階段共同的任務要求

5．1編寫文檔

在軟件開發過程的各個階段，都要求完成相應的文檔編寫工作。本文檔的前面部分已給出了在軟件自上而下周期各個階段中的文檔編制情況。軟件文檔從形式上來看，大致可分為兩類：

a． 開發過程中填寫的各種圖表，稱為工作表格；

b． 應編制的技術資料或技術管理資料，稱為文檔或文件。

按照文檔產生和使用的范圍，軟件文檔大致可分為三類：

a． 開發文檔：這類文檔是在軟件開發過程中，作為軟件開發人員前一階段工作成果的體現和后一階段工作依據的文檔。包括軟件需求說明書、數據庫設計說明書、概要設計說明書、詳細設計說明書、可行性研究報告、項目開發計劃。

b． 管理文檔：這類文檔是在軟件開發過程中，由軟件開發人員制定的需提交人員的一些工作計劃或工作報告。使管理人員能夠通過這些文檔了解軟件開發項目安排、進度、資源使用和成果等。包括項目開發計劃、測試計劃、測試報告、開發進度月報、項目周計劃周總結及項目開發總結等。c． 用戶文檔：這類文檔是軟件開發人員為用戶準備的有關該軟件使用、操作、維護的資料。包括用戶手冊、操作手冊、維護修改建議、軟件需求說明書。

項目各階段完畢后需把本階段相關文檔列表向總工辦移交。

5．2驗證與評審

軟件評審是保證軟件產品質量的重要手段，必須納入軟件開發過程，并把評審通過作為一個軟件階段完成的標志，進而轉入下一個開發階段。軟件評審包括有正式評審(即評審)、內部評審兩種形式。正式評審是軟件項目組上級技術主管主持的評審。內部評審以由項目負責人組織、開發人員相互檢查為基本方式。

就整個軟件開發過程而言，至少要進行可行性分析、軟件需求評審、設計評審、軟件驗證和確認評審、管理評審等五個方面的評審和檢查工作。

第五篇：軟件項目變更管理流程

變更管理流程 2 概述.......................................................................................錯誤！未定義書簽。變更流程.................................................................................................................2

2.1 摘要.........................................................................................................................................2 2.2 提交變更申請.........................................................................................................................3 2.3 審核變更申請.........................................................................................................................4 2.4 識別變更可行性.....................................................................................................................4 2.5 批準變更申請.........................................................................................................................4 2.6 實施變更申請.........................................................................................................................4 變更任務.................................................................................................................5

3.1 變更申請人.............................................................................................................................5 3.2 變更經理.................................................................................................................................5 3.3 變更可研小組.........................................................................................................................5 3.4 變更審批小組.........................................................................................................................5 3.5 變更實施小組.........................................................................................................................5 5 變更登記.................................................................................................................6 變更模板.................................................................................................................6

Confidential

Page 1 1 概述

描述變更管理的目的。就項目中變更管理的總體流程提供一份概述，如：

變更管理流程是成功交付項目的基礎。變更管理流程確保對在項目環境中的每個變更在實施以前都得以恰當的定義、評估和審批。

對項目的變更管理是通過對以下五個關鍵步驟的實施引入的。，: ? 提交和接收變更申請 ? 審核和記錄變更申請 ? 確定變更申請的可行性 ? 批準變更申請

? 實施和結束變更申請變更流程

對將要執行的流程和程序做一個圖表概述，以啟動、實施項目中的變更并審核其效果。例如：Provide a diagrammatic representation of the processes and procedures to be undertaken in order to initiate, implement and review the effects of changes within the project.An example follows:

2.1 概要

下圖對將要執行的變更流程和程序做了一個概述，以有效地管理與項目相關的變更。同時也明確的變更管理中的職責分工。

Confidential

Page 2 ChangeManagementProcessChangeManagementRole1.1 Changerequirementidentified1.0 SubmitChange Request1.2 ChangeRequest FormsubmittedChangeRequestor2.1 ChangeRequest Formreviewed2.0 ReviewChange Request2.2 FeasibilityStudy required?ChangeManagerNoYes3.1 ChangeFeasibility Studyperformed3.0 IdentifyChange Feasibility3.2 ChangeFeasibility StudyapprovedChangeFeasibility Group3.3 Changedocumentationsubmitted4.1 Changedocumentationreviewed4.0 ApproveChange Request4.2 Changeapproved?ChangeApproval GroupNoYes5.1 Changeimplementationscheduled5.2 Changeimplementationtested5.0 ImplementChange Request5.3 ChangeimplementationperformedChangeImplementationGroup5.4 Changeimplementationreviewed5.5 Changeclosed2.2 提交變更申請

本步驟中項目團隊中的任何成員都可以提交項目變更申請，需要完成以下工作：

? 變更申請人識別項目中任何方面的變更需求（如范圍、可交付成果、時限、組織）.? 變更申請人完成變更申請表（CRF），并將其呈交變更經理。變更申請表對需要進行的變更做一概述，包括：

? 變更描述

? 變更原因（包括商業驅動）? 變更利益 ? 變更成本

? 變更帶來的影響 ? 支持性文件

2.3 審核變更申請

本步驟授權變更經理對變更申請表進行審核，以決定是否需要一份充分的可行性研究報告以供變更批準小組評估變更可能帶來的全部影響。做出上述決定的基本依據是：

? 呈交的可選擇變更數目Number of change options presented ? 申請變更可選反性的復雜程度Complexity of the change options requested ? 提出的變更解決方案的衡量Scale of the change solutions proposed 變更經理將不會在變更日志中打開一份變更申請并記錄是否需要一個變更可行性研究。The Change Manager will open a 慍hange Request’ in the Change Log and record whether or not a change feasibility study is required.2.4 識別變更可行性

本步驟涉及完成一份完整的變更可行性研究，以確保對所有的變更可選項進行調查并上報，變更可行性研究包括對以下各項的定義：

? 變更需求

? 變更可選項Change options ? 變更成本及利益

? 變更風險及事項Change risks and issues ? 變更帶來的影響 ? 變更的建議和計劃

對對可行性研究進行認真審核以確保研究是切題的，同時確保（經過變更后的）最終的可交付成果是可以通過的—那研究報告就可以上報變更審批小組了。變更經理將整理所有變更文件并報變更審批小組做最終審核。這些文件包括：: ? 原始的變更申請表

? 已通過的變更可行性研究報告 ? 所有支持性文件

2.5 批準變更申請

本步驟涉及變更審批小組對變更申請的正式審核。變更審批小組可能做出下列任何一種結論：

? 拒絕變更Reject the change ? 要求與變更相關的更多信息Request more information related to the change ? 批準變更申請Approve the change as requested ? 在特定條件下批準變更Approve the change subject to specified conditions

決定是否變更的標準大致為：

? 實施變更給項目帶來的風險 ? 不實施變更給項目帶來的風險

? 實施變更對項目產生的影響（時間、資源、財務、質量方面）?

2.6 實施變更申請

本步驟涉及對變更的全面實施，包括: ? ? ? ? ? ? 確定變更進度（如：實施變更的日期）

實施前對變更進行測試Testing the change prior to implementation 實施變更

對實施變更的成功度進行審核 就實施變更的成功度進行溝通 在變更日志中結束變更 變更職責

對項目中啟動、審核和實施變更所涉及的所有資源（包括項目中或項目之外的資源）的職責和責任進行定義，如：

3.1 變更申請人

變更申請人最初意識到對項目進行變更的必要性并就此需求與變更經理進行正式溝通。其主要職責為: ? 及早識別對項目進行變更的需求

? 通過完成變更需求表來完成對更申請的正式文件 ? 將變更申請表提交變更經理以供審

3.2 變更經理

變更經理對一個項目中所有的變更進行接收、記錄、監測和控制。其主要職責為：

? 接收所有的變更申請并將其記錄于變更登記簿中 ? 將所有的變更申請進行分類、優選

? 審核所有變更申請以確定在提交變更審核小組前是否還需增加有關信息 ? 確定是否需要進行一個正式的可行性研究并提交變更審核小組 ? 通過委派變更可行性研究小組來啟動變更可行生研

? 對所有的變更申請進展情況進行監測以確保項目按時完成 ? 將所有的變更申請問題和風險上報變更審批小組 ? 就變更審批小組做出的所有決定進行下達和溝通

3.3 變更可行性研究（可研）小組

變更可行性小組負責完成由變更經理簽發的對于某變更申請的正式的可行性研究，主要職責為：

? 通過進行摸擬研究來確定變更可能的要素：成本、利益和變更帶來的影響。? 將變更可行性研究報告中的所有發現形成文字 ? 對報告進行認真審核并批準交其上報。? 將報告轉變更經理以提交變更審批小組 ?

3.4 變更審批小組

變更審批小組決定是否批準變更經理轉來的所有變更申請。其主要職責為：

? 審核變更經理轉來的所有變更申請 ? 考慮所有變更支持性文件

? 根據每個變更申請的相關價值決定批準還是拒絕 ? 解決變更爭議（當兩個或兩以上變更撞車時）? 解決變更問題Resolving change issues ? 決定實施變更時間表

3.5 變更實施小組

變更實施小組對項目中所有變更的實施進行計劃、落實和審核。變更實施小組主要負責： ? ? ? ? ? 計劃所有變更的進度（在變更審批小組提供的總體時間框架范圍內）)在實施前對所有變更進行測試 實施項目中的所有變更 實施后審核變更的成功度 在變更日志中請求結束變更 變更登記簿

變更登記簿是用于登記、跟蹤變更申請進展情況的日志/數據庫。描述項目變更登記簿的目的和用途，在下面插入一個真實的變更登記文本 變更模版

插入所需的每個模版（如變更申請表）以對項目中變更的效果加以啟動、執行、實施和考量。