欧美成人精品手机在线观看_69视频国产_动漫精品第一页_日韩中文字幕网 - 日本欧美一区二区

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

（Bill Hetzel 1993）

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

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

---

管理的基本原則

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

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

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

　　如果估算不準(zhǔn)確就會(huì)降低開(kāi)發(fā)效率，所以說(shuō)估算和項(xiàng)目進(jìn)度計(jì)劃是軟件開(kāi)發(fā)的基礎(chǔ)。精確的估算時(shí)進(jìn)行有效規(guī)劃的必要前提，而有效的規(guī)劃又是有效開(kāi)發(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)品的特色，是否需要購(gòu)買(mǎi)部分產(chǎn)品組建）

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

　　制定了一個(gè)項(xiàng)目計(jì)劃就要跟蹤檢查它是否在按計(jì)劃進(jìn)行，包括對(duì)它的進(jìn)度、費(fèi)用和質(zhì)量等目標(biāo)的檢查。典型的管理級(jí)跟蹤控制包括：任務(wù)列表、進(jìn)展?fàn)顩r會(huì)議、進(jìn)展報(bào)告、里程碑審查、預(yù)算報(bào)告以及走查管理等。典型的技術(shù)級(jí)跟蹤包括：技術(shù)審查、技術(shù)審計(jì)和標(biāo)志著里程碑是否完結(jié)的質(zhì)量關(guān)口等。

 圖 4.1.3-1 不同類(lèi)型項(xiàng)目的可視度

4. 量度

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

　　為了使開(kāi)發(fā)更有效，你需要具備軟件量度方面的基本知識(shí)。你需要了解收集數(shù)據(jù)的尺度基準(zhǔn)，包括應(yīng)該要收集什么數(shù)據(jù)，如何獲得這些數(shù)據(jù)。你還需要具備用來(lái)分析狀態(tài)，質(zhì)量和生產(chǎn)率的詳細(xì)基準(zhǔn)方面的知識(shí)。任何公司想要進(jìn)行快速的開(kāi)發(fā)就要收集這些基本的尺度，這樣才可以知道他們的開(kāi)發(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í)踐方法”就無(wú)法具有高的生產(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í)踐方法，但是仍舊和那些完全沒(méi)有使用該方法的項(xiàng)目具有一樣的生產(chǎn)率。因此，注意技術(shù)的基本原則是很必要的，但卻不足以達(dá)到快速開(kāi)發(fā)的目的（例如犯了某些典型錯(cuò)誤）。

1. 需求管理

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

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

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

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

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

　　成功的需求管理取決于了解足夠的不同的實(shí)踐經(jīng)驗(yàn)，以便能夠?yàn)樘囟?xiàng)目選擇可借鑒的一種。

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

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

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

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

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

　　想象一下，如果把需求變化從25%減少到10%，同時(shí)把每個(gè)需求變化導(dǎo)致的費(fèi)用減少5%-10%，那么綜合的效果會(huì)怎樣呢？

2. 設(shè)計(jì)

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

　　一個(gè)設(shè)計(jì)上的錯(cuò)誤如果到系統(tǒng)測(cè)試時(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)
  
• 對(duì)典型挑戰(zhàn)性事件的標(biāo)準(zhǔn)設(shè)計(jì)：包括異常處理、國(guó)際化、本地化、便攜性、字串存儲(chǔ)、輸入輸出、內(nèi)存管理、數(shù)據(jù)存儲(chǔ)、浮點(diǎn)算法、數(shù)據(jù)庫(kù)設(shè)計(jì)、性能和復(fù)用
  
• 對(duì)特殊領(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ì)工具的使用

　　當(dāng)構(gòu)建開(kāi)始時(shí)，項(xiàng)目成功與否大多就已經(jīng)注定了。需求管理和設(shè)計(jì)對(duì)開(kāi)發(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ī)會(huì)進(jìn)一步改進(jìn)時(shí)間效率低的任務(wù)或優(yōu)化一些任務(wù)。例如，花時(shí)間對(duì)那些無(wú)需鍍金的功能進(jìn)行鍍金；調(diào)試那些無(wú)用的多余代碼，或者對(duì)那些并不知道是否需要優(yōu)化的片段盡心優(yōu)化。

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

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

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

---

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

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

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

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

　　重做有缺陷的需求、設(shè)計(jì)和編碼通常花費(fèi)整個(gè)軟件開(kāi)發(fā)成本的40%—50%。（Jones 1968b，Boehm 1987a）

　　最糟糕的情況下，在運(yùn)行中的軟件項(xiàng)目只修改一次軟件需求問(wèn)題的花費(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ò)誤率和開(kāi)發(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ò)誤率的模塊開(kāi)發(fā)起來(lái)要比其它模塊更加昂貴和耗時(shí)，如果普通模塊開(kāi)發(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ù)壓力下開(kāi)發(fā)，往往沒(méi)有被完全測(cè)試過(guò)。對(duì)軟件開(kāi)發(fā)特別重要的一個(gè)方面就是對(duì)易錯(cuò)模塊的質(zhì)量保證。

2. 測(cè)試

　　最尋常的質(zhì)量保證實(shí)踐就是毋庸置疑地進(jìn)行測(cè)試，兩種基本的測(cè)試方法：

• 單元測(cè)試：程序員檢查他自己的代碼是否工作正常
  
• 系統(tǒng)測(cè)試：獨(dú)立測(cè)試員檢查整個(gè)系統(tǒng)是否如期望的那樣正常運(yùn)行

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

　　測(cè)試的有效性差異是巨大的。單元測(cè)試可以找到程序中10%—50%的漏洞；系統(tǒng)測(cè)試可以發(fā)現(xiàn)20%—60%的程序漏洞。加在一起，累積的漏洞檢測(cè)率經(jīng)常少于60%。（Jones 1986a）

　　剩下的錯(cuò)誤要么通過(guò)其它的查錯(cuò)技巧（如技術(shù)回顧）發(fā)現(xiàn)，要么就是在產(chǎn)品發(fā)布后被最終用戶(hù)發(fā)現(xiàn)。

　　平衡測(cè)試和快速開(kāi)發(fā)的最佳辦法是在壞消息出現(xiàn)之前做好計(jì)劃——設(shè)置對(duì)壞消息的測(cè)試，盡早地發(fā)現(xiàn)問(wèn)題。

3. 技術(shù)回顧

　　技術(shù)回顧包括在需求、設(shè)計(jì)、編碼和測(cè)試等事件中用于查錯(cuò)的所有類(lèi)型的回顧。回顧在形式上和效果上是多樣的，它在開(kāi)發(fā)速度上比在測(cè)試上扮演更重要的角色。下面講述最常見(jiàn)的幾種回顧。

1) 走查

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

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

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

2) 代碼閱讀

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

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

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

3) 檢查

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

　　在項(xiàng)目中可以使用檢查對(duì)需求分析、用戶(hù)界面原型、設(shè)計(jì)、編碼及其他認(rèn)為的過(guò)程查錯(cuò)。

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

　　檢查可以查出程序中60%—90%的漏洞，這點(diǎn)比走查或測(cè)試要好。因?yàn)榭梢栽陂_(kāi)發(fā)的早期應(yīng)用，因此，檢查方法被證明可以節(jié)約10%—30%的開(kāi)發(fā)時(shí)間。（Gilb and Graham 1993）

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

該文章在 2012/4/9 10:34:36 編輯過(guò)