軟件工程管理問題

導語：軟件工程管理問題一文來源于網友上傳，不代表本站觀點，若需要原創文章可咨詢客服老師，歡迎參考。

1時美國國防部曾立題專II研究軟件項日做不好的原因，發現70%的項日是因為管理不善引起的，而并不是因為技術實力不夠，進而得出一個結論，即管理是影響軟件研發項目全局的因素，而技術只影響局部。這個結論仆常重要。到了90年代中期，軟件研發項目管理不善的問題仍然存在。據美國軟件工程實施現狀的調查，軟件研發的情況仍然很難預測，大約只有10%的項目能夠在預定的費用和進度下交付。針對軟件項目管理不善的局而，我簡要談談石二軟件項目管理中存在的一些問題。1客戶干不份要全程參與不少軟件企業認為客戶的參與主要在二件事情上:協議簽訂和需求調研、客戶需求變更和項目驗收簽字，其它事情足企業內部項日開發管理的事情，屬公司內部行為，無需客戶參與。

結果，企業經常發現客戶嚴重拖延驗收，而Il在驗收期間客戶大量的需求變史，致使項目的進展嚴重推遲。經常一個預期益利的項}」，最后拖的不堪重負口我認為這里邊的一個重要原因就是客戶沒有參與項目的全過程。比方，項目初期的啟動會議、項日過程中所有干系人的知情制度，每周的工作例會、項日階段性工作總結等等都需要客戶的參與和反饋。否則當企業年之后提交一個無比龐人和復雜的最終方案時，客戶方根本不了解你的方案的進程，由誰敢簽字驗收昵?客戶只能花I幾兒個月來完全“肢解”消化整個方案，最終當然是發現大堆問題需要改進，企業只能再花上幾個月重新修改，如此往而復始，惡性循環。

2如果份求分析很困難，可不可以先做軟件對需求把握得越準確，軟件的修修補補就越少。有些需求在一開始時很難確定，在開發過程中要不斷地加以改正。軟件修改越早代價越少，修改越晚代價越人，就跟治病一樣道理。一是在項日的需求分析階段，開發方與客戶方在各種的問題的基本輪廓上達成一致即.IJ,具體細節可以在以后填充。軟件過程改善是一個持續改善的過程，需要不斷地學習，需要知識的積累，特別是當主客觀環境發生變化時，需要對過程進行修改，以適應變化了的情況。無論多么細致的需求分析，兒乎都難以避免修改。實際上許多軟件項日失敗的最l要的原因就是需求階段對問題的描述不夠細致，導致后來頂算超出或者時間進度達不到要求。這就要求在項H需求分析階段，開發方與客戶方必須個面地盡可能細致地討論項目的應用背景、功能要求、性能要求、操作界面要求、與其他軟件的接口要求，以及對項目進行評估的各種評價標準。并民，在需求分析結束以后，雙方還要建立可以直接聯系的渠道，以盡早地對需求變動問題進行溝通。

3軟件項目份求的改變容易實現嗎在具體實際中由于種種原因客戶方很難在需求分析階段全面而準確地描述所有問題。隨著開發進度的推進，往往會有一此需求的改變。而現代軟件工程理論也利用軟件的靈活性特點通過各種方式來適應這種情況。不過，這并不表明“軟件項目的需求可以持續不斷的改變，而且這此改變可很容易地被實現”。實踐表明，隨著開發進度的推進，實現軟件需求更改所需要的代價呈指數形式增長。假定在需求分析階段實現需求更改需要花費1倍的代價;那么，在系統設計和編碼階段，需要花費1.5-6倍的代價;在系統測試階段需要花費10-20倍的代價;在軟件版本以后，甚至可能要花費60-100倍的代價。由此可見，在項日開展過程中，軟件需求的改變應當盡量早地提出。這樣才可能花費少，容易被實現。

4項目的質f提高是否要依救完普的質fm試制度不少企業把軟件的測試工作定位于提高軟件開發項目的質量。我認為質量測試制度只是」個補救措施，是來挑出各種因素造成的缺陷，但不能避免新的缺陷的出現。真正有效的質量管理是建立在一套質量保證體系l幾的全過程質量管理方案，每一個環節的規范化管理是質量保證的一個基礎，除此之外，規范的項目方案評審制度也是質量保證的必備步驟，經常客戶對質量的評價首先是方案質量的優劣。有效的、科學的測試制度也將有助于在提交客戶之前發現設計中的問題。

5所有的內部洲試工作是不是全部應該由洲試人員完成軟件程序測試可以分為“白盒法”和“黑盒法”兩種方式。由于使用“自盒法”對測試人員各方面素質的種種要求，在進行程序測試時測試人員總是最優先使用“黑盒法”。他們的上作方式往往是先對程序進行“黑盒法”測試;如果測試沒有通過，不得已這才考慮對程序代碼進行“自盒法”測試。顯然，這種對“白盒法”有意無意的“逃避”，對軟件的可靠性和穩定性構成了威脅。如何解決這個問題?一方面需要提高對測試人員的要求，另一方向也需要程序員完成部分的“白盒法”測試。

6如果我們落后于計劃，是否可以增加更多的程序員來解決客觀情況是軟件開發不同J二傳統的農業生產，人多不見得力量大。如果給落后于計劃的項日增添新手，可能會更加延誤項日。因為:

1)新手會產生很多新的錯誤，使項目混亂。

2)老手向新手解釋上作以及交流思想都要花費時間，使實際開發時間更少。所以科學的項I-I計劃很重要，不在乎計劃能提前多少，重在恰如其分。如果用“”的方式奔向共產卞義，只會產生倒退的后果。投入項目上的人力，多多益善。在某些業務項日卜確實如此。但在系統項目管理中卻很少是這樣的。人們的技能和知識是不能互換的。如果多一些人加入到系統項目中來，由于協調不利和要培訓人員以快速適應丁:作，通常會減慢項日的進度。

7技術骨千是否應該成為項目的項目經理項目經理一定是所有項目成員中薪水最高的。在“軟件作坊”時代，這是一種普遍使用而目.效果不錯的方法;而在“軟件”時代，這種方法卻帶來各種問題，有時甚至直接導致項日失敗。究其原因這主要是因為隨著現代軟件開發分工的細化，對項目經理的要求也發生了根本的改變—最注重的不是其對某項專業技術的掌握程度，而是其組織、領導、協調開發團隊的能力。至于項目經理的薪水問題，這和定薪制度有很大關系。通常，項目經理執行的是管理人員的薪酬體系，而其他人員執行的是技術人員的薪酬體系。項目經理的薪水在項目成員中是比較高的，但不-定是最高的。有時候，為了激勵技術人員，項目中的技術骨干得到的酬勞比項目經理要高。