第一篇：項目軟件開發(fā)的質量保障方案

軟件項目開發(fā)質量保障方案

一、項目質量管理內容

1.1.項目編制和評審質量計劃

項目制定質量保證計劃：依據(jù)項目計劃及項目質量目標確定需要檢查的主要過程和工作產(chǎn)品，識別項目過程中的干系人及其活動，估計檢查時間和人員，并制定出本項目的質量保證計劃。

質量保證計劃的主要內容包括：例行審計和里程碑評審，需要監(jiān)督的重要活動和工作產(chǎn)品，確定審計方式，根據(jù)項目計劃中的評審計劃確定質量保證人員需要參加的評審計劃。明確質量審計報告的報送范圍。

質量保證計劃的評審：質量保證計劃需要經(jīng)過評審方能生效，以確保質量保證計劃和項目計劃的一致性。經(jīng)過批準的質量保證計劃需要納入配置管理。當項目計劃變更時，需要及時更改和復審質量保證計劃。

1.2.“過程和工作產(chǎn)品”的質量檢查

根據(jù)質量保證計劃進行質量的審計工作，并發(fā)布質量審計報告。

審計的主要內容包括：是否按照過程要求執(zhí)行了相應的活動，是否按照過程要求產(chǎn)生了相應的工作產(chǎn)品。本項目中對質量的控制主要體現(xiàn)在不同階段的審計當中。

1.3.不符合項的跟蹤處理

對審計中發(fā)現(xiàn)的不符合項，要求項目組及時處理，質量保證人員需要確認不符合項的狀態(tài)，直到最終的不符合項狀態(tài)為“完成”為止。

二、質量管理責任分配

開發(fā)項目上按照規(guī)范化軟件的生產(chǎn)方式進行開發(fā)。每個項目除配備了項目開發(fā)所需角色外，還專門配備了質量保證小組、配置管理小組、測試小組來確保質量管理的實施，下面針對這三種角色進行說明： 2.1.質量保證小組職責

質量保證小組作為質量保證的實施小組，在項目開發(fā)的過程中幾乎所有的部門都與質量保證小組有關。質量保證小組的主要職責是：以獨立審查方式，從第三方的角度監(jiān)控軟件開發(fā)任務的執(zhí)行，分析項目內存在的質量問題，審查項目的質量活動，給出質量審計報告。就項目是否遵循已制定的計劃、標準和規(guī)程，給開發(fā)人員和管理層提供反映產(chǎn)品和過程質量的信息和數(shù)據(jù)，使他們能了解整個項目生存周期中工作產(chǎn)品和過程的情況，提高項目透明度，從而支持其交付高質量的軟件產(chǎn)品。

質量保證人員依據(jù)質量保證計劃，通過質量審計報告向項目經(jīng)理及有關人員提出已經(jīng)識別出的不符合項，并跟蹤不符合項的解決過程，通過審計周報或者審計月報向項目經(jīng)理提供過程和產(chǎn)品質量數(shù)據(jù)，并與項目組協(xié)商不符合項的解決辦法。

質量保證小組的檢測范圍主要包括：項目的進度是否按照項目計劃執(zhí)行，用戶需求是否得到了用戶的簽字確認，軟件需求是否正確的反映了用戶的需求，是否將每一項用戶需求都映射到軟件需求；系統(tǒng)設計是否完全反映了軟件需求；實現(xiàn)的軟件是否正確的體現(xiàn)了系統(tǒng)設計；測試人員是否進行了較為徹底的和全面的測試；客戶驗收和交接清單是否完備；對于系統(tǒng)運行中出現(xiàn)的問題，維護人員是否記錄了詳細的維護記錄；配置管理員是否按照配置管理計劃建立了基線，是否嚴格控制變更過程，是否對配置庫進行了維護。

2.2.配置管理小組職責

配置管理活動的目的是通過執(zhí)行版本控制、變更控制、基線管理等規(guī)程，借助配置管理工具的使用，來保證整個生命周期過程產(chǎn)生的所有配置項的完整性、一致性和可追溯性。配置管理是對工作成果（階段工作成果和產(chǎn)品成果、進展狀態(tài)成果）的一種有效保護形式，是反映項目及其工作產(chǎn)品的過去、現(xiàn)在、動態(tài)的資料和數(shù)據(jù)集中管理體現(xiàn)。

配置管理小組的主要職責包括：根據(jù)項目計劃制定配置管理計劃，建立配置庫，為項目組人員分配配置庫權限，創(chuàng)建需求、設計、開發(fā)、測試、交付階段的基線。當納入基線庫的工作產(chǎn)品發(fā)生變更時，嚴格按照配置項變更控制過程執(zhí)行變更，變更后建立新的基線。

2.3.測試小組職責

作為質量控制的主要手段，如同軟件開發(fā)一樣，測試在執(zhí)行之前，測試小組制定軟件測試計劃、測試用例的編寫和執(zhí)行工作。

測試可以分為如下幾種類型：代碼走查、單元測試、集成測試、系統(tǒng)測試。為了保證程序的質量，開發(fā)人員需要對同伴的代碼進行代碼走查，同時對自己編寫的程序進行單元測試，確保程序編譯、運行正確。

測試人員根據(jù)軟件需求分析報告進行軟件集成測試用例和系統(tǒng)測試用例的編寫。對編寫完成的測試用例提交項目組進行評審，同時質量保證人員對評審過程和工作產(chǎn)品進行監(jiān)測。

測試人員根據(jù)測試計劃和測試用例執(zhí)行測試用例，并對發(fā)現(xiàn)的缺陷進行記錄，只有這樣才能確保項目組開發(fā)的軟件產(chǎn)品滿足用戶需求。在完成集成測試之后，可以進行軟件系統(tǒng)測試，系統(tǒng)測試包括對軟件進行功能測試、性能測試、安全測試、壓力測試。只有進行了系統(tǒng)測試軟件測試才是完整的。系統(tǒng)測試在本項目中占有重要的地位，性能要求有可能改變軟件的設計，為避免造成軟件的后期返工，測試在性能上需要較大的側重。

三、質量保證措施

通過質量管理責任的分配，通過如下幾個方面來進行質量保證的實施過程：

3.1.項目進度

項目計劃的制定為工程項目實施、管理和支持工作、項目進度、成本、質量及過程產(chǎn)品的有效控制打下了良好的基礎，以便所有相關人員能夠按照該計劃有條不紊地開展工作；制定《項目計劃》，必須獲得相關干系人的認可，并以此作為項目跟蹤的基礎。

項目進度是項目進行是否順利的最直觀表現(xiàn)。制定合理的項目計劃首要前提是選擇從事類似規(guī)模和類似業(yè)務項目的有經(jīng)驗的項目負責人參加制定項目進度計劃。

項目計劃由項目負責人制定，由項目各小組組長、項目成員、干系人、質量保證人員參加一起進行評審。評審過程主要討論項目計劃的可行性，對其中不合理的地方提出修改意見，對計劃中不合理的地方進行修改完善，并由質量保證人員對其結果進行跟蹤處理，以確保項目計劃完整性、可行性，項目計劃評審通過后，交由配置管理人員進行配置管理。

