1、精選優質文檔-傾情為你奉上XXX平臺項目實施方案XXX有限公司2014年10月專心-專注-專業目錄第1章 項目概述1.1 項目建設內容及范圍1.1.1 項目總體建設范圍1、服務對象1）2）1家典型重點工控企業。2、主要用戶包括信黨政機關和重點工控系統運營單位。1.1.2 項目內容序號名稱1XXX系統2XXX平臺34其中：1、風險防范系統系統包括采購一套監測設備、一套風險分析設備，并將互聯網監測系統整體納入監控平臺管理，提供3年監控技術服務及升級服務。2、XXX平臺主要包含。第2章 項目實施方案項目實施方案包括項目實施和項目管理。2.1 項目實施從項目實施的角度詳細描述了主要實施階段的主要參與人

2、員、工作內容和相應的工作方法。依據我們對相關領域的經驗提出對本項目建設計劃。我方在項目管理方面有著自己一套科學而先進的項目管理方法論，這套方法論已經在實施的所有的項目中得到了檢驗。項目管理方法論是公司最重要的一項核心競爭能力，是我們能夠對客戶承諾項目成功的信心所在。我方項目管理方法論建立在如下5項重要原則的基礎上：n 與客戶共同探討對項目成功衡量標準的定義，并以此作為雙方工作的共同標準和價值觀。n 制定細致的項目計劃，明確定義項目階段和階段交付成果。將一個大型的復雜的任務分解為可以量化和可以具體執行的分解工作任務，并明確定義每一個分解任務所需要達到的工作成果，使得項目總體目標得以有效的保證。n

3、 與客戶的充分溝通，通過各項例會制度，周報和月報制度等使客戶可以全面了解項目進展情況，保證項目的交付始終與客戶的預期保持一致。n 明確定義項目組織結構和工作職責，并設定相應的考核標準和方法，保證項目各方能夠有效的協同工作。n 建立明確的文檔管理，人員管理，配置管理，風險管理，預算管理，進度管理，采購管理，集成管理和變更管理規范與制度以保證項目的整體質量和各環節的配合。針對平臺實施工作，將其分為了如下圖所示的6個階段：圖21項目實施階段示意圖說明：考慮到本系統的建設周期，設計、實現、實施以及試運行部分將出現迭代：n 第一次迭代過程保證系統主要功能能夠正常使用。n 第二次迭代過程保證工信廳安全綜合

4、服務平臺項目其余輔助功能能夠使用。下面首先對各階段的工作進行說明： 2.1.1 項目啟動階段n 階段工作目標本階段的工作目標是從項目目標、項目范圍、項目工作方法以及后勤保障方面為系統建設項目的順利進行建立基礎。n 階段工作內容本階段的工作內容包括：組織項目所需的各項資源，包括：人員確定、辦公環境、網絡及通訊環境、個人工作設備、開發環境、現場工作環境及生活環境；確認工作范圍：針對項目投標方案中對工作范圍的描述，進一步與工信廳安全綜合服務平臺項目負責人討論確定項目工作范圍；制定項目計劃：根據項目投標方案中制定的項目計劃，與工信廳安全綜合服務平臺項目負責人重新審核和進一步建立細致的項目主計劃；確定項

5、目管理規范：根據項目管理規范要求，針對本系統建設項目進行適當裁剪，以滿足本項目管理的要求；確定質量規范明確定義項目各階段工作成果的格式、審核流程和驗收標準。召開項目啟動會：召集項目組全體成員、相關實施廠商及工信廳安全綜合服務平臺項目組成員，通過項目啟動會的形式進一步明確上述各部分要求。n 階段工作成果：項目施工實施方案2.1.2 需求調研、需求分析階段n 階段工作目標本階段的工作目標是通過對工信廳相關業務、周邊業務和現有系統和軟硬件環境的的深入細致的分析，并結合行業先進做法，為項目頂層設計建立基礎。n 階段工作內容有效需求管理的關鍵在于維護需求的明確闡述、每種需求類型所適用的屬性，以及與其它需

6、求和其他項目工作產品之間的可追蹤性。1管理不同層次的需求項目前期，客戶提出的需求一般不是直接面向軟件需求的，是從業務的角度描述他們的問題或者是需要。根據這些需要定義軟件系統的解決方案，確定系統提供哪些服務，也就是軟件系統的特征。在與客戶取得一致的特征集上可以定義出更為特定的軟件需求。軟件需求包括功能性需求和非功能性需求。不同的客戶以及在項目不同時期也可能提出特征或軟件需求層次的需求。管理這些不同抽象級別和目的需求，確保需求是完備的。2建立可追蹤性通過需求的屬性、需求之間的依賴關系以及需求與其它工作產品之間的依賴關系，管理需求的可追蹤性。用來了解需求的來源、管理項目的規模、管理需求的變更、評估需

