軟件項目主要階段及各個階段主要工作

1、軟件項目主要分為哪些階段？各個階段主要做哪些工作？本人在兩個中小型軟件開發(fā)企業(yè)工作過幾年，也做過幾年的項目管理工作。走過一些彎路也得出一些項目管理方面的體會，在此進行總結， 希望能夠與其他一些項目管理人員或對項目管理有興趣的同事共同探討一些中小型項目管理的問題及方法。大部分中小型軟件開發(fā)企業(yè)的軟件項目經常遇到的一些問題可能包括：項目時間緊、 項目組成員經常加班； 項目需求變更頻繁；項目進行過程中可能就有項目團隊成員離職或調離到其他項目組； 項目重復性建設問題嚴重，每個項目都需要從框架開始重新開發(fā)，難以重用已有項目的成果等等。 我覺得通過較好的規(guī)劃和管理能夠在一定程度上提高項目的成功率或者說提高

2、項目的質量，降低開發(fā)成本，縮短項目開發(fā)時間。我理解項目管理有兩個大的劃分方法一是通用的項目管理體系，也就是PMP中所說的5個項目管理過程組 9個知識領域44個項目管理過程；二是具體業(yè)務領域的按項目生命期劃分的各階段的管理。本文主要從項目生命期各階段的管理方面進行總結。我個人分析一個軟件項目生命期大體需要經過的流程（這只是我個人的一個劃分，有可能不是很全面）：可行性分析、需求、設計、開發(fā)、測試、實施、維護、總結。下面我針對每個階段談一下自己的體會。一、可行性分析一般的項目都是通過外部招標的形式得到的。對于有些公司在應標的時候對項目就要有個取舍。如果在特殊時期為了生存可能只要不是太賠的項目都會盡量

3、承接。但是一般項目在承接前最好在經濟、技術等方面進行可行性分析，而且這種可行性分析最好是管理者、市場、技術等人員都參與，因為市場人員一般不懂（或不通）技術，技術不懂（或不通）市場，因此只有大家在一起共同分析討論才能夠得出比較可行的結果。可行性分析的結果一方面可以作為是否承接項目的依據，另一方面也可以作為承接項目方式或與客戶談判的依據。 比如經分析項目工作量很大，如果按標書金額開發(fā)有可能會賠，那么可以與用戶探討是否將來能有個二期的項目；另外如果用戶要求的時間比較緊，可是經分析很難按標書時間完成， 那么也可以和用戶同共探討是否可以在正式簽定合同時延長系統(tǒng)交付時間等。當然這些與用戶的探討工作一般是需

4、要公司高層領導出面協(xié)調的，有時單獨靠項目組是沒有能力達成理想的結果的。另外在此階段最好對項目的成本和需要的資源進行一下估算。二、需求需求實際要細分為需求調研、需求分析、需求確認、需求管理等。因為對于需求要想說清楚可能需要較長的篇幅，所以在此不進行展開。在此只是先強調一下需要相當重要，如果早期需求做的不夠仔細會給項目的后期工作帶來很多的隱患。而且我建議每個項目無論多大也無論項目時間要求多緊急一定要有一個比較詳細的需求文檔。在需求比較確定之后建議再對項目成本進行估算。同時對需要的資源及相關里程碑進行說明。三、設計對于大部分中小型項目因為時間和人力的問題加上需求變更比較頻繁，所以有時很難書寫一個比較

5、詳細的設計文檔。但是如果沒有設計文檔一是為后期維護可能會帶來一些問題，尤其是當原來開發(fā)人員或主力開發(fā)人員離職或調離到其他項目組時；另外沒有經過詳細設計 的項目可能也會存在一些風險。因此建議不必為了文檔而文檔，除了項目驗收的要求外，建議設計文檔根據項目特點有 選擇地包括以下一些內容的說明：系統(tǒng)網絡情況。系統(tǒng)安全策略及備份策略。系統(tǒng)相關軟硬件環(huán)境說明。與其他系統(tǒng)的關系。主要庫表及關鍵字段說明。系統(tǒng)中關鍵數據關聯關系說明。關鍵字段校驗規(guī)則。項目中技術的論證及名種技術的結合方法。系統(tǒng)關鍵技術說明。一些技術使用過程中的注意點。異常處理機制。 事物處理機制。日志記錄方法及原則?？蚣苤邢嚓P命名說明。共通功能

