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

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

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

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

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

5、撐可能的最佳進度計劃。圖2.1-3 僅僅依賴面向進度的實踐不足以支撐最佳進度計劃2.2軟件開發(fā)的四維每個軟件項目都有四個重要的維：?人員：完成任務(wù)要么快，要么慢? 過程：優(yōu)化人員的工作效率，或者浪費人員的時間?產(chǎn)品：以自我完善的形式定義，或者阻礙人員達到最好效果的形式定義?技術(shù)：促進或者阻礙開發(fā)的實現(xiàn)技咸圖2.2-1開發(fā)速度的四維2.2.1 人員-眞有衣罔譚段烏廣圧扯盟巧人的生產(chǎn)玫車£昇雄逆10娃有同F(xiàn)蝕益為人吟蟲戶戒車晝岸&10 : 1応宙內(nèi)翼奇不同怏檢竹十如的望廣效卓基辛在$ : 1范團會？*臭冇相脫徑戲罰訂也的t/就卓£畀A25 ： 1 內(nèi).研究數(shù)據(jù)：人件極大

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

7、同項目和不同人員。 人員激勵是達成快速開發(fā)的最具潛力方法2.2.2 過程研究數(shù)據(jù)：HughesAircraft 、Lockheed、Motorola、NASA Raytheon 和 Xerox 等組織通過對開發(fā)過程的改 進將產(chǎn)品上市時間縮短了一半，降低成本、減少錯誤為原來的1/31/10。過程是指軟件開發(fā)生命周期中定義的一系列工作流程和活動的集合?？梢愿爬橐韵氯悾夯具^程：包括獲取過程、供應(yīng)過程、開發(fā)過程、運作過程、維護過程和管理過程 ? 支持過程：包括文檔過程、配置管理過程、質(zhì)量保證過程、驗證過程、確認過程、聯(lián)合評審過程、 審計過程以及問題解決過程? 組織過程：包括基礎(chǔ)設(shè)施過程、改進過程

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

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

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

11、 H烈卅皿純圖面向開發(fā)工具的設(shè)計模型空歳聃權(quán)為整証打耐厚布Jfe葫佛NTE4JT乍亍菲到ifdtTTfc；>ftW!«l«)祚ftPm鼻&仝斛卄“-知上iWVT%H4UK1KJM打£h打A"妝丹切疲底妁就E$爐,禺?t卄M耳劉 -wzxH*jIf畫良心黑*W_科呵C1豊*tJUi存柚X吊疔婕KaRUflL»!ldt護懺*rAh巾上盤史金t*好割I(lǐng)P.ZI-it內(nèi)黒廳常附門“尸cp?老X悄覘甲«nHt£伏占叫總吋 詵蜀瞥匱7TM - « mrsmt«髯業(yè)旳肯豐幻卅if芝護千舉到-譽箱橫仝ft老

12、兗何Kklif RZA 敕n葉用巧靜甘M希羸至H » MirjsM酣于即割ir,*r*.；M* kkt.r*.* i in 峙N*C* ! 9M tr-M匕或仝旳命q沖耒撫尸十一初*<bl:+« 甘上次“干孑盟殲工屈"總*芾世"鷹;1 恫予:耳協(xié)冊irfri ftK/A初時l>Or > 蚪燈之沖卜1 ”1"段z純WA點舊ill科Iftf1抵雷用亡曲-flftfti 11科呻wIftr1車址b WTfrf If 詡申F盅輯1fr-rij|If第NtrirITwtrnT'R7、面向客戶開發(fā)誰是客戶？對客戶的理解取決于場合，

13、可能是項目委托人，最終用戶，市場人員或者老板?，F(xiàn)代軟件開發(fā)非常關(guān)注客戶的需求與期望，開發(fā)岀合符產(chǎn)品規(guī)格的軟件只是完成了一半工作，另一半是幫助客戶配置岀產(chǎn)品能夠?qū)崿F(xiàn)的功能，而實現(xiàn)這些功能所花費的時間通常遠遠多于確定紙面上 的產(chǎn)品規(guī)格所需要的時間。將自己站在客戶的角度考慮問題是避免大量返工的最好方法。同時應(yīng)該建立有效的客戶溝通渠 道，合理控制客戶的期望值。223產(chǎn)品在軟件開發(fā)的四維中，最切實的維是產(chǎn)品維。對產(chǎn)品規(guī)模和產(chǎn)品特性的關(guān)注，意味著巨大的縮短 計劃進度的機會。削減了產(chǎn)品功能通常就可以縮短產(chǎn)品開發(fā)周期1、產(chǎn)品規(guī)模產(chǎn)品規(guī)模是對開發(fā)進度影響最大的一個因素。構(gòu)建軟件所需的工作量的增長比產(chǎn)品規(guī)模的增長

