1、軟件開發工程實施方案工程管理實施方案作為一個工程管理者，如何要成功的做好工程管理;首先必須先要明白的是 在特 定的領域中賦予這個角色所要實現的目標、承當的職責、以及工程管理者的 具體工作 內容是什么？從我個人的淺見和角度以及我們所從事的IT領域來分析回答以上三個 問題。第一：目標作為一個工程的管理者，必須要明確的知道自己的工作目標;我個人認為項 目管 理者的目標無非就是以下兩點：1、就是清晰明確地了解工程利害關系者的需求和期望，努力做到滿足工程利 害 關系者的不同需求;工程利害關系者包括:工程團隊成員和工程團隊外成員（比 如各部 門的部門負責人和市場人員，客戶等。2、就是保證開發工程按需按時保

2、質的完成。第二:職責作為工程的管理者，首先要端正態度，要明確知道自己的工作職責，認識到這份 工作職責的本質。工程管理者不是來管人的，而是來支持人的，是來協調資源的，是 來營造一個適合團隊成員比擬認同的工作環境和氣氛的，是來為一個共同的目 標和大 家一起戰斗共同成長的?？梢源蟾鸥爬ǔ梢韵聨c：1、建立有效的工作流程保證工程的順利進行。2、制定詳細周密的工程計劃。3、跟蹤，推動工程按計劃進行。4、積極解決工程過程中出現的問題和沖突。5、調動開發團隊的積極性，創造力，推動團隊成員在工程過程中不斷成長。6、工程風險識別、風險評估、風險解決和風險管理策略以及做好突發風險的應 急預案。7、實現目標第三:工

3、程管理者的具體工作內容最后一個是工程管理者的具體工作內容，作為工程管理者必須清晰的知道自 己的 工作范圍和所要做的工作內容以及工作重心，分為以下六點: 不同于制造業計件生產，各模塊最終要集成在一起形成一個有機的整體，這 就需要各 小組之間的密切配合，界定清楚工作界面及接口關系，并在實施過程中 持續地溝通交 流和共享，首先團隊要融為一體，產出的軟件才能融為一體。這是一個團隊的軟實力，團隊之間的協作好壞也將是個潛在的風險問題，在工程 啟動和團隊組建的時候就應該加以規避這樣的風險出現。工程風險管理的要點：1、上述我們所說的風險管理都是指可以預期將要發生的風險，那些不可預 期將 要發生的風險不屬于風險

4、管理的范疇。這也將是考驗一個工程管理者的經驗 和知識對 能否管理好風險至關重要的內容。2、對不可預期的風險，工程管理者要有潛在的風險意識評估，做好一些可操作 性的預案準備。3、詳細明確的工程計劃、以及工程執行過程中每個要點的質量保證是降低 工程 風險的必要條件。4、風險報告是工程團隊以及領導了解工程風險的一個有效手段。風險報告 的格 式：序號風險簡介對工程的影響解決方案或對策5、團隊管理團隊就是一組個體為實現共同的目標而相互依賴、一起工作的 共同 體。團隊工作顧名思義就是團隊成員為實現這個共同的目標而付出的共同努力，工程 團隊的工作是否有效直接關系到工程的成敗。團隊管理是個漸進的過程。世界上只

5、有完美的團隊，沒有完美的個人。好的 高效 的團隊不是管理出來的，而是營造出來的。團隊成員需要有大家可認同的團隊文化， 這需要大家共同的努力。1、營造良好的工作環境和氣氛。2、建設優秀或鮮明的團隊文化。3、保持高效的溝通。6、工程會議組織會議是工程管理者日常工作中一項非常重要的工作任務，工程 過程中很多重要的決定都是在會議中做出的，也有很多由于不成功的會議而對工程本10身造成了不好的影響。首先看看不成功的會議常常表現為哪些形式：1、會議氣氛不好，參與者發言不踴躍；2、會議討論常常偏離主題；3、會議沒有取得預期的結果；4、會議時間常常一拖再拖。這些不成功的會議最終的結果就是：既浪費了大家 的珍貴時

6、間又沒有到達會議的目的，很多人都對這樣的會議都有抵觸情緒，對此也是 深惡痛絕。以下是組織會議時應該注意的問題，也可看作組織會議的最正確實踐。在列出最正確 實踐之前有三點我們必須要清楚：1、會議是否會取得成功很大程度上取決于會議的組織者。只有組織得有力，會 議才有可能取得成功，這是會議成功的充分條件。2、會議的組織者和參與者的想法通常是不一致的，有時候甚至會大相徑庭。所 以不要希望會議的參與者和你一樣，對會議有著如此的期待，對大多數參與者而言， 在會議中他只是一個發表想法的人，他不用對會議的成功承當責任。3、以下十一條最正確實踐是形式上的約定，具體的實施可以根據實際情況來做。 組織會議的十一條最

7、正確實踐：1、只有需要開會時才開會。有時候兩三個人單獨小范圍溝通會更加有效。2、提前發出會議議程，以便會議參與者知道他們來做什么。3、請對人很重要，不要把非必要的人召來開會，當然也不要漏掉那些關鍵人物。 在確保必要人物都在的情況下一次會議參與者越少效果越好。4、提前預約參與者的時間，以確保他們能按時到場。5、會議的開場很重要。會議組織者要在開始前做好幾件事情。通常我建議有幾 點要在開場時說：A、再一次強調會議的目標，我們來做什么。B、強調會議的主題與基調。比方：本次會議是一個需求確認會，而非需求討論 會，主要是討論做還是不做以及告知大家我們要做什么，而不要把太多的精力放在討 論如何做上面。11

8、c、說明一下會議的規那么。如要發言，請舉手；不要有小圈子討論；不要打斷別人的講話，等別人說完你再說等等。6、會議過程中時刻注意引導和控制會議，以確保會議按照目標進行。一次會議的氣氛是否良好，討論是否充分，好的引導至關重要。比方多 提一些開放式的問題。7、會議記錄很重要，把一些結論和有價值的內容記錄下來，這些是本次會議的 重要成果之一。8、會議要有結論。我們常在會議上聽到有人說：大家討論了這么半天，結論 呢？ 。沒有結論的會議是沒有意義的。9、會議后別忘發會議紀要，以及一些Action,什么人什么時候做什么。10、 會議后的action執行情況的反響很重要。反響是對會議參與者的尊重，同 時也告知

