軟件開發(fā)基本原則

1、軟件開發(fā)基本原則（一） 策略和因素1 概 述時(shí)間 - 成本 - 質(zhì)量（或特性）是評價(jià)軟件項(xiàng)目成敗的三個(gè)關(guān)鍵指標(biāo)，這三個(gè)指標(biāo)之間相互影響和制約，形成了所謂的“項(xiàng)目管理三角形”。要提高質(zhì)量或增加特性意味著成本和時(shí)間的增加，或兩者都增加；要在時(shí)間不變的前提下縮減開發(fā)成本或成本不變的前提下縮減時(shí)間則意味著質(zhì)量的下降或特性的削減。圖 1-1 項(xiàng)目管理三角形上述分析其實(shí)只是理論上的“理想平衡”狀態(tài)?，F(xiàn)實(shí)工作中往往出現(xiàn)的情形是：要么時(shí)間超過計(jì)劃，要么成本超過預(yù)算，要么質(zhì)量達(dá)不到要求，要么三個(gè)指標(biāo)都達(dá)不到預(yù)期。典型例子：由于客戶的壓力需要盡量縮減開發(fā)時(shí)間，由于企業(yè)間的競爭和盈利壓力需要盡量節(jié)約成本，因此需要一

2、個(gè)人做兩個(gè)人的工作，一個(gè)月做兩個(gè)月的工作，同時(shí)壓縮需求分析、設(shè)計(jì)、測試、評審和項(xiàng)目會議等活動?？上攵?，即使軟件的構(gòu)建階段能夠按時(shí)完成，但做出的軟件質(zhì)量是難以保證的。更糟糕的還在后面：由于質(zhì)量的低劣，構(gòu)建階段結(jié)束后對系統(tǒng)進(jìn)行集成測試時(shí)，很多問題就會暴露出來：對某些需求的理解有誤差，導(dǎo)致這部分功能要重新分析、設(shè)計(jì)、編碼和測試；架構(gòu)設(shè)計(jì)缺乏整體思維導(dǎo)致系統(tǒng)不同模塊各自為政，產(chǎn)生大量重復(fù)的難以維護(hù)的代碼；編碼太倉促導(dǎo)致一大堆的Bug；溝通不暢順導(dǎo)致模塊接口不兼容從而項(xiàng)目被帶入了修改無限循環(huán)地帶，即使勉強(qiáng)上線發(fā)布，修改還是一直持續(xù)，直至最后，沒有人再敢接近這套代碼，對這個(gè)項(xiàng)目談虎色變。軟件開發(fā)項(xiàng)目有其

3、自身規(guī)律和原則，只有遵守其原則并付諸相應(yīng)的實(shí)踐才可能使項(xiàng)目健康穩(wěn)定地前進(jìn)。本文講述的是軟件開發(fā)的基本原則，它是通用的，幾乎適用于所有的軟件開發(fā)項(xiàng)目。不同項(xiàng)目可以根據(jù)自身特點(diǎn)在原則的指導(dǎo)下定義相應(yīng)的項(xiàng)目開發(fā)實(shí)踐。2 策略和因素2.1 總體策略要避免混亂低效的開發(fā)，就要求每個(gè)人能夠放棄他們自己的一些壞習(xí)慣，通過采取以下四種策略實(shí)現(xiàn)快速開發(fā)：1、 避免典型錯(cuò)誤2、 打好開發(fā)基礎(chǔ)3、 管理風(fēng)險(xiǎn)，避免災(zāi)難發(fā)生4、 采用面向進(jìn)度的實(shí)踐圖 2.1-1 快速開發(fā)的四跟支柱典型錯(cuò)誤：是指一些經(jīng)常被許多人使用的無效的開發(fā)實(shí)踐，如：不現(xiàn)實(shí)的預(yù)期，缺乏計(jì)劃，功能蔓延和銀彈綜合癥等。將在第3章詳細(xì)講解。開發(fā)基礎(chǔ)：是指項(xiàng)

4、目開發(fā)過程中管理、技術(shù)、質(zhì)量保證等方面行為和活動，如：計(jì)劃編制，需求管理和技術(shù)回顧等。將在第4章詳細(xì)講解風(fēng)險(xiǎn)管理：是指對有可能影響項(xiàng)目的風(fēng)險(xiǎn)進(jìn)行評估和控制。將在第5章討論進(jìn)度計(jì)劃相關(guān)的風(fēng)險(xiǎn)。面向進(jìn)度的實(shí)踐有以下三類· 面向速度的實(shí)踐：可以提升開發(fā)速度，幫助你更快的交付軟件· 面向進(jìn)度風(fēng)險(xiǎn)的實(shí)踐：可以降低計(jì)劃風(fēng)險(xiǎn)，幫助你的項(xiàng)目平穩(wěn)推進(jìn)· 面向可視化的實(shí)踐：可以提高進(jìn)程的可視化程度，幫助你掌握項(xiàng)目動態(tài)圖 2.1-2 面向進(jìn)度的實(shí)踐圖2.1-1所示的前三根柱子為可能的最佳進(jìn)度提供了最重要的支撐，雖然可能不是最理想的，但卻是最需要的。也就是說，即使不借助于面向進(jìn)度的實(shí)踐方

5、法，也可能實(shí)現(xiàn)較優(yōu)化的項(xiàng)目進(jìn)度；但是，如果僅僅依賴面向進(jìn)度的實(shí)踐卻不可以支撐可能的最佳進(jìn)度計(jì)劃。圖 2.1-3 僅僅依賴面向進(jìn)度的實(shí)踐不足以支撐最佳進(jìn)度計(jì)劃2.2 軟件開發(fā)的四維每個(gè)軟件項(xiàng)目都有四個(gè)重要的維：· 人員：完成任務(wù)要么快，要么慢· 過程：優(yōu)化人員的工作效率，或者浪費(fèi)人員的時(shí)間· 產(chǎn)品：以自我完善的形式定義，或者阻礙人員達(dá)到最好效果的形式定義· 技術(shù)：促進(jìn)或者阻礙開發(fā)的實(shí)現(xiàn)圖 2.2-1 開發(fā)速度的四維2.2.1 人員研究數(shù)據(jù)：人件極大地影響著生產(chǎn)效率，任何關(guān)注提高生產(chǎn)效率的組織首先必須有一套良好的人員激勵(lì)、團(tuán)隊(duì)合作、員工選擇及培訓(xùn)機(jī)制發(fā)揮人員

6、最大潛能，縮短項(xiàng)目周期的方法：1、 項(xiàng)目成員的選擇五個(gè)原則：· 用更少更好的人· 使任務(wù)與人員的技能和動機(jī)相匹配· 幫助人員自我實(shí)現(xiàn)，而不是強(qiáng)制地把他推到他最有經(jīng)驗(yàn)或最需要他的崗位上· 人員選擇應(yīng)強(qiáng)調(diào)人員之間的互補(bǔ)與協(xié)調(diào)性· 盡快排除或替換不稱職的人員2、 團(tuán)隊(duì)組織結(jié)構(gòu)人員的組織方式對人員的工作效率有很大影響，調(diào)整項(xiàng)目團(tuán)隊(duì)以使之與項(xiàng)目規(guī)模、產(chǎn)品特點(diǎn)以及進(jìn)度目標(biāo)相匹配。特定的軟件項(xiàng)目也可以從適宜的專門組織中受益。3、 人員激勵(lì)人員激勵(lì)能激發(fā)人的動力，從而付出額外的努力工作；它適用于不同組織、不同項(xiàng)目和不同人員。人員激勵(lì)是達(dá)成快速開發(fā)的最具潛力方法

7、2.2.2 過程研究數(shù)據(jù)：Hughes Aircraft、Lockheed、Motorola、NASA、Raytheon和Xerox等組織通過對開發(fā)過程的改進(jìn)將產(chǎn)品上市時(shí)間縮短了一半，降低成本、減少錯(cuò)誤為原來的1/31/10。過程是指軟件開發(fā)生命周期中定義的一系列工作流程和活動的集合?？梢愿爬橐韵氯悾?#183; 基本過程：包括獲取過程、供應(yīng)過程、開發(fā)過程、運(yùn)作過程、維護(hù)過程和管理過程· 支持過程：包括文檔過程、配置管理過程、質(zhì)量保證過程、驗(yàn)證過程、確認(rèn)過程、聯(lián)合評審過程、審計(jì)過程以及問題解決過程· 組織過程：包括基礎(chǔ)設(shè)施過程、改進(jìn)過程以及培訓(xùn)過程忽略過程容易造成工作效