在計劃實施過程中，按項目計劃中里程碑為界限，將整個開發(fā)周期劃分為若干階段。根據(jù)里程碑的完成情況，適當?shù)恼{整每一個較小的階段的任務量和完成的任務時間，動態(tài)跟蹤和動態(tài)調整，以利于項目質量保證的實施。

實際運作中，質量保證人員在對項目執(zhí)行過程進行檢查時，對于發(fā)現(xiàn)的項目偏差，以質量審計報告的形式提交項目負責人。由項目負責人組織人員對計劃進行維護，對于已經(jīng)變動的項目計劃，由配置管理進行配置管理。

3.2.需求分析

需求分析是開發(fā)人員對系統(tǒng)需要做什么和如何做的定義過程。從系統(tǒng)分析的經(jīng)驗來看，這個過程往往是個循序漸進的過程，一次性對系統(tǒng)形成完整的認識是困難的。只有不斷地和客戶領域專家進行交流確認，方能逐步明了用戶的需求。從系統(tǒng)開發(fā)的過程得知，系統(tǒng)分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發(fā)的后期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發(fā)影響系統(tǒng)的工期和系統(tǒng)的質量。

本項目中將邀請公司業(yè)務顧問參與需求調研，以便保證需求調研質量，同時形成用戶需求說明書。需求評審時由公司管理層、項目實施層共同進行，對于通過用戶確認的需求，交由配置管理員形成需求基線。

用戶需求在招標方確認后，由系統(tǒng)分析人員形成軟件需求分析報告，同時對軟件需求分析報告進行評審，對于評審通過的軟件需求分析報告可以交由測試人員進行測試計劃和測試用例的編寫。

對于開發(fā)過程存在的需求變動，需要填寫變更申請單發(fā)給項目經(jīng)理，在質量保證人員參加的情況下，對這個變更進行評審，由項目經(jīng)理組織項目組成員一起討論實施變更的可行性及實施后所帶來的影響，對于影響小的變更直接記錄，大的變更則需要形成正式的變更報告，無論那種變更都需要對相應的文檔實施同步變更（包括需求分析報告、系統(tǒng)設計、安裝手冊、操作手冊等）。但是對于無法實現(xiàn)或是變更會帶來巨大的影響而將導致進度的延期，這時，將變更報告提交給用戶并召開協(xié)調會議，討論變更取舍問題或是項目進度變更問題。

決定變更之后，由項目負責人組織實施變更，測試人員檢測變更結果，而質量保證人員監(jiān)督變更實施過程，并協(xié)助配置管理員對變更后的成果進行配置管理。變更實施完后，運行前還需要協(xié)助用戶一同測試并由用戶簽字后同意方可上線。

3.3.系統(tǒng)設計

優(yōu)良的體系結構應當具備可擴展性和可配置性，而好的體系結構則需要好的設計方法，需要針對項目的結構、項目的特征和用戶的需求來分析。項目中將安排我公司高級系統(tǒng)架構師擔當項目總體設計師，匯同總體設計組完成系統(tǒng)設計。

另外對公共類模塊的開發(fā)。由總體設計組通過對需求的仔細研究，盡可能的識別出公共類，并進行定義和設計，以減少重復工作。對于項目組提供的設計文檔，由項目經(jīng)理組織，質保小組成員參與，對其設計文檔進行評審，及時發(fā)現(xiàn)設計中可能存在的錯誤，降低項目開發(fā)風險，同時確保設計文檔能為開發(fā)人員、測試人員提供確實的指導。對于可復用的設計進行提取作為公共庫設計和開發(fā)，提供項目組。最后交由配置管理員進行設計文檔的版本控制。

3.4.系統(tǒng)實現(xiàn)

系統(tǒng)實現(xiàn)的目的是依據(jù)系統(tǒng)設計文檔，由程序員進行程序編寫，以便實現(xiàn)設計要求，系統(tǒng)實現(xiàn)過程中，開發(fā)人員需要對模塊進行代碼走查和交叉單元測試，以保證模塊代碼質量。軟件實現(xiàn)也就是代碼的生產(chǎn)過程。根據(jù)上一階段形成的設計文檔，程序員在完成代碼之后，可以開始編碼并且進行代碼走查和單元測試。對于測試完成的程序可以交由配置管理人員進行配置管理。

3.5.系統(tǒng)測試

系統(tǒng)開發(fā)涉及到一系列的過程，每一個過程都有可能引入缺陷，系統(tǒng)質量的好壞直接關系到正常使用和日后的維護。在開發(fā)過程中，我們將質量控制貫穿于所有階段和所有參與系統(tǒng)的人員中，包括系統(tǒng)分析、設計和編碼。分階段的評審和測試是軟件質量的有力保障。

系統(tǒng)存在平臺測試和應用系統(tǒng)的測試以及最終的測試。由于測試也存在協(xié)調的問題，如問題定位，在應用系統(tǒng)發(fā)現(xiàn)一個錯誤，到底是應用系統(tǒng)的自身的錯誤還是中間件存在的錯誤，需要開發(fā)人員進行準確的判斷。為了達到良好的測試目的，本系統(tǒng)測試工作由測試組來完成，主要采用下列方法進行系統(tǒng)的測試：

從測試方法上來說，分為黑盒測試和白盒測試：

黑盒測試：著重于測試軟件系統(tǒng)的外部特性；根據(jù)系統(tǒng)的設計要求，每一項功能都要進行逐個測試，檢查其是否達到了預期的要求，是否能正確地接受輸入，是否能正確地輸出結果。

白盒測試：由于軟件的所有源代碼都要由項目組成員編寫，對其內部的邏輯規(guī)則和數(shù)據(jù)流程，都要進行測試，以檢查其代碼編寫是否符合設計要求。

從測試策略上來說分為集成測試和系統(tǒng)測試：

集成測試：在所有模塊都通過了單元測試后，將各個模塊組裝在一起，進行組裝測試，用于發(fā)現(xiàn)與接口相聯(lián)系的問題。在通過組裝測試后，將經(jīng)過單元測試的模塊組裝成一個符合設計要求的軟件結構。

系統(tǒng)測試：項目通過了以上的測試步驟后，與其它系統(tǒng)元素（如硬件服務器、網(wǎng)絡系統(tǒng)等）進行集成測試和系統(tǒng)級的確認測試，將各種可能的缺陷完全排除掉，從根本上保證系統(tǒng)的長期穩(wěn)定運行。

3.6.系統(tǒng)維護

在項目中，技術支持小組的任務一方面是保證對項目客戶的跟蹤服務，另一方面是確保該項目的技術咨詢工作。

在系統(tǒng)維護期，對于一般性的錯誤，如操作不當?shù)纫鸬膯栴}，全部由技術支持小組執(zhí)行完成，但需要用戶測試確認上線。如果較大的修改則需要走變更控制流程，填寫變更申請，經(jīng)項目組討論分析可行方案在由技術支持小組實施，通過測試后方可提交用戶。在這個過程中質量人員需要對維護過程和維護記錄單進行檢查。

第二篇：軟件開發(fā)質量保障方案

軟件開發(fā)質量保障方案

一、質量管理內容

1.1.編制和評審質量計劃

制定質量保證計劃：依據(jù)項目計劃及項目質量目標確定需要檢查的主要過程和工作產(chǎn)品，識別項目過程中的干系人及其活動，估計檢查時間和人員，并制定出本項目的質量保證計劃。

質量保證計劃的主要內容包括：例行審計和里程碑評審，需要監(jiān)督的重要活動和工作產(chǎn)品，確定審計方式，根據(jù)項目計劃中的評審計劃確定質量保證人員需要參加的評審計劃。明確質量審計報告的報送范圍。

質量保證計劃的評審：質量保證計劃需要經(jīng)過評審方能生效，以確保質量保證計劃和項目計劃的一致性。經(jīng)過批準的質量保證計劃需要納入配置管理。當項目計劃變更時，需要及時更改和復審質量保證計劃。

1.2.“過程和工作產(chǎn)品”的質量檢查

根據(jù)質量保證計劃進行質量的審計工作，并發(fā)布質量審計報告。

