軟件質素管理

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書

軟件質素管理（Software quality management，縮寫SQM）是一種管理流程，目標在發展與管控軟件的質素，確保產出的成品可以滿足用戶的需求。軟件質素管理人員在產品正式發行之前對其進行質素測試，並且執行一系列稱之為軟件週期的步驟，為了在軟件發佈前預先發現並修正錯誤。他們（軟件質素管理人員）的工作不僅是確保軟件產品為消費者期待的型態，且經由正確的開發流程來保護他們的軟件產品，並對流程中的每一位成員提倡質素文化，避免欺騙行為的發生。

定義[編輯]

軟件質素管理（SQM）的目標為管理軟件開發過程中與開發完成後的軟件質素，一個優質的產品必須符合質素的要求條件，並且滿足用戶的需求。質素文化是指在一個組織環境中，質素被視為每個人的責任義務。

  • 軟件質素要求條件：[1][2]
    • 確認的目標與架構的範圍。
    • 監督專案的執行查核。
    • 差異的協調與調整。
    • 預防重複性的活動。
    • 執行歷程的書面紀錄。

描述[編輯]

Ian Sommerville[3]著作的軟件工程書籍中使用了傘狀概念的軟件質素管理，該概念包含以下軟件質素層級：

  • 軟件質素保證（SQA）層級，組織的質素指南包含：
    • 在軟件開發生命週期中的標準、法規與程式以生產、確認、測試與確認上線運作；
    • 整合最佳實務知識庫；
    • 選擇現成的軟件來套用以上程式。
  • 軟件質素計劃（SQP）層級：一個軟件質素管理的階段，每個專案皆需要撰寫，用以表示軟件開發專案周期內，專案的承諾與遵從的標準、規範、程式與工具。此外，SQP也包含了要實現的質素目標、風險預估、與風險管理。SQP來源衍生自
    • SQA元件的被採納使用或客製化以專案需求為主；
    • 新流程、標準與工具補充了被註記在專案的特別項目或從組織外部匯入的缺失與不合用的SQA元件。任何軟件質素保證（SQA）中的軟件質素計劃（SQP）偏失，都需要經由專案經理證明，並經由公司管理階層確認。
  • 軟件質素控制（SQC）層級：確保軟件開發過程中，皆有遵循SQA與SQP規範。軟件質素控制的作業包含：
    • 指導如何製作與開發物件（成果），例如事先定義的工程檔案與標準範本；
    • 指導如何進行標準流程，例如質素檢閱；
    • 執行線上質素檢閱、以驗證、評估、與確認開發物件（成果）；
    • 驗證與評估用以改善使用的方法、流程以及被採用的軟件工具。

軟件質素管理（SQM）規則[編輯]

  • 確保軟件產品達到質素可接受度；
  • 提倡全公司層級的「質素文化」概念為全體員工的責任；
  • 減少學習曲線與幫助團隊成員改變組織內部職位的連續性；
  • 在開發過程中啟動流程錯誤迴避與錯誤預防。

許多人交替使用SQM（軟件質素管理）與SQA（軟件質素保證）概念

  • 軟件質素管理 (SQM) 必須有效地為質素保證活動部署資源，以反映實現的產質素量，其更廣泛定義，包含可重用性和可維護性[4]。

質素保證和標準

  • 標準(standard)是達到有效質素管理的關鍵，可以是國際、全 國、組織或專案的標準。
  • 產品標準(product standard)定義所有元件需呈現(exhibit)的特 性(characteristics)，如程式語言風格(programming style)。
  • 流程標準(process standard)定義軟件流程扮演角色(how the software process should be enacted)。

軟件質素管理（SQM）與軟件生命周期（software lifecycle）[編輯]

軟件質素管理能夠以不同的方式實現，取決於組織與實際專案的類型，[5] 但是應該都包含在整個軟件開發周期範圍，

