“回顧一下被選為‘最佳項目’的十個軟件項目，如果說有所發(fā)現(xiàn)的話，那就是——最佳的項目一定是建立在最佳的軟件開發(fā)基礎(chǔ)之上的。我們都知道軟件開發(fā)基礎(chǔ)對于優(yōu)秀軟件的作用，但差別在于大多數(shù)軟件的基礎(chǔ)薄弱，這樣不可避免地使自己陷入麻煩之中”

（Bill Hetzel 1993）

　　本章的范疇只限定在確定軟件開發(fā)的基本原則，解析他們是如何影響開發(fā)計劃的，同時提供參考信息。

本章書把軟件開發(fā)基本原則實踐分為三類：管理實踐，技術(shù)實踐和質(zhì)量保證實踐。

---

管理的基本原則

　　管理原則由以下幾部分組成：

• 判定產(chǎn)品規(guī)模（包括功能、復雜度和其它產(chǎn)品特性）
  
• 根據(jù)產(chǎn)品規(guī)模分配資源
  
• 制定資源計劃
  
• 監(jiān)控、引導資源以保持項目方向不會偏離

• 首先估算項目規(guī)模大小
  
• 然后估算完成這樣規(guī)模的項目需要付出的代價
  
• 最后基于這種估算定制項目進度計劃

　　如果估算不準確就會降低開發(fā)效率，所以說估算和項目進度計劃是軟件開發(fā)的基礎(chǔ)。精確的估算時進行有效規(guī)劃的必要前提，而有效的規(guī)劃又是有效開發(fā)的必要條件。

2. 計劃編制

　　計劃一個軟件項目應該包括以下活動：

• 項目估算和時間進度
  
• 確定項目需要多少人參與、需要什么樣的技能、合適加入以及具體人選
  
• 確定項目組的運作方式
  
• 確定項目采用的生命周期模型
  
• 管理風險
  
• 確定項目策略（例如：如何控制產(chǎn)品的特色，是否需要購買部分產(chǎn)品組建）

　　跟蹤是一個基本的軟件管理行為。如果不跟蹤一個項目就不能管理它，就不會知道計劃是否被貫徹執(zhí)行了，也不會知道下一步該做什么，同時也無法監(jiān)控項目風險。有效的跟蹤能使項目組在還有時間做點什么來改正錯誤的時候，盡早發(fā)現(xiàn)進度表上的問題。

　　制定了一個項目計劃就要跟蹤檢查它是否在按計劃進行，包括對它的進度、費用和質(zhì)量等目標的檢查。典型的管理級跟蹤控制包括：任務列表、進展狀況會議、進展報告、里程碑審查、預算報告以及走查管理等。典型的技術(shù)級跟蹤包括：技術(shù)審查、技術(shù)審計和標志著里程碑是否完結(jié)的質(zhì)量關(guān)口等。

 圖 4.1.3-1 不同類型項目的可視度

4. 量度

　　老板問你：“我們能夠在9各月內(nèi)開發(fā)出這個產(chǎn)品嗎？”——你怎么回答？！

　　為了使開發(fā)更有效，你需要具備軟件量度方面的基本知識。你需要了解收集數(shù)據(jù)的尺度基準，包括應該要收集什么數(shù)據(jù)，如何獲得這些數(shù)據(jù)。你還需要具備用來分析狀態(tài)，質(zhì)量和生產(chǎn)率的詳細基準方面的知識。任何公司想要進行快速的開發(fā)就要收集這些基本的尺度，這樣才可以知道他們的開發(fā)速度是否正在改善或后退。

---

技術(shù)基本原則

　　1984年有關(guān)“現(xiàn)代程序設計實踐方法——技術(shù)的基本原則”的一份研究，詳細論述了不使用這些基本原則就不可能具有高的生產(chǎn)率的內(nèi)容。圖4.2-1展示了研究的結(jié)果。

圖 4.2-1 生產(chǎn)率與“現(xiàn)代程序設計實踐方法”的關(guān)系

