“回顧一下被選為‘最佳項目’的十個軟件項目，如果說有所發現的話，那就是——最佳的項目一定是建立在最佳的軟件開發基礎之上的。我們都知道軟件開發基礎對於優秀軟件的作用，但差別在於大多數軟件的基礎薄弱，這樣不可避免地使自己陷入麻煩之中”
（Bill Hetzel 1993）
本章的范疇只限定在確定軟件開發的基本原則，解析他們是如何影響開發計划的，同時提供參考信息。
本章書把軟件開發基本原則實踐分為三類：管理實踐，技術實踐和質量保證實踐。
管理的基本原則
管理原則由以下幾部分組成：
- 判定產品規模（包括功能、復雜度和其它產品特性）
- 根據產品規模分配資源
- 制定資源計划
- 監控、引導資源以保持項目方向不會偏離
- 首先估算項目規模大小
- 然后估算完成這樣規模的項目需要付出的代價
- 最后基於這種估算定制項目進度計划
如果估算不准確就會降低開發效率，所以說估算和項目進度計划是軟件開發的基礎。精確的估算時進行有效規划的必要前提，而有效的規划又是有效開發的必要條件。
2. 計划編制
計划一個軟件項目應該包括以下活動：
- 項目估算和時間進度
- 確定項目需要多少人參與、需要什么樣的技能、合適加入以及具體人選
- 確定項目組的運作方式
- 確定項目采用的生命周期模型
- 管理風險
- 確定項目策略（例如：如何控制產品的特色，是否需要購買部分產品組建）
跟蹤是一個基本的軟件管理行為。如果不跟蹤一個項目就不能管理它，就不會知道計划是否被貫徹執行了，也不會知道下一步該做什么，同時也無法監控項目風險。有效的跟蹤能使項目組在還有時間做點什么來改正錯誤的時候，盡早發現進度表上的問題。
制定了一個項目計划就要跟蹤檢查它是否在按計划進行，包括對它的進度、費用和質量等目標的檢查。典型的管理級跟蹤控制包括：任務列表、進展狀況會議、進展報告、里程碑審查、預算報告以及走查管理等。典型的技術級跟蹤包括：技術審查、技術審計和標志着里程碑是否完結的質量關口等。
圖 4.1.3-1 不同類型項目的可視度
4. 量度
老板問你：“我們能夠在9各月內開發出這個產品嗎？”——你怎么回答？！
為了使開發更有效，你需要具備軟件量度方面的基本知識。你需要了解收集數據的尺度基准，包括應該要收集什么數據，如何獲得這些數據。你還需要具備用來分析狀態，質量和生產率的詳細基准方面的知識。任何公司想要進行快速的開發就要收集這些基本的尺度，這樣才可以知道他們的開發速度是否正在改善或后退。
技術基本原則
1984年有關“現代程序設計實踐方法——技術的基本原則”的一份研究，詳細論述了不使用這些基本原則就不可能具有高的生產率的內容。圖4.2-1展示了研究的結果。
圖 4.2-1 生產率與“現代程序設計實踐方法”的關系
（不廣泛地使用“現代程序設計實踐方法”就無法具有高的生產率）
很顯然，不采用現代程序設計實踐方法的項目不可能具有高的生產率。但技術基本原則的應用，就其本身而言，不足以創造高的生產率。一些項目使用了大量現代程序設計實踐方法，但是仍舊和那些完全沒有使用該方法的項目具有一樣的生產率。因此，注意技術的基本原則是很必要的，但卻不足以達到快速開發的目的（例如犯了某些典型錯誤）。
1. 需求管理
研究數據：
典型項目平均會經歷25%的需求變化，從而至少產生25%的額外費用和時間。
一項針對8000多個項目的調查顯示，導致項目推遲發布、超出預算、功能比預期減少的最重要的三個原因——缺乏用戶的介入、不完善的需求分析和用戶不斷改變需求，都和需求管理有關。（Standish Group1994）
一項軟件工程研究所的調查也有相同的結論：超過半數的項目都遭遇過不充分的需求管理的麻煩。（Kitson and Masters 1993）
需求管理就是收集需求，把需求記錄成文檔、電子郵件、用戶界面串連腳本、可實現的原型等形式，然后依此來跟蹤設計和編碼，並隨時管理、修改需求，以適應項目后續的過程。
成功的需求管理取決於了解足夠的不同的實踐經驗，以便能夠為特定項目選擇可借鑒的一種。
需求管理的基礎：
- 需求分析方法：包括結構分析、數據結構分析和面向對象分析
- 系統建模實踐：如類圖表、數據流圖表、實體關系圖表、數據字典符號和狀態躍變圖表
- 溝通實踐：如聯合應用開發、用戶界面原型和常規會談實踐等
- 需求管理和其它生命周期類型的關系：如漸進原型、階段交付、螺旋模型、瀑布模型和編碼修正
需求管理在兩個方面對開發速度發揮着巨大的調節作用：
首先，正規的需求管理中，需求收集往往比其他軟件開發活動完成得要從容些。如果能加快需求步伐而不傷害質量，就可以縮短總的開發時間。
第二，正確地把需求擺在首位，往往要比被動地這樣做所花的時間少得多。一些需求管理實踐基本原則能夠減少需求變化的數量，其他開發實踐的基本原則能夠減少因需求改變而產生的費用。
想象一下，如果把需求變化從25%減少到10%，同時把每個需求變化導致的費用減少5%-10%，那么綜合的效果會怎樣呢？
2. 設計
研究數據：
一個設計上的錯誤如果到系統測試時才被發現，那么花費的修補時間要比它在設計階段時被發現所花費的時間多10倍。（Dunn 1984）
設計是系統構建、項目進度計划、項目跟蹤和項目控制的基礎。
體系結構和設計的基本原則：
- 主要設計風格：如面向對象設計、結構化設計和數據結構設計
- 基礎設計概念：如信息隱藏、模塊化、抽象、封裝、聚合、耦合、層次、繼承、多態、基本算法和基本數據結構
- 對典型挑戰性事件的標准設計：包括異常處理、國際化、本地化、便攜性、字串存儲、輸入輸出、內存管理、數據存儲、浮點算法、數據庫設計、性能和復用
- 對特殊領域應用程序設計的獨有思考：例如財務應用、科學應用、嵌入式系統、實時系統、安全性要求高的軟件等
- 架構安排：如子系統組織、分層結構、子系統通信方式和典型的系統架構
- 設計工具的使用
當構建開始時，項目成功與否大多就已經注定了。需求管理和設計對開發進度計划的調節作用比構建的調節作用大得多，這意味着小的波動可以導致進度的重大變化。
盡管構建是一個低層次的活動，但是它確實可以提供許多機會進一步改進時間效率低的任務或優化一些任務。例如，花時間對那些無需鍍金的功能進行鍍金；調試那些無用的多余代碼，或者對那些並不知道是否需要優化的片段盡心優化。
構建的基本原則：
- 編碼實踐：如變量和函數命名、版面布局和文檔
- 數據相關概念：如作用范圍、持續和捆綁時間
- 特定數據類型的使用方針：如通用基礎數據類型、枚舉、常量、數組和指針
- 控制相關的概念：如組織整齊的代碼、條件的使用、循環的控制、復雜度的控制、特殊控制結構的使用（goto、return、遞歸）
- 斷言和其它以代碼為核心的錯誤檢測方法
- 對例程、模塊、類和文件代碼打包的規則
- 單元測試和調試實踐
- 集成策略：如增量式集成、大爆炸式集成和漸進開發
- 代碼優化策略和實踐
- 與所使用的特定編程語言相關的其他事情
- 使用構建工具：如編譯環境、群組工作支持、源代碼控制、代碼庫和代碼生成器
軟件配置管理(SCM)是管理項目成果的一種實踐方法，能使項目在全程中保持一致的狀態。SCM包括評估變更、跟蹤變更、處理多版本，以及在不同時間保存項目成果的備份等實踐。
質量保證基本原則
很多公司現階段開發軟件都有一定的不當之處，使得他們的開發時間比需要的長。在調查了4000個軟件項目后，Capers Jones遞交報告說，糟糕的質量是進度被拖延的最普遍的原因之一。他還說，中途被取消的項目中，大約有一半是由於其糟糕的質量。（Jones 1994）
一項軟件工程研究所的調查顯示，大約有60%的公司遭受着不適當的質量保證體系的困擾。（Kitson and Masters 1993）。
在過大的時間壓力下發布的產品，其錯誤率是正常情況下的4倍。有進度問題的項目經常是在進行艱苦的工作而不是輕松活躍的工作，關注質量被認為是有些奢侈。但其結果卻是項目進展緩慢，並陷入更深的進度問題中。（Jones 1994）
重做有缺陷的需求、設計和編碼通常花費整個軟件開發成本的40%—50%。（Jones 1968b，Boehm 1987a）
最糟糕的情況下，在運行中的軟件項目只修改一次軟件需求問題的花費通常是在需求分析階段所花時間的50到200倍。（Boehm and Papacio 1988）
大約60%的錯誤通常在設計階段就存在了。（Gilb 1988）
如果可以盡早地預防並修正漏洞，可以節省大量時間，在進度的安排上占了先機。
圖 4.3-1 錯誤率和開發時間的關系
（大多數情況下，具有低錯誤率的項目同時實現了最短日程的目標）
1. 易錯模塊
易錯模塊是那些容易存在或多或少漏洞的模塊。
研究數據：
IBM的IMS項目中，57%的漏洞存在於7%的模塊中。（Jones 1991）
程序中20%的模塊包含了80%的錯誤。（Boehm 1987b）
高錯誤率的模塊開發起來要比其它模塊更加昂貴和耗時，如果普通模塊開發每個功能點要花費$500—$1000，那么易錯模塊每個功能點就要花費$2000—$4000。（Jones 1994）
易錯模塊往往比系統中的其它模塊更復雜，缺乏結構化，或者不同尋常的龐大，並且往往在背負壓力下開發，往往沒有被完全測試過。對軟件開發特別重要的一個方面就是對易錯模塊的質量保證。
2. 測試
最尋常的質量保證實踐就是毋庸置疑地進行測試，兩種基本的測試方法：
- 單元測試：程序員檢查他自己的代碼是否工作正常
- 系統測試：獨立測試員檢查整個系統是否如期望的那樣正常運行
研究數據：
測試的有效性差異是巨大的。單元測試可以找到程序中10%—50%的漏洞；系統測試可以發現20%—60%的程序漏洞。加在一起，累積的漏洞檢測率經常少於60%。（Jones 1986a）
剩下的錯誤要么通過其它的查錯技巧（如技術回顧）發現，要么就是在產品發布后被最終用戶發現。
平衡測試和快速開發的最佳辦法是在壞消息出現之前做好計划——設置對壞消息的測試，盡早地發現問題。
3. 技術回顧
技術回顧包括在需求、設計、編碼和測試等事件中用於查錯的所有類型的回顧。回顧在形式上和效果上是多樣的，它在開發速度上比在測試上扮演更重要的角色。下面講述最常見的幾種回顧。
1) 走查
走查是指任何兩個以上的開發人員以增進軟件質量為目的所召開的回顧技術工作會議。走查可能是最平常的非正式回顧，走查可以在寫設計說明書時，設計和編碼完成之前就發現漏洞。
研究數據：
走查可以發現30%—70%的程序漏洞。（Myers 1979，Boehm 1987b，Yourdon 1989b）
2) 代碼閱讀
代碼閱讀時比走查更正式些的回顧方式，但僅適用於代碼。代碼閱讀時，寫這段代碼的程序員把代碼清單交給兩個或更多的審閱者審閱，審閱者閱讀代碼，並把發現的錯誤報告給編寫者。
研究數據：
NASA的軟件工程實驗室的一項研究發現：代碼閱讀能發現的漏洞是測試時能發現的漏洞的兩倍。（Card 1987）
3) 檢查
檢查是一種正式的技術回顧，它被認為是在整個項目中最具效率的查錯方式。使用檢查的方法，開發人員需要接受檢查的特殊訓練，並且在檢查中扮演重要的角色。在檢查會議之前“仲裁人”發布產品要被檢驗評估的消息和檢查列表，“審閱人”在會議前檢查程序，在檢查會議上“作者”通常要解釋要檢驗的東西，“審閱人”鑒別錯誤，“書記員”記錄錯誤。在會后“仲裁人”寫一份報告說明每個漏洞和處理辦法。
在項目中可以使用檢查對需求分析、用戶界面原型、設計、編碼及其他認為的過程查錯。
研究數據：
檢查可以查出程序中60%—90%的漏洞，這點比走查或測試要好。因為可以在開發的早期應用，因此，檢查方法被證明可以節約10%—30%的開發時間。（Gilb and Graham 1993）
一項對大型程序的調查結果顯示，在檢查上每花1小時，就可以避免在維護上33個小時的花費。檢查比測試有效20倍以上。（Russel 1991）
敬請期待：軟件開發基本原則（四）—— 風險管理