軟件工程管理問題

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

2、變更和項日驗收簽字，其它事情足企 業(yè)內部項日開發(fā)管理的事惜，屬 公司內部行為，無需客戶參與。結果，企業(yè)經常發(fā)現客戶嚴重拖延驗收， 而 II 在驗收期間客戶大量的需求 變史， 致使項 LI 的進展嚴重推遲。經常一個預期益利的項門，最后拖的不堪重負 口我認為 這里邊的一個重要原因就是客戶沒有參與項 U 的全過程。比方，項 U 初 期的啟動會 議、項日過程中所有干系人的知情制度，每周的工作例會、項日階段 性工作總結等等 都需要客戶的參與和反應。 否那么當企業(yè)年之后提交一個無比龐人 和復雜的最終方案時， 客戶方根本不了解你的方案的進程，山誰敢簽字驗收呢？ 客戶只能花 I 兒兒個月來完 全“肢解消化整個

3、方案，最終當然是發(fā)現大堆問題 需要改良，企業(yè)只能再花上兒個 月重新修改，如此往而復始，惡性循環(huán)。2 如果份求分析很困難，可不可以先做軟件對需求把握得越準確，軟件的修 修補 補就越少。有些需求在一開始時很難確定，在開發(fā)過程中要不斷地加以改正。 軟件修 改越早代價越少，修改越晚代價越人，就跟治病一樣道理。一是在項日的 需求分析階 段，開發(fā)方與客戶方在各種的問題的根本輪廓上達成一致即 ?叮，具體 細節(jié)可以在以 后填充。軟件過程改善是一個持續(xù)改善的過程，需要不斷地學習， 需要知識的積累， 特別是當主客觀環(huán)境發(fā)生變化時，需要對過程進行修改，以適 應變化了的情況。無論 多么細致的需求分析，兒乎都難以防止修

4、改。實際上許多 軟件項日失敗的最 1 要的原 因就是需求階段對問題的描述不夠細致， 導致后來頂 算超出或者時間進度達不到要求。 這就要求在項 H 需求分析階段，開發(fā)方與客戶 方必須個面地盡可能細致地討論項 LI 的應用背景、功能要求、性能要求、操作界 面要求、與其他軟件的接口要求，以及對 項 LI 進行評佔的各種評價標準。并民， 在需求分析結束以后，雙方還要建立可以直 接聯系的渠道，以盡早地對需求變動 問題進行溝通。3 軟件工程份求的改變容易實現嗎在具體實際中山于種種原因客戶方很難在 需求 分析階段全面而準確地描述所有問題。隨著開發(fā)進度的推進，往往會有一此 需求的改 變。而現代軟件工程理論也利

5、用軟件的靈活性特點通過各種方式來適應 這種情況。不 過，這并不說明“軟件工程的需求可以持續(xù)不斷的改變，而且這此 改變可很容易地被 實現。實踐說明，隨著開發(fā)進度的推進，實現軟件需求更改 所需要的代價呈指數形 式增長。假定在需求分析階段實現需求更改需要花費 1倍 的代價 ;那么，在系統(tǒng)設計 和編碼階段，需要花費 1.5-6倍的代價 ;在系統(tǒng)測試階 段需要花費 10-20倍的代價 ;在 軟件版本發(fā)布以后，棋至可能要花費 60-100 倍的 代價。山此可見，在項日開展過程 中，軟件需求的改變應當盡量早地提出。這樣 才可能花費少，容易被實現。4 項訂的質 f 提高是否要依救完普的質 fm 試制度不少企業(yè)

6、把軟件的測試工作 定 位于提高軟件開發(fā)項 U 的質量。我認為質量測試制度只是個補救措施，是來 挑出 各種因素造成的缺陷，但不能防止新的缺陷的出現。真正有效的質量管理是 建立在一 套質量保證體系 1 兒的全過程質量管理方案， 每一個環(huán)節(jié)的標準化管理 是質量保證的 一個根底，除此之外，標準的項口方案評審制度也是質量保證的必 備步驟，經常客戶 對質量的評價首先是方案質量的優(yōu)劣。有效的、科學的測試制 度也將有助于在提交客 戶之前發(fā)現設計 ?中的問題。5 所有的內部洲試工作是不是全部應該山洲試人員完成軟件程序測試可以分 為 “白盒法和“黑盒法兩種方式。 由于使用“自盒法對測試人員各方面素 質的種 種要求

7、，在進行程序測試時測試人員總是最優(yōu)先使用“黑盒法。他們的 上作方式往 往是先對程序進行“黑盒法測試 ; 如果測試沒有通過，不得已這才 考慮對程序代碼 進行“自盒法測試。顯然，這種對“白盒法有意無意的“逃 避，對軟件的可靠 性和穩(wěn)定性構成了威脅。如何解決這個問題？一方面需要提 高對測試人員的要求，另 一方向也需要程序員完成局部的“口盒法測試。6 如果我們落后于汁劃，是否可以增加更多的程序員來解決客觀悄況是軟件 開發(fā) 不同 J 二傳統(tǒng)的農業(yè)生產，人多不見得力量大。如果給落后于方案的項日增 添新手， 可能會更加延誤項日。因為：1) 新手會產生很多新的錯誤，使項口混亂。2) 老手向新手解釋上作以及交流

8、思想都要花費時間， 使實際開發(fā)時間更少。 所 以科學的項 1-1 方案很重要，不在乎方案能提前多少，重在恰如其分。如果用 “大躍進的方式奔向共產卞義，只會產生倒退的后果。投入項忖上的人力，多 多 益善。在某些業(yè)務項日卜確實如此。但在系統(tǒng)項 LI 管理中卻很少是這樣的。人 們的 技能和知識是不能互換的。如果多一些人參加到系統(tǒng)項口中來，山于協(xié)調不 利和要培 訓人員以快速適應丁 : 作，通常會減慢項日的進度。7技術骨千是否應該成為項1:1的項LI經理項U經理一定是所有工程成員中薪水最高的。在“軟件作坊時代，這是一種普遍使用而 L I .效果不錯的方法 ; 而在 “軟件 時代，這種方法卻帶來各種問題，有時其至直接導致項日失敗。究其原 因這主要是因 為隨著現代軟件開發(fā)分工的細化， 對項口經理的要求也發(fā)生了根本 的改變一最注重的 不是其對某項專業(yè)技術的掌握程度，而是其組織、領導、協(xié)調 開發(fā)團隊的能力。至于 項 U 經理的薪