軟件開發基本原則（三）—— 基本原則
當前位置：點晴教程→知識管理交流
→『 技術文檔交流 』
“回顧一下被選為‘最佳項目’的十個軟件項目，如果說有所發現的話，那就是——最佳的項目一定是建立在最佳的軟件開發基礎之上的。我們都知道軟件開發基礎對于優秀軟件的作用，但差別在于大多數軟件的基礎薄弱，這樣不可避免地使自己陷入麻煩之中” （Bill Hetzel 1993） 本章的范疇只限定在確定軟件開發的基本原則，解析他們是如何影響開發計劃的，同時提供參考信息。 本章書把軟件開發基本原則實踐分為三類：管理實踐，技術實踐和質量保證實踐。 管理的基本原則 管理原則由以下幾部分組成：
1. 項目估算和進度安排 一個運行良好的項目一般通過三個基本步驟來定制軟件開發進度表。
如果估算不準確就會降低開發效率，所以說估算和項目進度計劃是軟件開發的基礎。精確的估算時進行有效規劃的必要前提，而有效的規劃又是有效開發的必要條件。 2. 計劃編制 計劃一個軟件項目應該包括以下活動：
3. 跟蹤 跟蹤是一個基本的軟件管理行為。如果不跟蹤一個項目就不能管理它，就不會知道計劃是否被貫徹執行了，也不會知道下一步該做什么，同時也無法監控項目風險。有效的跟蹤能使項目組在還有時間做點什么來改正錯誤的時候，盡早發現進度表上的問題。 制定了一個項目計劃就要跟蹤檢查它是否在按計劃進行，包括對它的進度、費用和質量等目標的檢查。典型的管理級跟蹤控制包括：任務列表、進展狀況會議、進展報告、里程碑審查、預算報告以及走查管理等。典型的技術級跟蹤包括：技術審查、技術審計和標志著里程碑是否完結的質量關口等。
圖 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） 設計是系統構建、項目進度計劃、項目跟蹤和項目控制的基礎。 體系結構和設計的基本原則：
3. 構建 當構建開始時，項目成功與否大多就已經注定了。需求管理和設計對開發進度計劃的調節作用比構建的調節作用大得多，這意味著小的波動可以導致進度的重大變化。 盡管構建是一個低層次的活動，但是它確實可以提供許多機會進一步改進時間效率低的任務或優化一些任務。例如，花時間對那些無需鍍金的功能進行鍍金；調試那些無用的多余代碼，或者對那些并不知道是否需要優化的片段盡心優化。 構建的基本原則：
4.軟件配置管理 軟件配置管理(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） 該文章在 2012/4/9 10:34:36 編輯過 |
關鍵字查詢
相關文章
正在查詢... 
|
400 186 1886