審計的主要內容包括：是否按照過程要求執(zhí)行了相應的活動，是否按照過程要求產(chǎn)生了相應的工作產(chǎn)品。本項目中對質量的控制主要體現(xiàn)在不同階段的審計當中。

1.3.不符合項的跟蹤處理

對審計中發(fā)現(xiàn)的不符合項，要求項目組及時處理，質量保證人員需要確認不符合項的狀態(tài)，直到最終的不符合項狀態(tài)為“完成”為止。

二、質量管理責任分配

開發(fā)項目上按照規(guī)范化軟件的生產(chǎn)方式進行開發(fā)。每個項目除配備了項目開發(fā)所需角色外，還專門配備了質量保證小組、配置管理小組、測試小組來確保質量管理的實施，下面針對這三種角色進行說明： 2.1.質量保證小組職責

質量保證小組作為質量保證的實施小組，在項目開發(fā)的過程中幾乎所有的部門都與質量保證小組有關。質量保證小組的主要職責是：以獨立審查方式，從第三方的角度監(jiān)控軟件開發(fā)任務的執(zhí)行，分析項目內存在的質量問題，審查項目的質量活動，給出質量審計報告。就項目是否遵循已制定的計劃、標準和規(guī)程，給開發(fā)人員和管理層提供反映產(chǎn)品和過程質量的信息和數(shù)據(jù)，使他們能了解整個項目生存周期中工作產(chǎn)品和過程的情況，提高項目透明度，從而支持其交付高質量的軟件產(chǎn)品。

質量保證人員依據(jù)質量保證計劃，通過質量審計報告向項目經(jīng)理及有關人員提出已經(jīng)識別出的不符合項，并跟蹤不符合項的解決過程，通過審計周報或者審計月報向項目經(jīng)理提供過程和產(chǎn)品質量數(shù)據(jù)，并與項目組協(xié)商不符合項的解決辦法。

質量保證小組的檢測范圍主要包括：項目的進度是否按照項目計劃執(zhí)行，用戶需求是否得到了用戶的簽字確認，軟件需求是否正確的反映了用戶的需求，是否將每一項用戶需求都映射到軟件需求；系統(tǒng)設計是否完全反映了軟件需求；實現(xiàn)的軟件是否正確的體現(xiàn)了系統(tǒng)設計；測試人員是否進行了較為徹底的和全面的測試；客戶驗收和交接清單是否完備；對于系統(tǒng)運行中出現(xiàn)的問題，維護人員是否記錄了詳細的維護記錄；配置管理員是否按照配置管理計劃建立了基線，是否嚴格控制變更過程，是否對配置庫進行了維護。

2.2.配置管理小組職責

配置管理活動的目的是通過執(zhí)行版本控制、變更控制、基線管理等規(guī)程，借助配置管理工具的使用，來保證整個生命周期過程產(chǎn)生的所有配置項的完整性、一致性和可追溯性。配置管理是對工作成果（階段工作成果和產(chǎn)品成果、進展狀態(tài)成果）的一種有效保護形式，是反映項目及其工作產(chǎn)品的過去、現(xiàn)在、動態(tài)的資料和數(shù)據(jù)集中管理體現(xiàn)。

配置管理小組的主要職責包括：根據(jù)項目計劃制定配置管理計劃，建立配置庫，為項目組人員分配配置庫權限，創(chuàng)建需求、設計、開發(fā)、測試、交付階段的基線。當納入基線庫的工作產(chǎn)品發(fā)生變更時，嚴格按照配置項變更控制過程執(zhí)行變更，變更后建立新的基線。

2.3.測試小組職責

作為質量控制的主要手段，如同軟件開發(fā)一樣，測試在執(zhí)行之前，測試小組制定軟件測試計劃、測試用例的編寫和執(zhí)行工作。

測試可以分為如下幾種類型：代碼走查、單元測試、集成測試、系統(tǒng)測試。為了保證程序的質量，開發(fā)人員需要對同伴的代碼進行代碼走查，同時對自己編寫的程序進行單元測試，確保程序編譯、運行正確。

測試人員根據(jù)軟件需求分析報告進行軟件集成測試用例和系統(tǒng)測試用例的編寫。對編寫完成的測試用例提交項目組進行評審，同時質量保證人員對評審過程和工作產(chǎn)品進行監(jiān)測。

測試人員根據(jù)測試計劃和測試用例執(zhí)行測試用例，并對發(fā)現(xiàn)的缺陷進行記錄，只有這樣才能確保項目組開發(fā)的軟件產(chǎn)品滿足用戶需求。在完成集成測試之后，可以進行軟件系統(tǒng)測試，系統(tǒng)測試包括對軟件進行功能測試、性能測試、安全測試、壓力測試。只有進行了系統(tǒng)測試軟件測試才是完整的。系統(tǒng)測試在本項目中占有重要的地位，性能要求有可能改變軟件的設計，為避免造成軟件的后期返工，測試在性能上需要較大的側重。

三、質量保證措施

通過質量管理責任的分配，通過如下幾個方面來進行質量保證的實施過程：

3.1.項目進度

項目計劃的制定為工程項目實施、管理和支持工作、項目進度、成本、質量及過程產(chǎn)品的有效控制打下了良好的基礎，以便所有相關人員能夠按照該計劃有條不紊地開展工作；制定《項目計劃》，必須獲得相關干系人的認可，并以此作為項目跟蹤的基礎。

項目進度是項目進行是否順利的最直觀表現(xiàn)。制定合理的項目計劃首要前提是選擇從事類似規(guī)模和類似業(yè)務項目的有經(jīng)驗的項目負責人參加制定項目進度計劃。

項目計劃由項目負責人制定，由項目各小組組長、項目成員、干系人、質量保證人員參加一起進行評審。評審過程主要討論項目計劃的可行性，對其中不合理的地方提出修改意見，對計劃中不合理的地方進行修改完善，并由質量保證人員對其結果進行跟蹤處理，以確保項目計劃完整性、可行性，項目計劃評審通過后，交由配置管理人員進行配置管理。

