軟件質量是什麼

衆所周知軟件質量是軟件產品之本，但軟件質量究竟是什麼？咱們真正地理解了軟件質量嗎？一說到軟件質量，在頭腦中很容易想到它應當知足用戶的需求、用起來方便以及含有儘量少的缺陷（bug或defect），等等。若是一個產品已經開發出來了，那缺陷儘量的少這一指標就顯得尤其突出，所以，潛移默化地，缺陷少成爲了高質量軟件的代名詞。

缺陷少真的就意味着是高質量軟件嗎？筆者認爲否則！這是由於軟件質量的高低從不一樣的層面去考察，其評估標準是不同的。站在軟件用戶的角度來看，缺陷越是少說明質量越是高，這應當是合理的，後面咱們稱這種高質量標準爲用戶級的高質量。可是，站在開發團隊的角度，高質量的軟件應當不只僅只意味着缺陷少，而是還有其它內容。試想，若是一個軟件的缺陷的確少，可是開發團隊爲了實現這一目標卻要花費並不相稱的超額努力，這種軟件能稱之爲高質量嗎？

什麼又是超額努力呢？從項目團隊不一樣職能人員的角度來看，其結果可能大爲不一樣。或許，有的項目相關人員認爲只要在計劃時間內完成了開發工做就不存在超額努力，至因而否存在大量的加班加點那也無所謂。軟件開發是否存在超額努力，參與其中的一線開發工程師最瞭解！若是開發人員爲了在計劃時間內加班加點，或者開發工做作得心力憔悴，或者感受工做再繼續進行下去產品質量在將來也不樂觀，那這些可能都代表開發團隊正在付出超額努力。由此看來，軟件的質量不能片面的從軟件用戶的角度去看，而應當深刻到從開發團隊的角度去理解，這種高質量標準稱之爲開發團隊級的高質量。真正高質量的軟件不能只知足缺陷少這樣單一的條件，更應當包含開發團隊能保持良好士氣且從容地從事軟件開發工做以及維持團隊個體正常的生活質量。顯然開發團隊級的高質量涵蓋了用戶級的高質量，且提出了更高的要求。開發團隊級的高質量更可能從長遠的角度保證用戶級的高質量，不然，用戶級的高質量有可能只是曇花一現。咱們的風險管理是否考慮過如何從長遠保證用戶級的高質量呢？若是要考慮，必須考慮作到開發團隊級的高質量，不然只能是空談。

由此看來，在軟件行業可能存在一種誤解，即將缺陷少是高質量軟件的必要條件當成了是高質量軟件的充分必要條件。另外，業內的很多質量管理體系是從缺陷數量這個角度出發的，而從這裏的分析來看，其存在必定的片面性。由於，這種管理方式並無切中「高質量」的要害，沒有將開發團隊的健康成長做爲其考察質量的因素之一。那要作到開發團隊級的高質量，技術方面的關鍵又是什麼？軟件設計質量！（什麼是軟件設計請參見《什麼是軟件設計》一文）

那如何保證設計質量呢？這很容易讓人想到開發流程和認證，好比敏捷軟件開發、CMMI認證等等，其實認證的本質仍是流程。可是，設計質量是不能簡單地經過流程而得到的，由於流程所控制的是看得見的東西，而軟件設計過程不少是發生在人的大腦當中的。要保證設計質量人是關鍵，這種人明白什麼是軟件設計以及擁有本身的設計思想並付之於項目實踐。還有，掌握軟件設計比理解業務需求更加的難，開發團隊不多由於理解不了業務需求而沒法開發產品，但是由於不理解軟件設計從而身受其苦卻並很多見。

軟件設計能力很抽象，但不能由於抽象就不重視它，軟件開發團隊應當以培養和打造本身的核心設計骨幹做爲本身的重要內容之一。因爲具有軟件設計能力的工程師是稀缺資源，不能期望項目組中的每個人都是真正的設計者，也就是說軟件開發工程師並不等同於軟件設計師（或者說軟件開發不等同於軟件設計），這一點咱們必須清楚地認識到。軟件開發團隊的組織結構形式應當如《人月神話》中所提出的，採用與「外科手術式隊伍」相相似的組織形式。在外科手術中，操刀的人只能是主刀醫生一我的，而不是手術室中的每一個人，其它的人都是主刀醫生的助手。採用相似於外科手術式的隊伍組織軟件開發，有助於保持軟件的一致性，更加容易體現思想性。另外一個例子是，假如十我的在一塊兒吃飯，若是每一個人都點一個菜，則更難達到葷素搭配這一要求，要作到也須要花費更多的溝通成本。相反，若是是由一我的點菜，則更容易作到這一點，固然這裏的假設是這個點菜的人具有點菜應當葷素搭配這一思想。在外科手術式的開發隊伍中，「主刀醫生」能夠徵求他人的意見，可是最終仍是由「主刀醫生」決定如何「下刀」。另外，與真正的外科手術不一樣的是，在軟件項目中「主刀醫生」並非真正地只能有一個，而多是由2、三我的組成的「主刀醫生」小組。