14、要快得多，并且增長是不成比例的，所以產(chǎn)品規(guī)模的縮小將大大提高開發(fā)速度。將中等規(guī)模的軟件削減 一半通常可以使工作負荷削減2/3。2、產(chǎn)品特性產(chǎn)品的一些非功能性需求或額外關(guān)注點會影響設(shè)計的復(fù)雜度和構(gòu)建的工作量，如對性能、穩(wěn)定性、可維護性和可擴展性等要求很高的產(chǎn)品比沒有這些特性要求的產(chǎn)品需要更長的開發(fā)周期。技術(shù)從使用低效的工具轉(zhuǎn)為使用高效的工具是提高開發(fā)速度的快捷方法。選擇有效的工具并管理好由此帶來的風(fēng)險也是提高開發(fā)速度的方法。大多數(shù)典型錯誤其表面都具有誘惑性，給人們一種誘人的前景，但通常卻不能產(chǎn)生期望的結(jié)果?！跋胪炀冗M度已經(jīng)落后的項目嗎？ 給項目補充更多人員！”下面分別按照人員、過程、產(chǎn)品和技術(shù)四

15、個維度列出36個典型錯誤。人員典型錯誤 1：挫傷積極性 對人員不夠關(guān)心和重視；過度的進度壓力；缺乏激勵；過分夸張的激勵等。典型錯誤 2：人員素質(zhì)低人員能力欠佳，工作效率低，甚至做多錯多。典型錯誤 3：對有問題的員工失控 不對有問題的人員采取措施是項目組成員對領(lǐng)導(dǎo)最常見的抱怨。典型錯誤 4：英雄主義 強調(diào)個人英雄主義會導(dǎo)致發(fā)生額外的風(fēng)險，也會削弱在軟件開發(fā)過程中多個角色的合作。典型錯誤 5：項目后期加入人員盲目地在項目后期加入人手等于火上澆油。典型錯誤 6：辦公室環(huán)境擁擠嘈雜擁有安靜、隱蔽辦公環(huán)境的人員比工作在嘈雜、 擁擠環(huán)境中的人員往往會有更好的工作業(yè)績表現(xiàn)。 典型錯誤 7：開發(fā)人員與客戶之間

16、發(fā)生摩擦主要原因是缺乏溝通。這種摩擦耗費時間，它會轉(zhuǎn)移客戶和開發(fā)人員雙方對項目工作的注意力。 典型錯誤 8：不現(xiàn)實的預(yù)期過高的期望值和主觀的不切實際的設(shè)想。 是導(dǎo)致開發(fā)人員和客戶或項目經(jīng)理之間的摩擦常見原因 之一。典型錯誤 9：缺乏有效的項目支持軟件開發(fā)項目的許都方面都需要高層的支持， 包括實際的計劃、 變更控制以及新型開發(fā)方法的采用等。缺乏有效的高層支持事實上注定了項目的失敗。軟件開發(fā)中所有主要人員必須齊心協(xié)力專注于項目， 包括高層支持者、 項目領(lǐng)導(dǎo)、項目成員、 市 場人員、最終用戶、客戶和任何項目介入者。典型錯誤 11：缺乏用戶介入沒有用戶早期介入的項目充滿需求誤解的風(fēng)險，易受項目后期功能

17、蔓延的威脅。典型錯誤 12：政治高于物質(zhì)“政治家”型項目強調(diào)“管理至上”， 主要精力集中在他們與經(jīng)理的關(guān)系上。 將政治凌駕于結(jié)果 之上對軟件項目會造成極大傷害。典型錯誤 13：充滿想象閉上眼睛毫無理由地希望某事將像想象那樣運作。很多軟件開發(fā)問題都是由于充滿想象造成的。想象示例：項目組不知道他們能不能按時完成項目， 但他們認為如果每個人能更努力工作， 并且不出現(xiàn)問題， 他們應(yīng)該能完成項目。我們無需向客戶演示最新的修改，我們確信這個效果是客戶想要的。項目組錯過了一個里程碑好幾天了， 他們說會更努力工作趕上下一個里程碑， 我想他們能夠及時 趕上的。過程典型錯誤 14：過于樂觀的計劃定制過于樂觀的項目