意味：

  • 收集需求與定義IT專案的範疇，如果需求是可測試的，則着重於檢驗。最後產生測試策略。
  • 設計解決方法，着重於計劃測試步驟，例如可執行哪些類型的測試、如何在測試環境下執行、與測試資料取得，最後產生測試計劃或是測試排程。
  • 建置解決方案，透過建立測試案例、測試情境、執行項目以及登記缺陷、修正狀況、與重複性測試的報告之程式。
  • 變更管理，透過確認如何計劃變更能夠影響解決方案建立的質素以及測試計劃的最終變更，最後產出測試計劃、測試案例與測試情境。
  • 結束計劃，透過實際測試的重點集中在復雜的檢驗，以建立解決方案的整體質素，包含了系統整合測試、用戶驗收測試與運行驗收測試，最後產生系統建議上線時間。[6]
  • 為實現項目目標或目的而進行的活動邏輯序列[7]。
    • (1)啟動：定義輸出和關鍵成功因素；
    • (2)規劃：將項目縮小為可管理範圍/任務；
    • (3)執行：項目計劃執行；
    • (4)監測：實際項目活動以基線為基準；
    • (5)關閉或退出：最終完成項目。
  • 對軟件專案開發進行有效管理的作業，質素管理係扮演了一個軟件專案開發過程中扮演了關鍵性角色（Reel, 1999 ; Karl, 2008）。
  1. 確保軟件產品達到所需的質素層次(required level of quality)。
  2. 包括定義適當的質素標準和程式(procedures)，並確保遵循這些標準和程式。
  3. 專注於發展質素文化(quality culture)，質素被視為每個人的責任。

軟件質素管理（SQM）風險管理[8][編輯]

1. 什麼是風險？

風險是一個問題「……它可能在未來發生並產生不想要的後果」（SPILLNER 等人，2008 年）。 風險可以表示為損壞量和損壞概率的乘積（SPILLNER & LINZ 2005）。


2. 風險和軟件