（不廣泛地使用“現(xiàn)代程序設計實踐方法”就無法具有高的生產(chǎn)率）

 　　很顯然，不采用現(xiàn)代程序設計實踐方法的項目不可能具有高的生產(chǎn)率。但技術(shù)基本原則的應用，就其本身而言，不足以創(chuàng)造高的生產(chǎn)率。一些項目使用了大量現(xiàn)代程序設計實踐方法，但是仍舊和那些完全沒有使用該方法的項目具有一樣的生產(chǎn)率。因此，注意技術(shù)的基本原則是很必要的，但卻不足以達到快速開發(fā)的目的（例如犯了某些典型錯誤）。

1. 需求管理

　　研究數(shù)據(jù)：

　　典型項目平均會經(jīng)歷25%的需求變化，從而至少產(chǎn)生25%的額外費用和時間。

　　一項針對8000多個項目的調(diào)查顯示，導致項目推遲發(fā)布、超出預算、功能比預期減少的最重要的三個原因——缺乏用戶的介入、不完善的需求分析和用戶不斷改變需求，都和需求管理有關(guān)。（Standish Group1994）

　　一項軟件工程研究所的調(diào)查也有相同的結(jié)論：超過半數(shù)的項目都遭遇過不充分的需求管理的麻煩。（Kitson and Masters 1993）

　　需求管理就是收集需求，把需求記錄成文檔、電子郵件、用戶界面串連腳本、可實現(xiàn)的原型等形式，然后依此來跟蹤設計和編碼，并隨時管理、修改需求，以適應項目后續(xù)的過程。

　　成功的需求管理取決于了解足夠的不同的實踐經(jīng)驗，以便能夠為特定項目選擇可借鑒的一種。

　　需求管理的基礎(chǔ)：

• 需求分析方法：包括結(jié)構(gòu)分析、數(shù)據(jù)結(jié)構(gòu)分析和面向?qū)ο蠓治?
  
• 系統(tǒng)建模實踐：如類圖表、數(shù)據(jù)流圖表、實體關(guān)系圖表、數(shù)據(jù)字典符號和狀態(tài)躍變圖表
  
• 溝通實踐：如聯(lián)合應用開發(fā)、用戶界面原型和常規(guī)會談實踐等
  
• 需求管理和其它生命周期類型的關(guān)系：如漸進原型、階段交付、螺旋模型、瀑布模型和編碼修正

　　需求管理在兩個方面對開發(fā)速度發(fā)揮著巨大的調(diào)節(jié)作用：

　　首先，正規(guī)的需求管理中，需求收集往往比其他軟件開發(fā)活動完成得要從容些。如果能加快需求步伐而不傷害質(zhì)量，就可以縮短總的開發(fā)時間。

　　第二，正確地把需求擺在首位，往往要比被動地這樣做所花的時間少得多。一些需求管理實踐基本原則能夠減少需求變化的數(shù)量，其他開發(fā)實踐的基本原則能夠減少因需求改變而產(chǎn)生的費用。

　　想象一下，如果把需求變化從25%減少到10%，同時把每個需求變化導致的費用減少5%-10%，那么綜合的效果會怎樣呢？

2. 設計

　　研究數(shù)據(jù)：

　　一個設計上的錯誤如果到系統(tǒng)測試時才被發(fā)現(xiàn)，那么花費的修補時間要比它在設計階段時被發(fā)現(xiàn)所花費的時間多10倍。（Dunn 1984）

　　設計是系統(tǒng)構(gòu)建、項目進度計劃、項目跟蹤和項目控制的基礎(chǔ)。

　　體系結(jié)構(gòu)和設計的基本原則：

• 主要設計風格：如面向?qū)ο笤O計、結(jié)構(gòu)化設計和數(shù)據(jù)結(jié)構(gòu)設計
  
• 基礎(chǔ)設計概念：如信息隱藏、模塊化、抽象、封裝、聚合、耦合、層次、繼承、多態(tài)、基本算法和基本數(shù)據(jù)結(jié)構(gòu)
  