18、計劃相當(dāng)于自己為項目失敗畫出了底線， 導(dǎo)致縮短分析、 設(shè)計等關(guān)鍵性前期 開發(fā)活動；同時也向開發(fā)人員施加了額外壓力，會長期對開發(fā)人員的自信心和生產(chǎn)率造成巨大傷害。典型錯誤 15：缺乏足夠的風(fēng)險管理如果你不主動管理風(fēng)險，風(fēng)險隨時會來找你，打亂你的開發(fā)計劃。典型錯誤 16：承包人導(dǎo)致的失敗如果不對承包商加以認真管理，交付可能延期，并且質(zhì)量難以保證。典型錯誤 17：缺乏計劃沒有計劃的項目就像飄蕩在海洋中的小船，沒人知道會飄到哪里。很多項目組定制了計劃，但遇到了麻煩時就放棄計劃。項目失敗的原因不是在于放棄計劃本身， 而是不能及時修訂計劃制定替代計劃，并一頭栽進編碼和問題處理中。典型錯誤 19：在模糊的項

19、目前期浪費時間 由于花在審批、預(yù)算等前期工作的時間過長，或需求無限循環(huán)等原因， 導(dǎo)致壓縮開發(fā)計劃。 項目 前期節(jié)省幾周或幾個月時間比將開發(fā)計劃壓縮同樣時間來得更容易、更廉價，風(fēng)險也更少。典型錯誤 20：前期活動不符合要求研究數(shù)據(jù)：前期被跳過的活動或工作通常在后期會以 10倍到 100倍的代價來完成。如果一項工作在項目初期 需要5小時完成，那么在項目后期你至少需要50小時才能完成它。( Fagan 1976 ， Boehm andPapaccio 1988 )典型錯誤 21：設(shè)計低劣前期活動不符合要求的一個特殊情況就是設(shè)計低劣。 高壓環(huán)境導(dǎo)致設(shè)計缺乏周密思考往往導(dǎo)致設(shè) 計低劣。典型錯誤 22：缺

20、少質(zhì)量保證措施研究數(shù)據(jù)：項目前期砍掉1天的質(zhì)量保證活動，到項目后期就需要 3到10天的處理代價。(Jones 1994 )典型錯誤 23：缺少管理控制缺少管理控制點就難以對項目的階段和狀態(tài)進行跟蹤，因此不能知道項目是否按正常軌道前進。典型錯誤 24：太早或過于頻繁的集成在構(gòu)建未完全鎖定時， 進行過早的集成或額外的集成不利于產(chǎn)品， 它僅僅是在浪費時間， 延長進 度。典型錯誤 25：項目估算時遺漏必要的任務(wù)訓(xùn)、公司和部門會議，技術(shù)評審會議等活動在項目估算時通常被遺漏。典型錯誤 26：追趕計劃當(dāng)進度落后時不重新檢查任務(wù)和調(diào)整計劃，而是簡單地決定把進度趕上來。另一種情況是，當(dāng)產(chǎn)品出現(xiàn)變更卻沒有做相應(yīng)的

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

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

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

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

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

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

27、得這些數(shù)據(jù)。你還需要具備用來分析狀態(tài)，質(zhì)量和生產(chǎn)率的詳細基準(zhǔn) 方面的知識。任何公司想要進行快速的開發(fā)就要收集這些基本的尺度，這樣才可以知道他們的開發(fā)速度是否正在改善或后退。技術(shù)基本原則1984年有關(guān)“現(xiàn)代程序設(shè)計實踐方法一一技術(shù)的基本原則”的一份研究，詳細論述了不使用這些基本原則就不可能具有高的生產(chǎn)率的內(nèi)容。圖4.2-1展示了研究的結(jié)果。 -ITV . - - -i - 一J-亠-j-j. 嚴一二 U-t3<«>I址1毀知心 MMO+如MOr0 I甲黠7-IWVr|ffiKT處，怕圖4.2-1生產(chǎn)率與“現(xiàn)代程序設(shè)計實踐方法”的關(guān)系(不廣泛地使用“現(xiàn)代程序設(shè)計實踐方法”就無

28、法具有高的生產(chǎn)率)很顯然，不采用現(xiàn)代程序設(shè)計實踐方法的項目不可能具有高的生產(chǎn)率。但技術(shù)基本原則的應(yīng)用， 就其本身而言，不足以創(chuàng)造高的生產(chǎn)率。一些項目使用了大量現(xiàn)代程序設(shè)計實踐方法，但是仍舊和那 些完全沒有使用該方法的項目具有一樣的生產(chǎn)率。因此，注意技術(shù)的基本原則是很必要的，但卻不足 以達到快速開發(fā)的目的(例如犯了某些典型錯誤) 。1. 需求管理研究數(shù)據(jù)：典型項目平均會經(jīng)歷25%勺需求變化，從而至少產(chǎn)生25%勺額外費用和時間。一項針對8000多個項目的調(diào)查顯示，導(dǎo)致項目推遲發(fā)布、超岀預(yù)算、功能比預(yù)期減少的最重要的 三個原因一一缺乏用戶的介入、不完善的需求分析和用戶不斷改變需求，都和需求管理有關(guān)。