8、率低下，工作目的交叉重復(fù)，產(chǎn)品質(zhì)量難以保證等問題；另一方面，如果過程過于嚴(yán)格、過于官僚同樣會挫傷人員的積極性，或者由于執(zhí)行過程的成本過高而影響實(shí)際的工作效率。組織可以對現(xiàn)有的過程進(jìn)行裁剪和調(diào)整，制定出適合特定項(xiàng)目的過程；或者可以為項(xiàng)目從頭開始定義過程。無論是裁剪過程或是定義過程，應(yīng)該把關(guān)注點(diǎn)放在以下幾個(gè)方面：1、 避免返工軟件項(xiàng)目節(jié)省時(shí)間一個(gè)最直接的方式就是確定過程，避免重復(fù)工作。如果在項(xiàng)目最后階段改變需求，就可能不得不重新設(shè)計(jì)、編碼和測試；如果直到系統(tǒng)測試階段才發(fā)現(xiàn)設(shè)計(jì)有問題，就可能不得不扔掉已經(jīng)細(xì)化的設(shè)計(jì)和編碼。2、 質(zhì)量保證質(zhì)量保證有兩個(gè)目的· 確保交付的產(chǎn)品能夠達(dá)到可接受的質(zhì)

9、量水平· 在各階段以最少的時(shí)間和成本代價(jià)查出錯(cuò)誤應(yīng)盡早在錯(cuò)誤發(fā)生的時(shí)候就查出來，錯(cuò)誤在產(chǎn)品中停留的時(shí)間越長，清楚錯(cuò)誤所花費(fèi)的時(shí)間和成本就越多。質(zhì)量保證是任何開發(fā)過程中必不可少的部分。3、 開發(fā)基礎(chǔ)一系列的軟件工程實(shí)踐活動形成了開發(fā)基礎(chǔ)，如：分析、設(shè)計(jì)、構(gòu)建、集成和測試等。在過程中對開發(fā)基礎(chǔ)加以關(guān)注，并定義良好的工作規(guī)范和任務(wù)集合能防止項(xiàng)目失控。4、 風(fēng)險(xiǎn)管理與進(jìn)度相關(guān)的風(fēng)險(xiǎn)管理是開發(fā)過程必要的組成部分。風(fēng)險(xiǎn)管理雖然不能直接提高開發(fā)速度，但它是避免項(xiàng)目災(zāi)難的有效實(shí)踐。5、 資源目標(biāo)資源包括人力資源、環(huán)境資源和軟硬件資源等。優(yōu)化資源的調(diào)配有助于提高生產(chǎn)率。6、 生命周期計(jì)劃生命周期計(jì)劃是

10、基本的管理計(jì)劃，有助于確定軟件項(xiàng)目要進(jìn)行的活動集合和資源分配。每種周期模型都有其適用范圍和缺點(diǎn)，為項(xiàng)目選擇適當(dāng)?shù)纳芷谀Ｐ湍苡行岣吖ぷ餍驶蚪档晚?xiàng)目風(fēng)險(xiǎn)。圖 2.2.2-1 純瀑布模型圖 2.2.2-2 瀑布模型的另一種形式鮭魚生命期模型圖 2.2.2-3 編碼修正模型（一種不規(guī)范的模型）圖 2.2.2-4 螺旋模型圖 2.2.2-5 生魚片模型圖 2.2.2-6 包含子項(xiàng)目的瀑布模型圖 2.2.2-7 能夠降低風(fēng)險(xiǎn)的瀑布模型（對需求分析和架構(gòu)設(shè)計(jì)階段采用螺旋模型）圖 2.2.2-8 漸進(jìn)原型模型圖 2.2.2-9 階段交付模型圖 2.2.2-10 面向進(jìn)度模型圖 2.2.2-11 漸進(jìn)交

11、付模型圖 2.2.2-12 面向開發(fā)工具的設(shè)計(jì)模型7、 面向客戶開發(fā)誰是客戶？對客戶的理解取決于場合，可能是項(xiàng)目委托人，最終用戶，市場人員或者老板?，F(xiàn)代軟件開發(fā)非常關(guān)注客戶的需求與期望，開發(fā)出合符產(chǎn)品規(guī)格的軟件只是完成了一半工作，另一半是幫助客戶配置出產(chǎn)品能夠?qū)崿F(xiàn)的功能，而實(shí)現(xiàn)這些功能所花費(fèi)的時(shí)間通常遠(yuǎn)遠(yuǎn)多于確定紙面上的產(chǎn)品規(guī)格所需要的時(shí)間。將自己站在客戶的角度考慮問題是避免大量返工的最好方法。同時(shí)應(yīng)該建立有效的客戶溝通渠道，合理控制客戶的期望值。2.2.3 產(chǎn)品在軟件開發(fā)的四維中，最切實(shí)的維是產(chǎn)品維。對產(chǎn)品規(guī)模和產(chǎn)品特性的關(guān)注，意味著巨大的縮短計(jì)劃進(jìn)度的機(jī)會。削減了產(chǎn)品功能通常就可以縮短產(chǎn)品

12、開發(fā)周期1、 產(chǎn)品規(guī)模產(chǎn)品規(guī)模是對開發(fā)進(jìn)度影響最大的一個(gè)因素。構(gòu)建軟件所需的工作量的增長比產(chǎn)品規(guī)模的增長要快得多，并且增長是不成比例的，所以產(chǎn)品規(guī)模的縮小將大大提高開發(fā)速度。將中等規(guī)模的軟件削減一半通?？梢允构ぷ髫?fù)荷削減2/3。2、 產(chǎn)品特性產(chǎn)品的一些非功能性需求或額外關(guān)注點(diǎn)會影響設(shè)計(jì)的復(fù)雜度和構(gòu)建的工作量，如對性能、穩(wěn)定性、可維護(hù)性和可擴(kuò)展性等要求很高的產(chǎn)品比沒有這些特性要求的產(chǎn)品需要更長的開發(fā)周期。2.2.4 技術(shù)從使用低效的工具轉(zhuǎn)為使用高效的工具是提高開發(fā)速度的快捷方法。選擇有效的工具并管理好由此帶來的風(fēng)險(xiǎn)也是提高開發(fā)速度的方法。軟件開發(fā)基本原則（二） 典型錯(cuò)誤大多數(shù)典型錯(cuò)誤其表面都具有

13、誘惑性，給人們一種誘人的前景，但通常卻不能產(chǎn)生期望的結(jié)果。“想挽救進(jìn)度已經(jīng)落后的項(xiàng)目嗎？- 給項(xiàng)目補(bǔ)充更多人員！”下面分別按照人員、過程、產(chǎn)品和技術(shù)四個(gè)維度列出36個(gè)典型錯(cuò)誤。人 員典型錯(cuò)誤1：挫傷積極性對人員不夠關(guān)心和重視；過度的進(jìn)度壓力；缺乏激勵(lì)；過分夸張的激勵(lì)等。典型錯(cuò)誤2：人員素質(zhì)低人員能力欠佳，工作效率低，甚至做多錯(cuò)多。典型錯(cuò)誤3：對有問題的員工失控不對有問題的人員采取措施是項(xiàng)目組成員對領(lǐng)導(dǎo)最常見的抱怨。典型錯(cuò)誤4：英雄主義強(qiáng)調(diào)個(gè)人英雄主義會導(dǎo)致發(fā)生額外的風(fēng)險(xiǎn)，也會削弱在軟件開發(fā)過程中多個(gè)角色的合作。典型錯(cuò)誤5：項(xiàng)目后期加入人員盲目地在項(xiàng)目后期加入人手等于火上澆油。典型錯(cuò)誤6：辦公室

14、環(huán)境擁擠嘈雜擁有安靜、隱蔽辦公環(huán)境的人員比工作在嘈雜、擁擠環(huán)境中的人員往往會有更好的工作業(yè)績表現(xiàn)。典型錯(cuò)誤7：開發(fā)人員與客戶之間發(fā)生摩擦主要原因是缺乏溝通。這種摩擦耗費(fèi)時(shí)間，它會轉(zhuǎn)移客戶和開發(fā)人員雙方對項(xiàng)目工作的注意力。典型錯(cuò)誤8：不現(xiàn)實(shí)的預(yù)期過高的期望值和主觀的不切實(shí)際的設(shè)想。是導(dǎo)致開發(fā)人員和客戶或項(xiàng)目經(jīng)理之間的摩擦常見原因之一。典型錯(cuò)誤9：缺乏有效的項(xiàng)目支持軟件開發(fā)項(xiàng)目的許都方面都需要高層的支持，包括實(shí)際的計(jì)劃、變更控制以及新型開發(fā)方法的采用等。缺乏有效的高層支持事實(shí)上注定了項(xiàng)目的失敗。典型錯(cuò)誤10：缺乏各種角色的齊心協(xié)力軟件開發(fā)中所有主要人員必須齊心協(xié)力專注于項(xiàng)目，包括高層支持者、項(xiàng)目領(lǐng)

