施工進度計劃書

　　一、工期安排

　　**項目總體工程實施，依照合同按計劃在5個月內完成。工期從20**年9月初開工，至20**年1月底截止。為了保證項目圓滿完成，分階段進行進度控制，同時加強軟件質量管理，以保障項目按工期規定順利交付。

　　二、項目進度表

　　項目階段

　　時間

　　工作內容

　　成果

　　需求調研

　　20**.9.1-20**.9.20

　　成立項目咨詢專家組，對項目需求進行詳細的調研

　　系統需求規格說明書

　　系統設計

　　20**.9.20-20**.10.20

　　在需求調研的基礎上對系統架構、安全體系、功能等進行系統設計

　　系統設計說明書

　　系統開發

　　20**.9.20-20**.12.15

　　進行各個子系統的迭代開發，完成單元測試

　　不同迭代版本的可運行系統

　　系統集成

　　20**.12.15-20**.12.25

　　系統集成和對各模塊集成測試

　　測試報告

　　形成可完整運行的系統

　　系統初驗

　　20**.12.25-20**.12.30

　　項目初驗

　　初驗報告

　　系統試運行

　　20**.12.30-20**.1.10

　　1、平臺上線試運行

　　2、系統持續優化

　　升級版本的可運行系統，并安裝部署到用戶本地

　　用戶培訓

　　20**.1.10-20**.1.25

　　對各級用戶進行培訓

　　使用說明

　　項目終驗

　　20**.1.30

　　項目終驗

　　驗收報告

　　三、項目實施各環節實施方案

　　在明確本項目的建設目標、建設任務和范圍、建設時間進度要求、項目建設特點分析的基礎上，依據招標文件的要求和我方在以往大型信息化平臺建設實施方面的經驗和教訓，為了更好的保障項目的整體進度和整體質量，更好地回避和解決項目建設過程中的可能風險，更好地達到系統的建設目標、項目的總體目標，在本章中，針對本項目的特點，提出我們的項目建設實施整體階段過程的劃分、每個階段要達成的目標、實施方法和實施計劃。

　　系統建設過程主要分為需求調研/分析、系統設計、開發/測試、集成測試、培訓/試運行、驗收交付以及質保期七個大的建設階段。

　　充分吸收面向對象開發的迭代思想，在經典的幾個項目階段基礎上，于每個階段的內部，又分成了若干次的迭代過程;每一個迭代包括計劃、分析、原型等。于是項目可以遞進地進展，每一個迭代周期完成，都會形成一個產品原型，通過與業主的不斷交互，完善，直到原型發展成為可用的產品。

　　如圖：

　　1.項目里程碑

　　里程碑在項目實施中通常設置在階段任務完成點或關鍵任務的完成點。

　　在項目實施計劃中設置里程碑，便于以里程碑為監控點，對項目實施從進度、質量、績效等方面進行更加有效的監控和管理;便于項目組織成員有一個共同的視野，展示項目簡明清晰的階段性目標;便于項目經理與相關人員之間就進度問題進行溝通。

　　在為項目進度計劃設置里程碑時，遵循以下原則：

　　以項目目標為依據，以可交付成果物為向導，設置里程碑?？山桓冻晒锟梢允俏臋n，也可以是可運行的程序。

　　將實施各階段的完成點設置成里程碑。如需求規格定稿作為需求分析階段的完成點，可以定義成為里程碑。

　　設置的里程碑必須可審查、可測量，有明確的完成標準。只有里程碑通過審查，才能進入到下一個階段的任務。

　　綜上所述，本項目的里程碑如下表所示：

　　序號

　　時間

　　里程碑描述

　　1第20天

　　應用系統需求分析/設計完成

　　第120天

　　應用系統編碼實現

　　第130天

　　系統完成測試

　　第140天

　　用戶培訓完成

　　5第150天

　　系統上線試運行，完成初驗

　　6第160天

　　系統試運行完成

　　2.需求分析階段

　　任務范圍：

　　本階段任務范圍包括完善、細化需求分析階段的工作計劃;開展需求調研工作;進行需求分析;編寫需求分析報告。