29、(Standish Group1994 )一項軟件工程研究所的調(diào)查也有相同的結(jié)論：超過半數(shù)的項目都遭遇過不充分的需求管理的麻煩。(Kitson and Masters 1993)需求管理就是收集需求，把需求記錄成文檔、電子郵件、用戶界面串連腳本、可實現(xiàn)的原型等形式，然后依此來跟蹤設(shè)計和編碼，并隨時管理、修改需求，以適應(yīng)項目后續(xù)的過程。成功的需求管理取決于了解足夠的不同的實踐經(jīng)驗，以便能夠為特定項目選擇可借鑒的一種。需求管理的基礎(chǔ)：需求分析方法：包括結(jié)構(gòu)分析、數(shù)據(jù)結(jié)構(gòu)分析和面向?qū)ο蠓治鱿到y(tǒng)建模實踐：如類圖表、數(shù)據(jù)流圖表、實體關(guān)系圖表、數(shù)據(jù)字典符號和狀態(tài)躍變圖表溝通實踐：如聯(lián)合應(yīng)用開發(fā)、用戶界面原

30、型和常規(guī)會談實踐等需求管理和其它生命周期類型的關(guān)系：如漸進原型、階段交付、螺旋模型、瀑布模型和編碼修正需求管理在兩個方面對開發(fā)速度發(fā)揮著巨大的調(diào)節(jié)作用：首先，正規(guī)的需求管理中， 需求收集往往比其他軟件開發(fā)活動完成得要從容些。 如果能加快需求 步伐而不傷害質(zhì)量，就可以縮短總的開發(fā)時間。第二，正確地把需求擺在首位， 往往要比被動地這樣做所花的時間少得多。 一些需求管理實踐基 本原則能夠減少需求變化的數(shù)量，其他開發(fā)實踐的基本原則能夠減少因需求改變而產(chǎn)生的費用。想象一下， 如果把需求變化從 25%減少到 10%，同時把每個需求變化導(dǎo)致的費用減少 5%-10%，那么 綜合的效果會怎樣呢？2. 設(shè)計研究數(shù)

31、據(jù)：一個設(shè)計上的錯誤如果到系統(tǒng)測試時才被發(fā)現(xiàn)， 那么花費的修補時間要比它在設(shè)計階段時被發(fā)現(xiàn) 所花費的時間多10倍。(Dunn 1984)設(shè)計是系統(tǒng)構(gòu)建、項目進度計劃、項目跟蹤和項目控制的基礎(chǔ)。體系結(jié)構(gòu)和設(shè)計的基本原則：主要設(shè)計風(fēng)格：如面向?qū)ο笤O(shè)計、結(jié)構(gòu)化設(shè)計和數(shù)據(jù)結(jié)構(gòu)設(shè)計基礎(chǔ)設(shè)計概念：如信息隱藏、模塊化、抽象、封裝、聚合、耦合、層次、繼承、多態(tài)、基本算法 和基本數(shù)據(jù)結(jié)構(gòu)對典型挑戰(zhàn)性事件的標(biāo)準(zhǔn)設(shè)計： 包括異常處理、 國際化、本地化、便攜性、字串存儲、 輸入輸出、 內(nèi)存管理、數(shù)據(jù)存儲、浮點算法、數(shù)據(jù)庫設(shè)計、性能和復(fù)用對特殊領(lǐng)域應(yīng)用程序設(shè)計的獨有思考：例如財務(wù)應(yīng)用、科學(xué)應(yīng)用、嵌入式系統(tǒng)、實時系統(tǒng)、安

32、全 性要求高的軟件等架構(gòu)安排：如子系統(tǒng)組織、分層結(jié)構(gòu)、子系統(tǒng)通信方式和典型的系統(tǒng)架構(gòu)設(shè)計工具的使用3. 構(gòu)建當(dāng)構(gòu)建開始時， 項目成功與否大多就已經(jīng)注定了。 需求管理和設(shè)計對開發(fā)進度計劃的調(diào)節(jié)作用比 構(gòu)建的調(diào)節(jié)作用大得多，這意味著小的波動可以導(dǎo)致進度的重大變化。盡管構(gòu)建是一個低層次的活動， 但是它確實可以提供許多機會進一步改進時間效率低的任務(wù)或優(yōu) 化一些任務(wù)。例如，花時間對那些無需鍍金的功能進行鍍金；調(diào)試那些無用的多余代碼，或者對那些 并不知道是否需要優(yōu)化的片段盡心優(yōu)化。構(gòu)建的基本原則：? 編碼實踐：如變量和函數(shù)命名、版面布局和文檔? 數(shù)據(jù)相關(guān)概念：如作用范圍、持續(xù)和捆綁時間? 特定數(shù)據(jù)類型的使

