軟體質量基本概念

broadviewbj發表於2012-11-28

如何理解軟體的質量

什麼是質量?
詞典的定義是:① 典型的或本質的特徵;② 事物固有的或區別於其他事物的特徵或本質;③ 優良或出色的程度。
CMM對質量的定義是:① 一個系統、元件或過程符合特定需求的程度;② 一個系統、元件或過程符合客戶或使用者的要求或期望的程度。
上述定義很抽象,軟體開發人員看了準會一臉迷惘。軟體的質量不容易說清楚,但我們今天非得把它搞個水落石出不可。
就以健康做類比吧。早先人們以為長得結實、飯量大就是健康,這顯然是不科學的。現代人總是透過考察多方面的生理因素來判斷是否健康,如測量身高、體重、心跳、血壓、血液、體溫等。如果上述因素都合格,那麼表明這人是健康的。如果某個因素不合格,則表明此人在某個方面不健康,醫生會對症下藥。同理,我們也可以透過考察軟體的質量屬性來評價軟體的質量,並給出提高軟體質量的方法。
一提起軟體的質量屬性,人們首先想到的是“正確性”。“正確性”的確很重要,但執行正確的軟體就是高質量的軟體嗎?不見得,因為這個軟體也許執行速度很低,並且浪費記憶體,甚至程式碼寫得一塌糊塗,除了開發者本人誰也看不懂,也不會使用。可見正確性只是反映軟體質量的一個因素而已。
軟體的質量屬性很多,如正確性、精確性,健壯性、可靠性、容錯性、效能、易用性、安全性、可擴充套件性、可複用性、相容性、可移植性、可測試性、可維護性、靈活性等。除此之外還可以列出十幾個,新詞可謂層出不窮。
上述這些質量屬性“你中有我,我中有他”。如果開發人員每天都要面對那麼多的質量屬性咬文嚼字,不久就會迂腐得像孔乙己,因此我們有必要對質量屬性做些分類和整合。質量屬性可分為兩大類:“功能性”與“非功能性”,後者有時也稱為“能力”(Capability)。
從實用角度出發,本章將重點論述“10大”質量屬性,如表1-1所示。
表1-1 “10大”軟體質量屬性

功 能 性
正確性(Correctness)
健壯性(Robustness)
可靠性(Reliability)
非 功 能 性
效能(Performance)
易用性(Usability)
清晰性(Clarity)
安全性(Security)
可擴充套件性(Extendibility)
相容性(Compatibility)
可移植性(Portability)

 
其中,功能性質量屬性有3個:正確性、健壯性和可靠性;非功能性質量屬性有7個:效能、易用性、清晰性、安全性、可擴充套件性、相容性和可移植性。
為什麼碰巧是“10大”呢?
不為什麼,只是方便記憶而已(如同國際、國內經常評“10大”那樣)。
為什麼“10大”裡面不包括可測試性、可維護性、靈活性呢?它們不也是很重要的嗎?
它們是很重要,但不是軟體產品的賣點,所以擠不進“10大”行列。我認為如果做好了上述“10大”質量屬性,軟體將會自然而然地具備良好的可測試性、可維護性。人們很少純粹地去提高可測試性和可維護性,勿要顛倒因果。至於靈活性,它有益處也有壞處,該靈活的地方已經被其他屬性覆蓋,而不該靈活的地方就不要刻意去追求。
根據經驗,如果你想一股腦兒地把任何事情都做好,結果通常是什麼都做不好,做事總是要分主次的。什麼是重要的質量屬性,應當視具體產品的特徵和應用環境而定,請讀者不要受本書觀點的限制。最簡單的判別方式就是考察該質量屬性是否被使用者關注(即賣點)。
質量的死對頭是缺陷,缺陷是混在產品中的人們不喜歡、不想要的東西。缺陷越多質量越低,缺陷越少質量越高。
Bug是缺陷的形象比喻,人們喜歡說Bug是因為可以把Bug當作“替罪羊”。軟體的缺陷明明是人造成的,有了Bug這個詞後就可以把責任推給Bug——“都是Bug惹的禍”。唉,當一隻Bug真是太冤枉了!
軟體存在缺陷嗎?是的,有以下典故為證。