6、描述及調用方法。核心算法。系統(tǒng)性能解決方案。并發(fā)的考慮及處理。系統(tǒng)用戶及角色權限設計說明。系統(tǒng)的關鍵配置說明（如數據庫服務器，應用服務器等等，如有必要可另加附件進行說 明）。個人認為對于中小型項目如果不是用戶要求有時不必在設計文檔中對所有數據庫表及字段都進行說明，可以只說明比較重要的一些數據庫表及字段以及相關數據庫的關聯關系就可。因為在用數據庫建模軟件（如Powerdesig ner）進行數據庫設計的時候可以對每個表及每個字段加注釋進行說明，在使用開發(fā)工具（如：pl/sql ）進行開發(fā)的時候自然可以看到每個數據庫表或字段的說明。而且一般中小型項目在開發(fā)的過程中可能需要經常性地修改數據庫表的設計

7、，如果還有文檔描述數據庫的設計那么每次修改時除了修改數據庫之外還要維護設計 文檔的一致性，如果項目忙忘記了修改就會導致文檔和數據庫的不一致，有時這種不一致的文檔可能還不如沒有，因為它可能會誤導其他人員的理解。另外也可以通過開發(fā)過程的規(guī)范來減少設計文檔的內容。這個將在下面的開發(fā)環(huán)節(jié)進行 詳細的說明。四、開發(fā)整個項目有一個合理的框架是很重要的?？蚣芫唧w包括哪些內容在此很難解釋清楚，但是我想最起碼整個框架應該把項目所采用的各種技術（如java中的Hibernate、Struts、Spring的結合） 比較合理地組織起來，并為具體模塊的開發(fā)提供一些工具類等，同時整個框架應該具有較好的可擴展性、可維護性

8、和較好的性能?？蚣茏詈糜身椖拷M中技術最強的人（在此稱他為技術負責人）進行搭建及維護。另外對于整個項目有一個統(tǒng)一的命名規(guī)范（類和方法按什么方式命名，所有文檔都加上時 間作者等）并進行遵守是很必要的，這樣一個人開發(fā)的代碼其他人很容易就能夠讀懂。在整個項目進行全面開發(fā)前最好先向項目組全體成員講解需求及項目框架的機制、使用方式及注意事項，再說明相關規(guī)范。然后每一個開發(fā)人員按照理解開發(fā)一個簡單的功能。然后大家再一起 （或者由技術負責人）看一下每個人對于框架的使用是否合理，規(guī)范理解的是否有誤，編碼習慣是否需要改正等等。在討論并達成共識后再進行具體功能的開發(fā)。另在具體的開發(fā)過程中盡量在關鍵算法處加一些注釋進

9、行說明。建議定期進行一些代碼走查的工作。盡量由技術負責人負責這份工作，當然也可以進行互相檢查等。 代碼走查的好處很多，如可發(fā)現一些不好的編碼習慣；提高整個系統(tǒng)代碼的可讀性；發(fā)現一些 bug ；借鑒別人好的編碼思路或技術等。五、測試有些公司有獨立的測試或質量保證部門，有的公司只是由開發(fā)人員自己完成測試工作。在此假設公司有一個獨立的測試部門進行系統(tǒng)的測試工作。首先開發(fā)人員一定要養(yǎng)成單元測試的習慣。對自己開發(fā)模塊的功能進行單元測試過之后再提交測試組進行結合測試、系統(tǒng)測試甚至性能測試。單元測試很重要，在進行單元測試的時候如果條件允許可以使用junit等一些工具，或其他一些代碼覆蓋率工具幫助分析測試用例

10、的覆蓋程度。 另外在此再提一點， 一般項目可能是整體開發(fā)完之后才進行性能測試，可是這時測試出性能問題了卻因為臨近上線或試運行時期，不一定有充足的時間進行修改，另外也可能因為整個項目已經都使用了某種影響性能的技術或方法，要想改變要付出很大的代價。所以建議如果條件允許可以在開發(fā)的過程中（甚至搭建項目框架時）使用一些輕量級的開源性能測試工具由開發(fā)人員對可能影響性能的功能進行測試。對于測試部門的測試人員要盡早地參與到項目中來，建議在需求階段就介入。早介入的好處一是可以對需求理解的比較深入，知道原始需求是怎么來的，中間經過哪些變化，這樣會比在開發(fā)結束后一次性地講解能夠更好地把握需求，更好地書寫測試用例及