33、用方針：如通用基礎(chǔ)數(shù)據(jù)類型、枚舉、常量、數(shù)組和指針? 控制相關(guān)的概念：如組織整齊的代碼、條件的使用、循環(huán)的控制、復(fù)雜度的控制、特殊控制結(jié)構(gòu) 的使用( goto 、 return 、遞歸)? 斷言和其它以代碼為核心的錯誤檢測方法? 對例程、模塊、類和文件代碼打包的規(guī)則單元測試和調(diào)試實踐 集成策略：如增量式集成、大爆炸式集成和漸進開發(fā) 代碼優(yōu)化策略和實踐與所使用的特定編程語言相關(guān)的其他事情 使用構(gòu)建工具：如編譯環(huán)境、群組工作支持、源代碼控制、代碼庫和代碼生成器4. 軟件配置管理軟件配置管理(SCM)是管理項目成果的一種實踐方法，能使項目在全程中保持一致的狀態(tài)。SCM包括評估變更、跟蹤變更、處理多版

34、本，以及在不同時間保存項目成果的備份等實踐。質(zhì)量保證基本原則很多公司現(xiàn)階段開發(fā)軟件都有一定的不當(dāng)之處， 使得他們的開發(fā)時間比需要的長。 在調(diào)查了 4000 個軟件項目后， Capers Jones 遞交報告說，糟糕的質(zhì)量是進度被拖延的最普遍的原因之一。他還說， 中途被取消的項目中，大約有一半是由于其糟糕的質(zhì)量。(Jones 1994)一項軟件工程研究所的調(diào)查顯示，大約有60%的公司遭受著不適當(dāng)?shù)馁|(zhì)量保證體系的困擾。(Kitson and Masters 1993 )。在過大的時間壓力下發(fā)布的產(chǎn)品，其錯誤率是正常情況下的4倍。有進度問題的項目經(jīng)常是在進行艱苦的工作而不是輕松活躍的工作，關(guān)注質(zhì)量被

35、認為是有些奢侈。但其結(jié)果卻是項目進展緩慢，并 陷入更深的進度問題中。 ( Jones 1994 )重做有缺陷的需求、設(shè)計和編碼通常花費整個軟件開發(fā)成本的40% 50%。 ( Jones 1968b ， Boehm1987a)最糟糕的情況下， 在運行中的軟件項目只修改一次軟件需求問題的花費通常是在需求分析階段所 花時間的 50到 200倍。 (Boehm and Papacio 1988 )大約60%的錯誤通常在設(shè)計階段就存在了。 (Gilb 1988 )如果可以盡早地預(yù)防并修正漏洞，可以節(jié)省大量時間，在進度的安排上占了先機圖4.3-1 錯誤率和開發(fā)時間的關(guān)系(大多數(shù)情況下，具有低錯誤率的項目同

36、時實現(xiàn)了最短日程的目標(biāo))1. 易錯模塊易錯模塊是那些容易存在或多或少漏洞的模塊。研究數(shù)據(jù)：IBM的IMS項目中，57%勺漏洞存在于7%勺模塊中。(Jones 1991)程序中20%勺模塊包含了 80%勺錯誤。(Boehm 1987b)高錯誤率的模塊開發(fā)起來要比其它模塊更加昂貴和耗時，如果普通模塊開發(fā)每個功能點要花費$500 $1000,那么易錯模塊每個功能點就要花費 $2000 $4000。(Jones 1994 )易錯模塊往往比系統(tǒng)中的其它模塊更復(fù)雜，缺乏結(jié)構(gòu)化，或者不同尋常的龐大，并且往往在背負 壓力下開發(fā)，往往沒有被完全測試過。對軟件開發(fā)特別重要的一個方面就是對易錯模塊的質(zhì)量保證。2.

37、測試最尋常的質(zhì)量保證實踐就是毋庸置疑地進行測試，兩種基本的測試方法? 單元測試：程序員檢查他自己的代碼是否工作正常? 系統(tǒng)測試：獨立測試員檢查整個系統(tǒng)是否如期望的那樣正常運行研究數(shù)據(jù)：測試的有效性差異是巨大的。單元測試可以找到程序中10%- 50%勺漏洞；系統(tǒng)測試可以發(fā)現(xiàn)20%-60%勺程序漏洞。加在一起，累積的漏洞檢測率經(jīng)常少于60% (Jones 1986a )剩下的錯誤要么通過其它的查錯技巧(如技術(shù)回顧)發(fā)現(xiàn)，要么就是在產(chǎn)品發(fā)布后被最終用戶發(fā) 現(xiàn)。平衡測試和快速開發(fā)的最佳辦法是在壞消息岀現(xiàn)之前做好計劃一一設(shè)置對壞消息的測試，盡早地發(fā)現(xiàn)問題。3. 技術(shù)回顧技術(shù)回顧包括在需求、 設(shè)計、 編碼