在計劃實施過程中，按項目計劃中里程碑為界限，將整個開發(fā)周期劃分為若干階段。根據(jù)里程碑的完成情況，適當?shù)恼{整每一個較小的階段的任務量和完成的任務時間，動態(tài)跟蹤和動態(tài)調整，以利于項目質量保證的實施。

實際運作中，質量保證人員在對項目執(zhí)行過程進行檢查時，對于發(fā)現(xiàn)的項目偏差，以質量審計報告的形式提交項目負責人。由項目負責人組織人員對計劃進行維護，對于已經(jīng)變動的項目計劃，由配置管理進行配置管理。

3.2.需求分析

需求分析是開發(fā)人員對系統(tǒng)需要做什么和如何做的定義過程。從系統(tǒng)分析的經(jīng)驗來看，這個過程往往是個循序漸進的過程，一次性對系統(tǒng)形成完整的認識是困難的。只有不斷地和客戶領域專家進行交流確認，方能逐步明了用戶的需求。從系統(tǒng)開發(fā)的過程得知，系統(tǒng)分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發(fā)的后期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發(fā)影響系統(tǒng)的工期和系統(tǒng)的質量。

本項目中將邀請公司業(yè)務顧問參與需求調研，以便保證需求調研質量，同時形成用戶需求說明書。需求評審時由公司管理層、項目實施層共同進行，對于通過用戶確認的需求，交由配置管理員形成需求基線。

用戶需求在招標方確認后，由系統(tǒng)分析人員形成軟件需求分析報告，同時對軟件需求分析報告進行評審，對于評審通過的軟件需求分析報告可以交由測試人員進行測試計劃和測試用例的編寫。

對于開發(fā)過程存在的需求變動，需要填寫變更申請單發(fā)給項目經(jīng)理，在質量保證人員參加的情況下，對這個變更進行評審，由項目經(jīng)理組織項目組成員一起討論實施變更的可行性及實施后所帶來的影響，對于影響小的變更直接記錄，大的變更則需要形成正式的變更報告，無論那種變更都需要對相應的文檔實施同步變更（包括需求分析報告、系統(tǒng)設計、安裝手冊、操作手冊等）。但是對于無法實現(xiàn)或是變更會帶來巨大的影響而將導致進度的延期，這時，將變更報告提交給用戶并召開協(xié)調會議，討論變更取舍問題或是項目進度變更問題。

決定變更之后，由項目負責人組織實施變更，測試人員檢測變更結果，而質量保證人員監(jiān)督變更實施過程，并協(xié)助配置管理員對變更后的成果進行配置管理。變更實施完后，運行前還需要協(xié)助用戶一同測試并由用戶簽字后同意方可上線。

3.3.系統(tǒng)設計

優(yōu)良的體系結構應當具備可擴展性和可配置性，而好的體系結構則需要好的設計方法，需要針對項目的結構、項目的特征和用戶的需求來分析。項目中將安排我公司高級系統(tǒng)架構師擔當項目總體設計師，匯同總體設計組完成系統(tǒng)設計。

另外對公共類模塊的開發(fā)。由總體設計組通過對需求的仔細研究，盡可能的識別出公共類，并進行定義和設計，以減少重復工作。對于項目組提供的設計文檔，由項目經(jīng)理組織，質保小組成員參與，對其設計文檔進行評審，及時發(fā)現(xiàn)設計中可能存在的錯誤，降低項目開發(fā)風險，同時確保設計文檔能為開發(fā)人員、測試人員提供確實的指導。對于可復用的設計進行提取作為公共庫設計和開發(fā)，提供項目組。最后交由配置管理員進行設計文檔的版本控制。

3.4.系統(tǒng)實現(xiàn)

系統(tǒng)實現(xiàn)的目的是依據(jù)系統(tǒng)設計文檔，由程序員進行程序編寫，以便實現(xiàn)設計要求，系統(tǒng)實現(xiàn)過程中，開發(fā)人員需要對模塊進行代碼走查和交叉單元測試，以保證模塊代碼質量。軟件實現(xiàn)也就是代碼的生產(chǎn)過程。根據(jù)上一階段形成的設計文檔，程序員在完成代碼之后，可以開始編碼并且進行代碼走查和單元測試。對于測試完成的程序可以交由配置管理人員進行配置管理。

3.5.系統(tǒng)測試

系統(tǒng)開發(fā)涉及到一系列的過程，每一個過程都有可能引入缺陷，系統(tǒng)質量的好壞直接關系到正常使用和日后的維護。在開發(fā)過程中，我們將質量控制貫穿于所有階段和所有參與系統(tǒng)的人員中，包括系統(tǒng)分析、設計和編碼。分階段的評審和測試是軟件質量的有力保障。

系統(tǒng)存在平臺測試和應用系統(tǒng)的測試以及最終的測試。由于測試也存在協(xié)調的問題，如問題定位，在應用系統(tǒng)發(fā)現(xiàn)一個錯誤，到底是應用系統(tǒng)的自身的錯誤還是中間件存在的錯誤，需要開發(fā)人員進行準確的判斷。為了達到良好的測試目的，本系統(tǒng)測試工作由測試組來完成，主要采用下列方法進行系統(tǒng)的測試：

從測試方法上來說，分為黑盒測試和白盒測試：

黑盒測試：著重于測試軟件系統(tǒng)的外部特性；根據(jù)系統(tǒng)的設計要求，每一項功能都要進行逐個測試，檢查其是否達到了預期的要求，是否能正確地接受輸入，是否能正確地輸出結果。

白盒測試：由于軟件的所有源代碼都要由項目組成員編寫，對其內部的邏輯規(guī)則和數(shù)據(jù)流程，都要進行測試，以檢查其代碼編寫是否符合設計要求。

從測試策略上來說分為集成測試和系統(tǒng)測試：

集成測試：在所有模塊都通過了單元測試后，將各個模塊組裝在一起，進行組裝測試，用于發(fā)現(xiàn)與接口相聯(lián)系的問題。在通過組裝測試后，將經(jīng)過單元測試的模塊組裝成一個符合設計要求的軟件結構。

系統(tǒng)測試：項目通過了以上的測試步驟后，與其它系統(tǒng)元素（如硬件服務器、網(wǎng)絡系統(tǒng)等）進行集成測試和系統(tǒng)級的確認測試，將各種可能的缺陷完全排除掉，從根本上保證系統(tǒng)的長期穩(wěn)定運行。

3.6.系統(tǒng)維護

本項目中，技術支持小組的任務一方面是保證對項目客戶的跟蹤服務，另一方面是確保該項目的技術咨詢工作。

系統(tǒng)維護期，對于一般性的錯誤，如操作不當?shù)纫鸬膯栴}，全部由技術支持小組執(zhí)行完成，但需要用戶測試確認上線。如果較大的修改則需要走變更控制流程，填寫變更申請，經(jīng)項目組討論分析可行方案在由技術支持小組實施，通過測試后方可提交用戶。在這個過程中質量人員需要對維護過程和維護記錄單進行檢查。

第三篇：軟件開發(fā)項目實訓方案

軟件開發(fā)實訓項目方案

——北京中科海教育科技有限公司

一.實訓公司介紹

科海集團是在1983年5月由中國科學院和北京市海淀區(qū)政府聯(lián)合創(chuàng)辦，是中關村最早成立的高新技術企業(yè)，國內知名的IT企業(yè)，與“四通、融通、京海、科?！辈⒎Q為中關村的“兩通兩海”。2003年，科海集團投資創(chuàng)辦北京金科?？萍及l(fā)展有限公司。2004年，公司被認定為中關村高新企業(yè)。

北京中科海教育科技有限公司是以軟件開發(fā)為主的高科技公司，專注于技術提高用戶體驗為目標，我們追求軟件產(chǎn)品的最優(yōu)化，致力于為客戶打造最實用的軟件產(chǎn)品。我們主要致力于全球中小型企業(yè)信息化系統(tǒng)的開發(fā)工作，包括CRM，ERP，協(xié)同系統(tǒng)等。涉及政府，房地產(chǎn)，醫(yī)藥等多個行業(yè)。同時為廣大客戶提供全方位的網(wǎng)絡綜合信息化服務及多層次電子商務解決方案。協(xié)助企業(yè)創(chuàng)建完備出色的互聯(lián)網(wǎng)信息平臺，利用現(xiàn)代科技手段把握機遇，并創(chuàng)造更高價值。其下屬的全資子機構，北京新科海學校致力于IT職業(yè)技能培訓業(yè)務，牢固樹立以就業(yè)為導向，以服務為宗旨的辦學理念，多年來培養(yǎng)了大量的IT領域高技術專門人才，為區(qū)域經(jīng)濟和社會發(fā)展做出了巨大貢獻。

二.關于大學生就業(yè)實訓

2009年，全國應屆高校畢業(yè)生將達到萬人，加上往年未就業(yè)的高校畢業(yè)生，就業(yè)需求極大。而另一方面，受當前經(jīng)濟形勢影響，出現(xiàn)了企業(yè)用工需求下降、現(xiàn)有崗位非正常流失等新情況、新問題，致使當今大學生就業(yè)問題顯得尤為突出。與此同時，當今高等教育和社會需求之間并不能很好地銜接，企業(yè)需要的是復合型、實用技能型人才，而高校畢業(yè)生所受教育普遍存在與其日后從事崗位所需的實踐技能脫節(jié)的問題，學歷層次不等于技能層次。