15、導(dǎo)、項(xiàng)目成員、市場人員、最終用戶、客戶和任何項(xiàng)目介入者。典型錯(cuò)誤11：缺乏用戶介入沒有用戶早期介入的項(xiàng)目充滿需求誤解的風(fēng)險(xiǎn)，易受項(xiàng)目后期功能蔓延的威脅。典型錯(cuò)誤12：政治高于物質(zhì)“政治家”型項(xiàng)目強(qiáng)調(diào)“管理至上”，主要精力集中在他們與經(jīng)理的關(guān)系上。將政治凌駕于結(jié)果之上對軟件項(xiàng)目會造成極大傷害。典型錯(cuò)誤13：充滿想象閉上眼睛毫無理由地希望某事將像想象那樣運(yùn)作。很多軟件開發(fā)問題都是由于充滿想象造成的。想象示例：項(xiàng)目組不知道他們能不能按時(shí)完成項(xiàng)目，但他們認(rèn)為如果每個(gè)人能更努力工作，并且不出現(xiàn)問題，他們應(yīng)該能完成項(xiàng)目。我們無需向客戶演示最新的修改，我們確信這個(gè)效果是客戶想要的。項(xiàng)目組錯(cuò)過了一個(gè)里程碑好幾

16、天了，他們說會更努力工作趕上下一個(gè)里程碑，我想他們能夠及時(shí)趕上的。過 程典型錯(cuò)誤14：過于樂觀的計(jì)劃定制過于樂觀的項(xiàng)目計(jì)劃相當(dāng)于自己為項(xiàng)目失敗畫出了底線，導(dǎo)致縮短分析、設(shè)計(jì)等關(guān)鍵性前期開發(fā)活動；同時(shí)也向開發(fā)人員施加了額外壓力，會長期對開發(fā)人員的自信心和生產(chǎn)率造成巨大傷害。典型錯(cuò)誤15：缺乏足夠的風(fēng)險(xiǎn)管理如果你不主動管理風(fēng)險(xiǎn)，風(fēng)險(xiǎn)隨時(shí)會來找你，打亂你的開發(fā)計(jì)劃。典型錯(cuò)誤16：承包人導(dǎo)致的失敗如果不對承包商加以認(rèn)真管理，交付可能延期，并且質(zhì)量難以保證。典型錯(cuò)誤17：缺乏計(jì)劃沒有計(jì)劃的項(xiàng)目就像飄蕩在海洋中的小船，沒人知道會飄到哪里。典型錯(cuò)誤18：在壓力下放棄計(jì)劃很多項(xiàng)目組定制了計(jì)劃，但遇到了麻煩時(shí)就

17、放棄計(jì)劃。項(xiàng)目失敗的原因不是在于放棄計(jì)劃本身，而是不能及時(shí)修訂計(jì)劃制定替代計(jì)劃，并一頭栽進(jìn)編碼和問題處理中。典型錯(cuò)誤19：在模糊的項(xiàng)目前期浪費(fèi)時(shí)間由于花在審批、預(yù)算等前期工作的時(shí)間過長，或需求無限循環(huán)等原因，導(dǎo)致壓縮開發(fā)計(jì)劃。項(xiàng)目前期節(jié)省幾周或幾個(gè)月時(shí)間比將開發(fā)計(jì)劃壓縮同樣時(shí)間來得更容易、更廉價(jià)，風(fēng)險(xiǎn)也更少。典型錯(cuò)誤20：前期活動不符合要求研究數(shù)據(jù)：前期被跳過的活動或工作通常在后期會以10倍到100倍的代價(jià)來完成。如果一項(xiàng)工作在項(xiàng)目初期需要5小時(shí)完成，那么在項(xiàng)目后期你至少需要50小時(shí)才能完成它。（Fagan 1976，Boehm and Papaccio 1988）典型錯(cuò)誤21：設(shè)計(jì)低劣前期活

18、動不符合要求的一個(gè)特殊情況就是設(shè)計(jì)低劣。高壓環(huán)境導(dǎo)致設(shè)計(jì)缺乏周密思考往往導(dǎo)致設(shè)計(jì)低劣。典型錯(cuò)誤22：缺少質(zhì)量保證措施研究數(shù)據(jù)：項(xiàng)目前期砍掉1天的質(zhì)量保證活動，到項(xiàng)目后期就需要3到10天的處理代價(jià)。（Jones 1994）典型錯(cuò)誤23：缺少管理控制缺少管理控制點(diǎn)就難以對項(xiàng)目的階段和狀態(tài)進(jìn)行跟蹤，因此不能知道項(xiàng)目是否按正常軌道前進(jìn)。典型錯(cuò)誤24：太早或過于頻繁的集成在構(gòu)建未完全鎖定時(shí)，進(jìn)行過早的集成或額外的集成不利于產(chǎn)品，它僅僅是在浪費(fèi)時(shí)間，延長進(jìn)度。典型錯(cuò)誤25：項(xiàng)目估算時(shí)遺漏必要的任務(wù)訓(xùn)、公司和部門會議，技術(shù)評審會議等活動在項(xiàng)目估算時(shí)通常被遺漏。典型錯(cuò)誤26：追趕計(jì)劃當(dāng)進(jìn)度落后時(shí)不重新檢查任務(wù)

19、和調(diào)整計(jì)劃，而是簡單地決定把進(jìn)度趕上來。另一種情況是，當(dāng)產(chǎn)品出現(xiàn)變更卻沒有做相應(yīng)的計(jì)劃調(diào)整典型錯(cuò)誤27：魯莽編碼沒有足夠的需求基礎(chǔ)和清晰的架構(gòu)設(shè)計(jì)而進(jìn)行“邊編碼邊修改”造成太多重復(fù)工作和返工，這樣的做法使項(xiàng)目大多以失敗告終產(chǎn) 品典型錯(cuò)誤28：需求的鍍金項(xiàng)目的產(chǎn)品要求要求比實(shí)際需求多得多的產(chǎn)品特性或復(fù)雜功能，卻又不給進(jìn)度計(jì)劃分配足夠的時(shí)間。典型錯(cuò)誤29：功能蔓延在整個(gè)開發(fā)過程中，項(xiàng)目平均會有25%的需求變更，對軟件計(jì)劃至少有25%的影響。如果任由客戶不斷提出新需求，項(xiàng)目就會一直都做不完典型錯(cuò)誤30：開發(fā)人員的鍍金開發(fā)人員著迷于新技術(shù)，有時(shí)渴望在自己的產(chǎn)品中使用這些技術(shù)，而不管那些技術(shù)是否適合或是

20、否會對系統(tǒng)整體造成破壞。典型錯(cuò)誤31：又推又拉的交易管理者批準(zhǔn)進(jìn)度落后的項(xiàng)目順延，但同時(shí)又給這個(gè)項(xiàng)目加入新任務(wù)。典型錯(cuò)誤32：研究導(dǎo)向的開發(fā)軟件開發(fā)進(jìn)度是完全有理由可以預(yù)測的，而軟件研究進(jìn)度甚至理論上都是不可預(yù)知的，不能采用像軟件研究一樣的工作方式引導(dǎo)項(xiàng)目開發(fā)。技 術(shù)典型錯(cuò)誤33：銀彈綜合癥過于相信某些技術(shù)宣傳（某種開發(fā)過程、某種程序設(shè)計(jì)方法、某種開發(fā)語言），缺少在特定環(huán)境下使用這些工具的必要信息。當(dāng)團(tuán)隊(duì)寄望利用他們來解決進(jìn)度問題時(shí)，不可避免會失敗的。典型錯(cuò)誤34：過高估計(jì)了新技術(shù)或方法帶來的節(jié)省量無論采用多少新工具或方法，以及這些工具或方法有多好，他們很少能夠大幅度提高生產(chǎn)率。軟件開發(fā)由多個(gè)

21、任務(wù)組成，特定的工具或方法只會可能提高特定任務(wù)的生產(chǎn)效率。同時(shí)，它們所帶來的效率常常被學(xué)習(xí)它們所花費(fèi)的時(shí)間抵消了。典型錯(cuò)誤35：項(xiàng)目中間切換工具在項(xiàng)目中間更換工具時(shí)，伴隨使用新工具而帶來的人員學(xué)習(xí)和掌握的過程、重復(fù)的工作、不可避免的錯(cuò)誤等會徹底抵消它所帶來的益處。典型錯(cuò)誤36：缺乏自動的源代碼控制手段缺乏自動的源代碼控制容易造成版本沖突、歷時(shí)版本丟失、更新丟失等一系列問題，并浪費(fèi)大量的時(shí)間處理這些問題。軟件開發(fā)基本原則（三） 基本原則“回顧一下被選為最佳項(xiàng)目的十個(gè)軟件項(xiàng)目，如果說有所發(fā)現(xiàn)的話，那就是最佳的項(xiàng)目一定是建立在最佳的軟件開發(fā)基礎(chǔ)之上的。我們都知道軟件開發(fā)基礎(chǔ)對于優(yōu)秀軟件的作用，但差別