9、了會議的效果。否那么會讓大家感覺到這是一個可無可無的會議，大家以后參與的積極性也會降低。 很多會議往往都不注意這一點。11、按時結束的會議會受到所有人的歡迎。7、版本控制版本控制也是工程管理者的一個重要工作內容之一，一個工程或產 品的完成不可能是一步到位的，在工程完成的后期可能會有多個不同的版本的發布 （開發版本，測試版本，發布版本等）。需要做好版本的管理和控制。8、工程總結在工程完成后，總結整個完成工程的過程和經歷，為下一次的 工程 啟動提供參考經驗，完善缺乏，防止在類似的工程中出現可能存在的相同的 錯誤發生。1軟件開發實施方案系統開發嚴格按照軟件工程的方法進行組織，系統的開發過程按照需求分

10、析、系統分析與設計要求、系統編碼、系統測試幾個過程有序推進。下 表所示系統開發流程圖，采用原型及迭代方式開發，根據用戶需求持續改進，直到最 終用戶確認滿意。1. 1開發流程總述如以下圖示流程定義了我公司內部的軟件開發過程，以指導和規范軟件工程中 開發12 過程的定義和相應的實施。該過程可劃分為一系列子過程，包括：軟件需求分析、設計、編碼、測試、驗收、維護，每個子過程又由一系列任務和活動組成，如設計過 程又 可分為結構設計和詳細設計。但是在實際開發工程中，情況仍然會是千變萬化的，因此我們也并不是一成 不變 的死板執行一個僵化的工作流程，我們的原那么是在一個規范流程的指導和約 束下，根 據具體工程

11、工程的實際要求，為每一個工程評估并制定真正能夠最好的 滿足該工程要 求的開發流程。開始軟件需求分析YN：改進YN：改進YN：改進軟件需求規格說明書（初稿）系統測試計劃系統測試案例（初稿）用戶手冊（概要）追溯表一軟件需求規格說明書系統測試計劃系統測試案例個人評審記錄評審報告同行評審通過結構設計評審通過結構設計說明書（初稿）13集成測試計劃集成測試案例（初稿） 用戶手冊（初稿）追溯表一結構設計說明書集成測試計劃集成測試案例個人評審記錄評審報告詳細設計說明書（初稿）單元測試計劃單元測試案例（初稿）用戶手冊（修改稿）追溯表一詳細設計說明書單元測試計劃單元測試案例用戶手冊（修改稿）個人評審記錄評審報告源

12、代碼、源代碼文件清單單元測試報告（經過審批）軟件問題狀態登記表軟件問題報告單集成工作單集成測試工作單集成測試報告（經過審批）軟件問題狀態登記表軟件問題報告單集成的軟件系統系統測試報告（經過審批）軟件問題狀態登記表軟件問題報告單系統管理員使用說明書（經過審批）安裝手冊（經過審批）14用戶手冊（經過審批軟件系統（系統測試通過）驗收測試報告軟件問題報告單軟件問題狀態登記表驗收報告可交付產品軟件需求規格說明書（升級版）客戶需求登記表客戶需求統計表設計說明書（升級版）軟件問題報告單軟件問題狀態登記表軟件維護實施計劃維護后的軟件系統詳細設計評審通過編碼集成測試系統測試驗收維護結束圖LIT軟件開發流程總圖在

13、應用系統軟件開發工程中，我們仍將遵循這一思想，這一點將在隨后的工程開 發實施計劃局部有具體的表達，在這里和下面的相關章節中，我們仍將圍繞著這個完 整的開發流程來分析說明，以此來說明我們對工程開發的完整過程管理 思想和相關實 踐。下面我們對這個軟件開發工作流程進行簡要地分解說明。1.2軟件需求分析（1）概述由于應用系統與眾多相關應用軟件需要進行交互，因此需要先對這些應用系統進15 行分別梳理，充分做好需求調研工作，編寫經工程單位認可并評審通過的系 統需求 規格說明書。軟件需求分析是按照工程定義的軟件開發過程，根據系統分配給軟件的需求（見 系統需求規格說明書），進行軟件質量特性規格說明的過程。該過

14、程包括 進一步 明確軟件運行環境，明確對軟件的功能、性能和數據要求，以及軟件與硬 件、軟件與 軟件之間的接口要求等，并對軟件需求進行驗證和文檔化，即完成對 軟件需求的分析 與規格定義。本元素在整個過程中的位置如以下圖所示：系統分配給軟件的需求軟件需求分析結構設計圖示：軟件需求分析在軟件開發過程中的位置（2）入口準那么和出口準那么1）入口準那么要素判斷準那么客戶需求（系統需求規格已由CCB批準為基線說明書）已進入配置庫2）出口準那么要素判斷準那么已經過審查軟件需求規格說明書已批準為基線已進入配置庫系統測試計劃已經過審查16已獲得批準系統測試案例已進入配置庫用戶手冊(概要)追溯表一已編寫已填寫(3

15、)評審評審軟件需求規格說明書，具體評審過程見評審程序文件，對軟件需求 的評審準那么包括：系統需求和系統設計的可追溯性；與系統需求的一致性；內部一致性；可測試性；軟件設計的可行性；運作和維護的可行性。對軟件需求中的問題，與系統工程組或客戶一起確定和審查，根據審查結果對軟 件需求進行適當的修改，必要時按基線變更控制的要求對客戶需求進行相應的修改。對軟件需求規格說明書進行同行評審。審查、批準軟件需求規格說明書。將軟件需求規格說明書置于配置管理之下。(4)工作產品軟件需求規格說明書系統測試計戈|J系統測試案例用戶手冊 追溯表(5)職責工程經理：負責組建軟件需求分析組；確定是否需要對有關人員進行培訓；負

