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

2、 2、就是保證開發項目按需按時保質的完成。 其次:職責 作為項目的管理者,首先要端正態度,要明確知道自己的工作職責,熟悉到這份工作職責的本質。項目管理者不是來管人的,而是來支持人的,是來協調資源的,是來營造一個適合團隊成員比較認同的工作環境和氛圍的,是來為一個共同的目標和大家一起戰斗共同成長的。可以也許概括成以下幾點: 1、建立有效的工作流程保證項目的順當進行。 2、制定具體周密的項目方案。 3、跟蹤,推動項目按方案進行。 4、樂觀解決項目過程中消失的問題和沖突。 5、調動開發團隊的樂觀性,制造力,推動團隊成員在項目過程中不斷成長。 6、項目風險識別、風險評估、風險解決和風險管理策略以及做好突

3、發風險的應急預案。 7、實現目標 第三:項目管理者的詳細工作內容 最終一個是項目管理者的詳細工作內容,作為項目管理者必需清楚的知道自己的工作范圍和所要做的工作內容以及工作重心,分為以下六點: 1、項目前期階段 對項目進行技術可行性分析、技術評估、成本評估以及風險評估。與需求提出方的代表進行需求爭論,明確項目的目標、價值;確定項目范圍、功能及優先級。組建項目團隊,特殊要搞清晰項目的key person(對產品有打算權的人。項目啟動會議,相關的 利害關系人員都必需參與。 該階段完成后的成果:確認后的最終軟件需求規格說明書文檔。 2、分析設計階段 依據確認后的軟件需求規格說明書,制定項目進度方案,工

4、作任務分解(WBS;資源申請,項目涉及到的開發資源、測試資源、設計資源(包括人員和軟硬件資源;數據庫設計;系統設計;文檔(包括Use Case、Demo系統原型、Test Case等;評審會議。 該階段完成后的成果: A、User Case(系統用例; B、DEMO(系統原型; C、系統設計文檔(概要設計和具體設計; D、數據庫設計文檔。 最終對完成的成果,包括User Case和設計文檔等進行評審。 3、執行階段(開發和測試 預備開發環境、測試環境;跟蹤,推動項目按方案進行;以周報的形式通報項目的進展狀況。對項目的階段成果進行評估,以確保該階段完成的質量,包括代碼審核、SQL 審核等。對需求

5、變更進行掌握管理;對項目風險進行管理;測試階段BUG FIXED及改進、收集反饋看法。 4、發布階段 包括制定項目發布方案,用戶培訓,發布上線。 5、上線后監控 數據監控(日志、服務器狀態,依據監控消失的問題,準時進行BUG FIXED及改進或做補丁升級。 6、結束階段 產品交付,項目會。 第四:基于以上三個問題所做的應對細則 要做好項目管理,并能的確解決好以上三個問題,實現目標、履行職責、完成工作中的詳細內容,從我個人這幾年的工作閱歷和面臨的一些問題,還有所積累的一些項目管理中的 一些學問以及自己的觀看和思索的角度看,應當要努力做好以下這幾個方面的詳細工作: 1、項目開發時間的估算 制定項目

6、進度時間表的時候,需要估算每個任務所需的時間,其中開發任務中模塊的安排和時間估算是其中最主要的部分;在安排模塊和估算開發時間時需要遵循的原則和目標: 1、保證項目整體的進度。 2、有助于確保開發編碼的質量。 3、有助于提高開發編碼的速度。 在公司現有的技術框架下,開發人員主要的工作是投入在詳細的商業規律上。通常每個模塊所需的開發時間取決于以下三個因素: 1、所負責模塊的商業規律的簡單程度。 2、開發人員的技術水平和對項目所在應用的熟識程度(包括對框架和應用的熟識程度。 3、該模塊技術實現上是否有技術難點;這里所謂的技術難點定義是:在現有系統中還未實現的、開發人員自身也未沒接觸過的技術。對于這樣

7、的難點,開發者沒有相關的代碼可以參考,自己也沒有閱歷,所以需要投入一些時間討論解決。 模塊安排和開發時間估算的步驟: 1、在劃分好模塊后,首先自己先估算一下每個模塊所需要的開發時間。 2、然后召集全部開發人員,爭論模塊的安排和開發時間估算。將劃分好的模塊,讓開發人員從中選擇他們感愛好的模塊。這樣做可以提高開發人員的主動性和參加性。在安排模塊的時候還需從以下幾方面考慮,以確保開發的速度和質量: A、相同類似的模塊由同一人負責開發,比如用戶管理的增刪改由同一開發者負責。 這樣做的好處就是開發者對相關規律會更加熟識,同時接口的定義也會比較明確,溝通的成本比較低,同時功能實現的缺陷也相應的會降低。 B

8、、技術難度比較大的模塊由技術水平比較高的人負責。 C、業務規律比較簡單的由對這塊規律比較了解的人負責。 3、模塊安排完后,開發人員評估自己負責開發的模塊所需要的時間。在此過程中最好做到要和開發者比較具體的爭論每個模塊的技術實現,以便使時間的估算更加精確 。 4、對開發人員估算的時間進行確認。在確認過程中作為項目管理者應參考以上提到的三個因素,同時將自己估算的時間和開發人員估算的時間進行比較。這其中的差異當然會存在的。對于那些差異比較大的,將與技術人員探討其中的緣由。對于時間周期比較長的任務,盡量將任務通過再細分的手段細化任務,爭取每個任務的最長時間不超過3天;時間周期越長的任務,不確定性越高,

9、風險也越高,越有可能成為項目的瓶頸,影響項目的進度。 2、Code Review Code Review是保證項目中代碼質量特別重要的一個環節,在這一環中我們公司做的特別欠缺,把關不嚴格;這是導致每次測試后消失大量bug的主要緣由,這一環需要納入績效考核中,實行責任追究制,實施重點監控。消失這樣的薄弱環節,造成這樣的緣由,我想也是有許多因素造成的;比如開發人員對需求不是很明確,以自己比較主觀的因素去完成任務的;還有對整個系統業務規律沒有正確的清楚的熟悉的緣由,以及對項目組成員培訓不到位的緣由等眾多因素糾集在一起才產生的。 如何做好這方面的工作?首先編碼要有“編碼規范”文檔,Code Revie

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

11、時樂觀發覺隱蔽的bug;對這 些bug記錄在案。 5、代碼講解完畢后,代碼審核者給自己支配幾個小時再對代碼審核一遍。代碼需要一 行一行靜下心來看。同時代碼又要全面的看,以確保代碼整體上設計優良。 6、代碼審核者依據審核的結果編寫“代碼審核報告”,“審核報告”中記錄發覺的問題 及修改建議,然后把“審核報告”發送給相關人員。 7、代碼編寫者依據“代碼審核報告”給出的修改看法,修改好代碼,有不清晰的地方 可樂觀向代碼審核者提出。 8、代碼編寫者bug fixed完畢之后給出反饋。 9、代碼審核者把Code Review中發覺的有價值的問題更新到代碼審核規范的文檔中, 對于特殊值得提示的問題可群發em

12、ail給全部技術人員。假如通過以上步驟,還由于是代碼編寫者的緣由而消失嚴峻的缺陷問題,將通過績效考核來加深代碼編寫者的印象,并在周報會議上做通報批判。 3、需求變更管理 需求變更管理也是項目管理中最重要的一個環節,對需求變更管理的有效性將直接影響項目的勝利與否。 對待需求變更的態度: 1、需求變更是不行避開的。 2、需求變更要必需被管理。 3、樂觀發覺引起變更的因素,促使變更盡可能早的消失,減低變更帶來的風險。 需求變更管理的目標: 1、相關的干系人必需清晰地了解發生的變更。 2、變更處于有效的管理中。 3、盡量降低變更帶來的風險。 通過制定需求變更的流程,確保項目中的需求變更有效地進行,實現

13、上述的目標。需求變更流程: 1、確定需求的基準線。將以User Case作為需求基準線,在User Case確認之后的任何需求轉變,都需要走需求變更流程,這一環節我們基本沒有,期間有時候使的工 作很混亂,也就是由于沒有一個規范的變更流程而造成的;假如建立了這么一個流程規范和機制,需求變更沒有走這個流程的將不被認可。 2、項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產品經理、市場人員、開發人員、測試人員等。 3、項目管理者評估該需求變更。針對接收到的需求變更的要求,召集相關人員爭論該需求變更的合理性、可行性,實施的代價以及對項目的影響。包括可能影響的項目范圍,進 度,

14、費用,質量等方案。項目管理者作為項目的負責人,對項目的勝利與否負有主要的責任。所以需求變更的決策者應當由項目管理者擔當。 4、需求變更確認后由專人將需求變更記錄下來,通知給項目中全部成員。其中以下人員對需求的變更是緊密相關的,他們必需知曉并認可此需求變更。包括(客戶方,需求分析人員,測試人員,相關開發人員。需求變更記錄格式如下: 序號變更提出時間變更描述變更類型(是 對原有需求 的修改還是 新增需求 緣由變更提出 者 開發人員對進度的 影響(工 作量 1 2 5、確定變更的負責人。擔當需求變更的詳細工作,比如基線掌握,對需求變更的記錄,并通知相關人員。 6、相關人員接收到確認的需求變更后,做以

15、下事情。需求分析人員修改需求說明書和User Case的相關內容。測試人員修改測試用例的相關內容。開發人員修改代碼中的相關部分。 7、根據變更后的方案實施項目,并進行檢查,跟蹤,對變更后的實施反饋和可能消失的問題準時溝通和處理。 8、需求凍結。項目越到后期,需求變更對項目的影響就越大,所以在肯定時候要進入需求凍結階段,不再接收新需求或需求的變更。 4、風險管理 風險管理是項目管理者最重要的工作之一。風險管理是一個持續的過程,貫穿于整個項目過程中,風險管理包括風險識別、風險評估、風險解決以及風險管理策略。 在項目的實施過程中需要不斷地識別和應對風險,并加以有效的掌握,風險管理的好與壞直接影響項目

16、的實施效果,從某種意義上講,項目實施對于項目管理者就是識別、分析、應對、掌握風險的過程,使項目的約束性目標和質量目標朝有利的方向進展。 項目不同于日常任務,它有明確的起止時間和目標,要在明確的范圍、時間和成本約束下,達到相應的質量標準,并取得用戶的滿足。影響項目成敗的因素涉及方方面面,并且風險伴隨著項目的始終,是客觀存在的,作為一個項目管理者,應當具備良好的風險掌握意識,擅長識別風險并分析風險的影響,從中發覺影響目標的風險點,并施 加影響或實行應對措施,把風險的負面影響降到最低,并且風險掌握應當貫穿項目始終。 風險引起的負面后果集中體現在進度延后、成本超支、質量不達標等方面,導致這些問題的因素

17、主要包括目標以及需求不明確、范圍擴散以及需求變更、代碼質量或返工風險、人員技能和資源的不足、缺乏良好的團隊協作等。下面將具體描述一下這些問題以及消失這些問題時的應對方案: 1、目標以及需求不明確 為了市場競爭或內部管理決策的需要,業務部門提出的需求往往要求的時間比較緊迫,需求的提出大多停留在幾張紙或口頭的傳達上,沒有形成正式的業務需求文檔,在沒有明確的需求范圍的狀況下,有時為了迎合業務部門的口味匆忙開工,過程中用戶不斷地提出新的想法,技術人員開頭疲于奔命和應付,很難保證項目的進度和質量,也難以取得業務部門的認可。所以,在項目的前期肯定要實行相應的手段或措施,與業務部門共同明確項目目標、需求范圍

18、,充分考慮現有的時間和資源約束,將需求排定優先級, 對于關鍵的需求優先實現， 其他幫助性的依據過程中的詳細狀況進行滾動式方案， 并取 得業務部門的書面確認。在此過程中要注意挖掘用戶的隱性需求，可以通過引導、系統 原型等手段讓用戶在前期充分暴露自己的想法和需求。 2、范圍擴散以及需求變更 在有了明確的目標和需求范圍的狀況下， 需求的變更還是不行避開的， 業務部門在 看到詳細系統的真實雛形之后，源源不斷地要求、新想法隨之產生，假如不對此加以控 制， 新的需求的加入通常會影響已實現的需求， 并且對項目進度和成本產生很大的影響。 項目管理者針對這種狀況肯定要實行嚴格的變更掌握流程， 不能礙于面子， 否

19、則最終的 結果往往是出力不討好。針對用戶提出的新需求，根據正式流程提出變更申請，組織相 關團隊成員進行分析及評估， 作為是否實施的依據， 變更掌握負責人依據分析結果推斷 是否批準，假如批準，那項目組可以支配實施，否則，正式拒絕用戶的懇求，當然實際 狀況下可以實行一些軟措施緩解沖突。 需求變更風險：需求已經打上了基線，但此后仍舊有變更 發生，對項目造成影響。 如何削減此類風險的發生？ 前期的需求爭論要具體、充分。需求文檔中需求的范圍要明確、功能描述要清晰。 找出項目中需求的決策者(通常會是產品經理、相關職能主管、客戶，全部的需求要經 過他們的認可。客戶在項目過程中的全程參加有助于降低此類風險。需

20、求爭論、需求確 認、User Case 確認、測試階段的客戶驗收等環節，都要要求客戶參加。在發生需求變 更時， 嚴格根據需求變更流程執行。 在分析設計階段的中的確認和評審也是降低此類風 險的重要手段。 3、代碼質量或返工風險 質量風險主要指開發代碼的質量。 如何提高開發人員開發的質量？在制定項目方案 時，對開發時間的評估要盡可能的合適。合理的開發時間對開發質量的影響也很大。有 時開發人員為了趕進度在比較緊急的時間需要完成指定的任務， 可能就存在很大的開發 質量問題。開發要有一套嚴格可行的代碼規范，編碼時嚴格遵守，到現在為止，我們這 個方面做的不是很規范，做的也很不足，大家編寫的代碼隨便性比較大

21、，代碼編寫者的 主觀意識性比較強。要建立一套大家認可并且規范可行的編碼規范和考核規范，code review 時嚴格考核。在編碼前，開發人員要對框架嫻熟把握；一份好的系統設計文檔對 指導開發特別重要。 返工是項目組最不情愿看到的，既鋪張人力、物力和財力，又影響團隊樂觀性。需 求不明確或范圍沒有有效掌握都可能造成返工， 另外造成返工的緣由是質量沒有達到用 戶要求。往往有這樣一種狀況，每個團隊成員根據項目方案報告進度都是 100%完成， 但一到最終系統交互測試或集成的時候就會發覺一大堆問題， 不得不花費很大精力回頭 排查、修改程序，造成這種狀況的主要緣由是過程中質量保證沒有做到位，把大部分問 題留

22、在了后面。 這就需要在項目實施過程中實行有效的措施來規避返工的風險， 通常的 做法有同行評審， 比如概要設計完成之后， 邀請其他項目組的技術專家進行技術評審以 發覺架構設計問題； 管理評審， 通過組織級的質量審計看產品以及實施過程是否滿意質 量要求；代碼走查，在編碼過程中加入至少一次的代碼走查，排查不符合規范或性能要 求的代碼，走查通常能夠發覺 50%-70%的錯誤；每日構建，這是一種特別有效的方法， 可以避開把各部分的集成問題拖到最終， 并且能夠準時發覺相應的錯誤， 日構建一般在 項目的中后期開頭，每天自動從版本服務器上獵取源代碼進行自動編譯和測試。 4、人員技能和資源的不足 項目實施過程中

23、由于人員技能欠缺造成的進 度延后和軟件質量問題并不少見， 一個 嫻熟的技術人員完成同樣一個任務需要 3 天，但一個生手可能就需要 7-10 天。項目管 理者應當在前期就分析清晰項目所要采納的技術以及相應的人員技能要求， 針對不同的 角色，準時實行相應的技能培訓，以保證項目的順當實施。假如對于項目中某些部分專 業性特殊強或新技術，短期內又不能快速建立技能的狀況，可以考慮將該塊任務外包， 借鑒合作商的力氣降低實施風險，當然要進行外購人力成本與自建人力成本的效益分 析。開發過程中遇到技術難題，導致開發時間延遲或者需求不得不發生變更。如何削減 此類風險的發生？在項目開頭前的技術評估階段， 明確技術難點

24、， 提前支配人員進行攻 克。假如在可預期的時間內無法解決，假如可以，將向需求提出方要求變更需求或查找 可替代方案。 這樣的風險應當在項目的前期階段就應當解決在萌芽狀態來避開這樣的風 險在后期或中期消失。 項目所需人力資源無法按時到位， 導致資源風險。 如何削減此類風險的發生？這個 就需要在項目方案制定的時候提前申請確認資源，并在項目過程中不斷溝通協調。 5、缺乏良好的團隊協作 軟件項目實施屬于學問型，要發揮團隊成員的制造力，不同于制造業計件生產，各 模塊最終要集成在一起形成一個有機的整體， 這就需要各小組之間的親密協作， 界定清 楚工作界面及接口關系， 并在實施過程中持續地溝通溝通和共享， 首

25、先團隊要融為一體， 產出的軟件才能融為一體。 這是一個團隊的軟實力， 團隊之間的協作好壞也將是個潛在 的風險問題，在項目啟動和團隊組建的時候就應當加以規避這樣的風險消失。 項目風險管理的要點： 1、上述我們所說的風險管理都是指可以預期將要發生的風險，那些不行預期將要發生 的風險不屬于風險管理的范疇。這也將是考驗一個項目管理者的閱歷和學問對能否 管理好風險至關重要的內容。 2、對不行預期的風險，項目管理者要有潛在的風險意識評估，做好一些可操作性的預 案預備。 3、具體明確的項目方案、以及項目執行過程中每個要點的質量保證是降低項目風險的 必要條件。 4、風險報告是項目團隊以及領導了解項目風險的一個

26、有效手段。 風險報告的格式： 序號 風險簡介 對項目的影響 解決方案或對策 5、團隊管理 團隊就是一組個體為實現共同的目標而相互依靠、一起工作的共同體。 團隊工作顧名思 義就是團隊成員為實現這個共同的目標而付出的共同努力， 項目團隊的工作是否有效直接關 系到 項目的成敗。 團隊管理是個漸進的過程。世界上只有完善的團隊，沒有完善的個人。好的高效的團隊 不是管理出來的，而是營造出來的。團隊成員需要有大家可認同的團隊文化，這需要大家共 同的努力。 1、營造良好的工作環境和氛圍。 2、建設優秀或鮮亮的團隊文化。 3、保持高效的溝通。 6、項目會議 組織會議是項目管理者日常工作中一項特別重要的工作任務，

27、 項目過程中許多重要的決 定都是在會議中做出的，也有許多由于不勝利的會議而對項目本身造成了不好的影響。 首先看看不勝利的會議經常表現為哪些形式： 1、會議氛圍不好，參加者發言不踴躍； 2、會議爭論經常偏離主題； 3、會議沒有取得預期的結果； 4、會議時間經常一拖再拖。 這些不勝利的會議最終的結果就是：既鋪張了大家的珍貴時間又沒有達到會議的目的， 許多人都對這樣的會議都有抵觸心情， 對此也是深惡痛絕。 以下是組織會議時應當留意的問 題，也可看作組織會議的最佳實踐。在列出最佳實踐之前有三點我們必需要清晰： 1、會議是否會取得勝利很大程度上取決于會議的組織者。只有組織得有力，會議才有 可能取得勝利，

28、這是會議勝利的充分條件。 2、會議的組織者和參加者的想法通常是不全都的，有時候甚至會大相徑庭。所以不要 盼望會議的參加者和你一樣，對會議有著如此的期盼，對大多數參加者而言，在會議中他只 是一個發表想法的人，他不用對會議的勝利擔當責任。 3、以下十一條最佳實踐是形式上的商定，詳細的實施可以依據實際狀況來做。 組織會議的十一條最佳實踐： 1、只有需要開會時才開會。有時候兩三個人單獨小范圍溝通會更加有效。 2、提前發出會議議程，以便會議參加者知道他們來做什么。 3、請對人很重要，不要把非必要的人召來開會，當然也不要漏掉那些關鍵人物。在確 保必要人物都在的狀況下一次會議參加者越少效果越好。 4、提前預

29、約參加者的時間，以確保他們能按時到場。 5、會議的開場很重要。會議組織者要在開頭前做好幾件事情。通常我建議有幾點要在 開場時說： A、再一次強調會議的目標，我們來做什么。 B、強調會議的主題與基調。比如：本次會議是一個需求確認會，而非需求爭論會， 主要是爭論做還是不做以及告知大家我們要做什么， 而不要把太多的精力放在爭論 如何做上面。 C、說明一下會議的規章。如要發言，請舉手；不要有小圈子爭論；不要打斷別人 的講 話，等別人說完你再說等等。 6、會議過程中時刻留意引導和掌握會議，以確保會議根據目 標進行。一次會議的氛圍 是否良好，爭論是否充分，好的引導至關重要。比如多提一些開放式的問題。 7、

30、會議記錄很重要，把一些結論和有價值的內容記錄下來，這些是本次會議的重要成 果之一。 8、會議要有結論。我們常在會議上聽到有人說：大家爭論了這么半天，結論呢？。 沒有結論的會議是沒有意義的。 9、會議后別忘發會議紀要，以及一些 Action，什么人什么時候做什么。 10、會議后的 action 執行狀況的反饋很重要。反饋是對會議參加者的敬重，同時也告知 了會議的效果。 否則會讓大家感覺到這是一個可無可無的會議， 大家以后參加的樂觀性 也會降低。許多會議往往都不留意這一點。 11、按時結束的會議會受到全部人的歡迎。 7、版本掌握 版本掌握也是項目管理者的一個重要工作內容之一， 一個項目或產品的完成

31、不行能是一 步到位的，在項目完成的后期可能會有多個不同的版本的發布（開發版本，測試版本，發布 版本等） 。需要做好版本的管理和掌握。 8、項目總結 在項目完成后，總結整個完成項目的過程和經受，為下一次的項目啟動供應參考閱歷， 完善不足，避開在類似的項目中消失可能存在的相同的錯誤發生。 第2篇：軟件開發實施方案 1 軟件開發實施方案 系統開發嚴格根據軟件工程的方法進行組織， 系統的開發過程按 照需求分析、系統分析與設計要求、系統編碼、系統測試幾個過程有 序推動。下表所示系統開發流程圖，采納原型及迭代方式開發，依據 用戶需求持續改進，直到最終用戶確認滿足。 1.1 開發流程總述 如下圖示流程定義了

32、我公司內部的軟件開發過程， 以指導和規范軟件項目中開發過程的定義和相應的實施。 該過程可劃分為一系列子過程，包括：軟件需求分析、設計、編 碼、測試、驗收、維護，每個子過程又由一系列任務和活動組成，如 設計過程又可分為結構設計和具體設計。 但是在實際開發項目中， 情 況仍舊會是千變萬化的， 因此我們也并不是一成不變的死板執行一個 僵化的工作流程， 我們的原則是在一個規范流程的指導和約束下， 根 據詳細工程項目的實際要求， 為每一個項目評估并制定真正能夠最好 的滿意該項目要求的開發流程。 開頭 軟件需求分析 Y N：改進 Y N：改進 Y N：改進 軟件需求規格說明書（初稿） 系統測試方案系統測試

33、案例 （初稿） 用戶手冊（概要） 追溯表一 軟件需求規格說明書 系統測試方案系統測試案例 個人評審記錄 評審報告 同行評審 通過 結構設計 評審通過 結構設計說明書（初稿） 集成測試方案集成測試案例 （初稿） 用戶手冊（初稿） 追溯表一 結構設計說明書 集成測試方案集成測試案例 個人評審記錄 評審報告 具體設計說明書（初稿） 單元測試方案單元測試案例 （初稿） 用戶手冊（修改稿） 追溯表一 具體設計說明書 單元測試方案單元測試案例 用戶手冊（修改稿） 個人評審記錄 評審報告 源代碼、源代碼文件清單 單元測試報告（經過審批） 軟件問題狀態登記表 軟件問題報告單 集成工作單 集成測試工作單 集成測

34、試報告（經過審批） 軟件問題狀態登記表 軟件問題報告單 集成的軟件系統 系統測試報告（經過審批） 軟件問題狀態登記表 軟件問題報告單 系統管理員使用說明書 ( 經過審批) 安裝手冊（經過審批） 用戶手冊（經過審批 軟件系統（系統測試通過） 驗收測試報告 軟件問題報告單 軟件問題狀態登記表 驗收報告 可交付產品 軟件需求規格說明書（升級版） 客戶需求登記表 客戶需求統計表 設計說明書（升級版） 軟件問題報告單 軟件問題狀態登記表 軟件維護實施方案 維護后的軟件系統 具體設計 評審通過 編碼 集成測試 系統測試 驗收 維護 結束 圖 1.1-1 軟件開發流程總圖 在應用系統軟件開發項目中， 我們仍

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

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

37、編寫 已填寫 （3）評審 評審軟件需求規格說明書 ，詳細評審過程見評審程序文件，對軟件需求的評審準則包括： 系統需求和系統設計的可追溯性； 與系統需求的全都性； 內部全都性； 可測試性； 軟件設計的可行性； 運作和維護的可行性。 對軟件需求中的問題， 與系統工程組或客戶一起確定和審查， 依據審查結果對軟件需求進行適當的修改， 必要時按基線變更掌握的要求對客戶需求進行相應的修改。 對軟件需求規格說明書進行同行評審。 審查、批準軟件需求規格說明書。 將軟件需求規格說明書置于配置管理之下。 （ 4）工作產品 軟件需求規格說明書 系統測試方案 系統測試案例 用戶手冊 追溯表 （ 5）職責 項目經理：負

38、責組建軟件需求分析組；確定是否需要對有關 人員進行培訓；負責軟件需求規格說明書的審查和批準。 軟件需求分析組：軟件需求分析的主要擔當者，負責完成本 過程元素要求產生的全部工作產品。 系統測試負責人：負責組織軟件系統測試組對軟件需求進行 分析，審查軟件需求的可測試性；參加軟件需求規格說明書 的審查和批準。 質量保證人員：參加工作產品的審查，統計缺陷，并對軟件 需求分析過程進行審計。 系統開發組：協作處理涉及客戶需求的軟件需求問題。 客戶：必要時參加軟件需求規格說明書的審查和批準。 1.3 結構設計 （1）概述 結構設計是指根據軟件需求規格說明書 ，設計軟件系統的體系結構，即模塊結構，定義每個模塊

39、的主要功能和模塊之間的聯系 （即接口），并確定軟件系統的數據體系結構。 本元素在整個過程中的位置如下圖所示： 軟件需求分析 結構設計 具體設計 圖示：軟件需求分析在軟件開發過程中的位置圖 （2）入口準則和出口準則 1）入口準則 要素 推斷準則 軟件需求規格說明書 經過審查 審查獲得批準 進入配置庫 2）出口準則 要素 結構設計說明書 集成測試方案 集成測試案例 用戶手冊（初稿） 推斷準則 經過審查 審查獲得批準 進入配置庫 已完善 追溯表一 （ 3）評審 對結構設計說明書和集成測試方案進行同行評審。 對結構設計中的問題，與軟件需求分析人員一起確定和審查， 并對結構設計進行適當的更改。 審查、批

40、準結構設計說明書，必要時，對其進行設計評審。 將結構設計說明書、集成測試方案 和集成測試案例 置于配置管理之下。 （ 4）工作產品 結構設計說明書 集成測試方案 集成測試案例 用戶手冊 追溯表 （ 5）職責 1）項目經理 負責選擇合適的設計人員，組建結構設計工作組；負責結構設 計說明書和集成測試方案的審查和批準。 2）結構設計人員 結構設計階段工作的主要擔當者， 負責完成本過程元素產生的所 有工作產品。 3）系統分析員 協作處理涉及軟件需求的問題。 4）系統開發負責人 負責組織系統工程組對結構設計進行分析， 審查結構設計的可測 試性；負責協調處理涉及軟件需求的問題；參加結構設計說明書 和集成測

41、試方案的審查和批準。 5）軟件測試負責人 負責組織軟件測試組對結構設計進行分析， 審查結構設計的可測 試性；參加結構設計說明書和集成測試方案的審查和批準。 1.4 具體設計 （1）概述 具體設計是依據 結構設計說明書進行模塊設計，將結構設計所獲得的模塊根據單元、程序、規程的挨次逐步細化。具體定義各個單元的數據結構、程序的實現算法以及程序、單元、模塊之間的接口等，作為以后編碼工作的依據。 本元素在整個過程中的位置如下圖所示： 結構設計 具體設計 編碼 圖示：具體設計在軟件開發過程中的位置 （2）入口準則和出口準則 1）入口準則 要素 推斷準則 經過審查 審查獲得批準 結構設計說明書 進入配置庫

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

43、當者。 負責完成本過程元素產生的所 有工作產品。 3）系統分析員 協作處理涉及軟件需求的問題。 4）系統開發負責人 負責組織系統工程組對具體設計進行分析， 審查具體設計的可測 試性；負責協調處理涉及軟件需求的問題；參加具體設計說明書 和單元測試方案的審查和批準。 5）軟件測試負責人 負責組織軟件測試組對具體設計進行分析， 審查具體設計的可測 試性；參加具體設計說明書和單元測試方案的審查和批準。 1.5 編碼 （1）概述 編碼階段主要完成的工作是依據具體設計說明書編寫程序源代 碼，包括必要的數據文件， 并進行單元測試，單元測試的內容包括模 塊內程序的規律、功能、參數傳遞、變量引用、出錯處理等方面

44、。 本元素在整個過程中的位置如下圖所示： 具體設計 編碼 集成測試 圖示：編碼階段在軟件開發過程中的位置 （2）入口準則和出口準則 1）入口準則 要素 推斷準則 具體設計說明書 經過審查 單元測試方案 獲得批準 進入配置庫 2）出口準則 要素 推斷準則 源代碼文件 源代碼文件獲得批準 源代碼文件清單 源代碼文件進入配置庫的源代碼區 單元測試報告 提交測試負責人 軟件問題報告單 提交問題管理渠道 （3）評審 對源代碼文件進行同行評審， 主要的方法為對比具體設計說明書對代碼進行查閱，也可依據編程者的閱歷或程序的難度、重要程度，選擇走查評審方式，但目的都是發覺程序存在的問題。 （ 4）工作產品 源代

45、碼文件 單元測試報告 軟件問題報告單 軟件問題狀態登記表 （ 5）職責 1）項目經理 建立編碼組、測試組或相應崗位，并進行必要的培訓；跟蹤進度 和問題解決狀態； 對提交的源代碼進行批準 （或指定負責人進行批準 工作）。 2）程序員 編寫程序代碼；測試程序代碼；修改程序代碼；提交工作產品， 批準后將其導入配置區的源碼庫。 3）單元測試人員 測試源代碼；提交測試報告和軟件問題報告單。 4）評審人員 對指定源代碼文件進行閱讀，發覺缺陷和問題，填寫評審報告。 1.6 模塊集成測試 （1）概述 集成測試階段主要完成的工作是集成和集成測試。 集成是參考結構設計說明書并依據具體說明書中規定的系統集成方案將不

46、同的經 測試的程序單元進行構造， 并逐步構造成一個完整的軟件產品的過程；集成測試則是在集成完成之后， 對各單元、模塊之間接口的正確性和集成后功能的正確性進行驗證。 對于大型軟件， 集成測試可以實行分步進行的方法， 可以先對各子系統進行集成測試，然后在子系統之間進行集成測試。 本元素在整個過程中的位置如下圖所示： 編碼 集成測試 系統測試 圖示：集成測試在軟件開發過程中的位置 （2）入口準則和出口準則 1）入口準則 要素 推斷準則 經過審查 獲得批準 進入配置庫 結構設計說明書 具體設計說明書 集成測試方案 源代碼文件 2）出口準則 要素 推斷準則 獲得批準 進入配置庫 提交集成測試負責人 已進

47、入軟件問題管理流程 集成的軟件系統 （完整的源代碼和目標代碼） 集成測試報告 軟件問題報告單 （3）審查階段 核查集成狀態和結果，并進行批準； 批準后，將目標程序和程序清單進入目標代碼庫。 （ 4）工作產品 集成后的系統目標代碼 （包括文件清單），及相應的源代碼 （包括文件清單） 集成測試報告 軟件問題報告單 軟件問題狀態登記表 集成工作單 集成測試工作單 （5）職責 項目經理：建立集成組、集成測試組或相應崗位，并進行必 要的培訓；跟蹤進度和問題解決狀態；對集成后的系統目標 碼進行批準（或指定負責人進行批準工作） 。 集成負責人員：負責集成過程的實施。 集成人員：負責環境構建，集成的過程操作，

48、并將集成后的 目標代碼提交批準。 程序員、設計人員：修改源碼或設計，解決集成過程中消失 的與源碼有關的問題。 測試人員：測試系統目標碼，將測試報告和軟件問題報告單 提交測試負責人。 1.7 系統測試 （1）概述 系統測試的主要任務是從系統需求的角度對系統運行的正確性和性能進行驗證。系統測試的依據為系統測試方案。 本元素在整個過程中的位置如下圖所示： 集成測試 系統測試 驗收 圖示：系統測試在軟件開發過程中的位置 （2）入口準則和出口準則 1）入口準則 要素 推斷準則 經過審查 系統需求 要素 推斷準則 獲得批準 進入配置庫 編寫完成 系統的目標代碼 系統測試方案 用戶手冊 2）出口準則 要素

49、推斷準則 獲得批準 系統測試報告 軟件問題報告單 （ 3）工作產品 系統測試報告 軟件問題報告單 軟件問題狀態登記表 （ 4）職責 項目經理：負責建立系統測試組或相關的崗位，并進行必要 的培訓；跟蹤進度和問題解決狀態；對最終的目標代碼進行 批準（或指定負責人進行批準工作） 。 程序員、設計人員：修改源碼或設計，解決集成過程中消失 的與源碼有關的問題。 測試人員：測試系統目標碼，將測試報告提交測試負責人， 將軟件問題報告單提交問題管理渠道。 1.8 驗收 （1）概述 驗收階段主要由驗收測試、驗收測試問題改正和驗收三部分組成： 驗收測試的主要目的是驗證所開發的系統在用戶的使用環境下 （或模擬的使用

50、環境下） 是否滿意系統需求， 從用戶的角度驗證整個 系統運行的正確性。 驗收測試問題改正是對驗收測試中發覺的差異性問題進行修改。 驗收則是在驗收測試的基礎上， 依據項目合同或項目任務書對項 目的完成狀況進行綜合評價。 本元素在整個過程中的位置如下圖所示： 系統測試 驗收 維護 圖示：驗收在軟件開發過程中的位置 驗收的三個組成部分視項目立項類型和客戶的要求選擇執行。 （2）入口準則和出口準則 1）入口準則 要素 推斷準則 驗收測試前完成評審。 驗收測試方案（有驗收測試要求 的項目） 測試（系統測試、集成測試、單 已完成 元測試） 2）出口準則 要素 推斷準則 已提交 已關閉 已提交 驗收測試報告

51、 驗收測試問題報告單 驗收報告 （3）工作產品 驗收測試報告 軟件問題報告單 軟件問題狀態登記表 驗收報告 可交付產品 （ 4）職責 驗收測試組：負責驗收測試的各項活動。 開發組人員：負責驗收測試中發覺問題的改正和測試幫助。 項目管理人員：負責指派驗收測試責任和完成測試規程；確 保測試質量和進程；確保組間協調。 驗收組：詳細進行驗收。 CCB：批準運行基線。 1.9 維護 （1）概述 維護期是指： 軟件產品 / 系統驗收后，進入軟件運行 / 系統維護階段，直至軟件產品下一個版本的發布或系統維護期終止； 本元素在整個軟件開發過程中的位置如下圖所示： 驗收 維護 圖示：維護在軟件開發過程中的位置

52、（2）入口準則和出口準則 1）入口準則 要素 推斷準則 軟件產品 / 系統 已驗收 2）出口準則 要素 推斷準則 軟件產品 已退役 合同商定的維護期限 已到期 合同商定的維護范圍 已超出，須另簽協議 （3）工作產品 軟件需求規格說明書 客戶需求登記表 客戶需求統計表 設計說明書 軟件問題報告單 軟件問題狀態登記表 軟件維護實施方案 維護后的軟件系統 （4）職責 維護負責人：制定軟件維護實施方案， 確認維護類型、需求范圍，安排維護任務，追蹤任務的完成狀況及其他項目管理工作。 軟件維護人員：負責進行軟件維護任務的執行。 QA人員：負責幫助維護負責人依據實際狀況剪裁標準流程。 第3篇：軟件項目實施方

53、案 b 2.8 項目實施 2.8.1 項目實施概況 依據項目建設要求，對中山農情統計分析系統進行整體規劃設計更新維護， 對系統運行的平安性、牢靠性、易用性以及穩健性進行全新設計， 并將全部的應 用系統進行部署實施和軟件使用培訓以及技術支持。項目組承諾項目自立完成， 不轉包外包。 2.8.1.1 項目實施管理原則 項目開發維護的實施中，嚴格根據 ISO9001 國際質量體系進行掌握，保證為用戶供應優質的產品、嚴密的工程實施、高效的服務支持。為此，要遵循下列工程實施管理原則和保證體系。 （1）有閱歷、成熟的技術隊伍是工程實施的前提條件 完成任何項目工程，必需擁有一支有閱歷的、勇于探究的、高水平的、

54、具有嚴謹工作作風的技術隊伍， 在工程實施的過程中發揮團隊協作精神和用戶親密協作的力量。 （2）管理層次分明、職責清楚是工程實施的基礎 建立層次分明的項目工程實施管理機構， 明晰各層的管理職責， 從組織管理的角度保證項目實施方案落到實處。 （3）確定過程掌握點，以過程質量保證整體工程質量 整體都是由局部和詳細的細節構成， 項目由一個個過程環節組成， 只有仔細對待每一個過程細節，才能保證項目工程整體的實施質量。 （4）用戶參加是項目工程勝利的保證 從項目開頭到項目的結束， 每個階段都強調用戶的參加。 開發商只有和用戶相結合才能使開發出的系統為用戶所用， 發揮出系統的最大效益， 而用戶的參加也是系統

55、順當進行的保證。 對本項目短時間、大范圍的配置安裝來說， 假如有用戶的高度參加，項目工程的實施將大大加快。 b b 2.8.1.2 項目組織結構 本項目是一項涉及面廣、影響大、平安運行要求高，集數據處理、信息發布、資源整合于一體的政府信息化項目。為了更好的執行該項目，將實行統一指揮、并行實施、相互支援的實施方法。 為了使該項目能順當實施， 便于項目的管理和協調， 使工作職責更加清楚明白，建立項目組織實施小組，建立由項目領導小組、項目管理辦公室、項目監理公司、顧問詢問組、項目經理、項目詳細實施小組組成的實施管理掌握組織體系。 項目實施組織詳細職責如下： （1）項目領導小組 負責項目實施過程中的重

56、大大事決策； 依據項目的進度、質量、技術、資源、風險等實行宏觀監控； 負責組建驗收小組，主持驗收工作； 協調參加項目各方的工作關系。 （2）項目管理辦公室 組織各方統一制定工程管理方案； 組織總體實施方案評審，組織測試驗收； 負責項目進度方案與成本掌握； 協調解決項目實施過程中消失的各種問題。 （3）顧問詢問組 1）人員組成 農業信息化相關領域的業務專家； 多年從事 IT 行業和展廳建設的信息技術專家。 2）主要職責 系統總體設計指導； 對各子系統深化設計進行審核并提出優化建議； 對各子系統進行技術協調； 幫助客戶對系統的設備配置予以確認； 對現場系統安裝、調試供應必要的技術支持服務； 工程文

57、檔審核。 b b （4）項目經理 1)人員組成 項目經理由具有豐富項目管理閱歷的高級工程師擔當。 2）主要職責 制定項目方案：牽頭制定項目方案。 項目執行：對總體方案設計及工程設計；配置確認；工程質量保證；系統設計、開發、測試、安裝及調試；系統培訓、驗收。 項目檢查：通過其下屬各工作組供應的工程進展匯報，將項目進展狀態與項目方案進度進行比較，發覺過程誤差，提出整改措施。 項目掌握：審核項目進展狀態，必要時調集各種備用資源，確保項目按方案進度實施。 項目協調：與客戶、各分系統建設部門進行協調，解決工程組織接口及技術接口問題；定期主持系統建設協調會，準時解決各系統間消失的相關問題。 項目匯報：定期

58、向項目選購單位匯報整個項目的進展狀況，匯報在系統建設過程中消失的重大問題，聽取指導和建議。 （5）總體方案組 1）人員組成 由從事過多名基層電子政務項目的系統架構師、系統分析員和需求分析工程 師組成。 2）主要職責 對項目經理負責； 進行系統的需求分析調研； 負責系統的總體設計； 策劃系統的模塊功能結構； 協作業主方進行系統驗收。 （6）軟件開發組 對業主需求分析進行全面細致的了解或確認，深化描述軟件的功能和性能， 劃分系統的軟件功能需求和硬件功能需求， 確定軟件同其它系統元素的接口細節， b b 并與客戶一起爭論打算系統驗收方案。 1）人員組成 高級程序員； 具有豐富產品開發閱歷的產品開發設

59、計人員。 2）主要職責 負責項目應用軟件的系統設計； 負責項目應用軟件的程序編碼； 負責項目應用軟件的運行調試； 協作業主方進行系統驗收。 （7）系統測試組 從使用者的角度完成系統操作步驟的設計， 在實施過程中監控測試系統是否達到最初制定的操作目標，并編寫業主操作手冊。檢驗系統開發質量，并進行功能測試。 當開頭試運行階段后，還要對項目的各個方面指標進行測試和評估。 （8）系統實施組 1）人員組成 由具有豐富閱歷的系統工程師和參與系統開發的軟件工程師組成。 2）主要職責 負責各個實施區域的實施方案的設計與建議； 組織系統安裝及調試； 負責系統配置修改，安裝技術支持； 2.8.1.3 項目團隊 依

60、據上述項目組織結構和職能分解， 北京派得偉業科技進展有限公司方案投 入高級顧問 1 人，項目經理 2 人、技術負責人 1 人、實施經理 1 人、系統設計組 4 人、軟件開發組 13 人、系統測試組 3 人、系統實施組 3 人。共計 28 人。形成 特地服務本項目的技術開發實施隊伍。 隨著開發層次的深化、開發量的增加， 北 京派得偉業科技進展有限公司投入的人力資源將隨之增加和不斷進行調整。 未經 招標人同意，項目總負責人及各分項目負責人在項目結束前不得變更。 b b 詳細人員組成安排狀況分別如下表所示： 表 1.項目實施人員一覽表 序號 本項目職責 姓名 職務 公司副總、農業生產 本項目詳細分工