按照教育服務市場需求、服從產(chǎn)業(yè)結構調整的原則，改造現(xiàn)有高校課程設置結構、調整專業(yè)培養(yǎng)方向、強化實用技能培訓、為學生提供就業(yè)項目實訓等創(chuàng)新培養(yǎng)模式成為必然。

為推進高等教育、職業(yè)培訓與社會需求相銜接，北京中科海教育科技有限公司推出IT領域大學生就業(yè)實訓項目，本課程由IT企業(yè)為新入職技術職位員工的內訓課程改造而來，主要針對高校計算機及相關專業(yè)畢業(yè)生，通過專業(yè)的項目開發(fā)訓練，讓學員們在完

成項目的過程中鞏固在學校里學習到的基礎知識。獲得實用、領先的就業(yè)經(jīng)驗技能；增加求職競爭力，并在其職業(yè)生涯第一年擁有明顯優(yōu)勢；在職人員可以豐富自己的職業(yè)技能，開拓更為廣闊的職業(yè)道路。

三.實訓項目介紹

Java軟件開發(fā)實訓項目

實訓目標：

軟件開發(fā)實訓課程，通過一個完整的軟件開發(fā)項目，使具有一定編碼基礎、但沒有或只有很少實際工作經(jīng)驗的學員能夠了解軟件項目開發(fā)的整個過程，并最終具備編寫項目可行性研究報告、項目開發(fā)計劃書、軟件需求文檔、概要設計和詳細設計文檔、用戶手冊及項目開發(fā)總結報告的能力。

實訓項目資料：

開發(fā)環(huán)境配置手冊項目需求文檔項目概要設計文檔項目詳細設計文檔項目數(shù)據(jù)庫設計文檔程序代碼規(guī)范開發(fā)流程規(guī)范程序代碼質量控制規(guī)范

項目一: 內容管理系統(tǒng)CMS設計與實現(xiàn)

內容管理系統(tǒng)（Content Management System，CMS）內容管理系統(tǒng)是企業(yè)信息化建設和電子政務的新寵，也是一個相對較新的市場，CMS其實是一個很廣泛的稱呼，從一般的博客程序，新聞發(fā)布程序，到綜合性的網(wǎng)站管理程序都可以被稱為內容管理系統(tǒng)。

在CMS領域，在各個層面都有極多地優(yōu)點，在政府上網(wǎng)，學校上網(wǎng)，商業(yè)門戶，信息港，地方門戶網(wǎng)，等各種設計到文章發(fā)布和用管理的網(wǎng)站建設中。其特點/優(yōu)勢如下：

-可以針對各種內容進行分類和發(fā)布管理。可以針對不同類型的用戶發(fā)布不

同的內容，可以將各種內容進行分類。

-可以任意定義內容類型與多媒體支持。

-用戶接口可編輯性強，可以根據(jù)客戶要求訂做用戶接口和風格模塊。

-可分布式管理。站點管理和維護人員無須集中在同一個辦公室，甚至都不

用在同城，全球任何一個有網(wǎng)絡的地方都可以讓您實現(xiàn)高效率的管理。

-可開發(fā)性強，可以針對不同的需求進行專門的開發(fā)。

容易使用。用戶不必具備計算機編程基礎、只需根據(jù)用戶操作手冊（或經(jīng)

過簡單演示）就可以輕松地管理并運作整套系統(tǒng)。

系統(tǒng)開發(fā)與運行環(huán)境：

-服務器：基于Intel構架的企業(yè)服務器

-操作系統(tǒng)：Microsoft Windows 200x/XP

-支持環(huán)境：Tomcat/WebLogic Server、JDK

-數(shù) 據(jù) 庫：Oracle

-編程語言：Java、Servlet、JSP、Javabeans、HTML

-設計工具： Dreamweaver、Photoshop、Eclipse等

-客戶端：IE6.0以上

前提知識/技術：JavaSE、Java Web編程（JSP/Servlet/JavaBean）、數(shù)據(jù)庫應用、JDBC編程。

項目二: 網(wǎng)絡實時通訊系統(tǒng)設計與實現(xiàn)

實時通訊系統(tǒng)（Real-time Communication System，RCS）也稱“即時通訊工具”，用于實現(xiàn)網(wǎng)絡即使通訊——利用有效硬件，如電腦、視頻、可視電話、手機等，在這些終端硬件上安裝實時通訊程序，如QQ、ICQ、MSN、網(wǎng)易POPO等，只要雙方都安裝有同樣的這種程序，然后利用網(wǎng)絡連接在線，就可以類似面對面交流一樣，實行語音、文字、視頻等的實時交流。

系統(tǒng)開發(fā)與運行環(huán)境：

-服務器/客戶端：主流PC

-操作系統(tǒng)：Microsoft Windows 200x/XP

-支持環(huán)境：Sun JDK

-數(shù) 據(jù) 庫：Oracle

-編程語言：Java SE

-設計工具：UltraEdit/Jcreator/Eclipse等

前提知識/技術：JavaSE、Java GUI編程、Java Scoket編程、多線程編程、數(shù)據(jù)庫應用、JDBC編程。

四.實習特色及優(yōu)勢

實訓周期：

項目實訓時間由院校和我公司雙方協(xié)商，實訓學時：80學時（兩周）。

資深專家

行業(yè)內資深技術專家親自指導，他們在技術、項目及職業(yè)發(fā)展方面的經(jīng)驗與成就，為參加實習的學生提供最直接高效的實習效果。

全真項目

項目也是至關重要的因素，學生實習的項目就是公司真實開發(fā)的項目，代表了當前國際國內IT行業(yè)最主流的技術方向及應用領域。

贈送資料

凡參加暑期實訓的學員均贈送java學習視頻教程一套

五． 時間安排

暑期項目實訓時間定于2009年7月20日－2009年7月31日，周一至周五全天實訓。

7月20日－7月24日 項目實訓

7月27日－7月31日 項目實訓

7月26日參觀北京奧林匹克公園（免費）

除了暑期之外，其他時間，也歡迎各個大學聯(lián)系我們，組織學生參加我們的免費實訓（為期兩周，無任何學習費用，食宿自理）。

六.后勤保障及服務

接待

我們提供從車站到實習公司的一站式接待服務，院校及學生無需為交通、接站、入住基地等事宜操心。

食宿

公司統(tǒng)一安排食宿，安全衛(wèi)生便捷，以保證所有學生能全身心投入到實習中去。真正感覺北京IT行業(yè)的良好氛圍。

住宿費一天25元，樓房，24小時熱水，有空調。

七.聯(lián)系方式

聯(lián)系人：高老師

北京中科海教育發(fā)展有限公司

電話：010-82608892、82617627

第四篇：軟件開發(fā)項目合同

軟件開發(fā)合同書

甲方：

乙方： 深圳市凱路網(wǎng)絡技術有限公司

鑒于甲方委托乙方軟件開發(fā)，幫助甲方樹立企業(yè)形象，擴大宣傳，拓寬銷售渠道，為明確雙方責任，根據(jù)中國相關法律經(jīng)雙方協(xié)商，簽訂此合同，以期雙方共同遵守。

甲方在此委托乙方進行_軟件的開發(fā)，為明確雙方責任，經(jīng)友好協(xié)商，雙方達成以下協(xié)議：

第一條：項目的內容、價款、開發(fā)進度、交付方式由“合同附錄”載明。

第二條：甲方的權利和義務

１、提供專人與乙方聯(lián)絡。

２、提供所有需要開發(fā)需求的資料給乙方。

３、按照“合同附錄”的要求，及時支付費用。

４、甲方將在著作版權法的范圍內使用本合同標的及相關作品、程序、文件源碼，不得將其復