　　實施方法：

　　通過業務需求調研，確定并定義問題區、用戶的需求、項目范圍、項目成功標準與業主方接收標準。

　　定義實施范圍：確定并定義項目實施的目標、范圍和關鍵的成功要素。

　　編寫需求分析報告：包括業務系統的業務模型、業務流程、業務功能設計等。

　　業務需求調研：主要采取一對一面談、團體座談、發送調研表、調查問卷、查閱需求資料以及召開討論會等多種方式，從業務層、管理層、決策層多方位的獲取需求。

　　根據需求交流進展情況，采用快速原型法，以直觀的方式確認需求。

　　采用Rational Rose的“用例(Use Case)”表述方法定義系統需求，保證需求的完整性、準確性、唯一性、可度量性、可測試性、可追溯性。

　　在描述中盡量使用業主方相關使用人員的業務語言，便于需求的審查和測試。

　　完成標準：

　　本階段任務完成的標準是：正式提交需求分析報告，通過業主方和監理方審核，并經過業主方確認。

　　可交付成果：

　　本階段的可交付成果是：《**項目需求分析報告》

　　3.系統設計階段

　　任務范圍：

　　系統設計階段將按照面向對象的分析設計方法并結合使用其他軟件工程方法，完成各子系統的概要設計。

　　包括功能設計、數據庫結構設計、頁面設計、軟件實現結構的O-O(面向對象)設計。

　　實施方法：

　　本子階段將對業務流程、控制流程、功能模塊和數據結構進行設計，這是承上(需求分析)啟下(代碼實現)的階段，這個階段把業務需求變成技術設計，由業務描述變成技術描述，由業務語言變成技術語言。通常來講，這個階段又可以劃分為三個主要的步驟，即：業務流程及邏輯設計、控制及表現邏輯設計、功能模塊設計、數據結構設計。

　　業務流程及邏輯設計：使用業務圖形按照業務流程的順序對業務進行歸納、整理，繪制業務流程圖。對于其中描述良好和規范的業務需求可同需求分析合并進行，繪制工作將借助繪圖工具軟件Visio對圖形表述進行規范。

　　功能模塊及邏輯設計：抽取最小業務單元，按照按“職能域-業務過程-業務活動“三層結構分解和表達功能，依據業務流程組織功能層次，繪制功能層次圖。把業務流圖中以“操作單元”表現的節點看作功能模塊，描述其輸入、輸出、主要處理過程和所涉及到的數據及數據單元。

　　數據結構設計：對于功能模塊設計中所涉及的有關數據及數據單元進行歸納，利用“對象-關系型語言”表示出來，并指明數據之間的一致性或約束性關系。這就是通常所說的數據結構或稱為數據字典。這部分工作將采用實體-關系設計工具PowerDesigner來輔助進行。

　　系統設計說明書審核：項目經理對各應用子系統的系統設計說明書進行審核。審核工作由項目經理、技術總監和專家協同進行。

　　完成標準：

　　本階段任務完成的標準是：正式提交概要設計說明書，通過業主方確認。

　　可交付成果：

　　本階段的可交付成果是：《**系統設計說明書》。

　　4.編碼開發階段

　　任務范圍：

　　包括對標準化的內部數字內容資源轉換加工和管理、數字內容的深度加工、在線編撰流程管理、知識挖掘和知識數據庫開發、網絡數據采集和內容提供服務、產品打包和多渠道發布、在線交互服務等編碼實現、單元測試;以及項目的安全保障體系的建設。

　　實施方法：

　　(一)日創建、日部署

　　在本項目各應用子系統開發實現階段，將采用快速原型法與“日創建、日部署”開發方法，每天形成一個版本，并進行部署，在最短的時間內開發出核心業務功能交付用戶使用，并在此基礎上再與用戶交流溝通，對問題做出相應調整。

　　這種方法的特點如下：

　　可以在最短時間內開發出子系統核心業務功能交付項目相關人員測試和試用;

　　進入開發階段后，每天形成一個版本，以最直觀的溝通方式讓業主方項目主管領導看到最終的產品原型;