7、求變更對項目的影響、評估測試故障對需求的影響、核實所有需求都已實現、核實應用程序僅僅執行了預期的任務。3管理需求變更定義需求時無論怎樣謹慎小心，也總會有可變因素。對需求變更進行管理，使團隊的工作受到控制，以便它能夠高效的發現變更、進行影響分析并且系統地把那些既必要又可接受的變更集成到系統中。4需求定義n 細化業務和系統目標；n 定義清晰、簡明、一致、可測試、無二義性的業務需求；n 基于對業務需求排列優先級：必須有，應該有，可以有，將會沒有。5需求分析n 建立業務數據模型，精確描述信息和過程需求；n 檢驗提供業務所需的信息的數據和業務數據模型中的數據元素在源系統中的是可用的并且具備必須的特性。n

8、 階段工作成果此階段的項目工作成果將包括：系統業務調研報告系統需求規格說明書設備采購及到貨驗收、上架；2.1.3 設計階段n 階段工作目標本階段的工作目標是對系統進行總體設計，并對各相關子系統進行詳細設計，從而為系統的實現階段建立依據。n 階段工作內容本階段的工作內容包括：頂層初步設計系統總體設說明書數據接口及數據同步設計n 階段工作成果本階段的工作成果包括：頂層設計管理機制建設概要設計方說明書詳細設計說明書2.1.4 客戶化開發、實施與測試階段n 階段工作目標本階段的工作目標是根據系統總體設計及各模塊設計方案，進行系統的建設、開發和部署。n 階段工作內容系統配置部署；系統接口實現；項目頂層初

9、步設計評審；應用系統接口開發和測試。n 階段工作成果本階段的工作成果包括：各第三方軟硬件及文檔及平臺實施方案2.1.5 系統實施部署階段n 階段工作目標本階段的工作目標是對系統進行部署實施，以保證系統的試運行。n 階段工作內容本階段的工作包括：軟硬件的安裝部署；系統數據初始化；編制用戶手冊；技術培訓；用戶培訓；n 階段工作成果本階段的工作成果包括：用戶培訓計劃用戶操作手冊實施報告驗收報告2.1.6 上線試運行階段n 階段工作目標本階段的工作目標是通過一段時間的系統試運行，幫助用戶熟悉系統，發現并解決系統產生的問題，為系統正式投入使用打下基礎。n 階段工作內容本階段的工作內容包括：組織系統各方面

10、用戶使用系統；建立系統問題發現、跟蹤和解決機制；問題發現和處理； 2.1.7 驗收階段2.1.7.1 驗收對象項目名稱：平臺（一期）（以下簡稱“項目” ）。驗收對象為該項目的相關文檔技術文檔，系統運行情況、頂層設計等建設內容。2.1.7.2 項目驗收的前提條件n 所有建設項目按照合同要求全部建成，并滿足使用要求；n 已通過軟件系統測試評審；n 軟件已部署在生產環境上；n 各種技術文檔和驗收資料完備，符合合同的內容；2.1.7.3 驗收步驟n 編寫驗收方案（計劃書） n 成立項目驗收小組 實施測試驗收工作時，應當成立項目驗收小組，具體負責驗收事宜。 n 項目驗收的實施 嚴格按照驗收方案對項目應用

11、軟件、系統文檔資料等進行全面的測試和驗收。n 提交驗收報告 項目驗收完畢，對項目系統設計、建設質量、設備質量、軟件運行情況等做出全面的評價，得出結論性意見，對不合格的項目不予驗收，對遺留問題提出具體的解決意見。2.1.7.4 驗收內容和標準1、驗收的內容包括以下幾個部分：n 驗收內容包括：按功能要求的可執行軟件、開發計劃文檔、設計文檔、使用說明書等。n 驗收評測工作主要包括：文檔分析、方案制定、現場測試、問題單提交、測試報告。n 文檔驗收標準一般包括：文檔完備性、內容針對性、內容充分性、內容一致性、文字明確性、圖表詳實性、易讀性、文檔價值等。2、需要評審的資料包括以下幾部分：n 需求規格說明書

12、、概要設計說明書、系統維護手冊、用戶操作手冊。n 軟件開發管理文檔：項目計劃書、用戶培訓計劃、開發進度月報。2.1.7.5 驗收結論驗收結果分為：驗收合格、需要復議和驗收不合格三種。符合項目建設標準、系統運行安全可靠，視為驗收合格；由于提供材料不詳難以判斷，或目標任務完成不足80%而又難以確定其原因等導致驗收結論爭議較大的，視為需要復議。1、項目凡具有下列情況之一的，按驗收不合格處理：n 所提供的驗收材料不齊全或不真實的；n 實施過程中出現重大問題，尚未解決和作出說明，或項目實施過程及結果等存在糾紛尚未解決的；n 沒有對系統進行試運行，或者試運行不合格；n 違反法律、法規的其他行為。2、驗收結

13、論確認和處理n 由工信廳和我方共同根據驗收意見和相關資料得出結論，并進行確認。2.1.7.6 項目交接項目竣工驗收合格后,應辦理項目交接手續。項目的移交包括項目實體移交和項目文檔移交部分。2.2 項目管理本章描述了項目的管理特點和管理要求，并根據本項目的特點給出了工信廳擬實施項目的組織架構，管理方案和初步的進度計劃，列出了項目的成果交付物。并介紹了相關的項目管理方案，包括：質量管理，需求管理，配置管理，軟件發布與部署，項目跟蹤與監控，風險管理等內容。2.2.1 項目組織架構2.2.1.1 組織結構我們建議項目采用如下的組織形式：圖22項目組織結構圖項目的組織結構將分為三個層次：領導層、管理層和

