軟件開發(fā)項目管理制度兩份

軟件開發(fā)項目管理啟動階段這個階段的工作目的是決定一個項目是否需要啟動。為了達到這個目的，首先要明確項目的總體戰(zhàn)略目標，對項目的需要建立認同。即確定到底需要做什么、開發(fā)什么產(chǎn)品或提供什么服務，以及需要解決什么樣的問題和需要滿足客戶或市場的什么要求等，同時還要總結項目工作的范圍、所需資源、大約開支、各種風險，以及該項目不執(zhí)行的其他替代選擇等。這些代表了對整個項目目標從戰(zhàn)略角度和宏觀層次所進行的分析，通過項目的意向書總結出來，由此確證客戶或項目發(fā)起人和贊助者的要求與期望，并幫助他們判定項目是否上馬。項目意向總結書的通過及項目被批準上馬形成了這個項目的起始點。計劃階段這個階段的工作是為整個項目做計劃。項目開始后，首先要確定項目的具體范圍，明確定出項目到底要做什么，總結、歸納并定出產(chǎn)品的功能。然后進一步制定項目的計劃，列出每項具體工作，并建立所有工作任務的重要性及順序；確定每項工作的執(zhí)行人和所需資源；根據(jù)人員的配置和能力設定各項工作和整個項目的完成時間表。執(zhí)行階段這個階段的工作是通過執(zhí)行項目的計劃來完成項目的任務。它包括落實一切所需資源，如：人員、設備、費用、技術、信息，由管理者領導全體項目參與者開展各項工作。同時跟蹤各項具體工作和整個項目的進度，定期向全體項目人員及項目的發(fā)起人報告項目狀態(tài)?？刂齐A段這個階段的工作是確證項目工作的結果符合項目的計劃。它通過對項目結果的衡量和審核，與項目計劃所期望的結果進行比較，找出實際結果與計劃的差別，并制定處理措施。這個階段的工作還包括對項目進程中出現(xiàn)的任何更改要求進行審核和批準。同時調(diào)解項目進程中出現(xiàn)的各種問題，如：對缺乏的資源的補償調(diào)節(jié)；對項目的進度表及各項具體工作的優(yōu)先級或順序的修訂。結束階段這個階段的工作是確保項目的最終結果或提交物達到計劃的要求，并對完成的結果作可接受的確認。還包括在項目完成之后的收尾工作，對整個項目的經(jīng)歷進行總結，修訂項目文檔，用戶培訓等。項目管理實施方案

作為一個項目管理者，如何要成功的做好項目管理；首先必須先要明白的是在特定的領域中賦予這個角色所要實現(xiàn)的目標、承擔的職責、以及項目管理者的具體工作內(nèi)容是什么？第一：目標

作為一個項目的管理者，必須要明確的知道自己的工作目標；我個人認為項目管理者的目標無非就是以下兩點：

1、就是清晰明確地了解項目利害關系者的需求和期望，努力做到滿足項目利害關系者的不同需求；項目利害關系者包括：項目團隊成員和項目團隊外成員(比如各部門的部門負責人和市場人員，客戶等)。

2、就是保證開發(fā)項目按需按時保質的完成。

第二：職責

作為項目的管理者，首先要端正態(tài)度，要明確知道自己的工作職責，認識到這份工作職責的本質。項目管理者不是來管人的，而是來支持人的，是來協(xié)調(diào)資源的，是來營造一個適合團隊成員比較認同的工作環(huán)境和氛圍的，是來為一個共同的目標和大家一起戰(zhàn)斗共同成長的?？梢源蟾鸥爬ǔ梢韵聨c：

1、建立有效的工作流程保證項目的順利進行。

2、制定詳細周密的項目計劃。

3、跟蹤，推動項目按計劃進行。

4、積極解決項目過程中出現(xiàn)的問題和沖突。

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

6、項目風險識別、風險評估、風險解決和風險管理策略以及做好突發(fā)風險的應急預案。

7、實現(xiàn)目標

第三：項目管理者的具體工作內(nèi)容

最后一個是項目管理者的具體工作內(nèi)容，作為項目管理者必須清晰的知道自己的工作范圍和所要做的工作內(nèi)容以及工作重心，分為以下六點：