制、傳播、出售或許可給其它第三方。

５、甲方對合同中的系統(tǒng)軟件、頁面設計，程序開發(fā)享有排它的使用權。

第三條：乙方的權利和義務

１、提供專人與甲方聯(lián)絡。

２、按照“合同附錄”的要求，使用甲方資料，進行軟件的開發(fā)。

３、在“合同附錄”要求的期限內，完成軟件的開發(fā)，并通知甲方進行驗收。

４、在驗收期內甲方要求下，對不合格地方進行修改。

５、本合同標的及相關作品、程序、文件源碼的版權屬于乙方。(版權歸屬應該為嘉源公司)

第四條：驗收

１、驗收標準有以下幾條：

（a）、甲方可以通過任何上網(wǎng)的計算機訪問這個軟件

（b）、軟件系統(tǒng)中不存在任何錯誤或系統(tǒng)運行錯誤，圖片鏈接錯誤（以甲方提供的開發(fā)需求為準）。（功能符合開發(fā)需求，開發(fā)需求需要清晰界定功能）

（c）、網(wǎng)絡程序運行正常。

２、驗收期為一周。

第五條：違約責任

1、任何一方有證據(jù)表明對方已經(jīng)、正在或將要違約，可以中止履行本合同，但應及時通知對方。若對方繼續(xù)不履行、履行不當或者違反本合同，該方可以解除本合同并要求對方賠償損失。

2、因不可抗力而無法承擔責任的一方，應在不可抗力發(fā)生的3天內，及時通知另一方。

3、一方因不可抗力確實無法承擔責任，而造成損失的，不付賠償責任。本合同所稱不可抗力是指不能預見、不能克服并不能避免且對一方當事人造成重大影響的客觀事件，包括但不限于自然災害如洪水、地震、火災和風暴等以及社會事件如戰(zhàn)爭、**、政府行為等。

第六條：保密條款

雙方應嚴格保守在合作過程中所了解的對方的商業(yè)及技術機密，否則應對因此造成的損失進行賠償。

第七條：其它

1、如果本合同任何條款根據(jù)現(xiàn)行法律被確定為無效或無法實施，本合同的其它所有條款將繼續(xù)

有效。此種情況下，雙方將以有效的約定替換該約定，且該有效約定應盡可能接近原約定和本合同相應的精神和宗旨。

2、“合同附錄”規(guī)定的有效期滿，本合同自動失效。屆時雙方若愿意繼續(xù)合作，應重新訂立合同。

3、本合同經(jīng)雙方授權代表簽字并蓋章，自簽訂日起生效。

4、本合同一式兩份，雙方當事人各執(zhí)一份，具有同等法律效力。

第八條：以上條款如有未盡事宜，經(jīng)甲、乙雙方協(xié)商后加以補充。

5、付款方式：項目總費用為八千元(人民幣),在簽定合同當日內預付總項目費用的百分之三十，在軟件完成后交付總項目費用的百分之四十，測試用兩個月沒問題后再付剩下的總項目費用的百分之三十。

甲方：乙方：

甲方代表：乙方代表：

電話：電話：

電子信箱：電子信箱：

日期：日期：

合同附錄

<>

關于購買OA系統(tǒng)信息:

1在線郵局（增加部門群和全公司兩個功能）

新郵件發(fā)郵件發(fā)件箱收郵件廢郵件

2個人文件夾

私人文件夾公共文件夾管理員管理

3辦公用品管理

辦公用品種類領取辦公用品審核領用表發(fā)放辦公用品資料管理

4人事管理

企業(yè)員工資料企業(yè)員工統(tǒng)計 企業(yè)部門員工 員工調職管理員工培訓管理員工考勤管理 5權限設置

部門管理權限職位權限管理用戶帳號設置用戶權限設置系統(tǒng)維護設置 6系統(tǒng)幫助

系統(tǒng)幫助信息管理幫助類別輸入幫助信息

7常用資料

公共信息查詢常用公共網(wǎng)址手機與IP地址查用郵編查詢萬年日歷查詢世界時間查詢常用信息查詢常用網(wǎng)址查詢酒店飯店查詢常用郵編查詢列車資料查詢航班資料查詢單位換算查詢媒體資料查詢

8個人辦公(能否增加部門工作計劃)

個人工作計劃部門工作計劃員工工作任務

9通訊助理

個人通訊錄內部通訊錄外部通訊錄手機短消息

10通知管理

通知管理發(fā)送通知已發(fā)通知已收通知我的通知（做到按部門發(fā)送）11通告管理(發(fā)布通告)

發(fā)布通告管理通告瀏覽通告

12考勤管理+值班管理(能否放在一起,算一個模塊)

設置考勤時間開始考勤今日考勤統(tǒng)計日考勤統(tǒng)計月考勤統(tǒng)計值班管理值班記錄

第五篇：軟件開發(fā)項目管理（范文）

管理目標

1、所有關系人清晰明確地了解項目的需求和期望，努力做到滿足項目所有關系人的不同需求；項目關系人包括：項目團隊成員和項目團隊外(內部/外部客戶，內部/外部合作伙伴，經(jīng)銷商/客戶等)。

2、項目管理三要素平衡（時間/成本/質量），即開發(fā)項目按需按時按質的完成。

3、目標：功能滿足需求，設計支持變化，開發(fā)快速迭代，成果持續(xù)交付。

執(zhí)行概述

1、建立有效的工作流程保證項目的順利進行，初期使用傳統(tǒng)RUP過程，引入部分敏捷方法，團隊磨合完成后逐步實現(xiàn)敏捷開發(fā)全流程管理。

2、明確項目目標，制定具有可行性的項目計劃，有效明確的分解項目需求。

3、跟蹤設計/開發(fā)/測試/回歸/發(fā)布全流程，推動項目按預定計劃執(zhí)行。

4、解決項目過程中出現(xiàn)的問題和沖突，一般集中在需求不明/工作量或時長/開發(fā)難度/跨部門協(xié)調等幾個方面。

5、調動開發(fā)團隊的積極性，創(chuàng)造力，推動團隊成員在項目過程中的學習成長。

6、風險識別、風險控制以及風險的預案。

項目管理

1、需求階段

對項目進行技術可行性分析、技術評估、成本評估以及風險評估。與需求提出方的代表進行需求討論，明確項目的目標、價值。確定項目范圍、功能及優(yōu)先級。

組建項目團隊，特別要搞清楚項目的關鍵人。項目啟動會議，相關的關系人都必須參加。

2、設計階段

根據(jù)確認后的軟件需求規(guī)格說明書，制定項目進度計劃，工作任務分解(WBS)；資源申請，項目涉及到的開發(fā)資源、測試資源、設計資源(包括人員和軟硬件資源)；數(shù)據(jù)庫設計；系統(tǒng)設計；文檔(包括系統(tǒng)用例、Demo、測試用例等)；評審會議。

設計階段結果交付一般為系統(tǒng)用例/系統(tǒng)原型/系統(tǒng)設計文檔(概要設計和詳細設計)/數(shù)據(jù)庫設計文檔等。

該階段交付成果需要進行評審。

3、執(zhí)行階段(開發(fā)和測試)準備開發(fā)環(huán)境、測試環(huán)境。跟蹤，推動項目按計劃進行。

項目成員以日報/項目負責人以周報的形式通報各關系人當前項目的進展情況。按里程碑對階段成果進行評估，以確保該階段完成的質量。代碼審核，包括CS審核、SQL審核、WEB審核等。對需求變更進行控制管理。

測試階段BUG響應及改進、收集反饋意見。對項目風險進行管理。

4、發(fā)布階段

包括制定項目發(fā)布計劃，用戶培訓，發(fā)布上線。