22、在于大多數(shù)軟件的基礎(chǔ)薄弱，這樣不可避免地使自己陷入麻煩之中”（Bill Hetzel 1993）本章的范疇只限定在確定軟件開發(fā)的基本原則，解析他們是如何影響開發(fā)計(jì)劃的，同時(shí)提供參考信息。本章書把軟件開發(fā)基本原則實(shí)踐分為三類：管理實(shí)踐，技術(shù)實(shí)踐和質(zhì)量保證實(shí)踐。管理的基本原則管理原則由以下幾部分組成：判定產(chǎn)品規(guī)模（包括功能、復(fù)雜度和其它產(chǎn)品特性）根據(jù)產(chǎn)品規(guī)模分配資源制定資源計(jì)劃監(jiān)控、引導(dǎo)資源以保持項(xiàng)目方向不會偏離1. 項(xiàng)目估算和進(jìn)度安排一個(gè)運(yùn)行良好的項(xiàng)目一般通過三個(gè)基本步驟來定制軟件開發(fā)進(jìn)度表。首先估算項(xiàng)目規(guī)模大小然后估算完成這樣規(guī)模的項(xiàng)目需要付出的代價(jià)最后基于這種估算定制項(xiàng)目進(jìn)度計(jì)劃如果估算不準(zhǔn)

23、確就會降低開發(fā)效率，所以說估算和項(xiàng)目進(jìn)度計(jì)劃是軟件開發(fā)的基礎(chǔ)。精確的估算時(shí)進(jìn)行有效規(guī)劃的必要前提，而有效的規(guī)劃又是有效開發(fā)的必要條件。2. 計(jì)劃編制計(jì)劃一個(gè)軟件項(xiàng)目應(yīng)該包括以下活動：· 項(xiàng)目估算和時(shí)間進(jìn)度· 確定項(xiàng)目需要多少人參與、需要什么樣的技能、合適加入以及具體人選· 確定項(xiàng)目組的運(yùn)作方式· 確定項(xiàng)目采用的生命周期模型· 管理風(fēng)險(xiǎn)· 確定項(xiàng)目策略（例如：如何控制產(chǎn)品的特色，是否需要購買部分產(chǎn)品組建）3. 跟蹤跟蹤是一個(gè)基本的軟件管理行為。如果不跟蹤一個(gè)項(xiàng)目就不能管理它，就不會知道計(jì)劃是否被貫徹執(zhí)行了，也不會知道下一步該做什么，同時(shí)

24、也無法監(jiān)控項(xiàng)目風(fēng)險(xiǎn)。有效的跟蹤能使項(xiàng)目組在還有時(shí)間做點(diǎn)什么來改正錯(cuò)誤的時(shí)候，盡早發(fā)現(xiàn)進(jìn)度表上的問題。制定了一個(gè)項(xiàng)目計(jì)劃就要跟蹤檢查它是否在按計(jì)劃進(jìn)行，包括對它的進(jìn)度、費(fèi)用和質(zhì)量等目標(biāo)的檢查。典型的管理級跟蹤控制包括：任務(wù)列表、進(jìn)展?fàn)顩r會議、進(jìn)展報(bào)告、里程碑審查、預(yù)算報(bào)告以及走查管理等。典型的技術(shù)級跟蹤包括：技術(shù)審查、技術(shù)審計(jì)和標(biāo)志著里程碑是否完結(jié)的質(zhì)量關(guān)口等。圖 4.1.3-1 不同類型項(xiàng)目的可視度4. 量度老板問你：“我們能夠在9各月內(nèi)開發(fā)出這個(gè)產(chǎn)品嗎？”你怎么回答？！為了使開發(fā)更有效，你需要具備軟件量度方面的基本知識。你需要了解收集數(shù)據(jù)的尺度基準(zhǔn)，包括應(yīng)該要收集什么數(shù)據(jù)，如何獲得這些數(shù)據(jù)。

25、你還需要具備用來分析狀態(tài)，質(zhì)量和生產(chǎn)率的詳細(xì)基準(zhǔn)方面的知識。任何公司想要進(jìn)行快速的開發(fā)就要收集這些基本的尺度，這樣才可以知道他們的開發(fā)速度是否正在改善或后退。技術(shù)基本原則1984年有關(guān)“現(xiàn)代程序設(shè)計(jì)實(shí)踐方法技術(shù)的基本原則”的一份研究，詳細(xì)論述了不使用這些基本原則就不可能具有高的生產(chǎn)率的內(nèi)容。圖4.2-1展示了研究的結(jié)果。圖 4.2-1 生產(chǎn)率與“現(xiàn)代程序設(shè)計(jì)實(shí)踐方法”的關(guān)系（不廣泛地使用“現(xiàn)代程序設(shè)計(jì)實(shí)踐方法”就無法具有高的生產(chǎn)率）很顯然，不采用現(xiàn)代程序設(shè)計(jì)實(shí)踐方法的項(xiàng)目不可能具有高的生產(chǎn)率。但技術(shù)基本原則的應(yīng)用，就其本身而言，不足以創(chuàng)造高的生產(chǎn)率。一些項(xiàng)目使用了大量現(xiàn)代程序設(shè)計(jì)實(shí)踐方法，但是

26、仍舊和那些完全沒有使用該方法的項(xiàng)目具有一樣的生產(chǎn)率。因此，注意技術(shù)的基本原則是很必要的，但卻不足以達(dá)到快速開發(fā)的目的（例如犯了某些典型錯(cuò)誤）。1. 需求管理研究數(shù)據(jù)：典型項(xiàng)目平均會經(jīng)歷25%的需求變化，從而至少產(chǎn)生25%的額外費(fèi)用和時(shí)間。一項(xiàng)針對8000多個(gè)項(xiàng)目的調(diào)查顯示，導(dǎo)致項(xiàng)目推遲發(fā)布、超出預(yù)算、功能比預(yù)期減少的最重要的三個(gè)原因缺乏用戶的介入、不完善的需求分析和用戶不斷改變需求，都和需求管理有關(guān)。（Standish Group1994）一項(xiàng)軟件工程研究所的調(diào)查也有相同的結(jié)論：超過半數(shù)的項(xiàng)目都遭遇過不充分的需求管理的麻煩。（Kitson and Masters 1993）需求管理就是收集需求

27、，把需求記錄成文檔、電子郵件、用戶界面串連腳本、可實(shí)現(xiàn)的原型等形式，然后依此來跟蹤設(shè)計(jì)和編碼，并隨時(shí)管理、修改需求，以適應(yīng)項(xiàng)目后續(xù)的過程。成功的需求管理取決于了解足夠的不同的實(shí)踐經(jīng)驗(yàn)，以便能夠?yàn)樘囟?xiàng)目選擇可借鑒的一種。需求管理的基礎(chǔ)：需求分析方法：包括結(jié)構(gòu)分析、數(shù)據(jù)結(jié)構(gòu)分析和面向?qū)ο蠓治鱿到y(tǒng)建模實(shí)踐：如類圖表、數(shù)據(jù)流圖表、實(shí)體關(guān)系圖表、數(shù)據(jù)字典符號和狀態(tài)躍變圖表溝通實(shí)踐：如聯(lián)合應(yīng)用開發(fā)、用戶界面原型和常規(guī)會談實(shí)踐等需求管理和其它生命周期類型的關(guān)系：如漸進(jìn)原型、階段交付、螺旋模型、瀑布模型和編碼修正需求管理在兩個(gè)方面對開發(fā)速度發(fā)揮著巨大的調(diào)節(jié)作用：首先，正規(guī)的需求管理中，需求收集往往比其他軟件

28、開發(fā)活動完成得要從容些。如果能加快需求步伐而不傷害質(zhì)量，就可以縮短總的開發(fā)時(shí)間。第二，正確地把需求擺在首位，往往要比被動地這樣做所花的時(shí)間少得多。一些需求管理實(shí)踐基本原則能夠減少需求變化的數(shù)量，其他開發(fā)實(shí)踐的基本原則能夠減少因需求改變而產(chǎn)生的費(fèi)用。想象一下，如果把需求變化從25%減少到10%，同時(shí)把每個(gè)需求變化導(dǎo)致的費(fèi)用減少5%-10%，那么綜合的效果會怎樣呢？2. 設(shè)計(jì)研究數(shù)據(jù)：一個(gè)設(shè)計(jì)上的錯(cuò)誤如果到系統(tǒng)測試時(shí)才被發(fā)現(xiàn)，那么花費(fèi)的修補(bǔ)時(shí)間要比它在設(shè)計(jì)階段時(shí)被發(fā)現(xiàn)所花費(fèi)的時(shí)間多10倍。（Dunn 1984）設(shè)計(jì)是系統(tǒng)構(gòu)建、項(xiàng)目進(jìn)度計(jì)劃、項(xiàng)目跟蹤和項(xiàng)目控制的基礎(chǔ)。體系結(jié)構(gòu)和設(shè)計(jì)的基本原則：主要設(shè)