16、責軟件需求規格說明書的審查和批準。軟件需求分析組：軟件需求分析的主要承當者，負責完本錢過程元素要求產生的所有工作產品。17系統測試負責人：負責組織軟件系統測試組對軟件需求進行分析，審查軟件需求的可測試性；參與軟件需求規格說明書的審查和批準。質量保證人員：參與工作產品的審查，統計缺陷，并對軟件需求分析過程進行審計。系統開發組：配合處理涉及客戶需求的軟件需求問題。客戶：必要時參與軟件需求規格說明書的審查和批準。1.3結構設計（1）概述結構設計是指按照軟件需求規格說明書，設計軟件系統的體系結構，即模塊 結構，定義每個模塊的主要功能和模塊之間的聯系（即接口），并確定軟件 系統的數 據體系結構。本元素在

17、整個過程中的位置如以下圖所示：軟件需求分析結構設計詳細設計圖示：軟件需求分析在軟件開發過程中的位置圖（2）入口準那么和出口準那么1）入口準那么要素判斷準那么軟件需求規格說明書經過審查審查獲得批準進入配置庫2）出口準那么要素結構設計說明書集成測試計劃集成測試案例用戶手冊（初稿）判斷準那么經過審查18審查獲得批準進入配置庫追溯表一（3）評審對結構設計說明書和集成測試計劃進行同行評審。對結構設計中的問題，與軟件需求分析人員一起確定和審查，并對結構設計進行適當的更改。審查、批準結構設計說明書，必要時，對其進行設計評審。將結構設計說明書、集成測試計劃和集成測試案例置于配置管理之下。（4）工作產品結構設計

18、說明書集成測試計劃集成測試案例用戶手 冊-追溯表（5）職責1）工程經理負責選擇合適的設計人員，組建結構設計工作組；負責結構設計說明書和集成測試計劃的審查和批準。2）結構設計人員結構設計階段工作的主要承當者，負責完本錢過程元素產生的所有工作產品。3）系統分析員配合處理涉及軟件需求的問題。4）系統開發負責人負責組織系統工程組對結構設計進行分析，審查結構設計的可測試性；負責協調處理涉及軟件需求的問題；參與結構設計說明書191、工程前期階段對工程進行技術可行性分析、技術評估、本錢評估以及風險評估。與需求提 出方 的代表進行需求討論，明確工程的目標、價值;確定工程范圍、功能及優先級。組建 工程團隊，特別

19、要搞清楚工程的keyperson （對產品有決定權的人。工程啟動會議，相 關的利害關系人員都必須參加。該階段完成后的成果:確認后的最終軟件需求規格說明書文檔。2、分析設計階段根據確認后的軟件需求規格說明書，制定工程進度計劃，工作任務分解（WBS;資 源申請，工程涉及到的開發資源、測試資源、設計資源（包括人員和軟硬件資源；數據 庫設計；系統設計；文檔（包括UseCase、Dem。系統原型、TestCase等;評審 會議。該階段完成后的成果:A、UserCase （系統用例;B、DEMO （系統原型；C、系統設計文檔（概要設計和詳細設計;D、數據庫設計文檔。最后對完成的成果，包括UserCase和

20、設計文檔等進行評審。3、執行階段（開發和測試準備開發環境、測試環境;跟蹤，推動工程按計劃進行；以周報的形式通報項 目 的進展情況。對工程的階段成果進行評估，以確保該階段完成的質量，包括代碼 審核、 SQL審核等。對需求變更進行控制管理;對工程風險進行管理;測試階段BUGFIXED及改 進、收集反響意見。4、發布階段包括制定工程發布計劃，用戶培訓，發布上線。5、上線后監控數據監控（日志、服務器狀態，根據監控出現的問題，及時進行BUGFIXED及改進 或做補丁升級。6、結束階段產品交付，工程總結會。第四：基于以上三個問題所做的應對細那么要做好工程管理，并能確實解決好以上三個問題，實現目標、履行職責

21、、完成工 作中的具體內容，從我個人這幾年的工作經驗和面臨的一些問題，還有所積累的一些和集成測試計劃的審查和批準。5)軟件測試負責人負責組織軟件測試組對結構設計進行分析，審查結構設計的可測試性；參與結構設計說明書和集成測試計劃的審查和批準。L4詳細設計(1)概述詳細設計是根據結構設計說明書進行模塊設計，將結構設計所獲得的模塊按 照單元、程序、規程的順序逐步細化。詳細定義各個單元的數據結構、程序的實現算 法以及程序、單元、模塊之間的接口等，作為以后編碼工作的依據。本元素在整個過程中的位置如以下圖所示：結構設計詳細設計編碼圖示：詳細設計在軟件開發過程中的位置(2)入口準那么和出口準那么1)入口準那么

22、要素判斷準那么經過審查審查獲得批準結構設計說明書進入配置庫2)出口準那么要素判斷準那么要素判斷準那么經過審查審查獲得批準詳細設計說明書進入配置庫(3)評審對詳細設計說明書和單元測試計劃可進行走查或(和)同行評審；20對詳細設計中的問題，與結構設計人員一起確定和審查，并對詳細設計做出適當 的更改；審查、批準詳細設計說明書，必要時，對其進行設計評審；將詳細設計說明書和單元測試計劃置于配置管理之下。（4）工作產品詳細設計說明書單元測試計劃單元測試案例用戶手冊-追溯表（5）職責1）工程經理負責選擇合適的設計人員，組建詳細設計組；負責詳細設計說明書和單元測試計劃的審查和批準。2）詳細設計人員詳細設計階段

23、工作的主要承當者。負責完本錢過程元素產生的所有工作產品。3）系統分析員配合處理涉及軟件需求的問題。4）系統開發負責人負責組織系統工程組對詳細設計進行分析，審查詳細設計的可測試性；負責協調處理涉及軟件需求的問題；參與詳細設計說明書和單元測試計劃的審查和批準。5）軟件測試負責人負責組織軟件測試組對詳細設計進行分析，審查詳細設計的可測試性；參與詳細設計說明書和單元測試計劃的審查和批準。1. 5編碼21(1)概述編碼階段主要完成的工作是根據詳細設計說明書編寫程序源代碼，包括必要的數據文件，并進行單元測試，單元測試的內容包括模塊內程序的邏輯、功能、參數傳遞、變量引用、出錯處理等方面。本元素在整個過程中的