• 對典型挑戰(zhàn)性事件的標準設計：包括異常處理、國際化、本地化、便攜性、字串存儲、輸入輸出、內(nèi)存管理、數(shù)據(jù)存儲、浮點算法、數(shù)據(jù)庫設計、性能和復用
  
• 對特殊領(lǐng)域應用程序設計的獨有思考：例如財務應用、科學應用、嵌入式系統(tǒng)、實時系統(tǒng)、安全性要求高的軟件等
  
• 架構(gòu)安排：如子系統(tǒng)組織、分層結(jié)構(gòu)、子系統(tǒng)通信方式和典型的系統(tǒng)架構(gòu)
  
• 設計工具的使用

　　當構(gòu)建開始時，項目成功與否大多就已經(jīng)注定了。需求管理和設計對開發(fā)進度計劃的調(diào)節(jié)作用比構(gòu)建的調(diào)節(jié)作用大得多，這意味著小的波動可以導致進度的重大變化。

　　盡管構(gòu)建是一個低層次的活動，但是它確實可以提供許多機會進一步改進時間效率低的任務或優(yōu)化一些任務。例如，花時間對那些無需鍍金的功能進行鍍金；調(diào)試那些無用的多余代碼，或者對那些并不知道是否需要優(yōu)化的片段盡心優(yōu)化。

　　構(gòu)建的基本原則：

• 編碼實踐：如變量和函數(shù)命名、版面布局和文檔
  
• 數(shù)據(jù)相關(guān)概念：如作用范圍、持續(xù)和捆綁時間
  
• 特定數(shù)據(jù)類型的使用方針：如通用基礎(chǔ)數(shù)據(jù)類型、枚舉、常量、數(shù)組和指針
  
• 控制相關(guān)的概念：如組織整齊的代碼、條件的使用、循環(huán)的控制、復雜度的控制、特殊控制結(jié)構(gòu)的使用（goto、return、遞歸）
  
• 斷言和其它以代碼為核心的錯誤檢測方法
  
• 對例程、模塊、類和文件代碼打包的規(guī)則
  
• 單元測試和調(diào)試實踐
  
• 集成策略：如增量式集成、大爆炸式集成和漸進開發(fā)
  
• 代碼優(yōu)化策略和實踐
  
• 與所使用的特定編程語言相關(guān)的其他事情
  
• 使用構(gòu)建工具：如編譯環(huán)境、群組工作支持、源代碼控制、代碼庫和代碼生成器

　　軟件配置管理(SCM)是管理項目成果的一種實踐方法，能使項目在全程中保持一致的狀態(tài)。SCM包括評估變更、跟蹤變更、處理多版本，以及在不同時間保存項目成果的備份等實踐。

---

質(zhì)量保證基本原則

　　很多公司現(xiàn)階段開發(fā)軟件都有一定的不當之處，使得他們的開發(fā)時間比需要的長。在調(diào)查了4000個軟件項目后，Capers Jones遞交報告說，糟糕的質(zhì)量是進度被拖延的最普遍的原因之一。他還說，中途被取消的項目中，大約有一半是由于其糟糕的質(zhì)量。（Jones 1994）

　　一項軟件工程研究所的調(diào)查顯示，大約有60%的公司遭受著不適當?shù)馁|(zhì)量保證體系的困擾。（Kitson and Masters 1993）。

　　在過大的時間壓力下發(fā)布的產(chǎn)品，其錯誤率是正常情況下的4倍。有進度問題的項目經(jīng)常是在進行艱苦的工作而不是輕松活躍的工作，關(guān)注質(zhì)量被認為是有些奢侈。但其結(jié)果卻是項目進展緩慢，并陷入更深的進度問題中。（Jones 1994）

　　重做有缺陷的需求、設計和編碼通?；ㄙM整個軟件開發(fā)成本的40%—50%。（Jones 1968b，Boehm 1987a）

　　最糟糕的情況下，在運行中的軟件項目只修改一次軟件需求問題的花費通常是在需求分析階段所花時間的50到200倍。（Boehm and Papacio 1988）

　　大約60%的錯誤通常在設計階段就存在了。（Gilb 1988）