14、執行層，每個層次負責不同的項目職能。XXX（業主單位）XXX（承建單位）XXX（承建單位）領導層項目領導小組管理層項目負責人項目經理項目負責人執行層業務層業務負責人各業務部門的業務專家咨詢顧問業務專家需求分析師咨詢顧問業務專家需求分析師技術層實施人員應用系統開發經理系統分析師架構設計師安全分析師開發工程師測試工程師實施人員規劃編制員1、領導層n 項目領導層項目領導層將負責對項目整體方向的控制，并通過項目領導委員會的形式對項目過程中產生的重要問題進行討論分析和決策。2、執行層負責項目核心業務需求分析與設計、技術路線以及核心技術的設計，起草業務需求文檔項目執行層將在項目管理層的領導下完成對項目的規

15、劃設計、系統需求分析、系統整體設計、系統開發、系統測試、文檔整理、系統配置等各方面的具體工作。分為業務組和技術組，包含規劃設計組、項目實施組、甲方實施組和應急小組。涵蓋的角色如上表。n 規劃設計組規劃設計組包含頂層設置編制組、綜合管理服務機制建設編制組，負責本項目的頂層設計方面的業務需求了解、規劃編制、標準規范編制等工作。n 項目實施組項目實施組包含系統研發組、測試組、現場實施組，負責整個項目系統需求調研、系統設計開發、上線功能測試測試、現場實施及培訓相關工作。n 甲方實施組負責項目實施日常工作跟蹤、協調、功能測試、問題反饋跟蹤等相關工作。2.2.1.2 項目主要成員甲方成員序號項目組角色姓名

16、工作職責1領導、專家成員領導成員，負責項目總體協調。2項目實施負責人負責項目具體實施、實施進度監督、現場工作具體協調等。乙方成員序號項目組角色姓名工作職責1領導、專家成員項目領導專家成員，負責總體項目協調及專家咨詢。2領導、專家成員研究中心專家成員，負責總體項目協調及專家咨詢。3項目經理負責總體實施、項目進度控制及協調。4項目副經理協助項目經理，負責項目實施、現場項目進度、項目匯報等。5項目副經理協助項目經理，負責系統研發、實施及相關現場工作等。6軟件工程師負責軟件部分開發實施7系統集成工程師負責硬件設備部署以及相關中間件數據庫等部署8規劃編制研究中心規劃編制負責人，協助項目經理，負責對總體規

17、劃、機制體制等編制等工作。監理成員序號項目組角色姓名工作職責1項目總監XXX負責項目總體監理及進度監督工作。2監理工程師XXX負責現場項目實施監理工作。3監理工程師XXX負責現場項目實施監理工作。2.2.2 進度計劃和管理2.2.2.1 項目進度計劃：序號階段內容起始/截至工作日文檔11、系統設備采購及環境部署2設備采購設備采購2014年10月20日/2014年11月7日153設備到貨驗收設備到貨驗收2014年11月10日/2014年11月10日1設備到貨驗收文檔4設備環境部署開發環境部署2014年10月28日/2014年10月30日35采購設備部署2014年11月10日/2014年11月10

18、日2系統部署及配置文檔6系統聯調設備網絡聯調2014年11月11日/2014年11月12日27設備與系統聯調2014年12月18日/2015/1/315系統接口配置文檔82、軟件開發9計劃階段計劃編制2014年10月8日/2014年10月8日1項目實施計劃表10計劃階段項目啟動會2014年10月9日/2014年10月9日1計劃表細項討論11計劃階段小計2014年10月8日/2014/10/9212需求階段需求調研、分析2014年10月10日/2014/10/219需求規格說明書13需求評審2014年10月22日/2014/10/22114需求階段小計2014年10月9日/2014/10/221

19、015設計階段概要設計2014年10月23日/2014/10/273概要設計說明書1617數據庫設計2014年10月28日/2014/10/292數據庫詳細說明書18詳細設計2014年10月30日/2014/11/55系統詳細設計說明書19設計階段小計2014年10月23日/2014/11/51020實現階段數據庫實現2014年11月6日/2014/11/61相關代碼21XXX系統2014年11月7日/2014/11/18822XXX系統2014年11月19日/2014/11/28823XXX系統2014年11月19日/2014/12/232524XXX系統2014年11月19日/2014/1

20、2/162025XXX系統2014年12月17日/2015/1/132026實現階段小計2014年11月6日/2015/1/134927測試階段測試準備2015年1月14日/2015/1/141系統使用說明書系統測試方案書28功能測試2015年1月15日/2015/1/215測試報告29性能測試2015年1月15日/2015/1/215項目初步驗收報告30BUG修正2015年1月22日/2015/1/28531測試階段小計2015年1月14日/2015/1/281132試運行階段安裝2015年1月29日/2015/1/291系統培訓報告33試運行2015年1月30日/2015/2/1915系統