　　最大程度避免了產品的實現與系統需求間的分歧;

　　降低了需求變更的頻度;降低了系統實施的風險。

　　(二)代碼走查

　　代碼走查是由一組人通過閱讀、討論和爭議對程序進行靜態分析的過程。走查小組由組長，2～3名程序設計和測試人員及程序員組成。走查小組在充分閱讀待審程序文本、控制流程圖及有關要求、規范等文件基礎上，召開代碼走查會，程序員逐句講解程序的邏輯，并展開熱烈的討論甚至爭議，以揭示錯誤的關鍵所在。實踐表明，程序員在講解過程中能發現許多自己原來沒有發現的錯誤，而討論和爭議則進一步促使了問題的暴露。例如，對某個局部性小問題修改方法的討論，可能發現與之有牽連的甚至能涉及到模塊的功說明、模塊間接口和系統總結構的大問題，導致對需求定義的重定義、重設計驗證，可以大大改善軟件的質量。

　　(三)單元測試

　　單元測試集中在檢查軟件設計的最小單位—模塊上，通過測試發現實現該模塊的實際功能與定義該模塊的功能說明不符合的情況，以及編碼的錯誤。由于模塊規模小、功能單一、邏輯簡單，測試人員有可能通過模塊說明書和源程序，清楚地了解該模塊的I/O條件和模塊的邏輯結構，采用結構測試(白盒法)的用例，盡可能達到徹底測試，然后輔之以功能測試(黑盒法)的用例，使之對任何合理和不合理的輸入都能鑒別和響應。高可靠性的模塊是組成可靠系統的堅實基礎。將單元測試結果編寫成單元測試報告，提交項目經理審核，審核通過后提交項目領導組審批。

　　(四)系統測試

　　隨著代碼的實現和單元測試完成，軟件測試人員開始對代碼進行系統測試。系統測試以子系統為基本單元進行，其基本測試依據是測試計劃和測試方案。根據測試方案中的用例設計按照模塊逐一“輸入”數據(手工或自動工具)，并進行一定的壓力測試。主要工作過程是：

　　運行程序員提交的功能模塊代碼，輸入數據，如實記錄運行結果，填寫“測試記錄”。對于未通過測試的功能模塊，填寫測試反饋單，由程序員修改問題代碼后再次提交測試。這是一個多次循環反饋的過程。

　　編制系統測試報告：測試結束后，測試人員編制完整的測試報告，包括測試的對象、測試范圍、主要功能、測試環境、測試工具、測試結果匯總，并附完整的測試記錄和反饋記錄。

　　完成標準：

　　本階段任務完成的標準是：編碼完成且通過單元測試、集成測試、系統測試，并通過技術總監與項目經理的審核。

　　系統詳細施工進度計劃，詳見《施工進度計劃甘特圖》。

　　可交付成果：

　　本階段的可交付成果是：網站各系統可進行正常運行。

　　5.系統初驗階段

　　任務范圍：

　　本階段任務范圍包括：完成應用系統在測試環境的部署和集成測試后，由業主方認定是否滿足可進行試運行的基本條件。并完成驗收報告。

　　實施方法：

　　由供應商通過集成測試，對各應用系統自檢合格后，提交初驗申請至用戶方審批。

　　用戶方檢驗應用系統運行情況，看是否符合：

　　是否滿足簽字確認的需求分析報告;

　　是否滿足招標文件要求;

　　是否可以開始試運行。

　　驗收通過后，由雙方共同簽署初驗報告。

　　完成標準：

　　本階段的完成標準是：系統通過業主初步驗收，且可以開始試運行。

　　可交付成果：

　　本階段可交付成果是：系統初驗報告。

　　6.試運行階段

　　任務范圍：

　　本階段的任務范圍是：在用戶培訓工作的階段性成果完成后，開始組織系統試運行工作，由項目經理和業主方主管領導共同確定試運行范圍和試運行策略，并編制試運行計劃、組織試運行工作。

　　實施方法：

　　(一)試運行實施步驟：

　　準備應用系統運行需要的真實數據;

