時間：2023-01-13 22:06:34
引言：易發表網憑借豐富的文秘實踐，為您精心挑選了九篇項目管理軟件論文范例。如需獲取更多原創內容，可隨時聯系我們的客服老師。
在此次會議上，邦永招募了全國30多個地區的總，宣布于今年11月正式啟動市場。雖然邦，全國公務員共同天地永的產品價位僅在540萬元之間，定位為中低端市場，但同行還是感到了壓力。邦永在加緊營銷渠道建設的同時，還醞釀著和很多行業主管部門的技術合作，似乎意在打造國內項目管理軟件的行業標準。
今年，中國政府撥了3000億元專款用于各類政策性項目的建設，各省、市地方政府至少有1000億元的專款項目，全國每年至少有2000個1億元以上的大項目。如果這些項目都用軟件來進行管理的話，這個市場無疑非常可觀。據統計，目前項目管理軟件高端市場的容量在1億元以上，35年內將達到6億元左右。中、低端用戶數量更為可觀。
事實上，SAP、ORACLE、PEOPLESOFT等國際上知名的管理軟件商在項目管理軟件市場上已經先行了一步。他們憑借著產品線長的優勢，在向國內客戶銷售ERP系統的同時，也把項目管理軟件帶進了中國。同時PRIMAVERA等軟件公司也在嘗試開拓國內項目管理軟件市場。據記者了解，目前還有美國和歐洲的幾家大型的項目管理軟件公司正在中國調查市場，估計不久將挺進中國。國內管理軟件廠商也開始覺醒，紛紛邁開了進軍項目管理軟件的步伐。上海華普加快了向中關村企業項目管理的進軍、北京華炎軟件推出HotPM企業項目管理軟件……
當人們對ERP不再狂熱時，龐大的管理軟件市場一下子被催熟了。目前，國內軟件巨頭用友在與瑞典IFS公司成立了北京用友艾福斯軟件系統有限公司后，也開始將其業務迅速擴張到項目管理軟件市場。國內其他軟件公司如邦永（中國）、北京夢龍、新中大等也緊隨其后。美國Primavera、OpenPlan、微軟等國際性公司也紛紛殺入這一市場。
“對手非常強大，這說明商機很大！”楊鐵鈴對記者說，“我們認為目前SAP、ORACLE等國外管理軟件商的主要精力還是在ERP市場，項目管理只是其產品線的一部分。目前國內還沒有一家具規模的同類型軟件企業，更談不上標準。”邦永對稱霸這個市場充滿信心。
阻礙猶存
提起項目管理軟件，楊鐵鈴侃侃而談：其實很早人們就開始實施項目管理，如金字塔、長城等偉大的工程之所以成功，都得益于當時對工程項目進行嚴密的管理。20世紀60年代初，在著名數學家華羅庚的倡導下，將項目管理的概念引入了我國，并在當時的國民經濟各個部門進行試點應用，將這種方法命名為“統籌法”。2000年底，聯想在“天麒”、“天麟”兩款計算機產品的開發過程中，結合業務對項目管理的需求，配合項目管理相關理論和方法編制軟件方案，使該項目僅8個月便全部完成，并達到了國際上PC生產技術的最高水平。“只是當時的企業全都將目光放在ERP上。”楊鐵鈴不無惋惜地說。
楊鐵鈴認為，“項目管理對大家來說，并不是一個新的概念，一直以來大家都在提它，其在各行各業的應用也比較多。但是一直沒有落到實處。”楊鐵鈴所說的沒落到實處是指目前阻礙國內項目管理軟件發展的兩個因素：
一方面，國內的信息化水平還很低，尤其是工程的管理者對信息化認識不足。目前，我國對項目建設的管理仍然缺乏明確的法規，項目管理者對監管存在抵觸情緒；而另一方面，國內高端管理軟件市場一直是眾多管理軟件供應商爭奪的焦點。當大多數軟件生產商為ERP的高額利潤所吸引時，在自身還沒有完成ERP改造情況下，就匆匆轉身投入了ERP軟件市場的爭奪，使得項目管理軟件成了一塊被荒廢的良田。
楊鐵鈴為記者舉了一個例子，去年國家統計局在對舊有的網絡架構進行改造時，花了50多萬引進了惠普的項目管理，而這還是基于美國1969年建立的PMI（國際項目管理協會）標準。“在國外，90%以上的項目建設都采用軟件進行管理，而在我國則還不到10%。如果以應用項目管理軟件可以節省35%的建設資金來算，這將是一筆驚人的數字，”楊鐵鈴說，“我國目前有2000萬家中小型企業，在企業項目建設上他們大多數都需要進行項目管理。”
標準之蠱
在微軟技術教育大會上，微軟（中國）總經理唐駿針對中國軟件業難以做大的困境指出，正是由于國內眾多軟件商對項目管理不夠重視，軟件開發沒有一個規范，無法控制項目的可操作性，導致成本增加，直接影響了整個軟件業做大。其實這不僅是軟件業本身存在的問題，眾多重大項目投資也存在同樣問題。然而中國目前的項目管理大多受制于領導意志，要做到很好的控制項目成本，做到與國際標準接軌，其難度不言而喻。
專攻項目管理的邦永曾對外宣稱，邦永的PM2系列軟件不僅是國外軟件的漢化版，而且融合了國際標準化項目管理精髓與本土國情的項目管理模式。從事過項目管理的人都知道，通常一個人對項目管理的把握有4個層次，第1個層次是“誤以為自己了解”；第2個層次是“知道自己不了解”；第3個層次是“知道自己了解”；第4個層次是“自己不知道自己了解”。國家統計局計算中心網絡運行管理部主任張富民在談到項目管理實施的體會時對記者說，他覺得當時自己還處在第3個層次。這就是說，目前的項目管理還是一種投資人在投資內的把握，是用工具化的手段幫助投資者把握項目中的每一個贏利和去掉不良成本。
關鍵字：軟件項目管理需求分析系統設計
1.項目前期以及項目準備
在進行任何一項較大的項目時,首先要進行項目的可行性分析和研究,因為這些項目中的問題并不都有明顯的解決辦法,這樣就很難在預定的時間、費用之內解決這些問題，如果這些問題沒有可以行得通的解決辦法，貿然開始這些項目，就可能導致項目的失敗，造成巨大的損失。
1.1可行性分析
軟件項目可行性研究的目的是用最小的代價和時間，確定該項目是否能夠開發值得開發，其實質是要進行一次簡化的、抽象的需求分析和設計過程，主要應從以下幾個方面進行分析。
1.1.1技術可行性
對要開發項目的功能，性能和限制條件進行分析，確定在現有的資源條件下技術風險有多大，項目是否能夠實現，現有的資源包括硬件、軟件資源，現有的技術人員和技術水平，已經有的工作基礎等，判斷技術上是否可行，主要需要考慮以下幾個問題:
(1)開發的風險即在給定條件下能否實現目標的功能和性能；
(2)資源的有效性；
(3)技術的發展性；
由于需求未經過詳細的調研，存在模糊性和可能的變化，開發人員進行技術可行性評估時，存在比較大的風險，一旦出現估計的錯誤，將可能導致災難性的后果。
1.1.2經濟可行性
進行軟件開發項目的成本估算以及了解取得的效益估算，確定該項目是否值得開發，對于大多數項目，衡量經濟可行性，應考慮一個“底線”，同時應考慮公司的長期經營策略，潛在市場前景等因素。
1.1.3社會可行性
應考慮項目是否存在任何侵權、責任等問題，考慮在現有的制度、法規下是否行得通，包括合同、責任、法律等多種因素。
1.2需求調研
在項目前期工作中，需求調研是其中最重要的一個環節，今后的許多工作都依賴于需求調研的結果，需求調研的過程是漸進的，在可行性分析階段，主要關注的是項目規模、范圍和重點的功能，在項目進入正是開發流程以后，我們需要更加全面、準確地了解系統的需求不重視需求過程的項目隊伍將自食其果，需求工程中的缺陷將給項目成功帶來極大風險。如:無足夠用戶參與導致產品無法被接受；用戶需求的增加帶來過度的耗費和降低產品的質量；模棱兩可的需求說明可能導致時間的浪費和返工；用戶增加一些不必要的特性和開發人員畫蛇添足；過分簡略的需求說明以致遺漏某些關鍵需求；忽略某類用戶的需求將導致眾多客戶的不滿；不完善的需求說明使得項目計劃和跟蹤無法準確進行。
1.3項目團隊的組織
建立項目團隊是項目開發過程的開始，一切工作都是由項目團隊的成員完成的在整個項目的運行過程中，需要很多不同的角色參與到項目中，完成不同階段的任務。所以在建立項目團隊的過程中要把握好人員角色的劃分、特別人員管理與激勵、監督等。整個人員的管理是項目管理的關鍵，因為人是活的，而項目是死的，只要人員管理妥當，項目開發一般是不會出什么問題的。
1.4項目開發計劃
軟件項目的特征之一就是需求的不確定性和開發過程中存在的技術風險，按照通常的方法，制定一個項目的計劃應該是先根據項目的需求，進行詳細的任務分解找出實現的方法，估計出項目的工作量，再根據項目資源的狀況，制定出項目的計劃。
但是，再現實的工作中，項目的時間表往往是事先確定的，給開發留出的時間也是事先定好的。而我們能夠利用的資源，主要是開發的人力資源，也被事先基本確定了，在被確定的這2個前提條件下，我們如何根據項目的需求，合理地安排人力和時間，完成項目的開發，這是現實中項目經理經常遇到的問題如果事先確定的時間表是相對比較合理的，至少應該是我們夠的到的。我們制定的開發計劃才是有意義的，否則，按照這個時間表制定出來的計劃只能失敗的在這種情況下，項目經理唯一可以做的是對用戶的需求進行剪裁，去掉某些耗時長而且不太重要的功能，或是在開發中適當降低質量要求，或許可以完成項目的進度。當然這必須最終要得到用戶的認可。778論文在線
2.項目開發過程管理
2.1詳細設計
在詳細設計階段，由于任務已經詳細地分解，總體地解決方案和技術框架已經確立，詳細設計地目的就主要是針對某個特定地模塊或對象，根據需求，技術框架地要求和模塊間接口，描述出我們實現功能的方法，主要內容包括：
（1）內部算法描述；
（2）內部數據組織；
（3）相關接口詳細設計；
2.2設計評審
在設計完成后，必須安排設計評審以保證設計的質量，通常設計評審以小組內部的評審會的方式進行，參與人有項目小組內部的人員及其負責人，由開發者介紹其設計思路，其他人了解并對其設計質量進行評審。評審的內容主要包括：
（1）關鍵算法的可行性；
（2）接口是否符合概要設計的要求；
（3）技術清晰度是否符合設計標準；
（4）文檔的完備性；
評審通過的設計，才能夠開始編碼工作，評審的結果應記錄到開發文檔當中。
2.3編碼
在編碼階段，主要需要在編碼工作結束后，進行代碼審核，這項工作非常重要主要應該由項目小組的技術負責人完成，審核的目的并不是為了檢驗代碼的正確性而是需要對編碼是否按照規范進行審核。主要內容包括：
（1）變量、包、方法等的命名是否符合規則；
（2）注釋是否填寫完整，是否符合規范；
（3）代碼的可讀性，編寫風格是否符合規范；
（4）是否有明顯的造成系統運行低效率的處理方法；
（5）公共變量的定義和使用；
2.4調試
編碼工作完成以后，通常需要開發人員自己進行單元測試，有些部分需要編寫相應的測試程序。應該避免發生這類的情況，有些開發人員任務自己不應該進行測試工作，在編寫完代碼以后，只要編譯成功，就直接提交成果，將測試工作完全交給測試人員去做，這樣做不僅僅給測試人員增加了許多的工作量，同時增加了許多因為交流產生的時間，造成進度的延遲，管理人員應該杜絕程序員的這樣的思想，同時在管理中予以考慮，可以將提交成果產生的bug數量作為考核程序員業績的標準之一。
3.項目后期管理
3.1項目的驗收
項目驗收，是整個項目生命周期中最后一個環節。一般來說，軟件項目的驗收一般來說有2個階段，第一個階段是驗收測試，當驗收測試成功結束后，一般會有一個階段的試運行階段，只有當2個階段全部結束后，整個項目才算真正結束，可以收回全部的工程款，該軟件也進入其運行維護期。驗收測試應按照軟件的需求，質量要求進行測試驗收，需要甲乙雙方共同建立驗收小組，或請第三方測試機構進行驗收測試，在驗收測試之前，開發方應提供一系列的開發設計文檔供驗收測試使用。
3.2軟件維護
編程大師曾說“哪怕程序只有三行長，總有一天你也不得不對它維護。”，很
多軟件產品不是一次性的買賣，比如在電信、金融等領域，有些軟件系統要用十幾年，對軟件進行維護是必不可少的，軟件公司的經理們沒有哪一個喜歡被維護的費用嚇一跳，但軟件維護的代價通常是高昂的。對軟件而言“維護”是個不太直觀的術語，因為軟件產品在重復使用時不會被磨損，并不需要進行像對車輛或電器那樣的維護，軟件維護是人們對既豐富多彩又會令人心酸的活動的統稱，其中豐富多彩的活動是指那些反映客觀世界變化，能使軟件系統更加完善的修改和擴充工作，令人心酸的活動是指那些永無休止，并且改了舊錯卻引起新錯讓人欲哭無淚的工作。
參考文獻：
1.邱菀華沈建明楊愛華等編著現代項目管理導論機械工業出版社
2002年10月
2.美理查德懷特黑德著領導軟件開發團隊電子工業出版社2002年5月
3.尼爾懷特著管理軟件開發項目-通向成功的最佳實踐電子工
業出版社2002年4月
4.劉積仁康曉東饒友玲主編軟件開發項目管理人民郵電出版社
2002年2月
5.美JosephRaynus著CMM軟件過程改進指南電子工業出版社
1.1人員的組織與管理
一項工程的具體工作涉及到人員的管理，工作任務的分配，責任內容的明確，因此人員的組織及管理是工程項目的關鍵因素，要把注意力集中在項目組人員的構成、優化。
1.2軟件質量管理
軟件質量管理在工程項目實施過程中決定著質量方針與責任的范疇，包括質量計劃設計制定，項目質量檢測保證和項目質量控制等程序。通過保證手段在質量過程中有效進行。
1.3軟件配置管理
英文簡稱SCM，是在開發者中，標識，控制和管理軟件變更的一種管理。配置管理的使用取決于項目規模和復雜性以及風險水平。軟件配置管理針對開發過程中人員、工具的配置、使用提出管理策略。記錄軟件項目產品的更新過程，從而保證研發者在軟件項目周期的各個階段能夠獲得準確的產品配置。對項目開展過程軟件開發進行有效調控和有效預測具有重要作用。
1.4編寫軟件項目計劃書
它是軟件項目管理組的首要任務，主要包括工作量、成本、開發時間的估計。并根據估計值制定和調整項目組的工作，詳細記錄了開發日程安排，資源供需，項目管理等各項情況。使從事該項目的人員了解該項目的大致情況。
1.5軟件風險管理
軟件工程風險管理是預測工作中可能出現的各種危害到軟件產品質量的潛在因素的問題，對風險產生的后果進行分析評估。計算機軟件風險預測的準確性評估與有效防范措施的應用都利于提高軟件工程的效益，降低風險帶來的經濟損失，有效保證相關利益業主的權益。這幾個方面都是相互貫穿、交織于整個軟件開發過程中的。
2軟件工程項目管理中存在的現實問題及解決方案
2.1人員工作安排不明確，應建立團隊合作意識
在工程項目開發過程中是需要每個崗位人員的相互協調及無障礙交流，沒有團隊協作意識是無法有效的利用時間和資源開展各項工作。因此我們要提高一個工程項目的工作效率，就要合理安排人員的工作分配，強化每個工作人員的團隊協作意識，有效避免管理團隊中存在的分工不明確，不合作的問題。只有相互協作和相互信任的情況下才能高效的完成一件優質的軟件工程項目。建立一套完善的人事考核制度，加強對員工的職位升降，工資獎金分配管理，有利于提高員工開發軟件工作的積極性。
2.2缺乏實踐性調研報告，應納入到軟件項目計劃書
軟件開發工程不僅要創新變革，也要考慮到它的實用性，以往出現的多個工程項目沒有對實際項目建設中的需求實體和實際進行要求，以及實際項目建設的數據進行合理有效的調研，導致出現設計完整的軟件產品運用與實際偏差較大，造成不必要的人員和資源浪費。因此要在軟件設計前給予項目調研工作高度重視，對實際軟件項目的需求及要求嚴格調查，應將軟件項目調研報告附于項目計劃書中，引起重視。
2.3風險管理意識不夠，應該強化提高人員對風險管理的認知
風險的發生很可能會造成不可估量的損失，但是風險的發生是具有可控性的，如果能有效控制就會避免發生風險事故。可往往在計算機軟件工程項目管理中的工作人員卻很少知道風險管理的重要性，于是在軟件開發中應提高項目主要負責人的風險管理理念，提高自身對風險管理預測能力的水平。只有了解了風險管理理論與風險管理體系，定期對項目實施中可能發生的風險進行有效排除，把控好風險管理前后的形勢。
2.4杜絕搞工作進度，應要完善管理體系，對工作進度嚴格把控
一般來說，軟件工程師總是非常樂觀。當他們在計劃軟件項目時，經常認為每件事情都會像計劃那樣運行，或者，又會走向另外一個極端。軟件開發的創造性本質意味著我們不能完全預測會發生的事情，因此制定一個詳細計劃的關鍵點很難確定。當有預想不到的事情引起項目脫離正常軌道時，以上兩種觀點都會導致軟件項目的失敗。
目前，風險管理被認為是IT軟件項目中減少失敗的一種重要手段。當不能很確定地預測將來事情的時候，可以采用結構化風險管理來發現計劃中的缺陷，并且采取行動來減少潛在問題發生的可能性和影響。風險管理意味著危機還沒有發生之前就對它進行處理。這就提高了項目成功的機會和減少了不可避免風險所產生的后果。
2什么是風險
所謂“風險”，歸納起來主要有兩種意見，主觀說認為，風險是損失的不確定性；客觀學認為，風險是給定情況下一定時期可能發生的各種結果間的差異。它的兩個基本特征是不確定性和損失。IT行業中的軟件項目開發是一項可能損失的活動，不管開發過程如何進行都有可能超出預算或時間延遲。項目開發的方式很少能保證開發工作一定成功，都要冒一定的風險，也就需要進行項目風險分析。在進行項目風險分析時，重要的是要量化不確定的程度和每個風險相當的損失程度，為實現這一點就必須要考慮以下問題：
要考慮未來，什么樣的風險會導致軟件項目失敗？
要考慮變化，在用戶需求、開發技術、目標、機制及其它與項目有關的因素的改變將會對按時交付和系統成功產生什么影響？
必須解決選擇問題，應采用什么方法和工具，應配備多少人力，在質量上強調到什么程度才滿足要求？
要考慮風險類型，是屬于項目風險、技術風險、商業風險、管理風險還是預算風險等？
這些潛在的問題可能會對軟件項目的計劃、成本、技術、產品的質量及團隊的士氣都有負面的影響。風險管理就是在這些潛在的問題對項目造成破壞之前識別、處理和排除。
3風險管理
項目風險管理實際上就是貫穿在項目開發過程中的一系列管理步驟，其中包括風險識別、風險估計、風險管理策略、風險解決和風險監控。它能讓風險管理者主動“攻擊”風險，進行有效的風險管理。
在項目管理中，建立風險管理策略和在項目的生命周期中不斷控制風險是非常重要的，風險管理包括四個相關階段：
風險識別識別風險的方法常用的有風險識別問詢法（座談法、專家法）、財務報表法、流程圖法、現場觀察法、相關部門配合法和環境分析法等。
風險評估對已識別的風險要進行估計和評價，風險估計的主要任務是確定風險發生的概率與后果，風險評價則是確定該風險的經濟意義及處理的費/效分析，常用的方法有：概率分布、外推法、多目標分析法等。
風險處理一般而言，風險處理有三種方法，①風險控制法，即主動采取措施避免風險，消滅風險，中和風險或采用緊急方案降低風險。②風險自留，當風險量不大時可以余留風險。③風險轉移。
風險監控包括對風險發生的監督和對風險管理的監督，前者是對已識別的風險源進行監視和控制，后者是在項目實施過程中監督人們認真執行風險管理的組織和技術措施。
在IT軟件項目管理中，應該任命一名風險管理者，該管理者的主要職責是在制訂與評估規劃時，從風險管理的角度對項目規劃或計劃進行審核并發表意見，不斷尋找可能出現的任何意外情況，試著指出各個風險的管理策略及常用的管理方法，以隨時處理出現的風險，風險管理者最好是由項目主管以外的人擔任。
險識別
風險識別就是企圖采用系統化的方法，識別某特定項目已知的和可預測的風險。常用方法是建立“風險條目檢查表”，利用一組提問來幫助項目風險管理者了解在項目和技術方面有些風險。在“風險條目檢查表”中，列出了所有可能的與每一個風險因素有關的提問，使得風險管理者集中來識別常見的、已知的和可預測的風險，如產品規模風險、依賴性風險、需求風險、管理風險及技術風險等。“風險條目檢查表”可以以不同的方式組織，通過判定分析或假設分析，給出這些提問確定的回答，就可以幫助管理或計劃人員估算風險的影響。軟件項目一般有如下五類風險：
4.1產品規模風險
有經驗的項目經理都知道：項目的風險是直接與產品的規模成正比的。與軟件規模相關的常見風險因素有：
估算產品的規模的方法（LOC或代碼行，FP或功能點，程序或文件的數目）。
產品規模估算的信任度
產品規模與以前產品規模平均值的偏差
產品的用戶數
復用的軟件有多少
產品的需求改變多少
4.2需求風險
很多項目在確定需求時都面臨著一些不確定性和混亂。當在項目早期容忍了這些不確定性，并且在項目進展過程當中得不到解決，這些問題就會對項目的成功造成很大威脅。如果不控制與需求相關的風險因素，那么就很有可能產生錯誤的產品或者拙劣地建造正確的產品。每一種情況都會導致使人不愉快。
與客戶相關的風險因素有：
對產品缺少清晰的認識
對產品需求缺少認同
在做需求中客戶參與不夠
沒有優先需求
由于不確定的需要導致新的市場
不斷變化需求
缺少有效的需求變化管理過程
對需求的變化缺少相關分析
4.3相關性風險
許多風險都是因為項目的外部環境或因素的相關性產生的。經常我們不能很好地控制外部的相關性，因此緩解策略應該包括可能性計劃，以便從第二資源或協同工作資源中取得必要的組成部分，并且覺察潛在的問題。與外部環境相關的因素有：
客戶供應條目或信息
內部或外部轉包商的關系
交互成員或交互團體依賴性
經驗豐富人員的可得性
項目的復用性
4.4管理風險
盡管管理問題制約了很多項目的成功，但是不要因為風險管理計劃中沒有包括所有管理活動而感到驚奇。在大部分項目里，項目經理經常是寫項目風險管理計劃的人，并且大部分人都不希望在公共場合暴露自己的弱點。然而，像這些問題可能會使項目的成功變得更加困難。如果不正視這些棘手的問題，它們就很有可能在項目進行的某個階段影響項目。當我們定義了項目追蹤過程并且明晰項目角色和責任，就能處理這些風險因素：
計劃和任務定義不夠充分
實際項目狀態
項目所有者和決策者分不清
不切實際的承諾
員工之間的沖突
4.5技術風險
軟件技術的飛速發展和經歷豐富員工的缺乏，意味著項目團隊可能會因為技巧的原因影響項目的成功。在早期，識別風險從而采取合適的預防措施是解決風險領域問題的關鍵，比如：培訓、雇傭顧問以及為項目團隊招聘合適的人才等。主要有下面這些風險因素：
缺乏培訓
對方法、工具和技術理解的不夠
應用領域的經驗不夠
新的技術和開發方法
不能正確工作的方法
5風險估計
風險估計，又稱風險預測，常采用兩種方法估價每種風險。一種是估計風險發生的可能性或概率，另一種是估計如果風險發生時所產生的后果。一般來講，風險管理者要與項目計劃人員、技術人員及其他管理人員一起執行四種風險活動：
（1）建立一個標準（尺度），以反映風險發生的可能性。
（2）描述風險的后果。
（3）估計風險對項目和產品的影響。
（4）確定風險的精確度，以免產生誤解。
另外，要對每個風險的表現、范圍、時間做出盡量準確的判斷。對不同類型的風險采取不同的分析辦法。
1．確定型風險估計
（a）盈虧平衡分析
盈虧平衡分析（Break-EvenAnalysis）通常又稱為量本利分析或損益平衡分析。它是根據軟件項目在正常生產年份的產品產量或銷售量、成本費用、產品銷售單價和銷售稅金等數據，計算和分析產量、成本和盈利這三者之間的關系，從中找出它們的規律，并確定項目成本和收益相等時的盈虧平衡點的一種分析方法。在盈虧平衡點上，軟件項目既無盈利，也無虧損。通過盈虧平衡分析可以看出軟件項目對市場需求變化的適應能力。
（b）敏感性分析
敏感性分析（SensitivityAnalysis）的目的，是考察與軟件項目有關的一個或多個主要因素發生變化時對該項目投資價值指標的影響程度。通過敏感性分析，使我們可以了解和掌握在軟件項目經濟分析中由于某些參數估算的錯誤或是使用的數據不太可靠而可能造成的對投資價值指標的影響程度，有助于我們確定在項目投資決策過程中需要重點調查研究和分析測算的因素。
（c）概率分析
它是運用概率論及數理統計方法，來預測和研究各種不確定因素對軟件項目投資價值指標影響的一種定量分析。通過概率分析可以對項目的風險情況做出比較準確的判斷。主要包括解析法和模擬法（蒙特卡羅MonteCarlo技術）兩種。
2．不確定型風險估計
主要有小中取大原則、大中取小原則、遺憾原則、最大數學期望原則、最大可能原則。
3．隨機型風險估計
主要有最大可能原則、最大數學期望原則、最大效用數學期望原則、貝葉斯后驗概率法等。
5.1建立風險清單
風險清單是關鍵的風險預測管理工具，清單上列出了在任何時候碰到的風險名稱、類別、概率及該風險所產生的影響。其中整體影響值可對四個風險因素（性能、支持、成本及進度）的影響類別求平均值（有時也采用加權平均值）。
一旦完成了風險表的內容，就可以根據概率及影響來進行綜合考慮，風險影響和出現概率從風險管理的角度來看，它們各自起著不同的作用（見圖1）。一個具有高影響但低概率的風險因素不應當占用太多的風險管理時間，而具有中到高概率、高影響的風險和具有高概率及低影響的風險，就應該進行風險分析。
5.2風險評估
在風險分析過程中，我們對風險進行評估時可以建立一個如下的四元數組：
[ri,li,xi，yi]
其中，ri是風險，li為風險出現的概率，xi則表示風險損失大小，yi則表示期望風險。
一種對風險評估的常用技術是定義風險的參照水準，對絕大多數軟件項目來講，風險因素——成本、性能、支持和進度就是典型的風險參照系。也就是說對成本超支、性能下降、支持困難、進度延遲都有一個導致項目終止的水平值。如果風險的組合所產生的問題超出了一個或多個參照水平值時，就終止該項目的工作，在項目分析中，風險水平參考值是由一系列的點構成的，每一個單獨的點常稱為參照點或臨界點。如果某風險落在臨界點上，可以利用性能分析、成本分析、質量分析等來判斷該項目是否繼續工作。圖2表示了這種情況。
但在實際工作中，參照點很少能構成一條光滑的曲線，大多數情況下，它是一個區域，而且是個易變的區域。因而在做風險評估時，盡量按以下步驟執行：
（1）定義項目的水平參照值
（2）找出每組[ri,li,xi，yi]與每個水平參照值間的關系
（3）估計一組臨界點以定義項目的終止區域
（4）估計風險組合將如何影響風險水平參照值
5.3估計損失的大小
表1是風險分析表的一個例子，可以建立一個用風險、損失概率、損失大小和期望風險這樣的風險評估表。
在表1所示的風險估價的例子中，一個理論項目已經識別了從1到20周期間的潛在的幾個風險，風險發生的概率范圍在5%到50%之間。在現實的項目中，可能會識別出比此表要多得多的風險。
損失的大小常常比概率更容易受到控制。在以上的例子中，可以很精確地估計出完全支持自動從主機更新數據的時間是20個月。根據管理層將在何時討論項目建議書,可以知道項目不是在2月1日就是3月1日會被批準。如果假定會在2月1日批準，項目被批準的風險大小會比期望的長一些，也就是1個月時間。
如果損失的大小不容易直接估計出來，可以將損失分解為更小的部分，再對其進行評估，然后將各部分評估結果累加，形成一個合計評估值。例如，如果使用3種新編程工具，可以單獨評估每種工具未達到預期效果的損失，然后再把損失加到一起，這要比總體評估容易多了。
5.4評估損失的概率
評估損失的概率要比評估損失大小更具有主觀性。這里有許多實踐方法可以提高主觀評估的準確度。有以下方法：
由最熟悉系統的人評估每個風險的發生概率，然后保留一份風險評估審核文件。
使用Delphi法或少數服從多數的方法。使用Delphi法，必須要求每個人對每個風險進行獨立地評估，然后討論（口頭或紙上）每個評估的合理性，特別是最高和最低的那個。一輪輪討論，直到達成共識。?使用“形容詞標準”。首先讓每個人用表示可能性的形容詞短語選擇風險的級別，如非常可能、很可能、可能、或許、不太可能、不可能、和根本不可能。然后把可能性的評估轉換為數量化的評估（Boehm1989）。
5.5整個項目超限和緩沖
實際上，表1中表示的期望風險的計算數值來源于一個被稱為“期望值”的統計術語。設計欠佳引起的風險如果真正發生將花費15周的時間。既然它不是100%地會發生，當然不能預計損失15周時間。但它也不是沒有可能發生，所以也不應指望不會發生損失。統計學認為，預計損失的數量是概率乘以損失大小，即15%乘以15周。因此，在這個例子中，預計的是損失2.25周。由于只是談論計劃風險，可以累加所有的風險暴露量來得到項目的全部可預料超標值。這個項目可預料的超標值是12.8到13.2周，這就是如果不做任何風險管理的話有可能超過計劃的周數。
超出預期值的大小為整個項目風險控制級別的確定提供了依據。如果例子中的項目是個25周的項目，超出預期值的12.8到13.2周就很明顯需要進行風險管理了。
6風險管理策略
風險管理策略就是輔助項目組建立處理項目風險的策略。項目開發是一個高風險的活動，如果項目采取積極的風險管理策略，就可以避免或降低許多風險，反之，就有可能使項目處于癱瘓狀態。一般來講，一個較好的風險管理策略應滿足以下要求：
（1）在項目開發中規劃風險管理，盡量避免風險
（2）指定風險管理者，監控風險因素
（3）建立風險清單及風險管理計劃
（4）建立風險反饋渠道
7風險駕馭和監控
風險的駕馭與監控主要靠管理者的經驗來實施，它是利用項目管理方法及其它某些技術，如原型法、軟件心理學、可靠性等來設法避免或轉移風險。風險的駕馭和監控活動可用圖3來表示。
7.1建立風險駕馭與監控計劃
從圖3中可以看出，風險的駕馭與監控活動要寫入RMMP（RiskMonitoringandManagementPlan風險駕馭與監控計劃）。RMMP記述了風險分析的全部工作，并且作為整個項目計劃的一部分為項目管理人員所使用。
風險管理策略可以包含在軟件項目計劃中，也可以組織成一個獨立的風險緩解、監控和管理計劃（RMMP計劃）。RMMP計劃將所有風險分析工作文檔化，并由項目管理者作為整個項目計劃中的一部分來使用。一旦建立了RMMP計劃，且項目開始啟動，則風險緩解及駕馭及監控步驟也開始了。正如前面討論的，風險緩解是一種問題避免活動。風險駕馭及監控則是一種項目跟蹤活動，它有三個主要目標：?判斷一個預測的風險是否事實、是否發生。
進行風險再估計，確保針對某個風險而制定的風險消除活動正在使用。
收集可用于將來進行風險分析的信息。
風險駕馭及監控的策略如下：
與在職人員協商，確定人員流動原因。
在項目開始前，把緩解這些流動原因的工作列入風險駕馭計劃。
項目開始時，要作好人員流動的思想準備，并采取一些措施確保人員一旦離開時，項目仍能繼續。
制定文檔標準，并建立一種機制，保證文檔及時產生。
對所有工作進行細微詳審，使更多人能夠按計劃進度完成自己的工作。
對每個關鍵性技術人員培養后備人員。
在考慮風險成本之后，決定是否采用上述策略。
7.2軟件項目風險追蹤工具
追蹤風險的一個辦法是將風險輸入缺陷追蹤系統中，缺陷追蹤系統能將風險項目標示為已解決或尚未處理等狀態，也能指定解決問題的項目團隊成員，并安排處理順序。可將軟件風險項目依序排列出來，按照缺陷存在的時間與負責者等資料排列。這樣，缺陷追蹤系統就是追蹤風險的工作能更好執行并且不那么單調。
關鍵詞：軟件項目；軟件過程；CMM；KPA
一、引言
項目管理(PM，projectmanagement)是指利用現有的知識、方法和技術手段，有效地計劃、調度、控制和跟蹤項目的開始、執行、直止終止的過程，是項目順利實現的有效手段。軟件項目管理則是在項目管理的基礎上，結合軟件產品的實際，利用工程的概念和方法來開發與維護軟件，對成本、風險、時間、質量、過程、配置等進行分析、管理、控制，最終目的是為了讓軟件項目的整個生命周期都在管理者的控制范圍內，以預定成本按期、按質完成軟件的開發并交付用戶使用。目前，軟件產品已廣泛應用于各個領域，但是很多軟件項目的成功率并不高．雖然有些公司根據軟件工程理論建立了一些軟件開發管理規范．但并沒有從根本上提高軟件項目管理問題，這就導致軟件產品質量不穩定甚至是項目的失敗，同時也損害了用戶的利益。本文結合我國軟件項目管理的特點并經實踐應用．以提高軟件質量、降低成本、加強軟件項目的可控性為目標，通過對CMM的研究和改進，給出了一個基于CMM加強軟件項目管理的實踐模式，在這個模式中對目前CMM中的KPA做適當的裁減，定義了6個關鍵過程域和3個工作組。
二、軟件項目管理中目前存在的問題
影響軟件項目成功率的因素主要是軟件質量問題，而在整個軟件項目的實施過程中需求不明確、跟蹤和監督不力、缺乏客觀的軟件評審和軟件配置以及風險管理意識不足等都阻礙著軟件質量的提高。
2．1需求不明確
需求管理是軟件項目管理中非常關鍵的一個步驟．需求分析的完整與否可以降低軟件質量、延長項目周期、加大成本。由于用戶對計算機系統認識的不足，對于系統的需求往往比較模糊，遺漏甚至是錯誤的問題經常出現(包括管理流程、業務流程、數據或報表的分析處理等)，但這些問題往往沒有暴露給開發人員，而是隨著項目的進展才逐漸明確。對于開發人員來說，需求的變更意味著軟件產品的部分內容必須重新開發，而對于整個軟件項目管理而言，勢必要重新分配資源、調整計劃、估算成本等等，導致軟件產品質量下降。
2.2跟蹤和監督不力
跟蹤和監督主要針對過程而言，也是項目管理中最容易被忽視的環節。軟件項目過程由多個任務構成，大部分任務都有前置任務和后置任務，這就要求項目管理者要嚴格跟蹤和監督每一個任務。任務的完成主要從時間進度和質量兩方面來衡量，還要充分考慮因客戶方引起的一些客觀因素(更改需求分析等)。項目管理者雖然制定了具體的項目進度內容，但如果缺乏有效的跟蹤和監督機制，對于每一個階段所要完成的任務疏于評價，就會影響下階段軟件產品的質量，有時甚至是軟件產品的重新開發，最終影響整個軟件項目。
2．3缺乏客觀的軟件評審
客觀的軟件評審是軟件產品質量的直接保障，軟件評審一直貫穿于整個軟件項目的過程中，對軟件產品的評審應有客戶使用人員和軟件業中的同行來進行。客戶使用人員對軟件產品做階段性的評審可以及時發現軟件產品功能方面的不足，同行評審可以從軟件業的規范及標準去發現問題．軟件評審可以降低軟件開發的成本提高軟件產品的質量。大多情況下項目管理者沒有做任何階段性的評審，通常只是在軟件產品開發基本完成之后來組織評審，果發現了很多問題，但要修改已經非常困難．要花費很長的時間甚至從頭再來。
2．4軟件配置混亂
軟件配置是指軟件產品在各個階段各種版本的文檔、程序及數據的集合，貫穿于整個軟件項目的始終。隨著軟件產品開發的進行，由于各種客觀原因，其中的預算、設計方案、進度等內容都有可能需要大大小小的更改(這些改動可能是合理的)，整個改變的過程對軟件項目的參與人員來說必須是可視的，以便提高軟件的可靠性和質量，而這一切都應該有正確的軟件配置來控制如果失去正確的軟件配置管理，那么針對軟件產品發生的任何更改或者是維護都會給軟件項目帶來混亂甚至是失敗。
2．5風險管理意識不足
風險管理是軟件項目中防止失敗的一種重要手段，軟件項目不同的階段存在著不同的風險，并且風險會隨著項目的進展而變化，目前國內的軟件企業大都不注意軟件項目的風險管理。除了社會環境風險、商業風險等這些客觀風險之外．可控的軟件項目風險主要指技術風險。技術風險主要是指與軟件項目本身相關的的技術因素變化帶來的風險，如果在一定的條件下達不到技術條件能夠實現的目標，不但延緩項目的進度而且會增加項目的成本．繼而使整個項目受到影響。
三、通過過程管理加強軟件項目管理的實踐模式
利用cMMfCapabilityMaturityModeforSoftware)的核心思想把軟件項目管理看作一個軟件過程，并根據這一原則對整個軟件項目的開發和管理進行過程監控，監督發現過程中影響項目的關鍵問題并予以解決。軟件過程是指軟件開發人員開發和維護軟件及相關產品的一套行為、方法、實踐及變換過程，包括軟件開發過程和軟件管理過程。CMM把軟件開發機構按照不同開發水平劃分為5個級別。每個等級被分解為幾個KPA(關鍵過程域)，KPA是指在某個成熟度等級應重點關注的區域，也是達到此成熟度等級必須解決的關鍵點。①初始級，無過程意義。軟件過程是無序的、隨機的、缺乏總計劃，無預見性，大多數活動是應付危機，經常超期超支，成功取決于個人。②可重復級，具備基本的項目管理。KPA分別是：需求管理、軟件項目計劃、軟件跟蹤與監督、軟件子合同管理、軟件質量保證、軟件配置管理；③已定義級，已定義軟件過程。已將軟件管理和軟件工程兩方面的過程文檔化、標準化，并綜合成該組織的標準軟件過程。KPA分別是：組織過程焦點、組織過程定義、培訓大綱、集成軟件管理、軟件產品工程、組間協調、同行評審；④可管理級，過程可度量。已收集了軟件過程和產品質量的詳細度量方法，軟件過程和產品均可被定量地理解和控制。KPA分別是：定量過程管理、軟件質量管理；⑤優化級，過程控制。通過過程的量化反饋以及新技術、新方法促使過程不斷改進。KPA分別是：缺陷預防、技術更新預防、過程更改管理。
CMM只是一個過程改進的框架．并沒有給出具體實施的辦法。在該模式中對目前CMM中的KPA做適當裁減．定義了6個關鍵過程域：軟件項目計劃(SPP)、需求管理(RM)、軟件項目跟蹤和監督(SPTO)、軟件質量保證(SQA)、軟件配置(SCM)、同行評審(PR)，設置了三個工作組：軟件項目過程組(SPPG)、軟件工程組(SEG)、軟件質量保證組(SQAG)。通過工作組對關鍵過程域的操作來加強軟件項目的管理。
3．1定義KPA
3.1.1軟件項目計劃(SPP)
軟件項目計劃是為要實施的軟件項目編制軟件過程活動的安排，包括進度控制、成本控制、質量控制、風險控制等，也是實施CMM2的核心此階段在安排過程活動的同時開展項目設計的前期工作，設計和界定在整個項目中各階段所需的開發、質量、跟蹤、評審、風險、成本等工作。項目計劃是指導項目過程的具體措施，要在有軟件項目實施經驗的人員領導下投人大量的時間和人力資源來完成。制定項目計劃應注意7個問題。①在科學論證的基礎上制定過程，充分調動人員積極性合理地確定項目組的參加人員；②對軟件項目各程中的任務進行分解，明確項目的里程碑和檢查點；③正確估計軟件項目中的軟件資源、硬件資源、人力資源及其它費用；④正確估計各方面因素帶來的風險并制定應對措施；⑤制定項目實施過程中的跟蹤和監督措施；⑥確定軟件的評審和測試方法；⑦詳細的文檔資料。
3．1．2需求管理(RM)
需求分析主要包括面向用戶的用戶需求和面向開發人員的系統需求．是整個軟件工程的第一步．也是非常關鍵的一個環節。需求分析主要針對用戶的業務流程、系統功能、性能、數據分析進行嚴格的定義．是設計一個軟件應用系統的起點與基本依據，通過它來評判軟件產品是否能夠解決用戶問題，也是項目成功與否的標準。就目前國內現狀來講，一般簽定軟件項目合同的用戶是主管信息技術的負責人，它所關心的可能是整個系統的目標需求，用戶方中層管理人員關心的是業務流程需求．終端操作人員則注重軟件本身的易操作性和功能特性，因此．面向用戶的需求一定要和用戶多方人員多溝通、交流．最終通過雙方有關部門人員的論證以文檔資料的形式確定下來。任何一個需求分析因客觀原因可能存在著需求更改的現象，對于這種情況一定要注意需求更改的可控性．要建立需求的基準版本和更改版本控制文檔資料．使受需求變化影響的產品與需求變更一致。但要注意在更改需求的同時要衡量需求的穩定性，如果一個需求的變更比較頻繁，意味著本項目并沒有真正了解用戶想要解決的實際問題。可以說需求分析的完整性和變更可控性直接影響到軟件過程的改進，它可以降低軟件質量、加大軟件開發的成本、甚至是導致項目的失敗。軟件工程組(SEG)中要明確定義一個需求管理員。
3．1．3軟件項目跟蹤和監督(SPTO)
軟件項目的跟蹤和監督始終貫穿于整個軟件項目的過程中，是項目得以控制的前提和條件、是軟件質量的根本保障，其目的是增加軟件過程中進度、成本、工作量、質量、風險等內容的可視性，也是實施CMM2的核心。除去市場、法律等不可控制因素外，根據項目計劃對項目進展的有關情況及影響項目實施的相關因素進行及時、客觀、準確的信息采集，將采集到的需求、成本、進度、風險等內容形成文檔并建立一個項目跟蹤信息平臺。項目負責人定期召集軟件過程人員、開發人員、質量保證人員、用戶方有關人員召開開放式的例會，例會的主要內容是檢查項目進展、數據的分析、認識的偏差、資源的搭配、相關的風險等問題并討論確切的解決辦法，通過跟蹤和監督使項目始終處于可視化的受控狀態。
3.1.4軟件質量保證(SQA)
軟件質量保證是與軟件產品滿足規定的和隱含的需要能力有關的特征或特性的組合。對用戶來講主要體現在軟件產品的有效性、一致性、完整性、可靠性和可操作性等方面，對于軟件產品本身來講體現在軟件產品的可移植性、易維護性、健壯性、可重用性等方面。具體實踐中．軟件質量保證應在軟件項目計劃、需求分析、跟蹤和監督、軟件配置和軟件評審的相互配合下完成．軟件質量保證要做到以事先預防和跟蹤為主，事后糾偏為輔。
3．1．5軟件配置(SCM)
軟件配置是針對軟件產品的跟蹤和控制活動．貫穿于整個軟件項目的過程中．目的是建立和維護在整個生命周期內軟件產品的完整性和一致性，使整個軟件產品的演進過程處于可控的狀態，繼而提高軟件的可靠性和質量。在實踐應用中主要做到五個子項的配置①配置項的標識。標識做到唯一性。便于跟蹤和管理。②版本管理。對整個軟件過程中的文件和目錄提供有效的跟蹤手段。③變更控制。保持并傳遞修改信息。④配置審計。確定整個項目生產周期中產品在技術和管理上的完整性。⑤系統整合。把系統的不同部分集成后完成一組特定的功能。
3．1．6同行評審(PR)
同行評審是根據預定的規范和標準對軟件產品進行評審。評審的結果是衡量軟件產品質量的依據。在整個軟件過程中對詳細設計和軟件綜合測試作為兩個關鍵評審點來進行評審，評審的過程中注意要結合本軟件項目的具體要求和標準。
3．2組的定義
在具體的實踐應用中設置了三個組，在降低了人員成本的同時提高了軟件過程改進能力和軟件質量。
軟件項目過程組(SPPG)組織具體的項目實施活動，管理并協調整個軟件項目的過程，主要完成SPP和SPTO。
軟件工程組(SEG)負責軟件工程的需求分析、概要設計、詳細設計、編碼、測試、維護工作。
軟件質量保證組(SQAG)主要完成SPTO、SCM、PR、SQA等工作。
四、實踐模式效率評估
4．1開發時間
軟件開發由需求分析、概要設計、詳細設計、編碼、軟件測試、項目維護和軟件集成幾部分內容組成，在需求分析和設計階段采用CMM框架實施過程管理所花費的時間要多于沒有實施過程管理花費的時間。首先對項目做大量分析，論證項目的可行性。然后在和用戶做良好溝通、反復論證的基礎上做需求分析，形成文檔資料。這種模式下花費在需求分析和設計上的時間大約占項目總開發時間的40％，但這兩個階段完成了數據流程、算法描述、詳細的規格說明等內容，為代碼編寫、軟件測試、軟件維護等后續內容的工作節省了時間，軟件項目的開發周期大大縮短。經過評估，采用該實踐模式實施軟件過程管理的軟件項目開發周期比沒有實施軟件過程管理的軟件項目開發周期縮短20％。:
4．2開發質量
采用CMM標準通過軟件過程管理加強軟件項目管理的實踐模式使軟件質量明顯提高、需求分析周密、代碼錯誤率明顯降低、軟件產品完整性好、功能齊全、維護量下降，軟件項目最終得以順利實現。
WBSR模式是建立在WBS基礎之上的，與責任融合后形成的一種新模式。從WBSR角度開展工作，能夠確定軟件項目的工作及產品范圍，為工作順利開展指明了方向，將工作細化之后，分配給每一個工作人員，促使工作人員明確自身職責，從而為項目計劃制定、考核等工作奠定堅實的基礎和保障。
2模型具體步驟劃分
通過對模型進行深入分析和研究，并結合軟件項目特征，能夠確定責任范圍，對整個項目進行結構分解，得到WBS集；軟件項目的開發需要將用戶需求作為核心，進而通過模型進行分解，獲得PBS集；最后，要制定與項目開發相關的部署，確保每一個環節都能夠順利進行，保證項目進度，為工作提供依據，通過這種方式，不僅能夠確保工作有條不紊進行，還能夠有效提高工作質量和效率，從而促進軟件開發工作進一步發展。
3模型主要應用流程
WBSR模型在軟件項目管理中的應用主要涉及對項目的分解、工作目標的確認及更新。首先，建立工作小組，工作人員作為軟件項目管理的核心，其成員綜合素質直接影響工作能否順利進行，基于此，小組成員一般選擇項目經濟、技術人員等，還可以增加用戶代表等，以此來確保軟件開發的合理、科學性；其次，工作、產品等結構分解，工作分解作為模式應用的基礎，應結合實際情況進行合理分解，切勿盲目性，還需要結合成員經驗等因素，為工作順利開展提供支持；軟件產品作為參與市場競爭的關鍵，分解產品開發，能夠深度挖掘員工潛力，提高產品適應力，與客戶達成共識；最后，還需要結合實際情況對項目范圍進行及時調整，如果范圍發生變化，相對應的工作流程也需要進行調整，實現統一、系統發展目標。
4模型應用情況
將軟件項目管理與WBSR模式結合，將各個工作進行細致劃分，能夠為軟件計劃、預估等工作提供依據，確保工作順利開展，在一定程度上推動了軟件項目進一步發展，與此同時，在項目開展過程中，負責人加大對實際工作的監督和控制力度，能夠及時發現不足之處，并采取有針對性措施，確保軟件產品開發質量，該模式的應用，能夠直觀的反映組內成員的實際表現，為日后進行績效考核奠定了基礎，從而有效提高管理水平，促進企業可持續、健康發展。
5模式性能評價
通過對WBSR模式在軟件項目管理中應用情況調查可知，模式對工作過程及產品開發從不同角度進行合理分解，提高了項目范圍的精準性及有效性，避免工作失誤情況的發生，并且將工作細化至每一個人受眾，形成良性循環，促使員工能夠認真、負責完成工作，起到了積極地促進作用。因此，面對社會發展新形勢下，企業軟件項目管理可以大力推廣和普及WBSR模式，提高產品適應力及質量，從而實現企業經濟效益最大化目標。
6結論
一引言
項目管理技術是軟件工程專業的一門重要專業課。其教學任務是使學生了解和掌握項目管理的基本概念、基本原理和工程化方法。內容涉及項目管理知識體系（PMBOK）九大知識領域和五個標準化過程組，幾乎涵蓋了軟件項目從立項到結束的方方面面，是一門具有相當廣度的課程。然而，該課程的教學效果卻不容樂觀。
其一、項目管理技術的理論知識多脫胎于工程管理領域，由于國內軟件工程專業建設剛剛起步，相關教材往往照搬工程管理理論，缺乏完全針對軟件開發的必要整理和篩選。因此同軟件開發實踐結合并不十分緊密。
其二、而傳統的教學方式往往重理論而輕實踐，教師將理論知識“滿堂灌”給學生，學生“死記硬背”理論條文，并不懂得如何將理論用于實際軟件開發。這種僅以理論的多寡深淺作為對學生評價激勵唯一標準的教學手段，必然導致培養的人才實用性不強，職業能力較差，工程化程度較低。達不到項目管理技術的教學要求。
因此，需要對軟件項目管理技術的教學進行改革。二基于具體項目的軟件項目管理教學軟件工程項目相比一般工程項目具有更強的復雜性和更多的不可控因素，傳統的項目管理教學所傳授的知識常常不易使理論知識和實際開發吻合，給學生造成“學習無用之感”；課程本身也難以完全包括軟件開發過程的全部情況。最好的方法是通過一個具體軟件項目的開發過程，使學生接受項目管理的理念，而軟件項目的開發設備相對單一，團隊人數相對較少，相比一般工程項目更易進行實踐演練。
可以看出，項目管理進行過程將根據實際情況不斷進行計劃變更、計劃控制和計劃執行的搏弈和循環。由于軟件項目有以下特點：
（1）軟件產品是無形的，不可捉摸的，無法感覺形狀，設計也難以直觀表示，很難確定產品質量或估計開發工作量。
（2）由于軟件的拷貝生產輕而易舉，因此，幾乎全部的軟件項目成本在開發過程中，而不是在制造過程。
（3）軟件開發過程屬于勞動密集型過程，尚未實現完全自動化，因此對軟件項目開發進度的計劃和控制比對一般工程項目更加復雜。
（4）軟件是邏輯實體，本身很容易修改，但由于其復雜性，又很難正確地修改，在缺乏溝通的情況下，對個別模塊的修改可能會帶來新的錯誤。
（5）軟件不像其他產品會因使用而磨損，和一般工程產品不同，軟件產品的維護常常通過增加新模塊功能完成升級。為保證新版本的穩定性，常常需要對新版本的重新設計因此，軟件過程主要集中于軟件項目的開發過程，而在這一過程中，相比一般工程項目，項目管理過程組的核心循環表現得更加突出。基于具體項目對軟件開發過程進行闡述將更有利于學生理解軟件開發過程中的項目管理。由于課程目標并不在于具體技術細節的學習，而在于體會軟件開發過程中的項目管理。因此在項目選擇中，不能使學生投入過多精力在技術細節上，而應更多的關注軟件項目管理的溝通、計劃和控制。我們選擇計算機學院行政管理系統網站作為實踐項目讓學生組隊開發，這一項目屬于MIS（信息管理系統）項目類，難度不大，且能充分體現軟件項目需求不明確、多變、溝通復雜等特點。作為計算機學院的學生，學生對項目的需求的理解也將更加實際。
2.1基于項目驅動的評價體系“為了解決軟件問題，重要的第一步就是將整個軟件開發任務看做一個可控的、可度量的以及可改進的過程。”將項目管理方法運用于具體軟件項目開發的實踐或在實踐中改進現有方法，能夠幫助學生更好的掌握項目管理技術。在實際教學中，我們將學生分成若干團隊，每個團隊8~13人，充分使學生體會到團隊感，增加管理意識。項目經理是靠干出來的，不是靠背出來的。為使學生在具體項目實踐中更加投入，必須改革原有的基于卷面成績的評價體系。我們提出基于項目驅動的評價體系，使學生自覺將課堂所學的理論知識及時用于項目。學生的總評成績將由團隊項目評分、演練與總結評分、期末論文評分三部分組成：
（1）團隊項目評分：60%其中20%由教師根據團隊分階段提交的項目資料給出；剩下40%由每個團隊的“項目經理”根據團隊的成員的表現給出。而項目經理的打分權限則取決于項目完成時專家對項目的評審得分。
（2）演練與總結評分：20%項目結束后各個團隊成員對整個項目管理過程進行總結，評價和反思項目經理的管理過程，教師根據學生個人上課時有關項目的各種演練表現以及項目總結報告進行評分。
（3）期末論文評分：20%要求學生對項目管理九大知識領域進行一定深度的論述。為確保評價體系更加公平、公開、公正，我們規定：
（1）項目經理享有計劃和分配項目團隊資源，為項目組成員進行打分的權利，同時具有帶領項目組完成所有課堂演練環節，完成項目開發的義務。作為獎勵，項目經理可以直接獲得滿分的演練與總評成績；作為制約，項目經理為自己所打分數只得在項目評審得分5%上下浮動，如果項目經理引起過團隊半數以上成員不滿，將被彈劾，一旦彈劾，相應權利和獎勵同時消失。
（2）項目評審后，項目經理將得到“項目評審得分*團隊開發人數”的可分配分數，項目經理根據項目組分數分配方法給團隊成員打分，上限為40。
（3）項目評審時將邀請學院軟件工程專家、需方代表不少于5人組成專家組對各團隊項目進行公開評審，評審將從需方滿意度、項目開發文檔、項目開發過程三個角度進行打分。團隊最終得分通過delphi法得到。可以看出，在以上的評價體系中，基于項目驅動的評分所占比重相當大，不僅注重項目的結果，同時注重項目開發過程。學生的分數在一定程度上模擬了現實生活的“獎金”，而項目團隊則更加貼近現實生活中的軟件開發公司。為了使項目成功，學生必須自覺地實踐和探索科學的項目管理方法，不論成功與失敗都將成為學生寶貴的經驗和教訓。評分中，由于個體學生所能獲得的成績與其所在團隊成績緊密相關，因此，為整個團隊獲得高分而努力的開發過程極大地培養了學生的團隊協作精神。通過教學實踐，這一評價體系調動了學生的學習主動性，起到了較好的作用。超級秘書網
2.2基于項目過程的知識傳授和情景演練表1顯示了項目管理九大知識領域在五個標準化過程組中的作用。可以看出在不同的過程組中，各知識領域所起的作用是不同的。配合實際項目開發的過程，為使所傳授的知識能夠及時用于實際項目，我們顛覆了原有教材順序，按軟件項目五個過程組所涉及的知識領域對教學順序進行重新安排，基本做到項目進行階段與所傳授的相關知識同步。每次課程教學前后都及時安排對相關內容的情景演練。由表2所示教學實施安排表可以看出，項目管理的九大知識領域幾乎都能做到安排于項目情景中進行傳授，起到了理論對實踐的指導或總結作用。可以看出，每次演練環節一般都是對上次所本傳授知識的總結或當次所傳授知識的及時操練，知識點覆蓋較全面。通過設身處地去當一名項目經理或軟件工程師，增加了學生對軟件開發項目的感性認識和興趣，提高了他們的管理才能。通過知識傳授和情景演練的密切配合，使學生對軟件項目的管理過程理解得更加深刻。
二結論
基于具體項目的項目管理教學使學生能夠體會項目管理各知識領域的作用，領會各種方法、規范所適用的環境。通過實際開發后自己總結提煉的經驗和教訓，學生將更加接受項目管理的理念和知識，培養了團隊合作精神。在學期末進行的教學效果調查中，83%的學生認為這種教學方法效果良好。學生普遍反映“項目管理枯燥的理論知識變活了，知道怎么用了，印象更加深刻了。”
項目管理是軟件工程重要的專業課，在今后的教學實踐中，我們將繼續改進教學方法，做到量體裁衣，因地制宜，加強教學效果。
參考文獻：
[1]韓萬江，姜立新.軟件項目管理案例教程[M].北京:機械工業出版社.2005.
[2]張海藩.軟件工程[M].北京:人寫作論文民郵電出版社,2002.
論文摘要:軟件項目管理的根本目的是為了讓軟件項目尤其是大型項目的整個軟件生命周期(從分析、設計、編碼到瀏試、維護全過程)都能在管理者的拉制之下，以預定成本按期，按質的完成軟件交付用戶使用。目前，軟件項目管理不善的新問題仍然存在。本文將在分析軟件項目管理存在的新問題的基礎上，探索時策辦法。
隨著計算機應用范圍的日益廣泛深人，應用軟件的規模及復雜程度也日趨大型化、復雜化，這就導致軟件開發的方式也從早期的單兵作戰式或手工作坊式漸漸轉變為集團化、工廠流水線式的團隊協作開發方式。這種情況下，如何管理好項目的每一.步運作，及時解決出現的新問題是每一位項目主管責無旁貸的責任。
一、軟件項目管理存在的新問題
(一)缺乏項目管理系統培訓。項目經理在項目管理方面的培訓較少或不夠系統。項目經理或管理人員不了解項目管理的知識體系和一些常用工具和方法，所以在實際工作中沒有項目管理知識的指導，完全依靠個人現有的知識技能，管理工作的隨意性、盲目性比較大。在軟件企業中，以前幾乎沒有專招收項目管理專業的人員來擔任項目經理(甚至很少是管理專業的)，被任命的項目經理主要是因為他們能夠在技術上獨當一面，而管理方面非凡是項目管理方面的知識比較缺乏。
(二)對項目計劃熟悉不足。項目經理對總體計劃、階段計劃的功能熟悉不足。項目經理認為計劃不如變化快，項目中也有很多不確定的因素，做計劃是走過場，因此制定總體計劃時比較隨意，不少事情沒有仔細考慮;階段計劃因工作忙等理由經常拖延，造成計劃和控制管理脫節，無法進行有效的進度控制管理。沒有計劃或者是隨意的不負責任的計劃的項目是一種無法控制的項目。
(三)管理意識存在偏差。部分項目經理沒有意識到自己項目經理的角色，從總體上去把握管理整個項目，而是埋頭于具體的技術工作，造成項目組成員之間忙的忙、閑的閑，計劃不周、任務不均、資源浪費。在軟件企業中，項目經理大多是技術骨千，技術方面的知識比較深厚，但無論是項目管理知識，還是項目管理必備的技能、項目管理必備的素質都有待補充和提高，項目管理經驗也有待豐富。有些項目經理對于一些不服管理的技術人員，沒有較好的管理方法，工作不好布置的工作只好自己做。另外由于工作分解結構設計的合理性，項目任務無法有效、合理地分配給相關成員，以達到“負載均衡”。
(四)相互間缺乏溝通。在項目中一些重要信息沒有進行充分和有效的溝通。在制定計劃、意見反饋、情況通報、技術新問題或成果等方面和相關人員的溝通不足，造成各做各事、重復勞動，甚至造成不必要的損失;有些人沒有天天定時收郵件的習慣，以至于無法及時接收最新的信息。
(五)缺乏風險管理意識。項目經理沒有充分分析可能的風險，對付風險的策略考慮比較簡單。項目經理在做項目規劃時經常沒有做專門的風險管理計劃文檔，而是合并在項目計劃書中。有些項目經理沒有充分意識到風險管理的重要勝，對計劃書中風險管理的章節簡單應付了事，隨便列出幾個風險，隨便地寫一些簡單的策略，對于后面的風險防范起不到什么指導功能。
(六)項目干系人相關新問題。在范圍識別階段，項目組對客戶的整體組織結構、有關人員及其關系、工作職責等沒有足夠了解以致于無法得到完整需求或最終經權威用戶代表確認的需求。由于項目經理的工作新問題，客戶參和程度部不高，客戶方相關責任人不明確或對范圍和要求責任心不強，提出的要求具有隨意性，項目前期對需求的確認不吃積極;或者是多個用戶代表各說各話、昨是今非但同時又要求目盡早交付;項目后期需求變化隨意，造成項目范圍的蔓延，無度的拖延，成本的擴大。
二、加強軟件項目管理的辦法
(一)加強項目經理的系統培訓。項目經理接受系統的項管理知識培訓是非常必要的，有了專業領域的知識和實踐，再丈上項目管理知識和實踐和一般管理的知識和經驗的有機結合，組能大大提高項目經理的項目管理水平。應實行項目經理知識技育資格考核制度，讓項目經理自覺補充學習項目管理的知識和一些常用工具和方法。
(二)提高項目經理對計劃的熟悉。在高上術行業，日新月異是主要特征，因此計劃的制定需要在一定條.的限制和假設之下采用漸近明細的方式進行不斷完善。提高目經理的計劃意識，采用項目計劃制定相關各種知識、技術、具，加強對開發計劃、階段計劃的有效勝進行事前事后的評估。超級秘書網
(三)加強項目管理方面的培訓。加強項目管理方面的培訓，實通過對考核鄉勘際的合理設定和宣傳引導項目經理更好地做好項仁管理工作。技術骨干在擔任項目經理之前，最好能經過系統的目管理知識，非凡是其中的人力資源管理、溝通管理的學習，實且在實際工作中不斷提高自己的管理素質，豐富項目管理經驗，提高項目管理意識。
(四)加強相互間的溝通。制定有效的擇通制度和溝通機制，對由于缺乏溝通而造成的事件進行通報作夕教提醒，以提高溝通意識;溝通方式應根據內容而多樣化，甘究有效率的溝通;通過制度規定對由于未及時收取郵件而造成壯失的責任歸屬;對于非凡重要的內容要采用多種方式進行有效通以確保傳達到位。超級秘書網
(五)提高軟件項目的風險管理意識。通泛學習項目管理知識把握風險識別、量化、策略探究、反應控制爾工具和方法把握項目風險管理所必備的知識。通過加強對項目知劃中風險管理計劃的審核提高項目組的風險管理意識。總結本表業項目中常見的風險及其策略作為風險管理計劃中必要的風險詳容，并切實評估相應策略的有效勝和可行險
(六)理清項目頭系人。項目的目的就是實現項目干系人的需求和愿望。項目干弄人管理應當從項目的啟動開始，項目經理及其項目成員就要分耀項目干系人包含哪些人和組織，通過溝通協調對他們施加影響，驅動他們對項目的支持，調查并明確他們的需求和愿望，減刁琪對項目的阻力，以確保項目獲得成功。
關鍵詞：P6項目管理軟件，EPC，總包項目
在我國，工程項目管理長期以來一直是封閉落后的計劃經濟的管理模式，這種不講求效益，不遵守實際帶有長官命令色彩的“拍腦袋”式的管理模式使得我國工程項目長期處于“沒有管理的管理”狀態。我院自改制以來一直堅持走工程總承包模式的道路，不斷學習并摸索國際先進的項目管理模式及方法，在冶金行業率先引入了國際先進的項目管理軟件系統：美國Primavera公司的PrimaveraProject Plan（通常所說的P3軟件）6.2版，簡稱P6。P6是一種基于廣義網絡計劃技術的工程項目管理軟件，也是世界工程項目管理界普遍認可的項目管理軟件。這套系統的引入不僅加深了我們對項目管理的認識，提高了我們的業務水平，同時大大增強了公司的市場競爭力，2008年公司中標了一個位于印度的綜合鋼廠的EPC總包合同，本人有幸作為公司第一批開拓國際市場的項目管理人員參與了此工程的建設，并在工程建設過程中使用P6軟件進行項目管理，下面總結了自己在使用P6軟件進行項目管理在實際應用中的一些體會。
工程項目的管理是一個多目標、多工序、既復雜又龐大、既分別獨立又相互聯系的系統工程。論文參考網。一個大型復雜的工程工程管理實際上就是利用能夠控制的資源（人力、機具、材料、資金、工期）在一定的條件下對一個既定目標（進度、質量、費用）進行科學的計劃和以更多的定量數據做深入動態分析；對工程的實施過程進行有效的調整、控制、優化，以盡可能小的投入，獲得最大的效益。
1. 項目計劃的編制
在項目的最初階段，結合實際情況和業主的要求，并考慮到印度當地的氣候條件（印度每年7-9月為雨季，對土建施工影響較大，且夏季溫度較高，中午地面氣溫能夠達到50度以上）等，對項目進行初步分析和計劃編制，同時我們使用P6軟件對項目的基本內容進行科學的代碼編制，例如設計代碼為EN（Engineering），采購代碼PR（Purchase），施工代碼CO（Construction）等，這些編碼自上而下從大到小的將工程的各項任務編制成詳細的進度計劃，形成項目的基準計劃，并以此為框架，不斷對項目進行分析細化，使之成為一個可實際操作的項目進度計劃。
與在國內進行項目計劃編制不同的是，國外業主對計劃的編制工作室非常重視，往往會要求盡可能詳細的編制進度計劃，甚至要求詳細到每一道工序。論文參考網。雖然這樣加大了我們的工作數量和工作難度，但也讓我們對整個項目能夠做到了如指掌。而且在此過程中，P6軟件還可以按照我們設定好的各子項作業條目之間的邏輯關系，作業條目中添加的資源，費用，工期等進行進度計算，在時間上對所有工作進行排列，規定各個工作何時開始何時結束。P6可以對一個工程項目的所有任務做出精確的時間安排，同時還對完成任務所需的資源，費用等進行分析和比較，在千頭萬緒的任務中找出關鍵的任務（關鍵線路），保證對工期的控制。
2. 項目過程的跟蹤
以上面編排的項目計劃為基準計劃，在項目的實際實施過程中，P6軟件能夠對工程進度進行跟蹤，做到動態管理和控制。目前國內項目中，在對工程項目進行初期的計劃編制后即打印后懸掛在辦公室，并未對計劃進行細致的反饋和跟蹤，以至于很多時候對工程的實際完成情況了解不足，工期是超前了還是滯后了，提前多少滯后多少沒有人能說清。我們在此項目中不僅僅只編制計劃，更多的重要工作還在于對計劃進行跟蹤，定期按實際情況更新計劃，將計劃與實際相比較，通過P6的進度計算工程精確計算出項目當前的狀態。
以往國內的項目中，往往只對項目的重要結點進行跟蹤，而忽視了對整個項目的過程控制和管理，在此次的項目中，我們結合業主和自己的要求，使用以周為跟蹤周期，以月為考核周期的方式進行實際情況的更新和跟蹤，為下一步的項目分析、控制和優化提供堅實的依據。
3. 項目的分析、控制與優化
通過對項目基準計劃的編制、項目實際過程的跟蹤，P6軟件進行進度計算后，會通過基準計劃和實際情況兩條橫道做對比，一目了然的告訴你哪些工作的超前了，哪些工作滯后了，滯后的原因是什么？哪些工作實際何時開工或完工，本來應該在何時開工或完工，到目前為止完成了多少工程量或投資，本來應該完成多少工程量或投資以及我們關心的項目當前進展情況。我們根據軟件提供的信息，對比基準計劃（原計劃）找出偏差，分析原因，研究糾偏對策，并實施糾偏措施。P6軟件不但考慮時間問題，還根據資源和費用進行分析，求得一個時間短，資源耗費少，費用低的計劃方案，并通過軟件的強大的計算功能進行網絡計劃的優化，也就是利用浮時（Float）不斷改善網絡計劃的最初方案，使之獲得最佳工期、最低費用和對資源的最有效利用。并能夠利用軟件的過濾功能將影響制約工程進度的重要作業過濾出來重點監控。對于發現工期滯后的工程項目采取補救措施，制定相應的追趕計劃。
以往國內的項目里，一旦發生工期滯后不能按時完成工程結點的情況時，管理者往往采取的措施是盲目增加施工人員，施工機具等搶時間、搶結點以滿足業主對工期的要求，這樣不僅增加了自身的成本也不利于保證工程質量和安全。而在此次的項目中，由于施工人員都來自國內，不能做到想增加多少就增加多少，所以通過P6對項目的分析和優化，管理人員可以采取多種措施保證施工進度。論文參考網。
從以上P6項目管理軟件的使用過程和強大功能上可以看出，國外的工程項目計劃工作在現代項目管理中占有重要地位，是整個項目管理的龍頭。由于工程的其他管理工作都是圍繞著如何實現工程總進度計劃所指定的目標而展開的，因此，是否有一個全面、優質的進度計劃幾乎成為工程項目成功的關鍵。P6告訴我們現代化得工程項目管理要重視計劃水平，樹立起按計劃執行的嚴肅性，使參與工程項目的業主、監理單位、承包商等按照統一的進度目標，并為完成這一目標的各種要求做出各自的努力。
而在具體使用中應遵守幾個必要的應用原則：科學的項目工作分解和責任分工是關鍵；人員投入是保障（必須確保各級管理、編錄人員的務實工作）；自上而下來分解（根目錄的建立、各級作業面的分解、投資預算的設置必須自上而下來科學設置）；自下而上來匯總（主/子關系使項目管理必須從低層向高層次累計和匯總任何進度、投資和資源等等的信息）；督促檢查必須貫串始終（必須隨時跟蹤每一個目標的進展，發現問題及時協商、及時處理、及時采取正確的補救措施，確保目標運行方向正確、進展順利）；及時調整是靈魂（領導不重視、調整數據和投資資源不及時，必然是項目管理的P6平臺失去生命）。國外企業中，計劃管理部門是一個非常重要的部門，具有很強的現場指揮權和協調權。而在我國的企業中權力分散，令出多頭的現象很普遍，計劃部門只是履行編制施工計劃和統計報表等一般的職責。
當前，我國的項目管理模式和水平還處于混交階段，一方面國內固有的管理模式和思想已經不能滿足國外工程項目的要求，另一方面國外先進的管理模式、思想和工具進入國內，刺激我們必須轉變觀念，積極學習國外先進的管理思想和工具。特別是在涉外工程或合資工程項目建設中，如果不能很好的與外國業主的管理模式相融合，將不能很好領會業主的管理模式，在項目的實際實施過程中將處處受制，增加項目的實施和管理難度，并大大降低企業的國際市場競爭力。由于我國仍沿用著傳統的工程項目管理模式，企業中的計劃管理部門，材料部門和財務部門之間都是互為獨立的職能部門，都有著各自一套獨立的核算體系和方法，在短時間內很難達到三者的統一。為了全面推行和實施“進度、資源、成本”的綜合管理，傳統的工程項目管理模式已經不能適應新形勢下的工程管理和決策的需要。所以，在市場經濟和國際化趨勢向我們滾滾襲來的當前時代，市場競爭、優勝劣汰的潮流勢不可擋，我們要虛心學習國外先進的工程項目管理經驗，痛下決心，對自己已有的體制進行脫胎換骨的改造，只有這樣才能經得起這場大潮的考驗。