38、和測試等事件中用于查錯的所有類型的回顧。 回顧在形式上和 效果上是多樣的，它在開發(fā)速度上比在測試上扮演更重要的角色。下面講述最常見的幾種回顧。1) 走查走查是指任何兩個以上的開發(fā)人員以增進軟件質(zhì)量為目的所召開的回顧技術(shù)工作會議。 走查可能 是最平常的非正式回顧，走查可以在寫設(shè)計說明書時，設(shè)計和編碼完成之前就發(fā)現(xiàn)漏洞。研究數(shù)據(jù)：走查可以發(fā)現(xiàn) 30% 70%的程序漏洞。(Myers 1979 , Boehm 1987b, Yourdon 1989b)2) 代碼閱讀代碼閱讀時比走查更正式些的回顧方式, 但僅適用于代碼。 代碼閱讀時, 寫這段代碼的程序員把 代碼清單交給兩個或更多的審閱者審閱,審閱者閱

39、讀代碼,并把發(fā)現(xiàn)的錯誤報告給編寫者。研究數(shù)據(jù)：NASA勺軟件工程實驗室的一項研究發(fā)現(xiàn)：代碼閱讀能發(fā)現(xiàn)的漏洞是測試時能發(fā)現(xiàn)的漏洞的兩倍。( Card 1987 )3) 檢查檢查是一種正式的技術(shù)回顧,它被認為是在整個項目中最具效率的查錯方式。使用檢查的方法, 開發(fā)人員需要接受檢查的特殊訓(xùn)練, 并且在檢查中扮演重要的角色。 在檢查會議之前“仲裁人”發(fā)布 產(chǎn)品要被檢驗評估的消息和檢查列表, “審閱人”在會議前檢查程序, 在檢查會議上“作者”通常要 解釋要檢驗的東西,“審閱人”鑒別錯誤,“書記員”記錄錯誤。在會后“仲裁人”寫一份報告說明 每個漏洞和處理辦法。在項目中可以使用檢查對需求分析、用戶界面原型、

40、設(shè)計、編碼及其他認為的過程查錯。研究數(shù)據(jù)：檢查可以查出程序中 60%90%的漏洞, 這點比走查或測試要好。 因為可以在開發(fā)的早期應(yīng)用, 因 此，檢查方法被證明可以節(jié)約 10% 30%勺開發(fā)時間。(Gilb and Graham 1993 )一項對大型程序的調(diào)查結(jié)果顯示,在檢查上每花 1小時,就可以避免在維護上 33個小時的花費。檢查比測試有效 20倍以上。 (Russel 1991 )軟件開發(fā)基本原則(四) 風(fēng)險管理1988年， Peat Marwick 針對600家成功公司的調(diào)查結(jié)果顯示，35%的公司有過軟件項目失控的經(jīng)歷。( Rothfeder 1988 )1982年，Allstate 公

41、司宣布其公司運營全部要實行自動化。他們啟動了一個將耗時5年投資800萬美元的大型項目，而在花費了 6年和1 500萬美元后， Allstate 公司重新調(diào)整了目標(biāo)和最終期限，重 新調(diào)整后的預(yù)算大約 1億美元。1988年， Westpac Banking 公司決定重新設(shè)計他們的信息系統(tǒng)。他們做了 5年、 8500萬美元的計 劃。 3年后，在花費了 1.5 億美元卻依然收效甚微時， Westpac Banking 公司為了減少損失，取消了這 個項目，并為此裁員500人。(Glass 1992)從項目管理的角度來看，有五大硬性知識領(lǐng)域：范圍管理、進度管理、成本管理、質(zhì)量管理和風(fēng) 險管理。風(fēng)險會出現(xiàn)在

42、前面四個領(lǐng)域的各個過程中，只有有效地消除可能發(fā)生的危險因素，才能確保 項目順利推進。 項目的風(fēng)險貫穿于整個項目過程， 因此整個項目的生命周期都應(yīng)該堅持有效的風(fēng)險管 理。根據(jù)風(fēng)險的內(nèi)容，可以把風(fēng)險歸為以下幾類：? 產(chǎn)品規(guī)模風(fēng)險：與軟件的總體規(guī)模相關(guān)的風(fēng)險? 商業(yè)影響風(fēng)險：商業(yè)風(fēng)險影響到軟件開發(fā)的生存能力? 客戶特性風(fēng)險：與客戶的素質(zhì)以及開發(fā)者和客戶溝通能力相關(guān)的風(fēng)險? 過程定義風(fēng)險：與軟件過程定義相關(guān)的風(fēng)險? 開發(fā)環(huán)境風(fēng)險：與開發(fā)工具的可用性及質(zhì)量相關(guān)的風(fēng)險? 技術(shù)風(fēng)險：技術(shù)風(fēng)險是指在設(shè)計、實現(xiàn)、接口、驗證、維護、規(guī)約的二義性、技術(shù)的不確定性、 陳舊的技術(shù)等方面存在的風(fēng)險? 人員數(shù)目及經(jīng)驗帶來的