21、試運行報告34BUG修正2015年2月20日/2015/2/26535投運2015年2月27日/2015/2/271363、頂層設計、機制建設37編制階段編制2014年10月23日/2014/12/330頂層設計文檔、機制建設文檔38評審2014年12月4日/2014/12/5239修訂2014年12月8日/2014/12/12540整體項目合計2014年10月23日/2014/12/1237414、工控實施42需求階段需求調研、分析2014年12月13日/2014/12/164需求規格說明書43需求評審2014年12月17日/2014/12/17144需求階段小計2014年12月13日/20

22、14/12/17545實現階段接口開發2014年12月18日/2015/1/820相關代碼46實現階段小計2014年12月18日/2015/1/82047整體項目合計2014年12月13日/2015/1/825注:測試、試運行階段與“一、軟件開發”同步進行。485、監控接口開發49需求階段需求調研、分析2014年11月6日/2014/11/104需求規格說明書50需求評審2014年11月11日/2014/11/11151需求階段小計2014年11月6日/2014/11/11552實現階段接口開發2014年12月18日/2015/1/315相關代碼53實現階段小計2014年12月18日/2015

23、/1/31554整體項目合計2014年11月6日/2015/1/320注:測試、試運行階段與“一、軟件開發”同步進行。圖23項目實施計劃2.2.2.2 主要里程碑成果物序號階段成果物1合同簽訂2項目啟動3項目小組成立、項目實施計劃確定項目實施方案4一、XXX頂層設計5需求調研、需求分析6頂層設計編制頂層設計討論稿7頂層設計初審頂層設計初審稿8頂層設計初稿修訂編制9頂層設計終審及終審編制頂層設計10二、XXX機制建設11需求調研、需求分析12XXX機制編制XXX機制討論稿13XXX機制初審XXX機制初審稿14XXX機制初稿修訂編制15XXX機制終審及終審編制XXX機制16三、XXX平臺17需求調

24、研、需求分析需求規格說明書18系統概要設計及評審系統概要設計說明書系統數據庫設計說明書技術開發規范19系統開發設計系統詳細設計說明書系統操作手冊20系統測試系統測試方案系統測試報告21系統培訓系統培訓計劃22項目初步驗收初驗報告23項目試運行試運行報告24系統功能完善25系統正式運行26四、XXX系統27設備采購、供貨28設備上架、到貨驗收到貨驗收報告29系統安裝、入網聯調系統接入方案30培訓31正式運行32五、項目整體驗收33項目驗收資料整理34項目整體驗收驗收申請驗收方案驗收報告2.2.2.3 進度管理方法計劃是項目管理的基準，現代質量管理認為“計劃勝于檢驗”，“過程決定質量”，對于項目執

25、行來講同樣是這樣。計劃是項目執行的指導，計劃是控制的基準，計劃是項目各方溝通的平臺。計劃制定的過程強調漸進明細和分解。通常應用軟件開發過程中項目計劃容易出現的問題有：1項目計劃凌亂、無序，也就是說不能從項目計劃中看到項目執行全貌。對項目執行指導意義不大。2項目計劃只是在項目開始時進行制定，在執行過程中不對計劃進行及時管理，導致項目計劃失效，同時失去對項目執行的指導意義。3項目計劃不完整，只是在當前所關注的環節存在計劃，導致項目執行工作不能整體上全面協調的推進。本項目項目計劃跟蹤和控制建議：1項目計劃層次劃分項目計劃可分為：項目里程碑計劃、子項目計劃、周項目計劃3個層次。充分體現項目管理中漸進明

26、細和分解的原則。項目里程碑計劃作為項目各參與方均認可的項目階段目標指導性文件，項目各參與方均需對其負責。對里程碑計劃進行漸進明細形成子項目計劃，子項目計劃要說明里程碑計劃中階段目標的實現步驟和方法。在子項目計劃的指導下形成項目各參與方的周項目計劃，周項目計劃作為項目進度風險控制的最小單元，根據周項目計劃的執行情況進行考核，并及時形成調整措施。2項目計劃有效性和完整性“計劃趕不上變化”，在項目執行的過程中必然會發生各種各樣的情況變化，如各個層次的項目計劃不能得到及時的變更控制和管理，項目計劃將逐漸與項目執行情況脫節并失效。項目計劃有效性的喪失必然導致項目工作陷入無序狀態，最終導致項目目標不能如期

27、實現，甚至造成項目失敗。在形成各個階段或維度的子項目計劃時，非常重要的一點是要保證項目計劃的完整性。如果子項目計劃存在缺失，會造成項目執行中的重大缺陷，對整體項目執行產生重大影響。針對項目計劃的有效性和完整性問題提出本項目中相關項目管理建議：（1）項目管理組承擔項目計劃的變更控制和管理職能，對項目計劃的有效性負全面責任。（2）建立項目計劃變更控制流程。在項目執行情況發生重大變更時，相關方必須向本項目管理組提出變更申請；項目管理組根據情況及時組織項目相關方審查項目變更，并進行風險分析，更新項目計劃并通知項目各方。（3）項目總體計劃和子項目計劃制定，要進行相關評審，在評審通過后方可生效。（4）建立