5、試運行階段

數(shù)據(jù)監(jiān)控(日志、服務器狀態(tài))，根據(jù)監(jiān)控出現(xiàn)的問題，及時進行處理，改進性能問題，特定情況執(zhí)行補丁升級。

6、收尾階段

產(chǎn)品交付，項目總結會。

常見問題

1、開發(fā)時間的估算

制定項目計劃時，需要估算每個任務所需的時間，其中主要是開發(fā)任務中模塊的分配和時間估算，在公司現(xiàn)有的技術框架下，開發(fā)人員主要的工作是投入在具體的業(yè)務邏輯實現(xiàn)上。通常單個模塊開發(fā)時間取決于以下因素：

1、負責模塊的業(yè)務邏輯的復雜程度。

2、開發(fā)人員的技術水平和對項目所在應用的熟悉程度(包括對框架和應用的熟悉程度)。

3、模塊技術實現(xiàn)上是否存在難點，所謂的技術難點定義是：在現(xiàn)有系統(tǒng)中還未實現(xiàn)的、開發(fā)人員自身未沒接觸過的技術。對于這樣的難點，開發(fā)者沒有相關的代碼可以參考，自己也沒有經(jīng)驗，所以需要投入學習時間用于研究解決。

模塊分配和開發(fā)時間估算的步驟：

1、在劃分好模塊后，首先項目管理人員預先估算各個模塊所需要的開發(fā)時間。

2、召集所有開發(fā)人員，討論模塊的分配和開發(fā)時間估算。將劃分好的模塊，分配給開發(fā)人員，如狀況允許可允許開發(fā)人員自主選擇以提高開發(fā)人員的主動性和參與性。分配模塊的時為確保開發(fā)的速度和質量，基本原則如下：

A、類似的模塊由同一人負責開發(fā)，比如用戶信息的增刪改應由同一開發(fā)者負責。這樣開發(fā)者對相關邏輯會比較熟悉，代碼/接口的定義也會相對明確，溝通的成本低，相應可以降低功能實現(xiàn)的缺陷概率。

B、技術難度較大的模塊由技術水平比較高的人負責。C、業(yè)務邏輯比較復雜的由對業(yè)務邏輯比較了解的人負責。

3、模塊分配完成后，開發(fā)人員評估自己負責開發(fā)的模塊所需要的時間。在此過程中應

4、對開發(fā)人員估算的時間進行確認。在確認過程中作為，項目管理者將預估時間和開與開發(fā)者討論每個模塊的技術實現(xiàn)細節(jié)，使時間的估算更加準確。發(fā)人員估算時間進行比較。那些差異較大的，與人員探討其中的緣由。對于時間周期比較長的任務，將任務拆分為更小的子任務，每個任務的完成時間為8-24工時，消除時間周期較長的任務，避免不確定性影響項目的進度。

2、CodeReview CodeReview是保證項目中代碼質量非常重要的一個環(huán)節(jié)，在這一環(huán)控制不嚴往往是測試后出現(xiàn)大量bug的主因，有時甚至導致返工；關于CodeReview執(zhí)行，首先應有編碼規(guī)范和代碼審查規(guī)范。通過這兩個文檔來規(guī)范開發(fā)人員的代碼實現(xiàn)，代碼編寫者必須要嚴格按照規(guī)范來進行；代碼審核者根據(jù)這些標準來CodeReview代碼，同時在CodeReview過程中需要不斷完善該文檔。

CodeReview一般可按以下步驟實施：

1、檢查開發(fā)者的代碼實現(xiàn)是否遵循了編碼規(guī)范。

2、從代碼的易維護性、可擴展性角度考察代碼的質量，提出修改建議。

3、代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UseCase依次講解自己負責的代碼和相關邏輯，代碼審核者在此過程中可以隨時提出自己的疑問，同時積極發(fā)現(xiàn)隱藏的bug，對這些bug記錄在案。

4、代碼講解完畢后，代碼審核者給自己安排幾個小時再對代碼審核一遍。代碼需要檢查Bug。同時全面兼顧，確保代碼整體上結構優(yōu)良；審核完畢后，代碼審核者編寫“代碼審核報告”記錄發(fā)現(xiàn)的問題及修改建議，提交給相關人員。

5、代碼編寫者根據(jù)“代碼審核報告”給出的修改意見，修改好代碼，有不清楚的地方可積極向代碼審核者提出。

6、代碼編寫者bugfixed完畢之后給出反饋。

7、代碼審核者把CodeReview中發(fā)現(xiàn)的有價值的問題更新到“代碼審核規(guī)范”的文檔中，對于特別值得提醒的問題可群發(fā)email給所有技術人員。

3、需求變更管理

需求變更管理也是項目管理中最重要的一個環(huán)節(jié)，對需求變更管理的有效性將直接影響對待需求變更的正確態(tài)度：

1、需求變更是不可避免的。

2、需求變更要必須被管理。

3、積極發(fā)現(xiàn)引起變更的因素，促使變更盡可能早的出現(xiàn)，減低變更帶來的風險。需求變更管理的目標：

1、相關的干系人必須清楚地了解發(fā)生的變更。

2、變更處于有效的管理中。

3、盡量降低變更帶來的風險。

通過制定需求變更的流程，確保項目中的需求變更有效地進行，實現(xiàn)上述的目標。需求變更流程：

1、確定需求的基準線。將以UserCase作為需求基準線，在UserCase確認之后的任項目的成功與否。何需求改變，都需要走需求變更流程。

2、項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產(chǎn)品經(jīng)理、市場人員、開發(fā)人員、測試人員等。

3、項目管理者評估該需求變更。針對接收到的需求變更的要求，召集相關人員討論該需求變更的合理性、可行性，實施的代價以及對項目的影響。項目管理者對項目的成功與否負有主要的責任。需求變更的決策應由項目管理者做出。

4、需求變更確認后，由專人將生成需求變更單記錄下來，通知給項目中所有關系人。

5、確定變更的負責人。承擔需求變更的具體工作，比如基線控制，對需求變更的記錄，并通知相關人員。

6、相關人員接收到確認的需求變更后，需求分析人員修改需求說明書和UserCase的相關內容。測試人員修改測試用例的相關內容。開發(fā)人員修改代碼中的相關部分。

7、按照變更后的計劃實施項目，并進行檢查，跟蹤，對變更后的實施反饋和可能出現(xiàn)的問題及時溝通和處理。

8、需求凍結。項目越到后期，需求變更對項目的影響就越大，所以在一定時候要進入需求凍結階段，不再接收新需求或需求的變更。

4、風險管理

影響項目成敗的因素涉及方方面面，并且風險伴隨著項目的始終，是客觀存在的，風險引起的負面后果集中體現(xiàn)在進度延后、成本超支、質量不達標等方面，常見風險如下：

1、目標以及需求不明確

為了市場競爭或內部管理決策的需要，業(yè)務部門提出的需求往往要求的時間比較緊迫，需求的提出大多停留在幾張紙或口頭的傳達上，沒有正式的業(yè)務需求文檔，在沒有明確的需求范圍的情況下，有時為了迎合業(yè)務部門的口味匆匆開工，過程中用戶不斷地提出新的想法，技術人員開始疲于奔命和應付，很難保證項目的進度和質量，也難以取得業(yè)務部門的認可。

在項目的前期一定要采取相應的手段或措施，與業(yè)務部門共同明確項目目標、需求范圍，充分考慮現(xiàn)有的時間和資源約束，將需求排定優(yōu)先級，對于關鍵的需求優(yōu)先實現(xiàn)，其他輔助性的根據(jù)過程中的具體情況進行滾動式計劃，并取得業(yè)務部門的書面確認。在此過程中要注重挖掘用戶的隱性需求，可以通過引導、系統(tǒng)原型等手段讓用戶在前期充分暴露自己的想法和需求。