29、計(jì)風(fēng)格：如面向?qū)ο笤O(shè)計(jì)、結(jié)構(gòu)化設(shè)計(jì)和數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)基礎(chǔ)設(shè)計(jì)概念：如信息隱藏、模塊化、抽象、封裝、聚合、耦合、層次、繼承、多態(tài)、基本算法和基本數(shù)據(jù)結(jié)構(gòu)對典型挑戰(zhàn)性事件的標(biāo)準(zhǔn)設(shè)計(jì)：包括異常處理、國際化、本地化、便攜性、字串存儲、輸入輸出、內(nèi)存管理、數(shù)據(jù)存儲、浮點(diǎn)算法、數(shù)據(jù)庫設(shè)計(jì)、性能和復(fù)用對特殊領(lǐng)域應(yīng)用程序設(shè)計(jì)的獨(dú)有思考：例如財(cái)務(wù)應(yīng)用、科學(xué)應(yīng)用、嵌入式系統(tǒng)、實(shí)時(shí)系統(tǒng)、安全性要求高的軟件等架構(gòu)安排：如子系統(tǒng)組織、分層結(jié)構(gòu)、子系統(tǒng)通信方式和典型的系統(tǒng)架構(gòu)設(shè)計(jì)工具的使用3. 構(gòu)建當(dāng)構(gòu)建開始時(shí)，項(xiàng)目成功與否大多就已經(jīng)注定了。需求管理和設(shè)計(jì)對開發(fā)進(jìn)度計(jì)劃的調(diào)節(jié)作用比構(gòu)建的調(diào)節(jié)作用大得多，這意味著小的波動可以導(dǎo)

30、致進(jìn)度的重大變化。盡管構(gòu)建是一個(gè)低層次的活動，但是它確實(shí)可以提供許多機(jī)會進(jìn)一步改進(jìn)時(shí)間效率低的任務(wù)或優(yōu)化一些任務(wù)。例如，花時(shí)間對那些無需鍍金的功能進(jìn)行鍍金；調(diào)試那些無用的多余代碼，或者對那些并不知道是否需要優(yōu)化的片段盡心優(yōu)化。構(gòu)建的基本原則：· 編碼實(shí)踐：如變量和函數(shù)命名、版面布局和文檔· 數(shù)據(jù)相關(guān)概念：如作用范圍、持續(xù)和捆綁時(shí)間· 特定數(shù)據(jù)類型的使用方針：如通用基礎(chǔ)數(shù)據(jù)類型、枚舉、常量、數(shù)組和指針· 控制相關(guān)的概念：如組織整齊的代碼、條件的使用、循環(huán)的控制、復(fù)雜度的控制、特殊控制結(jié)構(gòu)的使用（goto、return、遞歸）· 斷言和其它以代碼為

31、核心的錯(cuò)誤檢測方法· 對例程、模塊、類和文件代碼打包的規(guī)則· 單元測試和調(diào)試實(shí)踐· 集成策略：如增量式集成、大爆炸式集成和漸進(jìn)開發(fā)· 代碼優(yōu)化策略和實(shí)踐· 與所使用的特定編程語言相關(guān)的其他事情· 使用構(gòu)建工具：如編譯環(huán)境、群組工作支持、源代碼控制、代碼庫和代碼生成器4.軟件配置管理軟件配置管理(SCM)是管理項(xiàng)目成果的一種實(shí)踐方法，能使項(xiàng)目在全程中保持一致的狀態(tài)。SCM包括評估變更、跟蹤變更、處理多版本，以及在不同時(shí)間保存項(xiàng)目成果的備份等實(shí)踐。質(zhì)量保證基本原則很多公司現(xiàn)階段開發(fā)軟件都有一定的不當(dāng)之處，使得他們的開發(fā)時(shí)間比需要的長。在調(diào)

32、查了4000個(gè)軟件項(xiàng)目后，Capers Jones遞交報(bào)告說，糟糕的質(zhì)量是進(jìn)度被拖延的最普遍的原因之一。他還說，中途被取消的項(xiàng)目中，大約有一半是由于其糟糕的質(zhì)量。（Jones 1994）一項(xiàng)軟件工程研究所的調(diào)查顯示，大約有60%的公司遭受著不適當(dāng)?shù)馁|(zhì)量保證體系的困擾。（Kitson and Masters 1993）。在過大的時(shí)間壓力下發(fā)布的產(chǎn)品，其錯(cuò)誤率是正常情況下的4倍。有進(jìn)度問題的項(xiàng)目經(jīng)常是在進(jìn)行艱苦的工作而不是輕松活躍的工作，關(guān)注質(zhì)量被認(rèn)為是有些奢侈。但其結(jié)果卻是項(xiàng)目進(jìn)展緩慢，并陷入更深的進(jìn)度問題中。（Jones 1994）重做有缺陷的需求、設(shè)計(jì)和編碼通常花費(fèi)整個(gè)軟件開發(fā)成本的40%5

33、0%。（Jones 1968b，Boehm 1987a）最糟糕的情況下，在運(yùn)行中的軟件項(xiàng)目只修改一次軟件需求問題的花費(fèi)通常是在需求分析階段所花時(shí)間的50到200倍。（Boehm and Papacio 1988）大約60%的錯(cuò)誤通常在設(shè)計(jì)階段就存在了。（Gilb 1988）如果可以盡早地預(yù)防并修正漏洞，可以節(jié)省大量時(shí)間，在進(jìn)度的安排上占了先機(jī)。圖 4.3-1 錯(cuò)誤率和開發(fā)時(shí)間的關(guān)系（大多數(shù)情況下，具有低錯(cuò)誤率的項(xiàng)目同時(shí)實(shí)現(xiàn)了最短日程的目標(biāo)）1. 易錯(cuò)模塊易錯(cuò)模塊是那些容易存在或多或少漏洞的模塊。研究數(shù)據(jù)：IBM的IMS項(xiàng)目中，57%的漏洞存在于7%的模塊中。（Jones 1991）程序中20%

34、的模塊包含了80%的錯(cuò)誤。（Boehm 1987b）高錯(cuò)誤率的模塊開發(fā)起來要比其它模塊更加昂貴和耗時(shí)，如果普通模塊開發(fā)每個(gè)功能點(diǎn)要花費(fèi)$500$1000，那么易錯(cuò)模塊每個(gè)功能點(diǎn)就要花費(fèi)$2000$4000。（Jones 1994）易錯(cuò)模塊往往比系統(tǒng)中的其它模塊更復(fù)雜，缺乏結(jié)構(gòu)化，或者不同尋常的龐大，并且往往在背負(fù)壓力下開發(fā)，往往沒有被完全測試過。對軟件開發(fā)特別重要的一個(gè)方面就是對易錯(cuò)模塊的質(zhì)量保證。2. 測試最尋常的質(zhì)量保證實(shí)踐就是毋庸置疑地進(jìn)行測試，兩種基本的測試方法· 單元測試：程序員檢查他自己的代碼是否工作正常· 系統(tǒng)測試：獨(dú)立測試員檢查整個(gè)系統(tǒng)是否如期望的那樣正常運(yùn)

35、行研究數(shù)據(jù)：測試的有效性差異是巨大的。單元測試可以找到程序中10%50%的漏洞；系統(tǒng)測試可以發(fā)現(xiàn)20%60%的程序漏洞。加在一起，累積的漏洞檢測率經(jīng)常少于60%。（Jones 1986a）剩下的錯(cuò)誤要么通過其它的查錯(cuò)技巧（如技術(shù)回顧）發(fā)現(xiàn)，要么就是在產(chǎn)品發(fā)布后被最終用戶發(fā)現(xiàn)。平衡測試和快速開發(fā)的最佳辦法是在壞消息出現(xiàn)之前做好計(jì)劃設(shè)置對壞消息的測試，盡早地發(fā)現(xiàn)問題。3. 技術(shù)回顧技術(shù)回顧包括在需求、設(shè)計(jì)、編碼和測試等事件中用于查錯(cuò)的所有類型的回顧。回顧在形式上和效果上是多樣的，它在開發(fā)速度上比在測試上扮演更重要的角色。下面講述最常見的幾種回顧。1) 走查走查是指任何兩個(gè)以上的開發(fā)人員以增進(jìn)軟件質(zhì)

36、量為目的所召開的回顧技術(shù)工作會議。走查可能是最平常的非正式回顧，走查可以在寫設(shè)計(jì)說明書時(shí)，設(shè)計(jì)和編碼完成之前就發(fā)現(xiàn)漏洞。研究數(shù)據(jù)：走查可以發(fā)現(xiàn)30%70%的程序漏洞。（Myers 1979，Boehm 1987b，Yourdon 1989b）2) 代碼閱讀代碼閱讀時(shí)比走查更正式些的回顧方式，但僅適用于代碼。代碼閱讀時(shí)，寫這段代碼的程序員把代碼清單交給兩個(gè)或更多的審閱者審閱，審閱者閱讀代碼，并把發(fā)現(xiàn)的錯(cuò)誤報(bào)告給編寫者。研究數(shù)據(jù)：NASA的軟件工程實(shí)驗(yàn)室的一項(xiàng)研究發(fā)現(xiàn)：代碼閱讀能發(fā)現(xiàn)的漏洞是測試時(shí)能發(fā)現(xiàn)的漏洞的兩倍。（Card 1987）3) 檢查檢查是一種正式的技術(shù)回顧，它被認(rèn)為是在整個(gè)項(xiàng)目中最