43、風(fēng)險：與參與工作的軟件工程師的總體技術(shù)水平及項目經(jīng)驗相關(guān)的風(fēng)險軟件項目的風(fēng)險主要體現(xiàn)在四個方面：需求、技術(shù)、成本、進度。風(fēng)險管理是一個相當(dāng)重要的話 題，但涉及的問題太多，很難在本章中全部囊括，本章主要講述進度相關(guān)的風(fēng)險管理。風(fēng)險管理要素軟件風(fēng)險管理就是在風(fēng)險成為影響軟件項目成功的威脅之前，識別、 處理并消除風(fēng)險。 可以在幾個層次上定位風(fēng)險管理：1 、危機管理 救火模式，即在風(fēng)險已經(jīng)造成麻煩后才著手處理它們2、失敗處理 覺察到了風(fēng)險并迅速做出反應(yīng)，但只是在風(fēng)險發(fā)生之后3、風(fēng)險環(huán)節(jié) 事先制定好風(fēng)險發(fā)生后的補救措施，但不做任何防范措施4、著力預(yù)防 將風(fēng)險識別與風(fēng)險防范作為軟件項目的一部分加以規(guī)劃和執(zhí)

44、行5、消滅根源 識別和消除可能發(fā)生的風(fēng)險的根源本章描述如何定位第 4、 5個層面上的進度風(fēng)險管理總體來講，風(fēng)險管理由風(fēng)險評估和風(fēng)險控制組成:圖5.1-1風(fēng)險管理由風(fēng)險評估和風(fēng)險控制組成1. 風(fēng)險評估> 風(fēng)險識別：建立一個潛在破壞項目進度的風(fēng)險列表> 風(fēng)險分析：評估每一個風(fēng)險出現(xiàn)可能性及其影響，判定風(fēng)險的級別> 風(fēng)險優(yōu)先級：按風(fēng)險影響大小排岀一個風(fēng)險優(yōu)先級列表，這個列表將作為風(fēng)險控制的基礎(chǔ)2. 風(fēng)險控制? 風(fēng)險管理計劃：定制一個應(yīng)對每個重要風(fēng)險的方案，同時應(yīng)確保每一個單獨的風(fēng)險管理計劃相互 之間以及與項目計劃之間保持一致? 風(fēng)險化解：執(zhí)行每一個重要風(fēng)險所對應(yīng)管理計劃? 風(fēng)險監(jiān)控

45、：對解決風(fēng)險的過程進行監(jiān)控。還包括：識別新的風(fēng)險，并將其加入到正在進行的風(fēng)險 管理進程；在風(fēng)險列表中移除已經(jīng)化解的風(fēng)險等工作風(fēng)險識別1. 最常見的進度計劃風(fēng)險功能蔓延需求鍍金或開發(fā)人員鍍金質(zhì)量不穩(wěn)定計劃過于樂觀設(shè)計欠佳銀彈綜合癥 研究導(dǎo)向的開發(fā)人員薄弱承包人導(dǎo)致的失敗開發(fā)人員與客戶之間發(fā)生摩擦2. 進度計劃風(fēng)險列表F面列岀了詳盡的可能對軟件進度有負面影響的潛在風(fēng)險。除了這里所列岀的風(fēng)險，大多數(shù)項目都有其特定的風(fēng)險，如:“ Joe要退岀項目組，除非可以允許他帶自己的小狗來上班，而管理層還沒有決定是否同意他這樣做”一一 這樣的風(fēng)險就要靠自己識別了！潛在的進度計劃風(fēng)險：（資料來源：Gilb 1988

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

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

48、低效12）管理層強調(diào)英雄主義而忽略客觀確切的狀態(tài)報告，錯過發(fā)現(xiàn)和改正問題的機會3、開發(fā)環(huán)境1）設(shè)施沒有及時到位2）設(shè)施到位但不配套3）設(shè)施擁擠、雜亂或破損4）開發(fā)工具沒能及時到位5）開發(fā)工具不如期望的那樣有效6）開發(fā)工具的選擇不是基于技術(shù)需求，不能提供計劃要求的性能7）開發(fā)人員需要長時間創(chuàng)建工作環(huán)境或切換新開發(fā)工具8）新開發(fā)工具的學(xué)習(xí)周期比預(yù)期的長，內(nèi)容繁多4、最終用戶1）最終用戶堅持新的需求2）最終用戶對于最后交付的產(chǎn)品不滿意，要求重新設(shè)計或重做3）最終用戶不買進項目產(chǎn)品，無法提供后續(xù)支持5、客戶6、承包商7、需求1）客戶堅持新的需求2）客戶對規(guī)則、原型和規(guī)格的審核和決策周期比預(yù)期的長3）客

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