2、項目目標擴大以及需求變更

在有了明確的目標和需求范圍的情況下，需求的變更還是不可避免的，業(yè)務部門在看到具體系統(tǒng)的真實雛形之后，源源不斷地要求、新想法隨之產(chǎn)生，如果不對此加以控制，新的需求的加入通常會影響已實現(xiàn)的需求，并且對項目進度和成本產(chǎn)生很大的影響。項目管理者針對這種情況一定要采取嚴格的變更控制流程，不能礙于面子，否則最終的結果往往是出力不討好。針對用戶提出的新需求，按照正式流程提出變更申請，組織相關團隊成員進行分析及評估，作為是否實施的依據(jù)，變更控制負責人根據(jù)分析結果判斷是否批準，如果批準，那項目組可以安排實施，否則，正式拒絕用戶的請求。

前期的需求討論要詳細、充分。需求文檔中需求的范圍要明確、功能描述要清楚。找出項目中需求的決策者(通常會是產(chǎn)品經(jīng)理、相關職能主管、客戶)，所有的需求要經(jīng)過他們的認可?？蛻粼陧椖窟^程中的全程參與有助于降低此類風險。需求討論、需求確認、UserCase確認、測試階段的客戶驗收等環(huán)節(jié)，都要要求客戶參與。在發(fā)生需求變更時，嚴格按照需求變更流程執(zhí)行。在分析設計階段的中的確認和評審也是降低此類風險的重要手段。

3、代碼質量風險

質量風險主要指開發(fā)代碼的質量。在制定項目計劃時，對開發(fā)時間的評估要盡可能的合適。合理的開發(fā)時間對開發(fā)質量的影響很大。開發(fā)人員為了趕進度在比較緊張的時間需要完成指定的任務，可能就存在很大的開發(fā)質量問題。在編碼前，開發(fā)人員要對框架熟練掌握；一份好的系統(tǒng)設計文檔對指導開發(fā)非常重要。

往往有這樣一種情況，每個團隊成員按照項目計劃報告進度都是100%完成，但一到最后系統(tǒng)交互測試或集成的時候就會發(fā)現(xiàn)一大堆問題。這需要在項目實施過程中采取有效的措施來規(guī)避風險，通常的做法有同行評審，比如概要設計完成之后，邀請其他項目組的技術專家進行技術評審以發(fā)現(xiàn)架構設計問題；管理評審，通過組織級的質量審計看產(chǎn)品以及實施過程是否滿足質量要求；代碼走查，在編碼過程中加入至少一次的代碼走查，排查不符合規(guī)范或性能要求的代碼，走查通常能夠發(fā)現(xiàn)50%-70%的錯誤；每日構建，這是一種非常有效的方法，可以避免把各部分的集成問題拖到最后，并且能夠及時發(fā)現(xiàn)相應的錯誤，日構建一般在項目的中后期開始，每天自動從版本服務器上獲取源代碼進行自動編譯和測試。

4、人員技能和資源的不足

項目實施過程中由于人員技能欠缺造成的進度延后和軟件質量問題并不少見，一個熟練的技術人員完成同樣一個任務需要3天，但一個新手可能就需要7-10天。項目管理者應該在前期就分析清楚項目所要采用的技術以及相應的人員技能要求，針對不同的角色，及時采取相應的技能培訓，以保證項目的順利實施。開發(fā)過程中遇到技術難題，導致開發(fā)時間延遲或者需求不得不發(fā)生變更。在項目開始前的技術評估階段，明確技術難點，提前安排人員進行攻克。如果在可預期的時間內無法解決，如果可以，將向需求提出方要求變更需求或尋找可替代方案。這樣的風險應該在項目的前期階段就應該解決在萌芽狀態(tài)來避免這樣的風險在后期或中期出現(xiàn)。

5、缺乏良好的團隊協(xié)作

軟件項目實施屬于知識型，要發(fā)揮團隊成員的創(chuàng)造力，不同于制造業(yè)計件生產(chǎn)，各模塊最終要集成在一起形成一個有機的整體，這就需要各小組之間的密切配合，界定清楚工作界面及接口關系，并在實施過程中持續(xù)地溝通交流和共享，首先團隊要融為一體，產(chǎn)出的軟件才能融為一體。這是一個團隊的軟實力，團隊之間的協(xié)作好壞也將是個潛在的風險問題，在項目啟動和團隊組建的時候就應該加以規(guī)避這樣的風險出現(xiàn)。

6、項目會議

組織會議是項目執(zhí)行過程中一項非常重要的工作任務，項目過程中很多重要的決定都是在會議中做出的，不成功的會議會對項目本身造成了不好的影響。

不成功的會議通常表現(xiàn)為如下形式：

1、會議氛圍不好，參與者發(fā)言不踴躍；

2、會議討論常常偏離主題；

3、會議沒有取得預期的結果；

4、會議時間常常一拖再拖。

這些不成功的會議最終的結果就是：既浪費了大家的寶貴時間又沒有達到會議的目的，很多人都對這樣的會議都有抵觸情緒，對此也是深惡痛絕。以下是組織會議時應該注意的問題，也可看作組織會議的最佳實踐。在列出最佳實踐之前有三點我們必須要清楚：

1、會議是否會取得成功很大程度上取決于會議的組織者。只有組織得有力，會議才有可能取得成功，這是會議成功的充分條件。

2、會議的組織者和參與者的想法通常是不一致的，有時候甚至會大相徑庭。所以不要希望會議的參與者和你一樣，對會議有著如此的期待，對大多數(shù)參與者而言，在會議中他只是一個發(fā)表想法的人，他不用對會議的成功承擔責任。

3、以下十一條最佳實踐是形式上的約定，具體的實施可以根據(jù)實際情況來做。組織會議的十一條最佳實踐：

1、只有需要開會時才開會。有時候兩三個人單獨小范圍溝通會更加有效。

2、提前發(fā)出會議議程，以便會議參與者知道他們來做什么。

3、請對人很重要，不要把非必要的人召來開會，當然也不要漏掉那些關鍵人物。在確保必要人物都在的情況下一次會議參與者越少效果越好。

4、提前預約參與者的時間，以確保他們能按時到場。

5、會議的開場很重要。會議組織者要在開始前做好幾件事情。通常我建議有幾點要在開場時說： A、再一次強調會議的目標，我們來做什么。

B、強調會議的主題與基調。比如：本次會議是一個需求確認會，而非需求討論會，主要是討論做還是不做以及告知大家我們要做什么，而不要把太多的精力放在討論如何做上面。

C、說明一下會議的規(guī)則。如要發(fā)言，請舉手；不要有小圈子討論；不要打斷別人的講話，等別人說完你再說等等。

6、會議過程中時刻注意引導和控制會議，以確保會議按照目標進行。一次會議的氛圍是否良好，討論是否充分，好的引導至關重要。比如多提一些開放式的問題。

7、會議記錄很重要，把一些結論和有價值的內容記錄下來，這些是本次會議的重要成果之一。

8、會議要有結論。我們常在會議上聽到有人說：“大家討論了這么半天，結論呢？”。沒有結論的會議是沒有意義的。

9、會議后別忘發(fā)會議紀要，以及一些Action，什么人什么時候做什么。

10、會議后的action執(zhí)行情況的反饋很重要。反饋是對會議參與者的尊重，同時也告知了會議的效果。否則會讓大家感覺到這是一個可無可無的會議，大家以后參與的積極性也會降低。很多會議往往都不注意這一點。

11、按時結束的會議會受到所有人的歡迎。