24、位置如以下圖所示：詳細設計編碼集成測試圖示：編碼階段在軟件開發過程中的位置(2)入口準那么和出口準那么1)入口準那么要素判斷準那么詳細設計說明書經過審查單元測試計劃獲得批準進入配置庫2)出口準那么要素判斷準那么源代碼文件源代碼文件獲得批準源代碼文件清單源代碼文件進入配置庫的源代碼區單元測試報告提交測試負責人軟件問題報告單提交問題管理渠道(3)評審對源代碼文件進行同行評審，主要的方法為對照詳細設計說明書對代碼進行查22 閱，也可根據編程者的經驗或程序的難度、重要程度，選擇走查評審方式，但目的都 是發現程序存在的問題。(4)工作產品源代碼文件單元測試報告軟件問題報告單軟件問題狀態登記表(5)職責工

25、程經理建立編碼組、測試組或相應崗位，并進行必要的培訓；跟蹤進度和問題解決狀態；對提交的源代碼進行批準(或指定負責人進行批準工作)。程序員編寫程序代碼；測試程序代碼；修改程序代碼；提交工作產品，批準后將其導入配置區的源碼庫。單元測試人員測試源代碼；提交測試報告和軟件問題報告單。評審人員對指定源代碼文件進行閱讀，發現缺陷和問題，填寫評審報告。6模塊集成測試(1)概述集成測試階段主要完成的工作是集成和集成測試。集成是參考結構設計說明書并根據詳細說明書中規定的系統集成方案將不同的經 測試的程序單元進行構造，并逐步構造成一個完整的軟件產品的過程；集成測試那么是在集成完成之后，對各單元、模塊之間接口的正確

26、性和集成后功能的正確性進行驗證。23對于大型軟件，集成測試可以采取分步進行的方法，可以先對各子系統進行集成 測試，然后在子系統之間進行集成測試。本元素在整個過程中的位置如以下圖所示：編碼集成測試系統測試圖示：集成測試在軟件開發過程中的位置（2）入口準那么和出口準那么1）入口準那么要素判斷準那么經過審查獲得批準進入配置庫結構設計說明書詳細設計說明書集成測試計劃源代碼文件2）出口準那么要素判斷準那么獲得批準進入配置庫提交集成測試負責人已進入軟件問題管理流程集成的軟件系統（完整的源代碼和目標代碼）集成測試報告軟件問題報告單（3）審查階段核查集成狀態和結果，并進行批準；批準后，將目標程序和程序清單進入

27、目標代碼庫。（4）工作產品集成后的系統目標代碼（包括文件清單），及相應的源代碼（包括文件清單）集成測試報告軟件問題報告單軟件問題狀態登記表集成工作單集成測試工作單（5）職責24工程經理：建立集成組、集成測試組或相應崗位，并進行必要的培訓；跟蹤進度和問題解決狀態；對集成后的系統目標碼進行批準(或指定負責人進行批準工作)。集成負責人員：負責集成過程的實施。集成人員：負責環境構建，集成的過程操作，并將集成后的目標代碼提交批準。程序員、設計人員：修改源碼或設計，解決集成過程中出現的與源碼有關的問題。測試人員：測試系統目標碼，將測試報告和軟件問題報告單提交測試負責人。1.7系統測試(1)概述系統測試的主

28、要任務是從系統需求的角度對系統運行的正確性和性能進行驗 證。系統測試的依據為系統測試計劃。本元素在整個過程中的位置如以下圖所示：集成測試系統測試驗收圖示：系統測試在軟件開發過程中的位置(2)入口準那么和出口準那么1)入口準那么要素判斷準那么經過審查系統需求要素判斷準那么獲得批準進入配置庫編寫完成系統的目標代碼系統測試計劃25用戶手冊2）出口準那么要素判斷準那么獲得批準系統測試報告軟件問題報告單（3）工作產品系統測試報告軟件問題報告單軟件問題狀態登記表（4）職工程經理：負責建立系統測試組或相關的崗位，并進行必要的培訓；跟蹤進度和問題解決狀態；對最終的目標代碼進行批準（或指定負責人進行批準工作）。

29、程序員、設計人員：修改源碼或設計，解決集成過程中出現的與源碼有關的問題。測試人員：測試系統目標碼，將測試報告提交測試負責人，將軟件問題報告單提交問題管理渠道。1.8驗收（1）概述驗收階段主要由驗收測試、驗收測試問題改正和驗收三局部組成：驗收測試的主要目的是驗證所開發的系統在用戶的使用環境下（或模擬的使用環境下）是否滿足系統需求，從用戶的角度驗證整個系統運行的正確性。驗收測試問題改正是對驗收測試中發現的差異性問題進行修改。驗收那么是在驗收測試的基礎上，依據工程合同或工程任務書對項目的完成情況進行綜合評價。本元素在整個過程中的位置如以下圖所示：26系統測試驗收維護圖示：驗收在軟件開發過程中的位置驗

30、收的三個組成局部視工程立項類型和客戶的要求選擇執行。(2)入口準那么和出口準那么1)入口準那么要素判斷準那么驗收測試前完成評審。驗收測試計劃(有驗收測試要求的工程)測試(系統測試、集成測試、單已完成元測試)2)出口準那么要素判斷準那么已提交已關閉已提交驗收測試報告驗收測試問題報告單驗收報告(3)工作產品驗收測試報告軟件問題報告單軟件問題狀態登記表驗收報告可交付產品(4)職責驗收測試組：負責驗收測試的各項活動。27開發組人員：負責驗收測試中發現問題的改正和測試輔助。工程管理人員：負責指派驗收測試責任和完成測試規程；確保測試質量和進程；確保組間協調。驗收組：具體進行驗收。CCB :批準運行基線。1