37、具效率的查錯(cuò)方式。使用檢查的方法，開發(fā)人員需要接受檢查的特殊訓(xùn)練，并且在檢查中扮演重要的角色。在檢查會議之前“仲裁人”發(fā)布產(chǎn)品要被檢驗(yàn)評估的消息和檢查列表，“審閱人”在會議前檢查程序，在檢查會議上“作者”通常要解釋要檢驗(yàn)的東西，“審閱人”鑒別錯(cuò)誤，“書記員”記錄錯(cuò)誤。在會后“仲裁人”寫一份報(bào)告說明每個(gè)漏洞和處理辦法。在項(xiàng)目中可以使用檢查對需求分析、用戶界面原型、設(shè)計(jì)、編碼及其他認(rèn)為的過程查錯(cuò)。研究數(shù)據(jù)：檢查可以查出程序中60%90%的漏洞，這點(diǎn)比走查或測試要好。因?yàn)榭梢栽陂_發(fā)的早期應(yīng)用，因此，檢查方法被證明可以節(jié)約10%30%的開發(fā)時(shí)間。（Gilb and Graham 1993）一項(xiàng)對大型程

38、序的調(diào)查結(jié)果顯示，在檢查上每花1小時(shí)，就可以避免在維護(hù)上33個(gè)小時(shí)的花費(fèi)。檢查比測試有效20倍以上。（Russel 1991）軟件開發(fā)基本原則（四） 風(fēng)險(xiǎn)管理1988年，Peat Marwick針對600家成功公司的調(diào)查結(jié)果顯示，35%的公司有過軟件項(xiàng)目失控的經(jīng)歷。（Rothfeder 1988）1982年，Allstate公司宣布其公司運(yùn)營全部要實(shí)行自動化。他們啟動了一個(gè)將耗時(shí)5年投資800萬美元的大型項(xiàng)目，而在花費(fèi)了6年和1500萬美元后，Allstate公司重新調(diào)整了目標(biāo)和最終期限，重新調(diào)整后的預(yù)算大約1億美元。1988年，Westpac Banking公司決定重新設(shè)計(jì)他們的信息系統(tǒng)。他

39、們做了5年、8500萬美元的計(jì)劃。3年后，在花費(fèi)了1.5億美元卻依然收效甚微時(shí)，Westpac Banking公司為了減少損失，取消了這個(gè)項(xiàng)目，并為此裁員500人。（Glass 1992）從項(xiàng)目管理的角度來看，有五大硬性知識領(lǐng)域：范圍管理、進(jìn)度管理、成本管理、質(zhì)量管理和風(fēng)險(xiǎn)管理。風(fēng)險(xiǎn)會出現(xiàn)在前面四個(gè)領(lǐng)域的各個(gè)過程中，只有有效地消除可能發(fā)生的危險(xiǎn)因素，才能確保項(xiàng)目順利推進(jìn)。項(xiàng)目的風(fēng)險(xiǎn)貫穿于整個(gè)項(xiàng)目過程，因此整個(gè)項(xiàng)目的生命周期都應(yīng)該堅(jiān)持有效的風(fēng)險(xiǎn)管理。根據(jù)風(fēng)險(xiǎn)的內(nèi)容，可以把風(fēng)險(xiǎn)歸為以下幾類：· 產(chǎn)品規(guī)模風(fēng)險(xiǎn)：與軟件的總體規(guī)模相關(guān)的風(fēng)險(xiǎn)· 商業(yè)影響風(fēng)險(xiǎn)：商業(yè)風(fēng)險(xiǎn)影響到軟件開發(fā)的生

40、存能力· 客戶特性風(fēng)險(xiǎn)：與客戶的素質(zhì)以及開發(fā)者和客戶溝通能力相關(guān)的風(fēng)險(xiǎn)· 過程定義風(fēng)險(xiǎn)：與軟件過程定義相關(guān)的風(fēng)險(xiǎn)· 開發(fā)環(huán)境風(fēng)險(xiǎn)：與開發(fā)工具的可用性及質(zhì)量相關(guān)的風(fēng)險(xiǎn)· 技術(shù)風(fēng)險(xiǎn)：技術(shù)風(fēng)險(xiǎn)是指在設(shè)計(jì)、實(shí)現(xiàn)、接口、驗(yàn)證、維護(hù)、規(guī)約的二義性、技術(shù)的不確定性、陳舊的技術(shù)等方面存在的風(fēng)險(xiǎn)· 人員數(shù)目及經(jīng)驗(yàn)帶來的風(fēng)險(xiǎn)：與參與工作的軟件工程師的總體技術(shù)水平及項(xiàng)目經(jīng)驗(yàn)相關(guān)的風(fēng)險(xiǎn)軟件項(xiàng)目的風(fēng)險(xiǎn)主要體現(xiàn)在四個(gè)方面：需求、技術(shù)、成本、進(jìn)度。風(fēng)險(xiǎn)管理是一個(gè)相當(dāng)重要的話題，但涉及的問題太多，很難在本章中全部囊括，本章主要講述進(jìn)度相關(guān)的風(fēng)險(xiǎn)管理。風(fēng)險(xiǎn)管理要素軟件風(fēng)險(xiǎn)管理就

41、是在風(fēng)險(xiǎn)成為影響軟件項(xiàng)目成功的威脅之前，識別、處理并消除風(fēng)險(xiǎn)。可以在幾個(gè)層次上定位風(fēng)險(xiǎn)管理：1、危機(jī)管理 救火模式，即在風(fēng)險(xiǎn)已經(jīng)造成麻煩后才著手處理它們2、失敗處理 覺察到了風(fēng)險(xiǎn)并迅速做出反應(yīng)，但只是在風(fēng)險(xiǎn)發(fā)生之后3、風(fēng)險(xiǎn)環(huán)節(jié) 事先制定好風(fēng)險(xiǎn)發(fā)生后的補(bǔ)救措施，但不做任何防范措施4、著力預(yù)防 將風(fēng)險(xiǎn)識別與風(fēng)險(xiǎn)防范作為軟件項(xiàng)目的一部分加以規(guī)劃和執(zhí)行5、消滅根源 識別和消除可能發(fā)生的風(fēng)險(xiǎn)的根源本章描述如何定位第4、5個(gè)層面上的進(jìn)度風(fēng)險(xiǎn)管理。總體來講，風(fēng)險(xiǎn)管理由風(fēng)險(xiǎn)評估和風(fēng)險(xiǎn)控制組成：圖 5.1-1 風(fēng)險(xiǎn)管理由風(fēng)險(xiǎn)評估和風(fēng)險(xiǎn)控制組成1. 風(fēng)險(xiǎn)評估· 風(fēng)險(xiǎn)識別：建立一個(gè)潛在破壞項(xiàng)目進(jìn)度的風(fēng)險(xiǎn)列

42、表· 風(fēng)險(xiǎn)分析：評估每一個(gè)風(fēng)險(xiǎn)出現(xiàn)可能性及其影響，判定風(fēng)險(xiǎn)的級別· 風(fēng)險(xiǎn)優(yōu)先級：按風(fēng)險(xiǎn)影響大小排出一個(gè)風(fēng)險(xiǎn)優(yōu)先級列表，這個(gè)列表將作為風(fēng)險(xiǎn)控制的基礎(chǔ)2. 風(fēng)險(xiǎn)控制· 風(fēng)險(xiǎn)管理計(jì)劃：定制一個(gè)應(yīng)對每個(gè)重要風(fēng)險(xiǎn)的方案，同時(shí)應(yīng)確保每一個(gè)單獨(dú)的風(fēng)險(xiǎn)管理計(jì)劃相互之間以及與項(xiàng)目計(jì)劃之間保持一致· 風(fēng)險(xiǎn)化解：執(zhí)行每一個(gè)重要風(fēng)險(xiǎn)所對應(yīng)管理計(jì)劃· 風(fēng)險(xiǎn)監(jiān)控：對解決風(fēng)險(xiǎn)的過程進(jìn)行監(jiān)控。還包括：識別新的風(fēng)險(xiǎn)，并將其加入到正在進(jìn)行的風(fēng)險(xiǎn)管理進(jìn)程；在風(fēng)險(xiǎn)列表中移除已經(jīng)化解的風(fēng)險(xiǎn)等工作風(fēng)險(xiǎn)識別1. 最常見的進(jìn)度計(jì)劃風(fēng)險(xiǎn)· 功能蔓延· 需求鍍金或開發(fā)人員鍍金

43、· 質(zhì)量不穩(wěn)定· 計(jì)劃過于樂觀· 設(shè)計(jì)欠佳· 銀彈綜合癥· 研究導(dǎo)向的開發(fā)· 人員薄弱· 承包人導(dǎo)致的失敗· 開發(fā)人員與客戶之間發(fā)生摩擦2. 進(jìn)度計(jì)劃風(fēng)險(xiǎn)列表下面列出了詳盡的可能對軟件進(jìn)度有負(fù)面影響的潛在風(fēng)險(xiǎn)。除了這里所列出的風(fēng)險(xiǎn)，大多數(shù)項(xiàng)目都有其特定的風(fēng)險(xiǎn)，如：“Joe要退出項(xiàng)目組，除非可以允許他帶自己的小狗來上班，而管理層還沒有決定是否同意他這樣做” 這樣的風(fēng)險(xiǎn)就要靠自己識別了！潛在的進(jìn)度計(jì)劃風(fēng)險(xiǎn)： （資料來源：Gilb 1988、Boehm 1989 Pressman 1993、Thomsett 1993、J