　　組建運行組織和人員準備：

　　建立由業主方主管領導和項目經理組成的試運行領導小組;

　　確定試運行期間系統管理人員和系統維護人員;

　　召開試運行參與人員的動員會，統一思想，明確指導思想、工作方針、工作方法和工作計劃;

　　落實其他試運行組織中的各職責人員。

　　雙方共同制定試運行工作計劃。工作計劃中包括試運行工作相關各方責任、工作日程安排、運行工作制度。

　　(二)試運行期間各方職責：

　　試運行工作將由供應商與業主方密切配合完成。試運行期間中，各方職責如下：

　　供應商負責在試運行期間進行應用系統運行記錄，對試運行中出現的問題做到及時維護和更新，并完成試運行報告。

　　在系統試運行階段，應達到系統連續無重大故障運行1個月，并不斷根據試運行報告進行修改完善，在試運行期內如出現重大故障，試運行期從故障排除之日起重新計算，直到系統連續1個月無重大故障為止。

　　業主方系統使用人員負責在試運行期間定期反饋系統存在問題。

　　完成標準：

　　本階段任務完成的標準是：試運行期間系統運行穩定，性能達標，試運行報告通過業主方確認。

　　可交付成果：

　　通過試運行驗證后的可運行的網站系統。

　　7.系統終驗階段

　　任務范圍：

　　本階段任務范圍包括：試運行結束后，經業主方審核通過后，協助組織業主方進行系統終驗驗收。

　　實施方法：

　　試運行結束后，由供應商提出驗收申請，并協助業主方組織項目驗收，最終完成項目交付。

　　(一)驗收標準：

　　?是否符合項目合同要求;

　　?是否滿足簽字確認的需求分析報告;

　　?是否滿足招標文件要求;

　　?是否滿足用戶培訓要求;

　　?是否滿足試運行期間的整改要求。

　　(二)驗收組織

　　試運行工作完成后，項目驗收工作由供應商、業主方共同組成項目驗收小組對項目進行驗收。

　　驗收小組對驗收內容，如實施過程文檔、用戶培訓效果、軟件運行效果、項目管理等方面進行審查。必要時對項目的主要內容、重要功能和性能組織第三方進行專業測試。

　　驗收完成后，由業主方、供應商共同編制驗收報告，簽署驗收意見，完成項目建設成果的交付。

　　項目驗收完成將作為質保期的開始。

　　完成標準：

　　本階段完成標準是：驗收通過，且完成項目建設成果的交付。

　　可交付成果：

　　本階段可交付成果是：《**項目驗收報告》。

　　四、保障措施

　　在項目開發過程中，策劃可行的質量管理活動，然后正確地執行和控制這些活動以保證絕大多數的缺陷可以在開發過程中被發現。在項目里，評審和測試活動是預先策劃好的，在執行過程中，根據已定義好的過程來執行這些活動。通過執行這些活動來識別缺陷，然后消除這些缺陷。

　　本項目質量保證貫穿于整個項目的始終，開展有計劃、有組織的活動，不斷地改進質量。保證指通過實施計劃中的系統質量活動，確保項目實施滿足要求所需的所用過程。項目團隊的管理人員采取有效措施，監督項目的具體實施結果，判斷它們是否符合項目有關的質量標準，并確定消除產生不良結果原因的途徑，通過質量控制確保項目質量目標得以完滿實現。

　　通過配置管理控制項目的進化過程，如持續的、變化的變更，為軟件系統提供了穩定性，從而保證項目有質量的按規定工期交付。

篇2：房地公司項目進度管理制度

　　房地公司項目進度管理制度

　　1 總則

　　1.2 明確項目所在公司進度管理責任人的義務，實施進度管理與公司考核及獎勵掛鉤的措施，確保高效、優質地完成項目建設的任務。

　　2進度管理的組織

　　2.1 管理公司經營管理委員會為進度管理的領導機構，負責各項目所在公司進度審核工作。

　　2.2 管理公司經營管理部是進度管理的業務歸口部門，負責各項目開發進度的分析整理和監督，定期匯報。