31、.9維護(1)概述維護期是指：軟件產品/系統驗收后，進入軟件運行/系統維護階段，直至軟件產品下一個版本 的發布或系統維護期終止；本元素在整個軟件開發過程中的位置如以下圖所示：驗收維護圖示：維護在軟件開發過程中的位置(2)入口準那么和出口準那么1)入口準那么要素判斷準那么軟件產品/系統已驗收2)出口準那么要素判斷準那么軟件產品已退役合同約定的維護期限28已到期合同約定的維護范圍已超出，須另簽協議(3)工作產品軟件需求規格說明書客戶需求登記表客戶需求統計表設計說明書軟件問題報告單軟件問題狀態登記表軟件維護實施計劃維護后的軟件系統(4)職責維護負責人：制定軟件維護實施計劃，確認維護類型、需求范圍，分

32、配維護任務, 追蹤任務的完成情況及其他工程管理工作。軟件維護人員：負責進行軟件維護任務的執行。QA人員：負責協助維護負責人根據實際情況剪裁標準流程。b8工程實施1工程實施概況依據工程建設要求，對中山農情統計分析系統進行整體規劃設計更新維護，對系統運行的平安性、可靠性、易用性以及穩健性進行全新設計，并將所有的應用系統進行部署實施和軟件使用培訓以及技術支持。工程組承諾工程獨立完 成， 不轉包外包。1. 1工程實施管理原那么工程開發維護的實施中，嚴格按照xxxx國際質量體系進行控制，保證為用 戶提 供優質的產品、嚴密的工程實施、高效的服務支持。為此，要遵循以下工程實施管理 原那么和保證體系。29工程

33、管理中的一些知識以及自己的觀察和思考的角度看，應該要努力做好以下這幾個方面的具 體工作：1、工程開發時間的估算制定工程進度時間表的時候，需要估算每個任務所需的時間，其中開發任務 中模 塊的分配和時間估算是其中最主要的局部;在分配模塊和估算開發時間時需 要遵循的 原那么和目標：1、保證工程整體的進度。2、有助于確保開發編碼的質量。3、有助于提高開發編碼的速度。在公司現有的技術框架下，開發人員主要的工作是投入在具體的商業邏輯上。通 常每個模塊所需的開發時間取決于以下三個因素：1、所負責模塊的商業邏輯的復雜程度。2、開發人員的技術水平和對工程所在應用的熟悉程度（包括對框架和應用的熟悉 程度。3、該模

34、塊技術實現上是否有技術難點；這里所謂的技術難點定義是:在現有 系統 中還未實現的、開發人員自身也未沒接觸過的技術。對于這樣的難點，開發者沒有相 關的代碼可以參考，自己也沒有經驗，所以需要投入一些時間研究解決。模塊分配和開發時間估算的步驟：1、在劃分好模塊后，首先自己先估算一下每個模塊所需要的開發時間。2、然后召集所有開發人員，討論模塊的分配和開發時間估算。將劃分好的模塊, 讓開發人員從中挑選他們感興趣的模塊。這樣做可以提高開發人員的主動性和參與性。 在分配模塊的時候還需從以下幾方面考慮，以確保開發的速度和質量:A、相同類似的 模塊由同一人負責開發，比方用戶管理的增刪改由同一開發者負責。這樣做的

35、好處就是開發者對相關邏輯會更加熟悉，同時接口的定義也會比擬明確, 溝通的本錢比擬低，同時功能實現的缺陷也相應的會降低。B、技術難度比擬大的模塊由技術水平比擬高的人負責。C、業務邏輯比擬復雜的由對這塊邏輯比擬了解的人負責。模塊分配完后，開發人員評估自己負責開發的模塊所需要的時間。在此過(1)有經驗、成熟的技術隊伍是工程實施的前提條件完成任何工程工程，必須擁有一支有經驗的、勇于探索的、高水平的、具有嚴謹 工作作風的技術隊伍，在工程實施的過程中發揮團隊協作精神和用戶密切協作的能 力。(2)管理層次清楚、職責清晰是工程實施的基礎建立層次清楚的工程工程實施管理機構，明晰各層的管理職責，從組織管理的角 度

36、保證工程實施計劃落到實處。(3)確定過程控制點，以過程質量保證整體工程質量整體都是由局部和具體的細節構成，工程由一個個過程環節組成，只有認真對待 每一個過程細節，才能保證工程工程整體的實施質量。(4)用戶參與是工程工程成功的保證從工程開始到工程的結束，每個階段都強調用戶的參與。開發商只有和用戶相結合才能使開發出的系統為用戶所用，發揮出系統的最大效 益，而用戶的參與也是系統順利進行的保證。對本工程短時間、大范圍的配置安裝來說，如果有用戶的高度參與，工程工程的 實施將大大加快。bb8. 1.2工程組織結構本工程是一項涉及面廣、影響大、平安運行要求高，集數據處理、信息發布、資 源整合于一體的政府信息

37、化工程。為了更好的執行該工程，將采取統一指揮、并行實 施、相互支援的實施方法。為了使該工程能順利實施，便于工程的管理和協調，使工作職責更加清晰明白， 建立工程組織實施小組，建立由工程領導小組、工程管理辦公室、工程監理 公司、顧 問咨詢組、工程經理、工程具體實施小組組成的實施管理控制組織體系。工程實施組織具體職責如下：(1)工程領導小組負責工程實施過程中的重大事件決策；根據工程的進度、質量、技術、資源、風險等實行宏觀監控；30負責組建驗收小組，主持驗收工作；協調參與工程各方的工作關系。(2)工程管理辦公室組織各方統一制定工程管理計劃；組織總體實施方案評審，組織測試驗收；負責工程進度計劃與本錢控制