11、測試計劃。另外有些人也比較推薦在需求的時候就開始書寫測試計劃和測試用例，因為我之前項目的特點我沒有這樣試過。項目組設計人員一定要把一些關鍵測試點、數據及功能的關聯關系對測試人員說清楚。測試過程中有一個 bug管理系統(tǒng)并對bug進行跟蹤是很必要的，在此就不展開說明了。另外在補充一點，最好是在項目結束后能對產生的所有bug進行一下分類。然后通過分析得出一些規(guī)律。通過在以后項目中采取一些措施進行項目質量的提高。六、實施對于涉及多個子系統(tǒng)的長期開發(fā)項目，在系統(tǒng)設計和開發(fā)過程中要優(yōu)化處理關聯性強的系統(tǒng)，同時有一個（或幾個）系統(tǒng)成熟了就試運行或上線，不必等所有系統(tǒng)都好了再上線。一是因為時間長了開發(fā)人員可能

12、調離至其它崗位，維護代價會增大；二是子系統(tǒng)用戶可能會改變而導致需求變更；三是時間長了用戶對系統(tǒng)需求會有陌生感，也可能會產生新的需求；四是時間長會給打消用戶對使用系統(tǒng)的積極性；五是較早地讓用戶看到系統(tǒng)也可以減輕因雙方理解偏差而導致的系統(tǒng)需求變更的影響。七、維護爭取把用戶的提過的所有修改都進行記錄，并爭取所有修改都請用戶簽字（不一定提一個修改就簽字一次，可以統(tǒng)一記錄然后定期把一段時間內的修改進行簽字確認），如果做不到所有修改都簽字也盡量做到對于重大修改請用戶簽字。簽字的好處很多：讓用戶看到項目組所做的工作； 如果修改的內容比較多可以通過雙方高層領導的溝通再新進行系統(tǒng)二期或三期的開發(fā)；有了簽字有時用

13、戶對需求變更會相對少一些等等。另外對于所有修改除了簽字留檔外爭取定期把所有修改的內容再整理到需求文檔中，保持需求文檔與正式環(huán)境功能的一致性。這個工作很有必要， 可能帶來以下一些好處：方便測試人員在回歸測試時理解系統(tǒng)功能；如果維護人員的調離其他接手人員比較方便理解系統(tǒng)功能等。八、總結在此不對項目驗收進行單獨的說明。只是說一下項目結束（有些項目可能要持續(xù)進行維護，在此主要指系統(tǒng)已經上線并穩(wěn)定運行）后要進行的總結工作。建議每個項目結束后都召開一個項目總結會。項目總結會建議與項目相關的所有人都參加。由項目經理進行主要總結，但每個參與人員最好也都進行總結。可以從管理和技術兩大方面對項目中的每個階段的成功

14、與失敗進行總結，目的是總結經驗教訓，提高每個人的項目經驗，提高項目組的成熟度，使以后的項目更加成功。在此要強調一下，一般項目總結時大家都喜歡只說成功的， 而很少提到失敗的或所走的一些彎路，而往往對這些失敗的總結更能使大家收獲更多，當然這也要看組織的文化，我建議如果可能盡量鼓勵大家多總結一些失敗的經驗教訓。另外項目結束后如果有時間最好是把項目中的一些有重用價值的文檔放到公司的組織過 程資產庫中。如果項目的框架比較合理也可以剔除項目中的業(yè)務相關功能的代碼，整理出項目框架并 加以簡要說明文檔供本項目組其他項目或其他項目組使用。九、項目經理職責分析對于中小型規(guī)模的項目，項目經理可能既要充當管理人員的角色又要充當開發(fā)甚至實施 人員的角色，基本上軟件項目生命期的每個階段都要參與。但是我覺得以下一些工作（其實遠不只下面所列）項目經理一定要重視：項目整體需求的把握。項目框架的把握。項目團隊的建設。與其他職能部門的協(xié)調工作。項目例會。客戶關系維護。定期向項目相關人員匯報進度?？傊椖拷浝硪獙椖康某蓴∝撠?，要對項目成員的發(fā)展負責，要對客戶負責，還要對公司負責，所以項目經理一定要有責任心、要有全局觀。最