1、項目前期階段

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

person(對產(chǎn)品有決定權的人)。項目啟動會議，相關的利害關系人員都必須參加。

該階段完成后的成果：確認后的最終軟件需求規(guī)格說明書文檔。

2、分析設計階段

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

Case、Demo系統(tǒng)原型、Test

Case等)；評審會議。

該階段完成后的成果：

A、User

Case(系統(tǒng)用例)；

B、DEMO(系統(tǒng)原型)；

C、系統(tǒng)設計文檔(概要設計和詳細設計)；

D、數(shù)據(jù)庫設計文檔。

最后對完成的成果，包括User

Case和設計文檔等進行評審。

3、執(zhí)行階段(開發(fā)和測試)

準備開發(fā)環(huán)境、測試環(huán)境；跟蹤，推動項目按計劃進行；以周報的形式通報項目的進展情況。對項目的階段成果進行評估，以確保該階段完成的質量，包括代碼審核、SQL審核等。對需求變更進行控制管理；對項目風險進行管理；測試階段BUG

FIXED及改進、收集反饋意見。

4、發(fā)布階段

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

5、上線后監(jiān)控

數(shù)據(jù)監(jiān)控(日志、服務器狀態(tài))，根據(jù)監(jiān)控出現(xiàn)的問題，及時進行BUG

FIXED及改進或做補丁升級。

6、結束階段

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

第四：基于以上三個問題所做的應對細則

要做好項目管理，并能確實解決好以上三個問題，實現(xiàn)目標、履行職責、完成工作中的具體內(nèi)容，從我個人這幾年的工作經(jīng)驗和面臨的一些問題，還有所積累的一些項目管理中的一些知識以及自己的觀察和思考的角度看，應該要努力做好以下這幾個方面的具體工作：

項目開發(fā)時間的估算

制定項目進度時間表的時候，需要估算每個任務所需的時間，其中開發(fā)任務中模塊的分配和時間估算是其中最主要的部分；在分配模塊和估算開發(fā)時間時需要遵循的原則和目標：

1、保證項目整體的進度。

2、有助于確保開發(fā)編碼的質量。3、有助于提高開發(fā)編碼的速度。

在公司現(xiàn)有的技術框架下，開發(fā)人員主要的工作是投入在具體的商業(yè)邏輯上。通常每個模塊所需的開發(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ā)的速度和質量：

A、相同類似的模塊由同一人負責開發(fā)，比如用戶管理的增刪改由同一開發(fā)者負責。這樣做的好處就是開發(fā)者對相關邏輯會更加熟悉，同時接口的定義也會比較明確，溝通的成本比較低，同時功能實現(xiàn)的缺陷也相應的會降低。

B、技術難度比較大的模塊由技術水平比較高的人負責。

C、業(yè)務邏輯比較復雜的由對這塊邏輯比較了解的人負責。

3、模塊分配完后，開發(fā)人員評估自己負責開發(fā)的模塊所需要的時間。在此過程中最好做到要和開發(fā)者比較詳細的討論每個模塊的技術實現(xiàn)，以便使時間的估算更加準確。

4、對開發(fā)人員估算的時間進行確認。在確認過程中作為項目管理者應參考以上提到的三個因素，同時將自己估算的時間和開發(fā)人員估算的時間進行比較。這其中的差異當然會存在的。對于那些差異比較大的，將與技術人員探討其中的緣由。對于時間周期比較長的任務，盡量將任務通過再細分的手段細化任務，爭取每個任務的最長時間不超過3天；時間周期越長的任務，不確定性越高，風險也越高，越有可能成為項目的瓶頸，影響項目的進度。

2、Code

Review

Code