38、；協調解決工程實施過程中出現的各種問題。(3)顧問咨詢組1)人員組成農業信息化相關領域的業務專家；多年從事IT行業和展廳建設的信息技術專家。2)主要職責系統總體設計指導；對各子系統深化設計進行審核并提出優化建議；對各子系統進行技術協調；協助客戶對系統的設備配置予以確認；對現場系統安裝、調試提供必要的技術支持服務；工程文檔審核。bb(4)工程經理人員組成工程經理由具有豐富工程管理經驗的高級工程師擔任。2)主要職責制定工程計劃：牽頭制定工程計劃。工程執行：對總體方案設計及工程設計；配置確認；31工程質量保證；系統設計、開發、測試、安裝及調試；系統培訓、驗收。工程檢查：通過其下屬各工作組提供的工程進

39、展匯報，將工程進展狀態與工程計 劃進度進行比擬，發現過程誤差，提出整改措施。工程控制：審核工程進展狀態，必要時調集各種備用資源，確保工程按計劃 進度實施。工程協調：與客戶、各分系統建設部門進行協調，解決工程組織接口及技術 接口問題；定期主持系統建設協調會，及時解決各系統間出現的相關問題。工程匯報：定期向工程采購單位匯報整個工程的進展情況，匯報在系統建設 過程中出現的重大問題，聽取指導和建議。（5）總體方案組1）人員組成由從事過多名基層電子政務工程的系統架構師、系統分析員和需求分析工程師組成。2）主要職責對工程經理負責；進行系統的需求分析調研；負責系統的總體設計；籌劃系統的模塊功能結構；配合業主

40、方進行系統驗收。（6）軟件開發組對業主需求分析進行全面細致的了解或確認，深入描述軟件的功能和性能，劃分系統的軟件功能需求和硬件功能需求，確定軟件同其它系統元素的接口細節,bb并與客戶一起討論決定系統驗收方案。1）人員組成32iWj級程序員；具有豐富產品開發經驗的產品開發設計人員。2)主要職責負責工程應用軟件的系統設計；負責工程應用軟件的程序編碼；負責工程應用軟件的運行調試；配合業主方進行系統驗收。(7)系統測試組從使用者的角度完成系統操作步驟的設計，在實施過程中監控測試系統是否到達 最初制定的操作目標，并編寫業主操作手冊。檢驗系統開發質量，并進行功能測試。當開始試運行階段后，還要對工程的各個方

41、面指標進行測試和評估。(8)系統實施組1)人員組成由具有豐富經驗的系統工程師和參加系統開發的軟件工程師組成。2)主要職責負責各個實施區域的實施方案的設計與建議；組織系統安裝及調試；負責系統配置修改，安裝技術支持；8. 1.3工程團隊根據上述工程組織結構和職能分解，北京派得偉業科技開展計劃投入高級顧問1人，工程經理2人、技術負責人1人、實施經理1人、系統設計組 4人、軟件開發組13人、系統測試組3人、系統實施組3人。共計28人。形成 專門服務本工程的技術開發實施隊伍。隨著開發層次的深入、開發量的增加，北京派得偉業科技開展投入的人力資源將隨之增加和不斷進行調整。未經招標人同意，工程總負責人及各分工

42、程負責人在工程結束前不得變更。b具體人員組成分配情況分別如下表所示：表1.工程實施人員一覽表33序號本工程職責姓名職務公司副總、農業生產本工程具體分工系統總體設計指導及系統深化設計進行審核并提出優化建議.高級顧問張俊與管理事業部總經理農業生產與管理事業部副總經理工程統籌和溝通協調、技術研發和總體設計.工程經理徐杰（工程經理證書見附件）農業生產與管理事工程統籌和溝通協調、技術業部.工程經理史同鑫研發和總體設計工程經理.技術負責人劉鵬高級架構師工程開發過程管理農業生產與管理事.34實施經理魯國寶工程實施管理業部實施工程師. 7. 8. 9. 10. 11. 12. 13.劉鵬飛總體設計組劉偉梁軼曉

43、楊彬高麗郭壽水路鑫辛堂峰軟件開發組系統設計師需求分析需求分析需求分析高級程序員、開發組長程序員、開發組長高級程序員、開發組長程序員、軟件開發程序員、軟件開發程序員、軟件開發程序員、軟件開發程序 員、軟件開發程序員、軟件開發原型制作系統設計師工程籌劃高級架構師高級架構師高級架構師程序員程序員14. 15. 16. 17. 18.秦巖賓賀永林程序員程序員程序員程序員閆壽增馮占衛劉霞美工b序號 19. 20.21.22. 23. 24. 25. 26.35本工程職責姓名李楠趙偉李妓職務美工美工系統測試師系統測試系統測試實施工程師實施工程師實施工程師本工程具體分工原型制作原型制作測試經理、系統測試系統

44、測試系統測試系統實施、安裝部署系統實施、安裝部署系統實施、安裝部署系統測試組徐勝慧王楠石立坤系統實施組胡桂金張鵬飛8. 2工程實施計劃工程實施的成功與否的關鍵因素中包括系統配置、工具的使用、人員組織、實施流程和工程方法等。工程開發及實施過程要遵循應用系統開發管理和流程管理規范，該規范包括以下幾局部內容：工程流程規范、人員組織規范、體系結構 規范、業務需求規范、模型設計規范、最終用戶應用規范、計劃和部署規范、項 目管理規范。8. 2. 1工程實施工作流程工程正式啟動后，工程將嚴格按照工程實施計劃進行。首先進行工程的需求調研，開始收集工程的各種資料，并形成詳細的需求規格說明書；在工程需求調研的基礎

45、進行概要設計和詳細設計的編寫，并聘請專 家進行咨詢、論證，通過專家評審，經修改后局部內容形成正式文稿； 在概要設計和詳細設計的指導下，開始進行系統的開發實施，在此 過程中軟件測試和軟件初始數據的錄入工作；系統開發完成后，進行安裝調試、試運行，同時進行現有系統的集成和數據導入 工作，進入系統全線運行階段，完成整體測試、修改完善；bb36在系統全線運行后，進行工程總結，完成系統的總體驗收。在此過程中，系 統培訓貫穿始終，確保受訓人員能夠熟練的對系統進行安裝、調試、運行、維護、管理。在工程開發階段遵循需求分析、概要設計、詳細設計、編碼階段、測試階段 及安 裝調試施工。(1)需求分析需求分析要從用戶的