28、項目計劃標識體系，包括項目計劃版本標識。每次項目計劃的變更均需更新標識，并說明變更原因和進行相關風險的說明。3項目計劃的執行情況跟蹤本著及早發現問題的原則，定期的對項目計劃的執行情況進行跟蹤，并對跟蹤結果進行公布。跟蹤的頻度與項目執行情況相關，可以每周、雙周等頻度進行。2.2.3 項目管理方法2.2.3.1 項目評審評審主要包括里程碑評審、同行評審和跟蹤，其中里程碑評審是管理評審，同行評審和跟蹤屬于同行評審的兩種形式。（1）里程碑評審里程碑評審的主要活動包括以下內容第1步 項目經理負責組織里程碑評審活動第2步 討論里程碑報告、評估報告第3步 項目經理負責形成項目里程碑報告第4步 確定下一個階段

29、的計劃是否需要修改里程碑評審后，質量保證員依據評審記錄，監督問題改正和變更的執行情況。（2）項目進度及問題跟蹤跟蹤的主要步驟如下：第1步 項目經理負責項目整體進度以及實施過程中具體問題的的跟蹤，一般來講，參與跟蹤人員可選擇項目組內的人員，但應注意跟蹤時避免跟蹤自己完成的工作產品部分。第2步 項目經理負責將要跟蹤的工作產品及相關資料在跟蹤前一天發送給參與跟蹤的人員第3步 參與跟蹤的人員按計劃進行跟蹤，并將跟蹤出的問題形成評審記錄第4步 項目經理匯總評審記錄，并對跟蹤出的問題進行分工，同時跟蹤問題的解決情況，直至問題解決結束。第5步 項目經理負責形成評審報告，記錄本次跟蹤的結論，參與跟蹤的人員，統

30、計本次跟蹤的工作量、發現的問題類型個數、修改的問題個數等。2.2.3.2 進度監控項目要制定合理的進度安排，并確保項目能夠按計劃進行。項目經理以及各組負責人根據項目特點、客戶需求、識別的風險、可能存在的限制安排項目進度；在項目執行過程中定期對所屬范圍內的項目進展情況進行監控，識別與分析實際進展與計劃的偏離原因，采取糾正措施進行調整，必要時進行正式的計劃變更。1進度安排進行合理的進度安排是進行監控的前提，考慮迭代的生命周期模型，項目采取分階段細化項目進度的策略。在項目初始策劃階段，項目制定總進度表，內容包括各主要里程碑和各迭代點；在每主要里程碑結束，細化下一里程碑的計劃；在每次迭代策劃階段，制定

31、本次迭代的進度表，細化本次迭代內的項目活動。進度安排時可以按照以下步驟進行：n 確定可用的資源。在編制進度表時，知道在何時以何種形式取得何種資源是必要的，這種對資源可用性的了解程度是需要不斷進化的。n 確定項目日歷和資源日歷。項目日歷和資源日歷標明了在該項目中或者對于某一資源來說哪些日期是用于工作的時間。n 根據任務的依賴關系和估計工期列出項目的關鍵路徑，為關鍵路徑上的各個關鍵任務分配資源，為非關鍵路徑上的其它任務分配資源。n 進度的安排可以使用表格形式或者圖形形式進行表示。2進度調整項目依據進度表的安排執行并控制項目進度，并根據項目狀態對進度進行調整。使用進度表監控項目進展，進度控制的內容有

32、：n 對造成進度變化的因素施加影響，以保證這種變化朝著有利的方向發展。n 收集項目實際進度狀態數據，與計劃進度數據進行比較，確定項目進度是否已發生變化。n 當在實際變化發生和正在發生時，對這種變化實施管理。根據項目狀態對進度進行調整，進度調整包括兩種類型，即日常調整、定期調整和項目進度發生重大變更時的調整。日常調整指項目各級負責人日常對進度表的更新活動，可以是每天或者每周進行，一般包括對以下內容的調整：n 調整某個任務的工期、計劃開始時間或結束時間。在調整時要注意與該任務具有依賴關系的其他任務的變化，特別是要注意關鍵路徑的變化，檢查所進行的調整是否導致項目里程碑結束日期或者項目日期發生變化。n

33、 根據人員負荷和進度變化調整資源的分配，為某個任務重新指定資源。n 收集并記錄進度實際數據，一般包括任務的實際開始時間、實際結束時間等。n 定期調整是指項目經理在迭代內里程碑、迭代結束和階段結束通過正式評審項目進展，根據項目完成狀況對項目進度的調整。當項目進度發生重大變更時，如需求變更引起的，需要調整項目進度表，此時需要對剩余工作進行重新估計，重新制定后續任務的進度表，包括調整迭代計劃以及項目總體計劃。2.2.3.3 資源監控資源是指在項目運行過程中所需要的人力資源。資源監控是指項目充分、有效地利用所涉及人員的過程，包括識別并管理這些資源以及在不同階段需要的數量、狀態等信息，確保項目的正常開展