50、供需要的性能水平1）需求已經(jīng)成為項目的基準(zhǔn)，但變化仍在繼續(xù)2）需求定義欠佳，但進一步的定義會擴展項目的范疇3）添加額外的需求4）需求定義含糊的部分需要的處理時間比預(yù)期多&產(chǎn)品9、外部環(huán)境1）錯誤發(fā)生率高的模塊需要比預(yù)期更多的設(shè)計、實現(xiàn)和測試工作2）校正質(zhì)量低下的產(chǎn)品需要比預(yù)期更多的設(shè)計、實現(xiàn)和測試工作3）在一個或多個新興領(lǐng)域推過產(chǎn)品技術(shù)使得進度延長或不可預(yù)期4）由于軟件的功能錯誤使得需要重新設(shè)計和實現(xiàn)5）開發(fā)額外不需要的功能（鍍金）延長了計劃進度6）要滿足產(chǎn)品規(guī)模的要求，需要比預(yù)期長的時間，包括重新計劃、設(shè)計和實現(xiàn)7）嚴格要求與原有系統(tǒng)兼容，需要進行比預(yù)期更多的計劃、設(shè)計、實現(xiàn)和測試8

51、）要與不受項目組控制的其他系統(tǒng)集成，導(dǎo)致無法預(yù)料的設(shè)計、實現(xiàn)和測試工作9）要求在不同操作系統(tǒng)或軟硬件環(huán)境下運行將花費比預(yù)期更長的時間10）在不熟識或未經(jīng)檢驗的軟件環(huán)境中運行，產(chǎn)生未預(yù)料到的問題11）在不熟識或未經(jīng)檢驗的硬件環(huán)境中運行，產(chǎn)生未預(yù)料到的問題12）開發(fā)一些全新的功能模塊比預(yù)期花費更長時間13）依賴未成熟的技術(shù)，使得進度延長或不可預(yù)期1）產(chǎn)品依賴政府的政策或制度，而政策或制度不可預(yù)期2）產(chǎn)品依賴草擬中的技術(shù)標(biāo)準(zhǔn)，而最后的標(biāo)準(zhǔn)不可預(yù)期10、人員1）招聘人員所花時間比預(yù)期長2）培訓(xùn)、工作許可證或其他項目的收尾等作為先決條件的任務(wù)不能按時完成3）開發(fā)人員和管理層之間關(guān)系不佳導(dǎo)致決策緩慢影響進

52、度4）項目組成員沒有全身心投入項目，進而無法達到要求的產(chǎn)品質(zhì)量水平5）缺乏激勵措施，士氣低下，降低生產(chǎn)力6）缺乏必要的規(guī)范，增加了工作失誤幾率和重復(fù)工作7）某些人需要更多時間適應(yīng)新的軟件工具和環(huán)境8）某些人需要更多時間適應(yīng)新的硬件工具和環(huán)境9）項目結(jié)束前，成員調(diào)離團隊或離職10）項目后期加入新開發(fā)人員，額外的培訓(xùn)和溝通降低現(xiàn)有成員的生產(chǎn)率11、設(shè)計和實現(xiàn)12、過程11）項目成員不能有效地一起工作12）項目組成員間有沖突，導(dǎo)致溝通不暢、設(shè)計欠佳、接口錯誤和額外的重復(fù)工作13)14)有問題的成員沒有調(diào)離項目組，損害了其他成員的積極性 項目的最佳人選沒有加入項目組15）項目的最佳人選已加入項目組，但因政治或其它原因未能合理使用16）沒有找到項目急需的，具有特殊技能的人17）關(guān)鍵人物只能兼職參與18）項目人員不足19）任務(wù)的分配與人員技能不匹配20）人員工作的進度比預(yù)期的慢21）項目管理人員怠工導(dǎo)致計劃的進度失效22）技術(shù)人員怠工導(dǎo)致工作遺漏和質(zhì)量低下1）設(shè)計過于簡單，無法確定主要事件，并導(dǎo)致重新設(shè)計和實現(xiàn)2）設(shè)計過于復(fù)雜，導(dǎo)致一些不必要的工作，影響實現(xiàn)效率3）設(shè)計質(zhì)量低下，導(dǎo)致重復(fù)設(shè)計和實現(xiàn)4）使用不熟識的方法和技術(shù)，導(dǎo)致額