軟件項(xiàng)目管理的論文

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