34、。在項目策劃階段，策劃合適的資源安排到各項項目任務中，形成完整的人員配備管理計劃；在項目實施過程中，通過郵件、周例會和里程碑總結等正式和不正式的手段對人員的狀態進行監控。一旦出現不可避免的人員變更問題，按照規定的流程進行工作交接。本項目的資源監控有兩個主要特點：n 工作匹配原則：保證為項目配備符合項目活動能力要求的工程和管理人員；n 動態人員結構：根據不同階段項目對人員的不同需求考慮投入不同能力和不同數量的人員。1人員策劃需要識別為完成項目所涉及的所有人員角色、所需的經驗技能、數量要求以及投入時間等信息，建立人員需求表。基于以上需求，獲取符合項目以上需求的技術和管理人員；獲取的途徑包括本事業部

35、內部、公司內部其他事業部或社會招聘。獲取人員的主要考慮人員的工作能力和熟練程度，具有類似項目的技術和管理經驗背景優先，同時也要考慮個人愛好和個人特點以及時間上可能性。根據項目進度的要求和任務的安排，為每項任務分配人力資源以及每項資源在各個時間段內（天、周、月或者其它時間間隔）完成的工時，形成完整的人員配備管理計劃。在人員配備管理計劃中，以圖或表的形式描述了資源分配和人員負荷等情況。2人員變更項目經理跟蹤人員配備管理計劃以監控項目人員的投入狀況，并在每周和每里程碑上進行總結，監控的主要內容包括：n 人員投入的數量以及投入的人員技能是否可以滿足項目實施要求；n 是否需要為項目人員提供必要的培訓；n

36、 人員負荷是否不平衡；n 人員是否流失或有流失的可能；在項目周會和里程碑會議上，高級管理者、客戶方和項目經理評審以上人員狀況，制定合理的措施以處理人員管理中遇到的一些問題。由于人員離職或工作變動會引起項目中人員的變更。項目經理會分析人員變更所帶來的影響，盡量控制人員變動，對于不可避免的人員變動要處理好工作交接，以使工作能夠全面、順利的交接，降低工作交接對項目工作帶來的風險和問題。下圖描述了人員變更主要活動的流程： 變更請求分析影響確定新負責人明確交接期限召開交接短會對當前工作內容和產品進行整理和完善制定交接計劃按計劃交接工作交接評審變更結束圖24項目實施人員變更流程對于以上人員變更活動需要注意

37、以下內容：n 新負責人應盡量選擇在相關領域有經驗的人員（由于是中途接手，難度較大）；n 如果選擇本項目中已承擔其他工作任務的人員作為新負責人，則一定要準確度量其負荷，并要明確其接手后的責任；n 交接期限的確定應以工作能夠有效交接為中心，可能的情況下部門應在工作交接結束后，才最終同意原擔當離職或變動工作；n 交接計劃要與項目經理和被交接者商討制定，計劃中應包含要進行哪些交接活動、時間、內容及相關人員安排等，應該包括相關培訓和自學的內容。n 項目經理要對工作交接的結果進行檢查，判斷相關工作是否都已經順利交接；如果存在問題，需要與相關人員商討后續計劃。2.2.3.4 風險管理在軟件開發中，風險是某種

38、不確定因素，在其正常分布范圍內，它可以危及項目成功或導致項目失敗。因此有效的管理項目風險是項目成功的關鍵。1風險管理策略根據風險發生的可能性和對項目影響的嚴重程度，定義風險等級：高、重大、中等、較小、低。風險對策：主要描述應對風險的策略。風險管理的核心思想不是被動地等待（等到風險變成現實、成為問題或導致項目失敗），而是決定如何對付風險。對于每個風險，有 3 種主要的可行措施： n 風險規避：重新組織項目，使風險無法影響項目；n 風險轉移：重新組織項目，讓其他方承擔該風險（客戶、廠商、銀行、其他主題等）；n 風險接受：決定接受這種可能發生的風險。監視風險征兆，如果風險出現，則制訂應急計劃，決定要

39、采取的措施。如果接受風險，還要采取兩種措施及：風險減輕：采取一些及時的、正面主動的步驟來減小風險發生的可能性或影響。制定應急計劃：如果風險變成實際問題，應當采取的措施。3項目風險和對策以下提出項目可能的風險及應對策略：（1）軟件需求涉及業務的軟件系統，經常會出現這樣的問題：系統開發完成了，但沒有滿足客戶的業務需求；需求經常發生變化，導致開發范圍的蔓延。避免軟件需求的風險，才能項目成功。化解風險的策略：n 理解客戶需要解決的問題：通過業務建模，了解客戶的業務流程和業務需求；n 增強與客戶的溝通：用例建模立足用戶角度描述，為具體的需求提供了充分的上下文信息，是銜接用戶和開發者的紐帶和溝通方式；n

40、及早收集客戶的反饋：每次迭代都會產生系統可執行的部分，通過及早部署演示來挖掘用戶的反饋意見，改進對于需求理解的偏差；n 控制需求變更：變更請求可能來自于客戶和最終用戶、設計人員、開發人員、測試人員、技術支持部門等，建立變更控制流程管理變更。（2）架構/技術風險可執行構架指的是系統的部分實施，該構架用于演示選定的系統功能和特征，尤其是那些滿足非功能性需求的功能和特征。利用該構架可以降低性能、吞吐量、容量、可靠性以及其他方面的風險。迭代開發在精化階段的關鍵活動是確定架構并為構架建立基線，在該階段經過幾次的迭代和測試修改，到精化結束時穩定的架構基線已經建立，性能等主要技術風險盡早的被發現和解決。從而