　　2.3 管理公司各業務部門負責各項目所在公司專項業務進度的管理工作，負責及時了解掌握各項目專項工作的進展情況，并定期將各項目所在公司專項業務進度完成情況匯總到管理公司經營管理部。

　　2.4 各項目所在公司總經理為項目進度管理的責任人，全面負責本公司的進度管理工作。

　　2.5 各項目所在公司開發設計部為進度管理的歸口部分，負責項目進度的管理工作。

　　3 進度管理的實施

　　3.1 項目分期進度

　　3.1.1 在項目整體經營策劃書中擬定項目總體開發進度，作為整個開發項目的經營周期。

　　3.1.2 根據項目實際的分期進度情況編制分期進度計劃，在分期項目委托設計開始前的一個月完成分期項目開發進度計劃，并報管理公司經營管理委員會審批。

　　3.1.3 經批準后的項目分期進度將作為項目經營管理責任書中項目開發周期的附件。

　　3.2 年度、季度開發進度

　　3.2.1 每年年初各項目所在公司根據"項目進度編制要點"的要求開始著手擬定本年度各公司開發進度計劃(其中包括各項目各期營銷進度、規劃進度、資金進度、招投標進度等)，并報管理公司經營管理委員會審批。

　　3.2.2 經審批確定后的項目年度開發進度將下發各項目所在公司執行，各項目所在公司需將年度進度計劃分解為季度進度計劃并報管理公司經營管理部備案。

　　3.2.3 管理公司各業務部門負責及時跟蹤各項目專項業務的工作進展情況，使項目的開發進度在受控范圍之內，并每月將各項目進度情況(能夠用橫道圖表達的盡量使用橫道圖)匯總到管理公司經營管理部。

　　3.2.4 管理公司經營管理部負責每季度編制各項目進度完成情況評估報告。

　　4 進度調整的管理

　　4.1在項目開發經營過程中如管理公司各業務部門或各項目所在公司進度管理員發現項目開發進度的某一項進度比原擬定的年度進度計劃延遲在1個月之以內的，應及時提出調整或整改措施確保整體進度能夠按時完成，并報管理公司經營管理部備案。

　　4.2如項目開發進度的某一項專項進度計劃比原進度延遲一個月以上或由于某些原因已確認無法按時完成原定進度計劃的，應認真分析原因，如需調整進度計劃應報管理公司批準。

　　4.3管理公司及項目所在公司進度管理員如提前發現某項進度無法按原定進度計劃完成的，應及時預警，提出解決方案，避免項目進度的延遲。

　　5 相關作業流程和指引文件

　　1) PMG001 進度計劃內容編制要點

篇3：開發項目工程進度付款作業指引

　　開發項目工程進度付款作業指引

　　1.目的

　　為規范公司工程費用、設計費、監理費的申請及支付過程，加強費用支付的計劃管理，實現相關部門對支付情況的及時準確掌握。

　　2.適用范圍

　　本作業指引僅適用于工程進度款和中間款的支付，不適用工程結算款和保修金的支付。

　　3.職責

　　3.1 監理單位負責審核形象進度及造價。

　　3.2 工程技術部負責審核形象進度、質量認定。

　　3.3造價部負責編制工程用款計劃和工程付款申請的審核、付款審批表的制單、付款情況核對。

　　3.4 財務部負責統計付款明細和辦理支付手續。

　　3.5 公司領導層負責各權限內的審批工作。

　　4.工作程序

　　4.1 年度、月度付款計劃的編制

　　4.1.1 年初造價、財務部根據公司經營計劃，針對在建項目實施情況及本年度新開項目計劃制訂本年度付款計劃。

　　4.1.2每份工程合同、監理合同或設計合同簽定之后，由造價部根據合同有關付進度款，按工程進度計劃細化編制付款計劃。

　　4.1.3 在公司每月經營計劃例會上，財務部根據公司的資金狀況協調下月工程費用支付額度，并將工程款支付的情況反饋給造價部。

　　4.1.4 項目部負責建立項目支付臺帳以了解進度款支付情況，為調整月度支付計劃提供數據。