46、具體要求出發進行抽象匯總最終形成需求分析文檔，形 成的 具體的內容如下：系統的各個模塊的功能說明系統的性能要求系統的平安性要求系統的容錯要求系統接口要求系統使用范圍系統的客戶界面要求等需求分析階段需要用戶方技術人員協調用戶各相關單位配合需求調研工作，在需 求調研工作結束后，簽署用戶需求分析書。(2 )概要設計從用戶的需求出發，概要設計人員在確認用戶最終需求的情況下進行概要設計形 成系統概要設計，在概要設計的結束日期將概要設計交由詳細設計人員作為依照進行 詳細設計。在概要設計階段應該形成如下內容：系統整體構架系統開發工具及方法每一模塊的用戶需求的說明系統各模塊之間的接口系統每一模塊的工作流及數據

47、流定義37數據庫結構的定義數據庫表結構的定義(3 )詳細設計bb根據概要設計對每一功能模塊按照開發工具提供的功能進行實現的詳細設計，此局部的文檔應該實現如下內容：每一功能模塊的用戶需求的詳細說明每一功能模塊工作流的詳細實現的設計(對應需求)每一功能模塊數據流詳細設計及數據實現走向詳細設計(對應需求)各功能模塊子模塊的定義和詳細實現方式各功能模塊之間接口的數據流及工作流的詳細描述。各種界面原型的設計要求：在詳細設計階段所有的設計必須按照可以作為編碼依據的方式進行設計，作到越詳細越好。(4 )編碼階段在編碼階段程序員要按照詳細設計進行編碼工作，要求編程人員所寫的代碼一定 要完成詳細設計的所有的功能

48、；在代碼編制過程中，要求程序員嚴格執行編碼規范和格式要求。(5 )測試階段測試過程嚴格按照軟件質量體系軟件測試控制程序執行。測試方法除采用傳 統的測試方式外，還采用了先進的測試工具輔助測試。測試分為兩個階段：單元測試階段和綜合測試階段。單元測試階段在編碼階段完成，所有的測試文檔由測試人員提供。綜合測試由開發人員和測試人員交叉擔任，包括集成測試和系統測試，同時所有 的測試文檔應該由專業測試人員完成。(6)安裝調試及施工測試工作結束后，工程由系統開發階段進入實施階段。8. 2. 2工程進度安排38工程執行計劃：九個月。第一階段：調研和需求分析：第1個月1調研中山市農業信息化基礎設施建設運行現狀，掌

49、握土肥業務需求，編 制需求分析報告b b2在需求分析報告的基礎上，結合工程建設目標和要求，制定詳細的工程 實施方案。第二階段：技術方案設計：第2-3個月1平臺各系統各局部功能的需求分析與詳細設計2 建立平臺各應用系統 的數據列表和數據庫表結構3 軟硬件技術、數據庫系統的選型和開發環境的搭 建4 建立完善的開發環境，做好開發前準備工作第三階段：應用系統的建設及 網絡測試：第4-7個月1開發土肥信息管理服務平臺各應用系統2完成系統集成工作3應用系統的測試、調試工作第四階段：應用系統的完善、安裝使用與培訓：第8個月1安裝部署應用系統2應用系統使用培訓，進入試運行。3根據用戶反響的意見對系統進行完善，

50、形成穩定的產品第五階段：應用 系統試運行：第9個月1試運行期間系統進一步修改和完善2整理文檔，撰寫工程竣工報告，完成工程的驗收工作3 系統交接工程總體實施進度如以下圖所示：月度39 程中最好做到要和開發者比擬詳細的討論每個模塊的技術實現，以便使時間的估 算更 加準確。4、 對開發人員估算的時間進行確認。在確認過程中作為工程管理者應參考以 上提到的三個因素，同時將自己估算的時間和開發人員估算的時間進行比擬。這其中 的差異當然會存在的。對于那些差異比擬大的，將與技術人員探討其中的緣由。對于 時間周期比擬長的任務，盡量將任務通過再細分的手段細化任務，爭取每個任務的最 長時間不超過3天;時間周期越長的

51、任務，不確定性越高，風險也越高，越有可能成 為工程的瓶頸，影響工程的進度。2、CodeReviewCodeReview是保證工程中代碼質量非常重要的一個環節，在 這 一環中我們公司做的非常欠缺，把關不嚴格；這是導致每次測試后出現大量bug的主 要原因，這一環需要納入績效考核中，實行責任追究制，實施重點監控。出現這樣的 薄弱環節，造成這樣的原因，我想也是有很多因素造成的；比方開發人員對需求不是 很明確，以自己比擬主觀的因素去完成任務的；還有對整個系統業 務邏輯沒有正確的 清晰的認識的原因，以及對工程組成員培訓不到位的原因等眾 多因素糾集在一起才產 生的。如何做好這方面的工作?首先編碼要有“編碼規

52、范”文檔,CodeReview要有“代 碼審核規范”文檔:記錄代碼實現應該遵循的標準。通過這兩個文檔來規范開發人員 的代碼實現，代碼編寫者必須要嚴格按照規范來進行；代碼審核者根據這些 標準來 CodeReview代碼，同時在CodeReview過程中不斷完善該文檔。在做好這些前期工作的前提下，分以下幾個步驟來實施：檢查開發者的代碼實現是否遵循了編碼規范。從代碼的易維護性、可擴展性角度考察代碼的質量，提出修改建議。代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UseCase依次講解自己負責的代碼和相關邏輯，從Web層-至ij Manage層再到Dao層；代碼審核者在此過程中可以隨時提出自己的疑