Review是保證項目中代碼質量非常重要的一個環(huán)節(jié)，在這一環(huán)中我們公司做的非常欠缺，把關不嚴格；這是導致每次測試后出現(xiàn)大量bug的主要原因，這一環(huán)需要納入績效考核中，實行責任追究制，實施重點監(jiān)控。出現(xiàn)這樣的薄弱環(huán)節(jié)，造成這樣的原因，我想也是有很多因素造成的；比如開發(fā)人員對需求不是很明確，以自己比較主觀的因素去完成任務的；還有對整個系統(tǒng)業(yè)務邏輯沒有正確的清晰的認識的原因，以及對項目組成員培訓不到位的原因等眾多因素糾集在一起才產(chǎn)生的。如何做好這方面的工作？首先編碼要有“編碼規(guī)范”文檔，Code

Review要有“代碼審費用，質量等計劃。項目管理者作為項目的負責人，對項目的成功與否負有主要的責任。所以需求變更的決策者應該由項目管理者承擔。

4、需求變更確認后由專人將需求變更記錄下來，通知給項目中所有成員。其中以下人員對需求的變更是緊密相關的，他們必須知曉并認可此需求變更。包括（客戶方，需求分析人員，測試人員，相關開發(fā)人員）。需求變更記錄格式如下：

序號

變更提出時間

變更描述

變更類型(是對原有需求的修改還是新增需求)

原因

變更提出者

開發(fā)人員

對進度的影響(工作量)

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

6、相關人員接收到確認的需求變更后，做以下事情。需求分析人員修改需求說明書和User

Case的相關內(nèi)容。測試人員修改測試用例的相關內(nèi)容。開發(fā)人員修改代碼中的相關部分。

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

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

4、風險管理

風險管理是項目管理者最重要的工作之一。風險管理是一個持續(xù)的過程，貫穿于整個項目過程中，風險管理包括風險識別、風險評估、風險解決以及風險管理策略。

在項目的實施過程中需要不斷地識別和應對風險，并加以有效的控制，風險管理的好與壞直接影響項目的實施效果，從某種意義上講，項目實施對于項目管理者就是識別、分析、應對、控制風險的過程，使項目的約束性目標和質量目標朝有利的方向發(fā)展。

項目不同于日常任務，它有明確的起止時間和目標，要在明確的范圍、時間和成本約束下，達到相應的質量標準，并取得用戶的滿意。影響項目成敗的因素涉及方方面面，并且風險伴隨著項目的始終，是客觀存在的，作為一個項目管理者，應該具備良好的風險控制意識，善于識別風險并分析風險的影響，從中發(fā)現(xiàn)影響目標的風險點，并施加影響或采取應對措施，把風險的負面影響降到最低，并且風險控制應該貫穿項目始終。

風險引起的負面后果集中體現(xiàn)在進度延后、成本超支、質量不達標等方面，導致這些問題的因素主要包括目標以及需求不明確、范圍蔓延以及需求變更、代碼質量或返工風險、人員技能和資源的不足、缺乏良好的團隊協(xié)作等。下面將詳細描述一下這些問題以及出現(xiàn)這些問題時的應對方案：

1、目標以及需求不明確

為了市場競爭或內(nèi)部管理決策的需要，業(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ù)分析結果判斷是否批準，如果批準，那項目組可以安排實施，否則，正式拒絕用戶的請求，當然實際情況下可以采取一些軟措施緩解矛盾。

需求變更風險：需求已經(jīng)打上了基線，但此后仍然有變更發(fā)生，對項目造成影響。如何減少此類風險的發(fā)生？

前期的需求討論要詳細、充分。需求文檔中需求的范圍要明確、功能描述要清楚。找出項目中需求的決策者(通常會是產(chǎn)品經(jīng)理、相關職能主管、客戶)，所有的需求要經(jīng)過他們的認可?？蛻粼陧椖窟^程中的全程參與有助于降低此類風險。需求討論、需求確認、User

Case確認、測試階段的客戶驗收等環(huán)節(jié)，都要要求客戶參與。在發(fā)生需求變更時，嚴格按照需求變更流程執(zhí)行。在分析設計階段的中的確認和評審也是降低此類風險的重要手段。

3、代碼質量或返工風險