　　4.2 進度結算付款流程

　　隨著工程建設項目的進展情況，施工單位會提出工程進度付款申請，公司按以下程序進行進度結算。

　　4.2.1施工單位須按照合同要求和進度要求進行施工，按月報施工進度的工程量提出工程量結算申請，并報監理單位審核。監理單位審核通過后須簽字蓋章，由項目部對照工程的實際進度進行審核。

　　4.2.2若因工程質量或其它原因，項目部不同意施工單位的付款申請，則應在施工單位提交資料上批注意見后，及時將資料返回監理，由其交還施工單位。

　　4.2.3若項目部同意（包括完全同意和部分同意）施工單位的付款申請，應確認簽字蓋章。然后將申請資料（含施工單位的工程款支付申請表；施工單位進度款報價書；施工單位報送的本期發生的補充造價；經工程部審核的工程形象進度和補充造價資料等）報造價部審核。

　　4.2.4造價部收到進度報表和有關資料后，作好簽收，并立即在各專業造價工程師的支付申請臺帳中登記，就相應付款章件、款項計算內容、數量和價格以及付款計劃額對照等工程施工合同、項目目標成本等進行審核。如果超出目標成本是否有補充造價（如設計變更、現場工程簽證）的完整手續。如果補充造價手續完整，且發生的補充造價在三個月內則登記工程進度臺帳，否則不予認可。

　　4.2.4.1設計變更、現場工程簽證審核

　　a) 結算中明確存在合同外的增減工程，需有項目部或項目部相關人員的確認簽字，及相應部門經理以上人員的審批簽字，審批權限按現場簽證和設計變更權限處理。

　　b) 現場簽證和設計變更單順序號不連貫、公章及簽字不全，無施工后完成情況不得作為結算書附件參與結算。

　　c) 在復核變更簽證時，造價部有權更正現場工程師及監理已確認但不符事實的工程量。

　　4.2.4.2工程量審核

　　a) 在結算工作進行前，成本管理人員應至少閱讀一遍合同，重點復核：工程內容、水電費、結算方式、結算時間、質保金、工期和質量獎罰等；

　　b) 對提供工程結算文件中存在易產生歧意、表示不清晰的文件，退回經辦人；

　　c) 結算單價在合同中有規定的，則按合同規定執行；結算單價在合同中未規定的則參照定額和市場合理低價進行確定

　　d) 結算的工程量核實，不清之處，造價部人員要到工程管理部、大項目部確認或到工地現場進行實地測量確定計量結果。

　　4.2.5以上工程付款的操作事項必須按《工程付款審批流程》要求執行并履行工程付款手續審批。

　　4.3工程付款審批單上報與審批

　　4.3.1《工程項目付款審批表》列有現場工程師、項目部經理、造價工程師、造價部經理、財務部經理、分管副總經理、總經理、董事長簽字欄，按公司有關付款審批權限的規定，分別簽署意見，對付款額度超出分管副總經理權限范圍的，按規定報董事長審批，審批結束后，財務部根據審批意見辦理支付手續。

　　4.3.1若審批結果是同意全部支付，則由財務部在當月內辦理付款手續。對需分期支付的，造價部不再制單，由財務部根據實際情況辦理后續付款手續。

　　4.3.2若審批結果是不同意支付或不同意全部支付，則由財務部于審批完成后兩個工作日內將審批單返回造價部，造價部根據審批意見重新制單，并繼續執行文件中報批流程。

　　4.4 付款情況核對

　　4.4.1根據支付控制情況需要，財務部和造價部應完成項目付款申請和實際付款數額的核對。

　　4.4.2在每月付款計劃中已列項，但未在當月制單的付款項目，其付款計劃額度作廢，下月重新報計劃；若已在當月制單，但未完成審批和付款手續，其當月付款計劃額度作廢，作為應付未付款項目在下月計劃中申報，不必重新制單。

　　4.4.3核對人須在付款清單上簽字確認，并注明核對日期。

　　5.支持性文件

　　5.1《工程付款審批流程》

　　6.相關記錄

　

　6.1《工程項目付款審批表》