44、ones 1994）類 型風(fēng) 險(xiǎn)1、計(jì)劃編制1) 計(jì)劃、資源和產(chǎn)品定義全憑客戶或上層領(lǐng)導(dǎo)口頭指令，而且不完全一致2) 計(jì)劃是優(yōu)化的，是“最佳狀態(tài)”（但不現(xiàn)實(shí)，只能算是“期望狀態(tài)”）3) 計(jì)劃忽略了必要的任務(wù)4) 計(jì)劃基于使用特定的小組成員，而那個(gè)小組成員其實(shí)指望不上5) 在限定時(shí)間內(nèi)無法建成已定規(guī)模大小的產(chǎn)品6) 產(chǎn)品規(guī)模比估計(jì)的要打（代碼行數(shù)、功能點(diǎn)或與前一產(chǎn)品規(guī)模的百分比）7) 工作量大于估計(jì)數(shù)（代碼行數(shù)、功能點(diǎn)、模塊等）8) 進(jìn)度已經(jīng)拖延的項(xiàng)目在重新評估時(shí)過于優(yōu)化或忽略項(xiàng)目歷史9) 過度的進(jìn)度壓力造成生產(chǎn)力下降10) 目標(biāo)日期提前，但沒有相應(yīng)地調(diào)整產(chǎn)品范圍或可用資源11) 一個(gè)任務(wù)的延時(shí)

45、導(dǎo)致相關(guān)任務(wù)的連鎖反應(yīng)12) 涉足不熟識的產(chǎn)品領(lǐng)域，花費(fèi)在設(shè)計(jì)和實(shí)現(xiàn)上的時(shí)間比預(yù)期要多2、組織和管理1) 項(xiàng)目缺乏一個(gè)用凝聚力的最高領(lǐng)導(dǎo)人2) 由于前期乏力，項(xiàng)目長時(shí)間被擱置3) 解雇和削減開支導(dǎo)致項(xiàng)目小組能力下降4) 僅由管理層或市場人員進(jìn)行技術(shù)決策，導(dǎo)致計(jì)劃進(jìn)度延長5) 低效的項(xiàng)目組織結(jié)構(gòu)降低生產(chǎn)率6) 管理層審查或決策的周期比預(yù)期的時(shí)間長7) 預(yù)算削減打亂項(xiàng)目計(jì)劃8) 管理層作出了打擊項(xiàng)目組積極性的決定9) 非技術(shù)的第三方的工作比預(yù)期延長（預(yù)算批準(zhǔn)、設(shè)備采購、法律審查等）10) 計(jì)劃性太差，無法達(dá)到期望的開發(fā)速度11) 項(xiàng)目計(jì)劃由于壓力而放棄，導(dǎo)致開發(fā)混亂低效12) 管理層強(qiáng)調(diào)英雄主義而

46、忽略客觀確切的狀態(tài)報(bào)告，錯(cuò)過發(fā)現(xiàn)和改正問題的機(jī)會3、開發(fā)環(huán)境1) 設(shè)施沒有及時(shí)到位2) 設(shè)施到位但不配套3) 設(shè)施擁擠、雜亂或破損4) 開發(fā)工具沒能及時(shí)到位5) 開發(fā)工具不如期望的那樣有效6) 開發(fā)工具的選擇不是基于技術(shù)需求，不能提供計(jì)劃要求的性能7) 開發(fā)人員需要長時(shí)間創(chuàng)建工作環(huán)境或切換新開發(fā)工具8) 新開發(fā)工具的學(xué)習(xí)周期比預(yù)期的長，內(nèi)容繁多4、最終用戶1) 最終用戶堅(jiān)持新的需求2) 最終用戶對于最后交付的產(chǎn)品不滿意，要求重新設(shè)計(jì)或重做3) 最終用戶不買進(jìn)項(xiàng)目產(chǎn)品，無法提供后續(xù)支持4) 最終用戶的意見未被采納，造成產(chǎn)品無法滿足最終用戶的期望而必須重做5、客戶1) 客戶堅(jiān)持新的需求2) 客戶對

47、規(guī)則、原型和規(guī)格的審核和決策周期比預(yù)期的長3) 客戶沒有或不能參與規(guī)劃和原型審查工作，導(dǎo)致需求不穩(wěn)定和耗時(shí)的變更4) 客戶溝通或答復(fù)的時(shí)間比預(yù)期長5) 客戶堅(jiān)持技術(shù)決策而導(dǎo)致進(jìn)度計(jì)劃延長6) 客戶對開發(fā)進(jìn)度管理過細(xì)，導(dǎo)致實(shí)際進(jìn)展緩慢7) 客戶提供的組件無法與開發(fā)的產(chǎn)品匹配，導(dǎo)致額外的設(shè)計(jì)和集成工作8) 客戶提供的組件質(zhì)量欠佳，導(dǎo)致額外的設(shè)計(jì)、測試、集成和客戶關(guān)系管理工作9) 客戶要求的支持工具和環(huán)境不兼容、性能差或功能不完善，導(dǎo)致生產(chǎn)率降低10) 客戶不接受交付的軟件，盡管它滿足合同的條款要求11) 客戶期望的開發(fā)速度無法達(dá)到6、承包商1) 承包商沒有按承諾交付組件2) 承包商遞交的組件質(zhì)量低

48、下無法滿足要求，必須再花時(shí)間改進(jìn)3) 承包商沒有買進(jìn)項(xiàng)目開發(fā)需要的工具，進(jìn)而無法提供需要的性能水平7、需求1) 需求已經(jīng)成為項(xiàng)目的基準(zhǔn)，但變化仍在繼續(xù)2) 需求定義欠佳，但進(jìn)一步的定義會擴(kuò)展項(xiàng)目的范疇3) 添加額外的需求4) 需求定義含糊的部分需要的處理時(shí)間比預(yù)期多8、產(chǎn)品1) 錯(cuò)誤發(fā)生率高的模塊需要比預(yù)期更多的設(shè)計(jì)、實(shí)現(xiàn)和測試工作2) 校正質(zhì)量低下的產(chǎn)品需要比預(yù)期更多的設(shè)計(jì)、實(shí)現(xiàn)和測試工作3) 在一個(gè)或多個(gè)新興領(lǐng)域推過產(chǎn)品技術(shù)使得進(jìn)度延長或不可預(yù)期4) 由于軟件的功能錯(cuò)誤使得需要重新設(shè)計(jì)和實(shí)現(xiàn)5) 開發(fā)額外不需要的功能（鍍金）延長了計(jì)劃進(jìn)度6) 要滿足產(chǎn)品規(guī)模的要求，需要比預(yù)期長的時(shí)間，包括

49、重新計(jì)劃、設(shè)計(jì)和實(shí)現(xiàn)7) 嚴(yán)格要求與原有系統(tǒng)兼容，需要進(jìn)行比預(yù)期更多的計(jì)劃、設(shè)計(jì)、實(shí)現(xiàn)和測試8) 要與不受項(xiàng)目組控制的其他系統(tǒng)集成，導(dǎo)致無法預(yù)料的設(shè)計(jì)、實(shí)現(xiàn)和測試工作9) 要求在不同操作系統(tǒng)或軟硬件環(huán)境下運(yùn)行將花費(fèi)比預(yù)期更長的時(shí)間10) 在不熟識或未經(jīng)檢驗(yàn)的軟件環(huán)境中運(yùn)行，產(chǎn)生未預(yù)料到的問題11) 在不熟識或未經(jīng)檢驗(yàn)的硬件環(huán)境中運(yùn)行，產(chǎn)生未預(yù)料到的問題12) 開發(fā)一些全新的功能模塊比預(yù)期花費(fèi)更長時(shí)間13) 依賴未成熟的技術(shù)，使得進(jìn)度延長或不可預(yù)期9、外部環(huán)境1) 產(chǎn)品依賴政府的政策或制度，而政策或制度不可預(yù)期2) 產(chǎn)品依賴草擬中的技術(shù)標(biāo)準(zhǔn)，而最后的標(biāo)準(zhǔn)不可預(yù)期10、人員1) 招聘人員所花時(shí)間比

50、預(yù)期長2) 培訓(xùn)、工作許可證或其他項(xiàng)目的收尾等作為先決條件的任務(wù)不能按時(shí)完成3) 開發(fā)人員和管理層之間關(guān)系不佳導(dǎo)致決策緩慢影響進(jìn)度4) 項(xiàng)目組成員沒有全身心投入項(xiàng)目，進(jìn)而無法達(dá)到要求的產(chǎn)品質(zhì)量水平5) 缺乏激勵(lì)措施，士氣低下，降低生產(chǎn)力6) 缺乏必要的規(guī)范，增加了工作失誤幾率和重復(fù)工作7) 某些人需要更多時(shí)間適應(yīng)新的軟件工具和環(huán)境8) 某些人需要更多時(shí)間適應(yīng)新的硬件工具和環(huán)境9) 項(xiàng)目結(jié)束前，成員調(diào)離團(tuán)隊(duì)或離職10) 項(xiàng)目后期加入新開發(fā)人員，額外的培訓(xùn)和溝通降低現(xiàn)有成員的生產(chǎn)率11) 項(xiàng)目成員不能有效地一起工作12) 項(xiàng)目組成員間有沖突，導(dǎo)致溝通不暢、設(shè)計(jì)欠佳、接口錯(cuò)誤和額外的重復(fù)工作13)