53、問，同時積極發現隱藏的bug;對這些bug記錄在案。時間（天）任務名稱需求調研收集資料制定開發技術方案XXXX101212 序號 123 b b456789101112系統功能概要設計系統功能詳細設計數據庫設計系統開發應用系統測試、調試安裝部署系統應用及培訓試運行、修改與完善準備驗收材料 與驗收圖L總體實施進度計劃圖2. 8. 3人員培訓為了保證系統建成以后良好的運行，制定完善的培訓計劃。2.8. 3. 1培訓內容對開發的應用系統軟件的使用和數據維護進行培訓，使業務人員能夠熟練使用系統，進行數據的管理維護和業務分析，實現決策、共享和信息發布等操作任 務，使軟件系統發揮應有的作用。2. 8. 3

54、. 2培訓方式培訓使用建設中跟隨培訓和建設后集中培訓兩個方式。建設中培訓：中山市農科推廣中心在建設階段積極參與各系統的建設，參與系統設計、系統實施，隨時熟悉系統設備和軟件的使用方法和內容；建設后培訓：系統建設完成后，對中山市農科推廣中心管理人員進行集中的系統使用和維護培訓，使業務管理人員從整體和局部上掌握系統的使用。提供完40整的用戶手冊，作為培訓的材料。bb8. 4工程驗收8. 4. 1工程驗收本工程由經信局組織專家進行會議評審驗收，驗收前需對平臺各系統的功能進行測試，并進行72小時穩定性測試。驗收后由經信局出具中山市土肥信息管理服務平臺建設工程的驗收報告。8. 4. 2工程交付項說明工程任

55、務完成后，投標方根據合同應提交給招標方的貨物、服務以及交接文 件、用戶手冊等，并附上相應的交付時間計劃表。投標方交給中山市農業科技推廣中心的中山市土肥信息管理服務平臺的代 碼，必 須是系統應用系統所有模塊不加密的、明文的、標準的源代碼。8. 4. 3工程付款本工程以總價承包方式采購，采用分期付款方式。1、合同簽訂后，投標人提交工程實施方案并通過采購單位審核之日起個工作日內，采購單位啟動支付流程向乙方支付合同總額的20%；102、系統完成設計、開發、測試、安裝部署，采購單位簽字同意進入試運行之日起10個工作日內，采購單位啟動支付流程向投標人支付合同總價的3、工程實施完成并通過經信局組織的專家終驗

56、之日起購單位啟動支付流程向投標人支付合同總價的40%o30%o10個工作日內，采4、投標人按照采購單位要求完成質保工作，工程質保期結束之日起工作日，采購單位啟動支付流程向投標人支付合同總價的10個4110%o8. 5售后服務針對本工程的售后及技術支持服務，派得偉業公司承諾如下：北京派得偉業科技開展設置專門人員，為本工程售后及技術支持提bb供優質、高效的服務；質量保證期：系統驗收后12個月。質保期內，投標人所有服務不得收取任何費用；投標人有責任解決所提供產品或服務及其附件、安裝介質的任何故障。投標人必須在8小時內對業主所提出的維護要求做出實質性反響，并提供應 急響 應策略。系統運行過程中如果出現

57、技術故障（如硬件故障、軟件故障、配置喪失等），在此期間按緊急預案處置，確保系統最大限度地不中斷運行。投標人應保證8小 時內解決此類問題，以恢復故障使得系統得以正常運行。質保期外，投標人為建設方提供有償技術支持和服務，考慮系統維護服務等工作 量情況，適當向建設方收取一定費用。如果有幸中標，我們將在建設、實施以及今后的運行維護中安排專門人員，針對本系統的特點結合我們在不同工程中的維護經驗，制訂高效完整的維護 方 案，提供高質量和全方位的支持和服務。我們的主要服務措施有：在北京派得偉業科技開展建立專門的技術服務小組；在客戶許可的情況下，維護人員將通過 、郵件或者即時通訊工具，提供實時 在線指導維護,

58、排除系統故障;設立專門的客戶協調經理，負責聆聽客戶的需求，定期對客戶進行現場訪問，加 強與客戶的溝通交流，調查系統運行情況，為客戶提供有預見性的建議與計劃，傳達 公司產品開展狀況等信息。設立專門的技術支持經理，在工程實施結束后，設立專門的技術支持經理，負責 各項售后服務工作；針對應用軟件本身出現的問題，積極組織人力查找原因，及時給出解決方案，并 在版本升級后徹底防止此類問題的發生;42對于非北京派得偉業科技開展應用軟件的問題，而是由于其他因素 影響 用戶的正常使用，北京派得偉業科技開展將會積極配合用戶查找問題原因。8. 5. 1常規支持服務從試運行期結束后算起，系統開始正式運行，北京派得偉業科

59、技開展有限公bb司承諾向用戶提供一年免費的標準支持服務，在免費服務期內，為用戶提供免費 的現場技術支持服務，免費的現場軟件安裝調試、保修和升級，維護人員的免費現場 培訓和技術指導等，針對軟件應用中出現的問題在1小時內提供應急相 應方案，假設軟 件系統出現無法遠程指導解決的故障，派得偉業公司技術人員上門服務，根據實際情 況最遲在48小時以內修復。同時: 北京派得偉業科技開展承諾本系統的知 識產權歸用戶方所有。在免費技術支持服務期內，除提供正常的工作時間熱線 支持外，還提供8*24 小時的值班手機支持服務，對于用戶關于軟件應用以及相關內容的咨詢和問題提供解答和解決方案。免費技術支持服務期結束后，北

60、京派得偉業科技開展將繼續提供優質的 支持服務，定期對系統進行維護查詢，對用戶提出的維護請求，通過 指導，E-maiK即時通訊工具和 等方式及時響應和處理用戶反響的問題和系統 運行的故障。對用戶需要的系統軟件和應用軟件的現場維護，包括現場的安裝調具體的收試和重裝，應用軟件升級服務，派得偉業公司將收取一定的本錢費用， 費由雙方協議后決定。5. 2故障等級與響應時間（1）故障等級定義緊急故障：系統已無法使用，導致用戶業務活動中止；系統頻繁出錯，頻繁產生完全錯誤的處理結果。嚴重故障：系統仍在維持狀態運行，但性能下降；系統能夠維持運行，但有多個功能無法工作，或某一功能不正常已嚴重影響系統 的運行。中等故