41、在構建階段可以在一個穩固的基礎上完成系統功能的全面添加，而不用擔心破壞系統。2.2.3.5 質量管理軟件質量保證過程的目的是為項目組的軟件開發過程提供指導，為管理層就軟件項目過程提供管理信息，為提升軟件質量提供手段。由于開發軟件系統或軟件產品的過程是決定項目成功與否的關鍵因素，因此軟件質量保證的工作是評審和審計軟件活動和軟件產品。軟件質量保證過程需要達到的目標包括：n 軟件質量保證活動是有計劃的活動；n 軟件產品和活動與適用的標準、過程和需求的一致性需經客觀驗證；n 軟件質量保證活動及成果應及時通知到受影響的組織和個人；n 軟件項目內部未能解決的有爭議問題，由上級管理部門處理；軟件質量保證過程

42、定義如下：n 由質量保證員負責向項目組人員進行PPQA定向培訓；n 由質量保證員負責編寫質量保證計劃；n 由質量保證員負責對軟件項目過程及其他公司規范及過程進行質量保證，軟件項目過程包括：軟件銷售管理過程、需求開發過程、需求管理過程、項目計劃和跟蹤過程、軟件設計過程、軟件編碼過程、軟件測試過程、項目實施過程、配置管理過程、變更過程、評審過程，其他過程包括：培訓管理過程、組織過程焦點過程、組織過程定義過程；對于項目內部不能解決的問題，由質量保證員匯報給高層管理者；2.2.3.6 溝通管理項目溝通管理的目的是能夠及時、適當地產生、收集、發布、存儲項目信息。溝通管理是人、意見和信息之間的關鍵紐帶，是

43、成功所必須的。參與項目的每一個人都必須做好以項目“語言”方式傳達和接收信息的準備，同時還必須明白他們以個人身份涉及的信息將如何影響整個項目。1溝通原則為了確保及時有效地進行溝通，本項目確定以下溝通原則：n 確保客戶可以最大程度地參與項目工程和管理活動；n 確保與客戶及早溝通需求，以消除需求中的不確定性；n 定期與客戶溝通項目各里程碑和各迭代的進度和進展狀況；n 確保各階段的主要成果物及時提交給客戶，以便客戶評審；n 對于項目出現的重大問題，及早報告給客戶以便客戶了解項目。2存在溝通需求的組織一般包括：n 項目與客戶；n 項目合作方；n 項目組內部，當項目成員工作位置不在同一地點時，要事先確定異

44、地開發的溝通機制，確保項目信息的溝通順暢。3溝通的方式一般包括：n 報告，例如周報、里程碑總結等；n 會議，包括評審、討論等。4溝通的程度一般包括參與和了解，具體參與程度需要根據具體項目需求進行調整：n 參與：參與內容的制定和檢驗，例如項目計劃的編制和評審；n 了解：不參與跟內容有關的制定和檢驗活動，對信息內容了解即可。5溝通的內容，分為三類：n 計劃：包括項目計劃和迭代計劃的制定與評審；n 進展：包括每個迭代狀態和里程碑狀態的評審；n 工程文檔：包括每個工程階段主要輸出物的評審。6項目溝通機制項目的溝通管理機制如下表所示：分類溝通內容組織/發布方溝通方式項目客戶報告會議計劃項目計劃項目-參與

45、項目計劃項目計劃評審會相關方配合計劃項目-參與協作項目計劃協作計劃評審會人員計劃項目-參與項目成員和角色規劃監理計劃監理方-參與監理計劃監理計劃評審計劃變更項目-參與最新項目計劃最新項目計劃評審會周報項目周進展和存在問題分析項目-了解項目周報-里程碑總結報告項目里程碑總結項目-參與項目里程碑總結里程碑總結與評審會狀態評估漸進的進展狀態項目-參與狀態評估狀態評估會需求需求規格項目-參與需求相關報告需求討論分析規劃架構設計設計模型數據庫設計項目-參與分析設計報告分析設計討論開發實現源代碼編碼規范項目-參與-實現功能測試功能測試測試計劃測試用例測試環境測試數據缺陷報告項目-參與測試相關文檔功能測試討

46、論部署部署計劃數據遷移用戶培訓系統集成上線割接驗收測試項目-參與部署相關文檔部署討論階段總結會按商務合同規定的階段項目-參與階段總結報告部署評審會2.2.4 質量管理2.2.4.1 質量控制質量控制的目的是確保：n 完成項目內容并達到預定的目標n 最終的系統是穩定的和可用的n 確保項目按預定計劃完成因此，在項目進行中，需要設立若干控制點，以確保項目的質量可控。質量控制隊伍獨立于項目實施小組，作為項目成功的重要因素和保障，在項目執行過程中始終與項目實施小組保持密切聯系。從另一個角度觀察和監督項目的開展，幫助PMO發現和解決項目執行中的問題確保項目的成功。可以采取以下步驟實施全面質量控制：1建立標

