做軟體質量管理需要方面的知識，度量要如何開展？

01-08

非高手，純屬個人理解；先了解下軟體與傳統製造業的區別如下圖

在製造業中，生產活動佔有不可忽視的地位，它所需要的成本投入、人員、場地等都是設計工作無法相比的，而軟體恰恰相反。軟體開發相當於製造業的產品設計；而軟體的生產是指軟體開發完成以後將代碼往各種介質上拷貝，這部分工作無論是技術含量還是投入的人力、物力都極為有限,特別是在批量生產的條件下，這種差別更為明顯，主要表現如下：

1.傳統的製造業在得到產品後，必須在運輸和倉儲方面做出相應的安排，付出必要的代價。而對軟體來說，這些需求是微乎其微的，甚至可以忽略不計。

2.軟體產品的功能度和複雜性要比製造業產品高得多，它在投入使用後，所能發揮的功能也是其他任何硬體產品無法相比的。

所以，製造業或硬體的質量問題主要反映在生產和儲運過程中，而軟體產品的質量問題主要來自開發過程。國外很多的大公司，QA的職責就是測試（主要是系統測試）。最初，幾乎所有的公司都是這樣的。後來，由於需求越來越多又缺乏有效的項目計劃和項目管理，留給系統測試的時間很少。另外，需求變化太快，沒有完整的需求文檔，測試人員就只能根據自己的想像和經驗來測試。這樣一來，產品的質量就參差不齊，事先預防的QA職能就應運而生。針對軟體方面也就有了SQA的工作，由於分工的細緻化，管理體系的複雜化，這些SQA人員將逐漸的轉化為SEPG人員，並且更加了解管理知識，而SQA工作漸漸成為他們的兼職工作。

軟體質量管理大致就是SQA的工作，那就要了解軟體工程理論；了解高成熟度的軟體開發過程的實施要求及方法；對項目日常活動與規程的符合性進行檢查；收集有效方法和項目經驗，提供過程改進依據；發現過程中存在的與標準軟體過程不符合問題，及時採取糾正措施，以確保項目過程的質量；對生命周期過程中創建的工作產品進行審計，驗證工作產品在格式和內容上是否符合適當的標準，來保證項目實施過程中產生的工作產品的質量；對處理過程改進意見和建議，負責流程文件的制定、試點和維護工作(每個公司的SQA的工作都有差別，所以就簡單說說通用的)。

需要的知識：

1 編程語言(這是廢話)，一定要參與軟體測試，只有這樣才能了解軟體的質量問題。

2 國家標準、行業標準、企業標準(這個你自己搞定)：GB/T19000-2000 idt ISO9000:2000 質量管理體系基礎和術語、GB/T19001-2000 idt ISO9001:2000 質量管理體系要求、GB/T19004-2000 idt ISO9004:2000 質量管理體系業績改進指南、《GB/T11457-1995 軟體工程術語》、《GB/T12504-1990 計算機軟體質量保證計劃規範》、《GB/T8566-1995 信息技術軟體生存期過程》、《GB/T8567-1988 計算機軟體產品開發文件編製指南》、《GB/T1526-1989 信息處理數據流程圖、系統流程圖、程序網路圖和系統資源圖的文件編製符號及約定》、《GB/T12505-1990 計算機軟體配置管理計劃規範》、《GB/T17544-1998信息技術/軟體包/質量要求和測試附錄A / 附錄B / 附錄C》、《GB/T16260-1996信息技術/軟體產品評價/質量特性及其使用指南附錄A》等等(加上你們公司內部標準就差不多了)。

3 質量方面的書：就如@Lynn凌雲所說。

如何度量：推薦ISO/IEC 9126(大致如下圖)：

還有個Mccall質量度量模型(大致如下圖)：

如何展開：推薦CMMI模型。也可根據上文中如何度量展開。

觀點：在開發過程中有效防止軟體產生缺陷，主要措施就是「不斷提高技術水平，不斷提高規範水平」，其實就是「軟體過程改進」。當軟體剛剛產生時馬上進行質量檢驗，及時找出消除軟體中的缺陷，最常用的方法是技術評審、軟體測試和過程檢驗(無論製造業還是軟體業的質量問題，都是越早發現損失就越少的)。

職責：質量人員負責制定質量計劃(細分為：質量要素分析、質量目標、人員與職責、過程檢查計劃、技術評審計劃、軟體測試計劃、缺陷跟蹤方法、審批意見)、過程檢查(找出不符合規範的工作過程和工作成果，及時與開發人員溝通解決)、技術評審、軟體測試、軟體過程改進。任何與軟體開發、管理工作相關的人員都會對質量生產影響，都要對質量負責。所以不能把質量問題簡單推到質量人員和測試人員那，誰的權力越大他的質量責任就越大。隨便寫寫，最後一句話：開發軟體產品或發展傳統製造業都是為了賺錢，那麼提高軟體或傳統製造業的質量，所付出的代價是有上限的，所以不要太吹毛求疵了。利潤才是王道(開玩笑，哈哈)。歡迎有興趣的知友繼續回答。

謝邀。未涉及過軟體行業。無法提供具體的建議。對於質量的理解，推薦幾本書單：

1、《朱蘭手冊》把質量計劃、質量控制、質量改進那幾章讀透了基本上對質量會有全新的理解。常讀常新；

2、《質量免費》克勞士比質量行業大師不多。朱蘭注重應用，克勞士比可以讓你學會以「以質量的思維方式」思考

3、《卓有成效的管理者》彼得德魯克的經典，站在管理的角度去思考，結合質量免費。對質量管理工作的性質、價值以及管理體系有效性會有幫助。