51、有問題的成員沒有調(diào)離項(xiàng)目組，損害了其他成員的積極性14) 項(xiàng)目的最佳人選沒有加入項(xiàng)目組15) 項(xiàng)目的最佳人選已加入項(xiàng)目組，但因政治或其它原因未能合理使用16) 沒有找到項(xiàng)目急需的，具有特殊技能的人17) 關(guān)鍵人物只能兼職參與18) 項(xiàng)目人員不足19) 任務(wù)的分配與人員技能不匹配20) 人員工作的進(jìn)度比預(yù)期的慢21) 項(xiàng)目管理人員怠工導(dǎo)致計(jì)劃的進(jìn)度失效22) 技術(shù)人員怠工導(dǎo)致工作遺漏和質(zhì)量低下11、設(shè)計(jì)和實(shí)現(xiàn)1) 設(shè)計(jì)過于簡單，無法確定主要事件，并導(dǎo)致重新設(shè)計(jì)和實(shí)現(xiàn)2) 設(shè)計(jì)過于復(fù)雜，導(dǎo)致一些不必要的工作，影響實(shí)現(xiàn)效率3) 設(shè)計(jì)質(zhì)量低下，導(dǎo)致重復(fù)設(shè)計(jì)和實(shí)現(xiàn)4) 使用不熟識的方法和技術(shù)，導(dǎo)致額外的

52、培訓(xùn)時(shí)間5) 使用低級語言開發(fā)產(chǎn)品，導(dǎo)致生產(chǎn)率比預(yù)期低6) 一些必要的功能無法使用現(xiàn)有的代碼或庫實(shí)現(xiàn)，必須采用新庫或重新實(shí)現(xiàn)7) 代碼和庫質(zhì)量低下導(dǎo)致需要額外的測試、錯(cuò)誤修正或重做8) 過高估計(jì)了工具對計(jì)劃進(jìn)度的節(jié)省量9) 獨(dú)立開發(fā)的模塊無法有效集成，需要重新設(shè)計(jì)或重做12、過程1) 大量的書面工作導(dǎo)致進(jìn)度比預(yù)期慢2) 進(jìn)度跟蹤不準(zhǔn)確，導(dǎo)致無法預(yù)知項(xiàng)目是否已落后于計(jì)劃進(jìn)度3) 前期的質(zhì)量保證行為不真實(shí)，導(dǎo)致后期重復(fù)工作4) 質(zhì)量跟蹤不準(zhǔn)確，導(dǎo)致無法得知影響進(jìn)度的質(zhì)量問題5) 不夠正規(guī)（缺乏對軟件開發(fā)標(biāo)準(zhǔn)和策略的遵循），導(dǎo)致溝通不足和質(zhì)量問題6) 過于正規(guī)（教條地遵循軟件開發(fā)標(biāo)準(zhǔn)和策略），導(dǎo)致過

53、多耗時(shí)于無用的工作7) 向管理層撰寫進(jìn)度報(bào)告占用開發(fā)人員的時(shí)間比預(yù)期多8) 風(fēng)險(xiǎn)管理不夠重視，導(dǎo)致沒有發(fā)現(xiàn)重大的項(xiàng)目風(fēng)險(xiǎn)9) 軟件項(xiàng)目風(fēng)險(xiǎn)管理花費(fèi)的時(shí)間比預(yù)期多風(fēng)險(xiǎn)分析1. 風(fēng)險(xiǎn)暴露量一種很有用的風(fēng)險(xiǎn)分析方法就是風(fēng)險(xiǎn)暴露量。風(fēng)險(xiǎn)暴露量就是風(fēng)險(xiǎn)發(fā)生的概率乘以損失的程度。舉例來說：如果你認(rèn)為“完成需求分析比原計(jì)劃延長4周的概率是30%”，那么風(fēng)險(xiǎn)暴露量就是4周*30%=1.2周。風(fēng) 險(xiǎn)發(fā)生概率損失程度（周）風(fēng)險(xiǎn)暴露量（周）計(jì)劃過于樂觀50%52.5由于要完全支持自動從主機(jī)更新數(shù)據(jù)而造成的額外需求5%201.0由于市場變化而增加額外的功能35%82.8圖形格式子系統(tǒng)接口不穩(wěn)定25%41.0設(shè)計(jì)欠佳需

54、要重新設(shè)計(jì)15%152.25項(xiàng)目審批超過預(yù)計(jì)時(shí)間25%41.0設(shè)施未能及時(shí)到位10%20.2為管理層撰寫進(jìn)程報(bào)告占用開發(fā)人員的時(shí)間比預(yù)期的多10%10.1承包商的圖形格式子系統(tǒng)推遲交付1020%40.40.8新的編程工具沒有節(jié)省預(yù)期的時(shí)間30%51.5表 5.3.1-1 風(fēng)險(xiǎn)暴露量1) 評估損失程度損失程度常常比發(fā)生概率更容易估算，在表5.3.1-1中，完全可能很精確地估計(jì)出由于增加“完全支持自動從主機(jī)更新數(shù)據(jù)”而增加的研發(fā)時(shí)間是20個(gè)月。如果有時(shí)損失程度不容易直接估算出來，還可以把損失分解為更小的部分分別進(jìn)行估算，之后將各個(gè)小的獨(dú)立評估結(jié)果累加得出合計(jì)估算值。2) 評估發(fā)生概率估算發(fā)生概率比

55、估算損失程度更具主觀性。有許多實(shí)踐方法可以提高主觀評估的精確度，例如：由最熟識系統(tǒng)的人評估每個(gè)風(fēng)險(xiǎn)的發(fā)生概率，然后保留一份風(fēng)險(xiǎn)評估審核文件每個(gè)人對風(fēng)險(xiǎn)進(jìn)行獨(dú)立評估，然后討論評估的合理性，直到達(dá)成共識使用“形容詞標(biāo)準(zhǔn)”，如非?？赡?、很可能、可能、或許、不大可能和不可能等，然后把口頭評估轉(zhuǎn)換成量化的評估2. 項(xiàng)目的延期和緩沖由于我們只談?wù)撨M(jìn)度風(fēng)險(xiǎn)，所以可以累加所有的風(fēng)險(xiǎn)暴露量來得到項(xiàng)目總風(fēng)險(xiǎn)暴露量。這個(gè)項(xiàng)目的總風(fēng)險(xiǎn)暴露量為12.813.2周，這意味著，如果不做任何風(fēng)險(xiǎn)管理的話計(jì)劃可能要延期12.813.2周。如果例子中的項(xiàng)目歷時(shí)25周，那么超出預(yù)計(jì)值12.813.2周就很顯然要進(jìn)行風(fēng)險(xiǎn)管理了。風(fēng)險(xiǎn)

56、優(yōu)先級項(xiàng)目通?；ㄙM(fèi)80%的金錢解決20%的問題，所以風(fēng)險(xiǎn)管理的重點(diǎn)是關(guān)注那最重要的20%的部分。（Boehm 1989）如果只關(guān)注進(jìn)度計(jì)劃風(fēng)險(xiǎn)而不是關(guān)注所有的風(fēng)險(xiǎn)，確定風(fēng)險(xiǎn)優(yōu)先級的工作就變得比較容易了。在風(fēng)險(xiǎn)評估表中按風(fēng)險(xiǎn)暴露量從大到小排序看看會得到什么結(jié)果：序 號風(fēng) 險(xiǎn)發(fā)生概率損失程度（周）風(fēng)險(xiǎn)暴露量（周）1由于市場變化而增加額外的功能35%82.82計(jì)劃過于樂觀50%52.53設(shè)計(jì)欠佳需要重新設(shè)計(jì)15%152.254新的編程工具沒有節(jié)省預(yù)期的時(shí)間30%51.55圖形格式子系統(tǒng)接口不穩(wěn)定25%41.06由于要完全支持自動從主機(jī)更新數(shù)據(jù)而造成的額外需求5%201.07項(xiàng)目審批超過預(yù)計(jì)時(shí)間25%41.08承包商的圖形格式子系統(tǒng)推遲交付1020%40.40.89設(shè)施未能及時(shí)到位10%20.210為管理層撰寫進(jìn)程報(bào)告占用開發(fā)人員的時(shí)間比預(yù)期的多10%10.1表 5.4-1 排序后的風(fēng)險(xiǎn)暴露量排序后的風(fēng)險(xiǎn)評估表實(shí)際上就形成了一個(gè)粗略