軟件開發(fā)基本原則之最佳項(xiàng)目
“回顧一下被選為‘最佳項(xiàng)目’的十個(gè)軟件項(xiàng)目，如果說有所發(fā)現(xiàn)的話，那就是——最佳的項(xiàng)目一定是建立在最佳的軟件開發(fā)基礎(chǔ)之上的。我們都知道軟件開發(fā)基礎(chǔ)對于優(yōu)秀軟件的作用，但差別在于大多數(shù)軟件的基礎(chǔ)薄弱，這樣不可避免地使自己陷入麻煩之中”
（Bill Hetzel 1993）
本章的范疇只限定在確定軟件開發(fā)的基本原則，解析他們是如何影響開發(fā)計(jì)劃的，同時(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)確就會降低開發(fā)效率，所以說估算和項(xiàng)目進(jìn)度計(jì)劃是軟件開發(fā)的基礎(chǔ)。精確的估算時(shí)進(jìn)行有效規(guī)劃的必要前提，而有效的規(guī)劃又是有效開發(fā)的必要條件。
2. 計(jì)劃編制
計(jì)劃一個(gè)軟件項(xiàng)目應(yīng)該包括以下活動(dò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í)也無法監(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ù)。你還需要具備用來分析狀態(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í)踐方法，但是仍舊和那些完全沒有使用該方法的項(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）
需求管理就是收集需求，把需求記錄成文檔、電子郵件、用戶界面串連腳本、可實(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ū)ο蠓治?/p>
系統(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ī)的需求管理中，需求收集往往比其他軟件開發(fā)活動(dòng)完成得要從容些。如果能加快需求步伐而不傷害質(zhì)量，就可以縮短總的開發(fā)時(shí)間。
第二，正確地把需求擺在首位，往往要比被動(dòng)地這樣做所花的時(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è)計(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òng)可以導(dǎo)致進(jìn)度的重大變化。
盡管構(gòu)建是一個(gè)低層次的活動(dòng)，但是它確實(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、遞歸）
斷言和其它以代碼為核心的錯(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)查了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%—50%。（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%的模塊包含了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)行
研究數(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ì)量為目的所召開的回顧技術(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)目中最具效率的查錯(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)對大型程序的調(diào)查結(jié)果顯示，在檢查上每花1小時(shí)，就可以避免在維護(hù)上33個(gè)小時(shí)的花費(fèi)。檢查比測試有效20倍以上。（Russel 1991）
原文鏈接：http://www.cnblogs.com/ldcsaa/archive/2012/03/06/2379310.html
【編輯推薦】