相信我。上面說的這基本書，可能對於你的實際工作（軟體質量管理）沒有太大實際的幫助。但這些書實際給出了質量管理工作需要關注的方面：具體的質量技術、質量的思維、管理的思維。

以上建議僅站在「質量」的角度回答。關於「軟體質量管理」歡迎其他高手回答。謝謝。

路過，

軟體質量管理應具備哪些知識？-

事實上，軟體質量管理（Software Quality Management）分為兩種，一種是以TESTER的角色對軟體質量進行管理，另一種是現在興起的SQA從過程角度對SW進行管理。

這裡，我們暫且只討論後者。

所以，High level上來說，要做好SQA，從業人員應具有軟體工程的知識、軟體開發的知識、行業背景的知識、數理統計的知識、項目管理的知識、質量管理的知識等等。

a) 對規範的掌握和對業務的理解

1) 熟悉規範：QA人員應對屬於所在組織的「研發管理規範」非常熟悉，只有自己熟悉了規範，才能更好地監察以及指導項目團隊。所以，質量管理人員應該是項目里最熟悉章程的那個人。

2) 了解業務：以我自己來說，所處automotive行業，要盡量去弄清楚這個行業有哪些key feature, 對業務了解了，你跟項目團隊才能有共同語言。網上有張對項目經理的調侃圖，

項目經理應該具備的硬技能，一個質量管理人員也應具備，對需求、策劃、設計、編碼、測試等均應該有較深的理解。項目經理跟 QA的關係可以理解成一個是執行者，一個是判斷執行者是否正確執行的。

這就是，你在做什麼，都被我看穿了~哈哈哈。所謂知己知彼，百戰不殆嘛。

不過這是對QA的終極要求，正常情況下，QA即使不具備編碼測試的能力的話，那麼至少也要了解編碼規範，清楚知道研發測試的流程和互相的制約關係。比如不熟悉軟體測試的方法和技術，就無法判定設計的測試用例是否能夠完全覆蓋需求，只能簡單的進行型式審查，QA就僅浮在表面了。

*************

推薦可以看看PMP，敏捷，CMMI。這些模型其實很多共性，看的時候可以試著換位思考一下啊。

b) 意識。

軟體質量管理，其實最忌坐井觀天或者主觀。這個我是認為的軟技能，任何時候要站在過程的角度去看待問題，但是又不能過於拘泥於章程。

這一點，需要通過積累項目經驗，以及平時多思考。

你如果注意觀察，會發現好的軟體質量管理，都是很善於思考的，並且很會舉一反三。

每一個項目周期結束（就像升級打怪），會總結的都成長得特別快~

c) 溝通

溝通在任何行業都很重要。每一個Run的好的項目後面都有一個善於溝通，推動團隊，激發團隊執行力的項目經理。

要做好軟體質量管理者，善於溝通也一定是必備技能。試想，在生活中，我們要說服改變一個人的觀念尚且艱難，更何況在企業中，尤其涉及眾多干係人的項目，要改變一群人的觀念何其不易？不知道是不是很多QA都會有　一個人對抗一群人的無力？

所以立足於如上，是可以成為一個好的軟體質量管理人員的。

&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>&>

關於度量。

度量是我認為在軟體質量管理中至關重要，又尤為複雜的一個環節。（很多人習慣稱為KPI).

可參考 IEEE Std. 1061-1998 for a Software Quality Metrics 。

感興趣的可以去學習一下CMMI 的MA和QPM兩個過程域。

不講廢話，那麼度量應該如何有效開展呢？

1. 首先一定要弄清楚，度量什麼？項目的數據散落各地，每一個好像都很有用，經常會發現各個項目組的關注點不同，有的喜歡考評工期，有的喜歡考評工作量。孰是孰非，度量是沒有統一的標準的。

所以，立足點就是組織的一級目標，度量最好就是按TQM的思想，一級級分解，將組織級的宏偉目標分解為一個個可度量可執行的小目標。

舉一個栗子，前公司某二級部門的質量目標是提升客戶滿意度。

這個比較虛，很感性化。如何是好，如何不好？

那麼細化到子部門，我們將它分解為

1.交付日期(是否按項目計劃交付）

2.缺陷數目（每次交付版本的bug數）

3.響應時間（客戶問題的響應時長，有沒有1天內響應，3天內給出方案和解決時間等等）

4.缺陷關閉周期（每個缺陷按嚴重程度大致解決周期多長）

這樣一分解，是不是就可以有效剔除那些看上去很合理實際上卻沒有什麼用的度量項？

度量是個很高深的學問，知道了度量什麼，還要巧用這些數據。數據會告訴我們很多事實和日常管理中忽略的問題。多看看數據的趨勢圖，多分析。

（一個字一個字敲出來的，經驗之談，輕拍）

粗答一發，見笑。

軟體質量一般分為三個維度，functional quality, structural quality, process quality.

Functional quality 就是功能上對需求的滿足程度，是用戶能夠感覺到的。

Structural quality 指軟體內部編碼的特性，是不是安全的，是不是易於測試的，這部分是最難去衡量的。有很多工具，很多度量可以來選擇，如缺陷率，函數複雜度，缺陷密度等等。

Process quality 指軟體被開發出來的過程。穩定的軟體是一定基於嚴謹的過程的，所以現在automotive SPICE 會被拿來作為準入門檻。因為軟體90%特性都是看不到的，我們只能通過生產他的過程來評判

可以看看《軟體研發成本度量規範》

推薦溫伯格的《質量·軟體·管理》三冊書，看完會有系統性的認識。