軟件項(xiàng)目管理的論文
軟件項(xiàng)目開(kāi)發(fā)是一項(xiàng)系統(tǒng)而復(fù)雜的工作 它需要一個(gè)團(tuán)隊(duì)互相配合、分工協(xié)作。軟件項(xiàng)目管理系統(tǒng)可以規(guī)范一個(gè)軟件開(kāi)發(fā)團(tuán)隊(duì)的日常工作，下面是關(guān)于軟件項(xiàng)目管理論文，歡迎借鑒！
隨著信息技術(shù)的飛速發(fā)展，軟件產(chǎn)品的規(guī)模也越來(lái)越龐大,各軟件企業(yè)都在積極將軟件項(xiàng)目管理引入開(kāi)發(fā)活動(dòng)中，對(duì)開(kāi)發(fā)實(shí)行有效的管理。但國(guó)內(nèi)軟件企業(yè)對(duì)于軟件項(xiàng)目的認(rèn)知，在一定程度上盲目多于理性、理論多于實(shí)踐。鑒于上述問(wèn)題，本文分析了基于項(xiàng)目管理的軟件開(kāi)發(fā)過(guò)程需要注意的幾個(gè)問(wèn)題。
1需求開(kāi)發(fā)要注意的問(wèn)題
需求開(kāi)發(fā)作為軟件項(xiàng)目啟動(dòng)的初始工作有兩個(gè)目標(biāo):發(fā)現(xiàn)真正的需求并以適合于用戶(hù)和開(kāi)發(fā)人員的方式加以表述。
發(fā)現(xiàn)需求即需求獲取,“真正的需求”是指在實(shí)現(xiàn)時(shí)可以給用戶(hù)帶來(lái)預(yù)期價(jià)值的需求“;以適合于用戶(hù)和開(kāi)發(fā)人員的方式”即需求定義,主要是指對(duì)需求的最后描述必須讓用戶(hù)和開(kāi)發(fā)人員無(wú)歧義的理解。在需求開(kāi)發(fā)過(guò)程,軟件開(kāi)發(fā)人員要注意如下的兩個(gè)問(wèn)題:
1.1 不要忽視非功能需求
通常，需求分析人員更多的關(guān)注功能需求，而忽視非功能需求，從而導(dǎo)致 NV[2]( 即“下一版本”) 陷阱。陷入 NV 陷阱后，產(chǎn)品的質(zhì)量會(huì)大打折扣，甚至“拿不出手”。另外，不完整的需求也容易導(dǎo)致架構(gòu)的錯(cuò)誤設(shè)計(jì)，如:1.1.1 XX 查詢(xún)的響應(yīng)時(shí)間必須小于 1 秒;1.1.2 并發(fā)用戶(hù)的數(shù)量每小時(shí)超過(guò) 10000個(gè)用戶(hù)對(duì)于此類(lèi)性能方面的非功能需求，直接影響到架構(gòu)中持久層設(shè)計(jì)所采用的技術(shù)，而且這種架構(gòu)上的缺陷實(shí)際上很難在“下一版本”輕易的改變。為了防止陷入 NV 陷阱，非功能性需求從一開(kāi)始就要被提出來(lái)，和功能性需求一樣受到應(yīng)有的重視。如果這些非功能性需求是確實(shí)需要的，就應(yīng)該被寫(xiě)入需求規(guī)格書(shū)，并在產(chǎn)品開(kāi)發(fā)過(guò)程中接受實(shí)現(xiàn)狀況的檢查。
1.2 正確面對(duì)需求變更
在大多數(shù)軟件項(xiàng)目中最不穩(wěn)定的部分就是需求。在項(xiàng)目需求分析階段，必需全面的、應(yīng)盡可能細(xì)致地討論項(xiàng)目的應(yīng)用背景、功能要求、性能要求、操作界面要求、與其它軟件的接口要求，以及對(duì)項(xiàng)目進(jìn)行評(píng)估的各種評(píng)價(jià)標(biāo)準(zhǔn)。但由于各方面的原因用戶(hù)需求始終處在一個(gè)持續(xù)變化的狀態(tài)中，這是項(xiàng)目開(kāi)發(fā)人員必須的接收的事實(shí)。那么對(duì)于這樣的現(xiàn)狀，軟件開(kāi)發(fā)者該怎么辦呢? 其一是把需求變化控制在最小的范疇，在需求變化發(fā)生之前盡量減少需求變化; 其二是在設(shè)計(jì)軟件體系結(jié)構(gòu)時(shí)，不僅應(yīng)該想到如何滿(mǎn)足現(xiàn)在已經(jīng)提出的用戶(hù)需求,同時(shí)也應(yīng)適當(dāng)?shù)乜紤]到需求的變更，想辦法應(yīng)對(duì)需求變化，例如:采用面向?qū)ο蟮乃枷搿Ｊ澜缍际怯蓪?duì)象組成的，而對(duì)象都是持久的。面向?qū)ο蟮拈_(kāi)發(fā)方法的精髓就是從企業(yè)的不穩(wěn)定需求中分析出企業(yè)的穩(wěn)定對(duì)象，以企業(yè)對(duì)象為基礎(chǔ)來(lái)組織需求、構(gòu)架系統(tǒng)。這樣得出的系統(tǒng)就會(huì)比傳統(tǒng)的系統(tǒng)要穩(wěn)定得多，因?yàn)槠髽I(yè)的模式一旦變化，只需要將穩(wěn)定的企業(yè)對(duì)象重新組織就行了。這種開(kāi)發(fā)的方法就被稱(chēng)為 OOAD(Ob-ject Orient Analysis & Design 面向?qū)ο蟮?分析和設(shè)計(jì))。
2項(xiàng)目管理人員需要克服的障礙
項(xiàng)目管理是一項(xiàng)控制性的工作,項(xiàng)目管理者的工作重點(diǎn)就是控制和協(xié)調(diào)。項(xiàng)目管理者首先要確保每個(gè)成員完全理解任務(wù),要把任務(wù)的目標(biāo)解釋清楚，并強(qiáng)調(diào)他對(duì)最終期限及評(píng)估成果的期望。
在軟件的整個(gè)開(kāi)發(fā)過(guò)程中項(xiàng)目管理者需要有效的監(jiān)控工作進(jìn)展，并提供給每個(gè)成員必要的協(xié)助，以確保整個(gè)開(kāi)發(fā)團(tuán)隊(duì)朝著目標(biāo)前進(jìn)，并且在項(xiàng)目迭代開(kāi)發(fā)過(guò)程中的設(shè)定可觀測(cè)的里程碑。作為團(tuán)隊(duì)開(kāi)發(fā)的項(xiàng)目管理者,要讓整個(gè)開(kāi)發(fā)團(tuán)隊(duì)有效地運(yùn)轉(zhuǎn)，發(fā)揮團(tuán)隊(duì)每位成員的最大能量,必須要克服下列障礙：
2.1障礙一:不信任員工
最簡(jiǎn)單的例子是，在重量級(jí)(Heavyweight)方法[3](制定了大量的規(guī)則的 RUP 方法)中,基本假設(shè)是對(duì)人的不信任，但不信任就會(huì)產(chǎn)生很多的問(wèn)題，比如士氣不高，計(jì)劃趕不上變化，創(chuàng)新能力低下，跳槽率升高等等。輕量級(jí)( Lightweight) (像XP 這樣只制定少量的規(guī)則來(lái)規(guī)范行為的方法)方法的出發(fā)點(diǎn)是相互信任，做到這一點(diǎn)是很難的，但是一旦做到了，那么這個(gè)團(tuán)隊(duì)就能高效運(yùn)作。
2.2 障礙二:對(duì)任務(wù)的控制走向極端
很多項(xiàng)目管理者害怕失去對(duì)任務(wù)的控制。如果能夠保持溝通與協(xié)調(diào)的順暢，采用類(lèi)似“關(guān)鍵會(huì)議制度”等手段，強(qiáng)化信息流通的效率與效果，任務(wù)在完成的過(guò)程中，失控的可能性其實(shí)是很小的。同時(shí)，在安排任務(wù)的時(shí)候，項(xiàng)目管理者應(yīng)該盡可能地把問(wèn)題、目標(biāo)、資源等，向各成員交代清楚，也有助于避免任務(wù)失控。
2.3 障礙三: 管理意識(shí)薄弱
在軟件企業(yè)中，項(xiàng)目經(jīng)理大多是技術(shù)骨干。因此有些項(xiàng)目管理者憑著自己的技術(shù)實(shí)力寧可自己做得很辛苦，也不愿意把工作內(nèi)容交給團(tuán)隊(duì)成員。為什么呢? 他們認(rèn)為，教會(huì)部下怎么做，得花上好幾個(gè)小時(shí); 自己做的話(huà)，不到半小時(shí)就做好了，花那么多時(shí)間教他們，還不如自己做更快些。問(wèn)題是: 難道項(xiàng)目管理者就這樣一直把所有的事情都自己做嗎? 由于團(tuán)隊(duì)成員的經(jīng)驗(yàn)、技能等方面的差異，盡管項(xiàng)目管理者自己親自動(dòng)手可能做得比其他成員好，但是如果項(xiàng)目管理者能夠教會(huì)團(tuán)隊(duì)成員，就會(huì)發(fā)現(xiàn): 其他成員也可以做得一樣好，甚至更好。也許今天項(xiàng)目管理者要耽誤幾個(gè)小時(shí)來(lái)教其他成員干活，但以后他們會(huì)為項(xiàng)目管理者節(jié)省幾十、幾百個(gè)小時(shí)，讓項(xiàng)目管理者有時(shí)間對(duì)關(guān)鍵業(yè)務(wù)作更多的更深入的思考，以保證軟件開(kāi)發(fā)的成功。
3 軟件模塊的再認(rèn)識(shí)
每一個(gè)軟件模塊都具有三項(xiàng)職責(zé): 第一個(gè)職責(zé)是它運(yùn)行起來(lái)所完成的功能，這也是該模塊存在的原因; 第二個(gè)職責(zé)是它要應(yīng)對(duì)變化，幾乎所有的模塊在它的生命周期內(nèi)都要變化，開(kāi)發(fā)者應(yīng)保證這種改變盡可能的簡(jiǎn)單。一個(gè)難以改變的模塊是拙劣的，即使能夠工作，也需要對(duì)它進(jìn)行修正; 第三個(gè)職責(zé)是能和閱讀它的人很好的溝通，對(duì)該模塊不熟悉的開(kāi)發(fā)人員也能比較容易的閱讀并理解它。一個(gè)無(wú)法進(jìn)行溝通的模塊也是拙劣的，同樣也需要對(duì)它進(jìn)行修正。
當(dāng)開(kāi)發(fā)人員最初編寫(xiě)一個(gè)模塊時(shí)，代碼對(duì)于他們來(lái)說(shuō)看起來(lái)也許是清晰的。這是由于他們專(zhuān)注于代碼的編寫(xiě)，對(duì)代碼非常熟悉。
經(jīng)過(guò)一段時(shí)間后，開(kāi)發(fā)者回過(guò)頭來(lái)在去看那個(gè)模塊，就知道自己怎么會(huì)編寫(xiě)如此糟糕的代碼。為了防止這種情況的發(fā)生，開(kāi)發(fā)人員必須站在閱讀者的位置，對(duì)代碼進(jìn)行必要的重構(gòu)，這樣其他的閱讀者就能夠理解代碼，同時(shí)所有的代碼也需要團(tuán)隊(duì)中其他成員的評(píng)審。
4 重視經(jīng)驗(yàn)的總結(jié)
在軟件開(kāi)發(fā)的過(guò)程中，對(duì)每一問(wèn)題的解決不可能一開(kāi)始就有一個(gè)好的方法，在解決一系列類(lèi)似的問(wèn)題后，開(kāi)發(fā)人員再回過(guò)頭來(lái)重新審視和評(píng)價(jià)自己解決問(wèn)題的方法，在大多數(shù)情況下，開(kāi)發(fā)人員都可以對(duì)這些解決方法加以提煉，對(duì)具有共性的解決方法進(jìn)一步抽象，尋求更通用的解決方式，并將該設(shè)計(jì)經(jīng)驗(yàn)提交到團(tuán)隊(duì)資源庫(kù)組織成項(xiàng)目事件庫(kù)。項(xiàng)目盡管有其獨(dú)特性，但借鑒從同類(lèi)型的項(xiàng)目之間的經(jīng)驗(yàn)教訓(xùn)提煉出來(lái)的知識(shí)是很十分有價(jià)值的。
在項(xiàng)目的收尾階段，不僅是給項(xiàng)目的利益相關(guān)者一個(gè)正式交代，還有一個(gè)任務(wù)就是項(xiàng)目整個(gè)過(guò)程的經(jīng)驗(yàn)教訓(xùn)予以提煉形成企業(yè)的知識(shí)財(cái)富[4]。企業(yè)的知識(shí)往往是隱含、散落在員工群體中，因此需要將員工的隱性知識(shí)轉(zhuǎn)化成公司的顯性知識(shí)。
結(jié)束語(yǔ)
項(xiàng)目管理雖然沒(méi)有非常高深的理論，但要真正實(shí)施起來(lái)，也絕非易事。對(duì)于軟件開(kāi)發(fā)企業(yè)而言，這不是一個(gè)小的改變，而是一種變革，企業(yè)需要為此付出艱苦的努力，從而在實(shí)踐中鍛煉提高，解決各種各樣的問(wèn)題，使項(xiàng)目管理工作越做越好。
參考文獻(xiàn)：
[1]鄭人杰等.實(shí)用軟件工程[M].北京:清華大學(xué)出版社,1997.4.
[2]新產(chǎn)品開(kāi)發(fā)項(xiàng)目中的需求問(wèn)題[EB/OL].
[3]Roger S.Pressman;黃柏素,梅宏譯.軟件工程-實(shí)踐者的研究方法 [M]. 北京: 機(jī)械工業(yè)出版社,1999,10.
[4]丁榮貴等.軟件企業(yè)項(xiàng)目管的有效性研究[J].經(jīng)濟(jì)與管理研究,2005,4.
【軟件項(xiàng)目管理的論文】相關(guān)文章：
軟件項(xiàng)目合作開(kāi)發(fā)合同09-21
關(guān)于軟件項(xiàng)目的策劃書(shū)03-01
供電企業(yè)生產(chǎn)信息管理系統(tǒng)軟件的開(kāi)發(fā)相關(guān)問(wèn)題論文02-17
軟件工程論文開(kāi)題報(bào)告01-25
公司項(xiàng)目管理細(xì)則11-20
游戲軟件項(xiàng)目可行性分析報(bào)告04-29
項(xiàng)目管理公司管理制度05-07