47、準化工作流程項目啟動時，項目組應根據項目范圍、項目要求，首先組織人力編制項目流程、工作標準及相應工作手冊，形成工作方法體系，實現項目工作的流程化、標準化，并對項目人員進行培訓，使他們了解和遵守項目流程和要求。2實行階段性成果提交與變更控制項目具有生命周期，這就為我們劃分項目階段提供了依據。一個大項目可分成若干階段，每個階段有自已的任務和成果。這樣一方面便于管理和控制項目進度，另一方面可以增強項目人員和用戶的信心。在每個階段末要提交部分成果物，作為下一階段開發的基礎。成果物提交之后不是不能修改，而是其修改要經過一定的審批程序，并且涉及到項目計劃的調整。3實行里程碑式的審查與版本控制里程碑式審查就

48、是在項目生命周期每個階段結束之前，都正式使用結束標準對該階段提交的成果進行嚴格技術審查，如果發現問題，應及時在階段內解決。版本控制是保證軟件項目順利進行的重要手段。版本控制的含義是通過給文檔和程序文件編上版本號，記錄每次的修改信息，使項目部的所有成員都了解文檔和程序的修改過程。4測試要采用適當的手段，對需求調查、系統分析、系統設計、實現和文檔進行功能測試。5用戶單位加強監督為進一步加強項目質量控制，要加強用戶單位對項目質量的監督。2.2.4.2 質量保證軟件質量保證過程的目的是為軟件項目組的軟件項目過程提供指導，為管理層就軟件項目過程提供管理信息，為提升軟件質量提供手段。由于開發軟件系統或軟件

49、產品的過程是決定項目成功與否的關鍵因素，因此軟件質量保證的工作是評審和審計軟件活動和軟件產品。軟件質量保證過程需要達到的目標包括：n 軟件質量保證活動是有計劃的活動；n 軟件產品和活動與適用的標準、過程和需求的一致性需經客觀驗證；n 軟件質量保證活動及成果應及時通知到受影響的組織和個人；n 軟件項目內部未能解決的有爭議問題，由上級管理部門處理；軟件質量保證過程定義如下：n 由質量保證員負責向項目組人員進行PPQA定向培訓；n 由質量保證員負責編寫質量保證計劃；n 由質量保證員負責對軟件項目過程及其他公司規范及過程進行質量保證，軟件項目過程包括：軟件銷售管理過程、需求開發過程、需求管理過程、項目

50、計劃和跟蹤過程、軟件設計過程、軟件編碼過程、軟件測試過程、項目實施過程、配置管理過程、變更過程、評審過程，其他過程包括：培訓管理過程、組織過程焦點過程、組織過程定義過程；n 由質量保證員對軟件工作產品進行質量保證，依照工作產品規范/模板檢查項目工作產品；n 質量保證員應參加項目的管理評審和技術評審；n 由質量保證員定期與不定期地將檢查結果報告給有關人員；n 對于項目內部不能解決的問題，由質量保證員匯報給高層管理者；2.2.5 需求管理在軟件項目中，所有的項目相關方都感興趣的就是需求分析階段。這部分工作若處理好了，能開發出很出色的產品，同時會使項目各方感到滿意。若處理不好，則會導致誤解、挫折、障

51、礙以及潛在質量和業務價值上的威脅。因為需求分析奠定了軟件工程和項目管理的基礎，所以所有項目相關方必須重視需求分析過程。軟件需求包括四個層次：業務需求、用戶需求、功能需求、非功能需求。優秀需求所具有的特性：完整性、正確性、可行性、必要性、劃分優先級、無二義、可驗證。需求分為需求開發和需求管理。需求開發包括：問題獲取、分析、編寫規格說明和驗證四個階段。需求管理包括建立和維護軟件需求。n 甲方在需求活動中的權利和義務。通常來說，甲方在需求活動中有如下權利：1要求分析人員使用符合客戶語言習慣的表達。2要求分析人員了解客戶系統的業務及目標。3要求分析人員組織需求獲取期間所介紹的信息，并編寫軟件需求規格說

52、明。4要求開發人員對需求過程中所產生的工作結果進行解釋說明。5要求開發人員在整個交流過程中保持和維護一種合作的職業態度。6要求開發人員對產品的實現及需求都要提供建議，拿出主意。7描述產品使其具有易用、好用的特性。8可以調整需求，允許重用已有的軟件組件。9當需要對需求進行變更時，對成本、影響、得失有個真實可信的評估。10獲得滿足客戶功能和質量要求的系統，并且這些要求是開發人員同意的。甲方在需求活動中有如下義務：1給分析人員講解業務及說明業務方面的術語等專業問題。2抽出時間清楚地說明需求并不斷完善。3當說明系統需求時，力求準確詳細。4需要時要及時對需求做出決策。5要尊重開發人員的成本估算和對需求的可行性分析。6對單項需求、系統特性或使用實例劃分優先級。7評審需求文檔和原型。8一旦知道要對項目需求進行變更，要馬上與開發人員聯系。9在要求需求變更時，應遵照開發組織確定的工作過程來處理。10尊重需求項目中開發人員采用的流程（過程）。n 需求變更控制流程軟件需求作為系統功能的范圍界定和說明，其變更必須進行嚴格的變更控制管理。本項目中，建議建立如下需求變更控制流程：1成立需求變更控制委員會