錯誤是嚴重的缺陷。醫生犯的錯誤最終會被埋葬在地下,從此一了百了。但軟體的錯誤不會自動消失,它會一直騷擾使用者。據統計,對於大多數的軟體產品而言,用於測試與改錯的工作量和成本將佔整個軟體開發週期的30%,這是巨大的浪費。如果不懂得如何有效地提高軟體質量,專案會付出很高的代價,你(開發人員)不僅沒有功勞,也沒人欣賞你的苦勞,你擁有最多的將只是疲勞。
怎樣才能提高軟體的質量呢?
還是先來聽一箇中國郎中治病的故事吧!

提高軟體質量的基本手段是消除軟體缺陷。與上述三個郎中治病很相似,消除軟體缺陷也有三種基本方式:
(1)在開發過程中有效地防止工作成果產生缺陷,將高質量內建於開發過程之中。這就是“預防勝於治療”的道理,無疑是最佳方式,但是要求開發人員必須懂得正確地做事(門檻比較高)。我們學習“高質量程式設計”的目的就是要在幹活的時候一次性編寫出高質量的程式,而不是在程式出錯後才去修補。
(2)當工作成果剛剛產生時馬上進行質量檢查,及時找出並消除工作成果中的缺陷—這種方式效果比較好,人們一般都能學會。最常用的方法是技術評審、測試和質量保證等(詳見本章1.4節),已經被企業廣泛採用並取得了成效。
(3)當軟體交付給使用者後,用著用著就出錯了,趕緊請開發者來補救,這種方式的代價最高。可笑的是,當軟體系統在使用者那裡出故障了,那些現場補救成功的人倒成了英雄,好心使用者甚至還寄來感謝信。J
質量的最高境界是什麼?是盡善盡美,即“零缺陷”。
“零缺陷”理念來源於國際上一些著名的硬體廠商。儘管軟體的開發與硬體生產有很大的區別,但我們仍可以借鑑,從中得到啟迪。
人在做一件事情時,由於存在很多不確定的因素,一般不可能100%地達到目標。假設平常人做事能完成目標的80%。如果某個人的目標是100分,那麼他最終成績可達80分;如果某個人的目標只是60分,那麼他最終成績只有48分。我們在考場上身經百戰,很清楚那些只想混及格的學生通常都不會及格。即使學習好的學生也常有失誤,因而捶胸頓足。
做一個專案通常需要多人協作。假設某系統的總質量是10個開發人員的工作質量之積,即最高值為1.0,最低值為0。如果每個人的質量目標是0.95,那麼10個人的累積質量不會超過0.598。如果每個人的質量目標是0.9,那麼10個人的累積質量不會超過0.35。只有每個人都做到1.0,系統總質量才會是1.0。只要其中一人的工作質量是0,那麼系統總質量也就成了0。因系統之中的一個缺陷而導致機毀人亡的事件已不罕見。
上述比喻雖然嚴厲了一些,但從嚴要求只有好處沒有壞處。如果不嚴以律己,人的墮落就會很快。如果沒有“零缺陷”的質量理念,也許缺陷就會成堆。
從理念到行動還是有一定距離的,企業在開發產品時應當根據自身實力和使用者的期望值來設定可以實現的質量目標。過低的質量目標會毀壞企業的聲譽,而過高的質量目標則有可能導致成本過高而拖累企業(請參見本章1.3節)。
 
 
本文節選自《高質量程式設計指南:C++/C語言》

林銳,韓永泉編著
電子工業出版社出版

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/13164110/viewspace-750101/,如需轉載,請註明出處,否則將追究法律責任。

相關文章