質量風險主要指開發(fā)代碼的質量。如何提高開發(fā)人員開發(fā)的質量？在制定項目計劃時，對開發(fā)時間的評估要盡可能的合適。合理的開發(fā)時間對開發(fā)質量的影響也很大。有時開發(fā)人員為了趕進度在比較緊張的時間需要完成指定的任務，可能就存在很大的開發(fā)質量問題。開發(fā)要有一套嚴格可行的代碼規(guī)范，編碼時嚴格遵守，到現(xiàn)在為止，我們這個方面做的不是很規(guī)范，做的也很不足，大家編寫的代碼隨意性比較大，代碼編寫者的主觀意識性比較強。要建立一套大家認可并且規(guī)范可行的編碼規(guī)范和考核規(guī)范，code

review時嚴格考核。在編碼前，開發(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天。項目管理者應該在前期就分析清楚項目所要采用的技術以及相應的人員技能要求，針對不同的角色，及時采取相應的技能培訓，以保證項目的順利實施。如果對于項目中某些部分專業(yè)性特別強或新技術，短期內(nèi)又不能快速建立技能的情況，可以考慮將該塊任務外包，借鑒合作商的力量降低實施風險，當然要進行外購人力成本與自建人力成本的效益分析。開發(fā)過程中遇到技術難題，導致開發(fā)時間延遲或者需求不得不發(fā)生變更。如何減少此類風險的發(fā)生？在項目開始前的技術評估階段，明確技術難點，提前安排人員進行攻克。如果在可預期的時間內(nèi)無法解決，如果可以，將向需求提出方要求變更需求或尋找可替代方案。這樣的風險應該在項目的前期階段就應該解決在萌芽狀態(tài)來避免這樣的風險在后期或中期出現(xiàn)。

項目所需人力資源無法按時到位，導致資源風險。如何減少此類風險的發(fā)生？這個就需要在項目計劃制定的時候提前申請確認資源，并在項目過程中不斷溝通協(xié)調(diào)。

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

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

項目風險管理的要點：

1、

上述我們所說的風險管理都是指可以預期將要發(fā)生的風險，那些不可預期將要發(fā)生的風險不屬于風險管理的范疇。這也將是考驗一個項目管理者的經(jīng)驗和知識對能否管理好風險至關重要的內(nèi)容。

2、

對不可預期的風險，項目管理者要有潛在的風險意識評估，做好一些可操作性的預案準備。

3、

詳細明確的項目計劃、以及項目執(zhí)行過程中每個要點的質量保證是降低項目風險的必要條件。

4、

風險報告是項目團隊以及領導了解項目風險的一個有效手段。

風險報告的格式：

序號

風險簡介

對項目的影響

解決方案或對策

5、團隊管理

團隊就是一組個體為實現(xiàn)共同的目標而相互依賴、一起工作的共同體。團隊工作顧名思義就是團隊成員為實現(xiàn)這個共同的目標而付出共同努力，項目團隊工作是否有效直接關系到項目的成敗。

團隊管理是個漸進的過程。世界上只有完美的團隊，沒有完美的個人。好的高效的團隊不是管理出來的，而是營造出來的。團隊成員需要有大家可認同的團隊文化，這需要大家共同的努力。

1、營造良好的工作環(huán)境和氛圍。

2、建設優(yōu)秀或鮮明的團隊文化。

3、保持高效的溝通。

6、項目會議

組織會議是項目管理者日常工作中一項非常重要的工作任務，項目過程中很多重要的決定都是在會議中做出的，也有很多由于不成功的會議而對項目本身造成了不好的影響。

首先看看不成功的會議常常表現(xiàn)為哪些形式：

1、會議氛圍不好，參與者發(fā)言不踴躍；2、會議討論常常偏離主題；3、會議沒有取得預期的結果；

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

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

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

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

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

組織會議的十一條最佳實踐：

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

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

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

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

5、會議的開場很重要。會議組織者要在開始前做好幾件事情。通常我建議有幾點要在開場時說：

A、再一次強調(diào)會議的目標，我們來做什么。

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

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

話，等別人說完你再說等等。

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

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

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

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

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

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

7、版本控制

版本控制也是項目管理者的一個重要工作內(nèi)容之一，一個項目或產(chǎn)品的完成不可能是一步到位的，在項目完成的后期可能會有多個不同的版本的發(fā)布（開發(fā)版本，測試版本，發(fā)布版本等）。需要做好版本的管理和控制。

8、項目總結

在項目完成后，總結整個完成項目的過程和經(jīng)歷，為下一次的項目啟動提供參考經(jīng)驗，完善不足，避免在類似的項目中出現(xiàn)可能存在的相同的錯誤發(fā)生。軟件開發(fā)項目管理制度總則為保障公司軟件開發(fā)項目的工作能有效、有序的執(zhí)行，保證項目的開發(fā)質量，維護公司及開發(fā)人員的利益特制訂本制度。組織軟件開發(fā)項目的實施以軟件開發(fā)項目組的形式進行，項目組中設有項目責任人（即項目經(jīng)理）、項目開發(fā)工程師、測試工程師、輔助人員等。一般情況下，一個項目組負責一個軟件項目的開發(fā)工作。對于特大型的項目可以組織多個項目組分塊進行實施。項目組人員各負其責，在項目經(jīng)理的統(tǒng)一領導組織下共同完成項目實施工作。軟件開發(fā)部軟件開發(fā)部項目組項目組項目組項目組項目組項目組開發(fā)工程師項目經(jīng)理測試工程師輔助人員開發(fā)工程師項目經(jīng)理測試工程師輔助人員測試工程師開發(fā)工程師項目經(jīng)理輔助人員測試工程師開發(fā)工程師項目經(jīng)理輔助人員責任項目經(jīng)理： 全面負責項目的開發(fā)組織工作，包括需求分析、系統(tǒng)設計、人員分工、進度安排等。項目經(jīng)理負責組織完成項目系統(tǒng)分析報告、系統(tǒng)總體設計報告、開發(fā)進度計劃表、系統(tǒng)測試大綱等技術文檔編寫工作。負責開發(fā)進行中的進度檢查，聯(lián)合調(diào)試、技術資料文件收集等工作。開發(fā)工程師： 按照項目經(jīng)理的分工安排完成軟件開發(fā)項目中自己所承擔的開發(fā)工作。負責完成模塊設計報告的編寫工作。協(xié)助完成軟件的安裝調(diào)試及售后服務工作。測試工程師： 按照項目經(jīng)理的分工安排完成對開發(fā)軟件的測試工作。負責完成測試方案設計、測試報告的編寫工作。負責完成軟件使用手冊、培訓教材等的編寫工作。完成軟件的安裝調(diào)試及售后服務工作。輔助人員： 按照項目經(jīng)理的分工安排完成項目開發(fā)中的輔助工作，包括文檔錄入、資料整理等。流程軟件開發(fā)項目應按照以下流程進行立項立項軟件組裝、測試完成測試報告軟件組裝、測試完成測試報告建立軟件開發(fā)項目組BB調(diào)研用戶需求調(diào)研用戶需求編寫項目系統(tǒng)分析報告編寫軟件用戶手冊編寫軟件用戶手冊討論確定系統(tǒng)設計方案討論確定系統(tǒng)設計方案編寫項目系統(tǒng)設計報告C安裝、試運行、培訓C安裝、試運行、培訓制定開發(fā)計劃確定人員分工進度安排制定開發(fā)計劃確定人員分工進度安排驗收、售后服務驗收、售后服務AAD工作總結分工進行模塊設計D工作總結分工進行模塊設計編寫模塊設計報告結束軟件編程、調(diào)試結束軟件編程、調(diào)試整個軟件開發(fā)項目可分為四個階段：A段： 設計階段。完成系統(tǒng)分析、總體設計、進度計劃等工作。以提交系統(tǒng)分析報告、系統(tǒng)設計報告及開發(fā)計劃進度表為完成標志。B段： 編程階段。完成系統(tǒng)子模塊設計、程序編寫、組裝測試等工作。以提交系統(tǒng)子模塊設計報告、測試報告為完成標志。C段： 安裝階段。完成系統(tǒng)安裝、用戶培訓、手冊編寫等工作。以提交用戶手冊培訓教材、安裝計劃、培訓計劃為完成標志。D段： 驗收階段。完成系統(tǒng)的最后修改、進行工作總結。以提交項目驗收報告、開發(fā)技