　　如果可以盡早地預防并修正漏洞，可以節(jié)省大量時間，在進度的安排上占了先機。

 

 圖 4.3-1 錯誤率和開發(fā)時間的關(guān)系

（大多數(shù)情況下，具有低錯誤率的項目同時實現(xiàn)了最短日程的目標）

1. 易錯模塊

　　易錯模塊是那些容易存在或多或少漏洞的模塊。

　　研究數(shù)據(jù)：

　　IBM的IMS項目中，57%的漏洞存在于7%的模塊中。（Jones 1991）

　　程序中20%的模塊包含了80%的錯誤。（Boehm 1987b）

　　高錯誤率的模塊開發(fā)起來要比其它模塊更加昂貴和耗時，如果普通模塊開發(fā)每個功能點要花費$500—$1000，那么易錯模塊每個功能點就要花費$2000—$4000。（Jones 1994）

　　易錯模塊往往比系統(tǒng)中的其它模塊更復雜，缺乏結(jié)構(gòu)化，或者不同尋常的龐大，并且往往在背負壓力下開發(fā)，往往沒有被完全測試過。對軟件開發(fā)特別重要的一個方面就是對易錯模塊的質(zhì)量保證。

2. 測試

　　最尋常的質(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)之前做好計劃——設置對壞消息的測試，盡早地發(fā)現(xiàn)問題。

3. 技術(shù)回顧

　　技術(shù)回顧包括在需求、設計、編碼和測試等事件中用于查錯的所有類型的回顧?；仡櫾谛问缴虾托Ч鲜嵌鄻拥模陂_發(fā)速度上比在測試上扮演更重要的角色。下面講述最常見的幾種回顧。

1) 走查

　　走查是指任何兩個以上的開發(fā)人員以增進軟件質(zhì)量為目的所召開的回顧技術(shù)工作會議。走查可能是最平常的非正式回顧，走查可以在寫設計說明書時，設計和編碼完成之前就發(fā)現(xiàn)漏洞。

　　研究數(shù)據(jù)：

　　走查可以發(fā)現(xiàn)30%—70%的程序漏洞。（Myers 1979，Boehm 1987b，Yourdon 1989b）

2) 代碼閱讀

　　代碼閱讀時比走查更正式些的回顧方式，但僅適用于代碼。代碼閱讀時，寫這段代碼的程序員把代碼清單交給兩個或更多的審閱者審閱，審閱者閱讀代碼，并把發(fā)現(xiàn)的錯誤報告給編寫者。

　　研究數(shù)據(jù)：

　　NASA的軟件工程實驗室的一項研究發(fā)現(xiàn)：代碼閱讀能發(fā)現(xiàn)的漏洞是測試時能發(fā)現(xiàn)的漏洞的兩倍。（Card 1987）

3) 檢查

 　　檢查是一種正式的技術(shù)回顧，它被認為是在整個項目中最具效率的查錯方式。使用檢查的方法，開發(fā)人員需要接受檢查的特殊訓練，并且在檢查中扮演重要的角色。在檢查會議之前“仲裁人”發(fā)布產(chǎn)品要被檢驗評估的消息和檢查列表，“審閱人”在會議前檢查程序，在檢查會議上“作者”通常要解釋要檢驗的東西，“審閱人”鑒別錯誤，“書記員”記錄錯誤。在會后“仲裁人”寫一份報告說明每個漏洞和處理辦法。

　　在項目中可以使用檢查對需求分析、用戶界面原型、設計、編碼及其他認為的過程查錯。

　　研究數(shù)據(jù)：

　　檢查可以查出程序中60%—90%的漏洞，這點比走查或測試要好。因為可以在開發(fā)的早期應用，因此，檢查方法被證明可以節(jié)約10%—30%的開發(fā)時間。（Gilb and Graham 1993）

　　一項對大型程序的調(diào)查結(jié)果顯示，在檢查上每花1小時，就可以避免在維護上33個小時的花費。檢查比測試有效20倍以上。（Russel 1991）

該文章在 2012/4/9 10:34:36 編輯過