軟件系統的故障會給企業帶來沉重的風險。一個例子發生在 2009 年，當時軟件錯誤使德國最大的移動電信提供商 T-mobile (http://www.spiegel.de/netzwelt/tech/0,1518,620388,00) 的整個移動電話網絡癱瘓。 html - 27/4/2010）。當與安全相關的軟件出現故障時，例如飛機的軟件，甚至可能危及人的生命。 NEUMANN (1995) 提供了一個令人印象深刻的列表，說明資訊科技系統中的故障如何導致嚴重事故和人員傷亡。因此，軟件必須具有足夠的質素以防止此類事件。


根據 PINKSTER 等人的說法。 (2006)，所有與軟件測試項目相關的風險都可以分為兩類，即項目風險和產品風險。 PINKSTER 等人。將項目風險定義為與測試過程管理相關的風險。它們進一步區分了與時間和預算相關的業務相關項目風險與 ICT 相關項目風險，例如不穩定的測試環境。根據這些作者的說法，軟件測試人員主要關注第二類風險，也可以分為「業務」和「ICT」相關的產品風險。為了更好地了解這些風險類別，


3. 根據 PINKSTER 等人的說法。 (2006)，軟件測試背景下的結構化風險管理過程包括以下步驟：

- 風險識別

- 風險分類與評估

- 風險分配和選擇

- 風險監控


4. 風險識別與分類

BACH (1999a) 推薦了兩種風險識別方法（BACH 使用術語「風險分析」）： 由內向外分析和由外向內分析：由內向外分析從產品及其組件開始。 BACH 建議針對每個組件提出以下三個問題：

- 「漏洞：這個組件有什麼弱點或可能的故障？」

- 「威脅：可能存在哪些輸入或情況可能會利用漏洞並觸發該組件的故障？」

- 「受害者：誰或什麼會受到潛在故障的影響，會有多糟糕？」


這種分析方法試圖回答哪些風險與軟件產品的不同部分相關的問題。它可以涉及技術細節，因此需要技術洞察力。因此，應該與軟件開發商合作完成。

BACH 提出的由外而內的分析則相反：預先創建潛在風險列表，然後將其與產品的不同部分聯繫起來。例如，風險列表可以以質素標準為導向，因為問題被問及基於質素標準的要求不滿足會發生什麼情況。也可以有一個通用的風險列表，例如：

- 軟件的哪些部分是新的？

- 軟件的哪些部分非常複雜？


由外而內的分析還導致下一步，即風險分類。 與 BACH 的第二種方法類似，PINKSTER 等人。 建議根據 ISO 9126 的質素屬性對第一步中已經識別的產品風險進行分類。 作者通過將其應用於控制自動櫃員機的軟件使這一點更加清晰：

將產品風險與自動櫃員機 (ATM) 的質素屬性聯繫起來的範例


圍繞質素屬性對可能的風險進行分組可以幫助作為風險識別過程一部分的測試涉眾，以確保風險列表是完整的。 之後，可以開發針對每個質素屬性的第一個測試安排（PINKSTER 等人，2006 年）。


5. 風險評估

識別風險後，必須對其進行評估，以確定測試優先級。可以以定性方式評估風險，例如使用「MoSCoW」原則，這意味着每個產品風險都被分配到以下類別：必須測試、應該測試、可以測試、不會測試（PINKSTER 等人）。在這些類的幫助下，可以在測試過程中建立相互之間的優先級。使用上述的損壞量×損壞概率公式，也可以對風險進行量化評估。處理數學公式意味着必須為這兩個因素提供定量值，以實現可用於設置測試過程優先級的結果。在大多數情況下，量化將使用指標和尺度（例如「1」代表低，「2」代表中等，「3」代表高）而不是貨幣價值。


6. 量化損壞量（REDMILL 2004）

由於每個系統都有許多利益相關者，因此每個利益相關者的故障後果或損害程度可能不同。例如，銀行可能會運行一個銀行賬戶系統，該系統顯示客戶被拒絕訪問其賬戶的故障：從銀行運營商和維護的角度來看，這種故障的成本，即損失金額，可能很低人員。但如果這樣的失敗在媒體上發表，可能會導致聲譽損失，這可能會導致商譽下降、市場份額和營銷成本下降，以重新獲得公司以前的市場地位。從業務的角度來看，這樣的失敗繼承了巨大的損失。還可以從軟件開發人員的角度來估計可能的損失量：一定數量的失敗可能會導致失去在同一組織內贏得另一個項目的機會。因此，在估計軟件故障的後果時，必須預先定義從哪個角度考慮它們。


此外，必須從適當的來源獲取有關故障可能導致的損壞量的資訊。適當的來源是例如定義系統目標的人，例如高級經理或系統戰略家。

資訊技術（IT）相關方法[編輯]

軟件質素管理與專案管理各項主題有密不可分的關聯，開發與資訊技術（IT）的作業方式如下：

透過RUP與V-Model來實現軟件質素管理
  • 專案管理的PRINCE2（專案中可控制的環境）方法 [9] 定義：
  • 元件「專案環境質素」，描述了需要雙重檢查的必要性與建立產品的目標控制項目，相關展示了四個元件：質素管理系統、質素控制功能、質素規劃與質素控制。
  • 「質素檢閱技巧」專注於確認建立的產品是否符合定義的質素標準。
  • 專案管理 PMBOK（專案管理知識體系，第四版 [10]）方法論，定義了專案質素管理的知識領域與以下程式：
  • 3.4.12 規劃質素，
  • 3.5.2. 施行質素保證，
  • 3.6.7. 施行質素控制
  • 統一軟件開發過程（RUP） 開發方法定義了測試規範，為所有階段以構思階段為開始，以移交階段做為結束。
  • 微軟解決方案開發框架（MSF）開發方法定義了測試員的規則與穩定階段，着重於測試解決方案。[11]
  • 敏捷軟件開發（Agile software development）不需要精確定義測試者的規則或者機制，涉及軟件質素管理。敏捷法只定義持續整合與測試驅動開發。雖然，最後出現了敏捷測試。
  • 能力成熟度模型整合（CMMI） 操作法定義中，有關於PPQA（程式與產品質素保證）的程式領域，相關紀載於CMMI第二階。
  • 資訊及相關技術控制目標（COBIT）操作法定義中，被定義為P08質素管理。
  • 資訊科技基礎架構庫（ITIL）操作法定義中，被定義為發行持續性改善。
  • V模型（V－Model）模組–定義了軟件開發周期與測試程式。
  • ISO 9000－一系列標準具有關於質素管理系統的標準以及設計來協助企業組織確保相關生產合乎客戶的需求與其他相關利益者，以滿足與產品相關的法定和法規要求。

協會和組織[編輯]

  • ISTQB, 國際軟件測試認證委員會（International Software Testing Qualifications Board，簡稱ISTQB）是在比利時合法註冊的非營利軟件測試質素認證組織。它管理軟件測試人員的認證過程。 已有超過200.000份ISTQB®證書（日期：2012年3月）。[12]
  • ASQ （頁面存檔備份，存於互聯網檔案館），美國質素協會是一個基於知識的全球質素專業人士社區，近80,000名成員致力於在工作場所和社區中推廣和推進優質工具，原則和做法。

參見[編輯]

參考檔案[編輯]

本條目部分或全部內容出自以GFDL授權發佈的《自由線上電腦詞典》（FOLDOC）。

  1. ^ 郭忠義. 軟體品質管理 (PDF). [12-11-2021]. （原始內容存檔 (PDF)於2021-12-11）. 
  2. ^ Bishop, D., & Reeves, K. How to build a quality management climate in a small to medium enterprise. An action research project.. Lean Six Sigma. 2021 [2021-12-16]. （原始內容存檔於2021-12-16）. 
  3. ^ Ian Sommerville (2004), Software Engineering, 7th ed., chapter 27
  4. ^ Alexander Poth; Ali Sunyaev. Effective Quality Management: Value- and Risk-Based Software Quality Management. IEEE Software. 2014-11, 31 (6): 79–85. doi:10.1109/MS.2013.138. 
  5. ^ Kelemen, Z. D. (2013). Process Based Unification for Multi-Model Software Process Improvement （頁面存檔備份，存於互聯網檔案館） Eindhoven: Technische Universiteit Eindhoven. ISBN 978-90-386-3313-8
  6. ^ Software Quality Management. [2017-10-30]. （原始內容存檔於2006-06-04）. 
  7. ^ Wong, Whee Yen; Wen Yu, Su; Too, Chian Wen. A Systematic Approach to Software Quality Assurance: The Relationship of Project Activities within Project Life Cycle and System Development Life Cycle. 2018 IEEE Conference on Systems, Process and Control (ICSPC) (Melaka, Malaysia: IEEE). 2018-12: 123–128 [2021-12-16]. ISBN 978-1-5386-6327-1. doi:10.1109/SPC.2018.8703978. （原始內容存檔於2021-12-16）. 
  8. ^ Sickinger, Jan. Risk management in software quality assurance. https://www.grin.com/document/178001. [2022-01-06]. ISBN 978-3-640-99994-1. （原始內容存檔於2022-01-06） （德語）.  缺少或|title=為空 (幫助)
  9. ^ OGC (Office of Government Commerce) (2009). Managing Successful Projects with PRINCE2 (2009 ed.). TSO (The Stationery Office). ISBN 978-0-11-331059-3
  10. ^ A Guide to the Project Management Body of Knowledge, Fourth Edition, PMI, USA, 2008
  11. ^ Microsoft Solution Framework - Chapter 18 Stabilization phase, Published: April 27, 2005 [1] （頁面存檔備份，存於互聯網檔案館）
  12. ^ ISTQB. [2017-10-30]. （原始內容存檔於2010-02-10）. 
質素
內部
外部
標準和列表
過程
取自 "https://zh.100ke.info/w/index.php?title=軟體品質管理&oldid=70481428"