軟體品質保證.ppt

同仁審查 由產品製作人之同仁進行審查。 基本上，上層主管不參與，以避免審查失焦問題的發生，因審查焦點應在產品而不是人。 Chap 4軟體品質保證 目的 軟體品質保證(Software Quality Assurance, SQA)根據軟體品質管理計劃，執行一系列「計劃性」及「系統性」軟體品質活動，以期軟體品質滿足品質需求。 好的軟體品質保證 清楚的目標，標準。 著重預防性的活動。 記錄並產生相關文件。 持續性的改進，經驗學習。 獨立的品質稽查。 軟體品質保證單位主要活動 擬定品質政策與策略 制定品質計畫與管理制度 定期執行品質計畫與控制 重大品質案件的處理 品質教育訓練工作 獎勵推行品質管理績優人員 軟體品質保證計畫 根據IEEE(1987)對軟體品質保證計畫的內容規定如下： 1.目的(Purpose) 2.參考文件(Reference Documents) 3.管理(Management) 4.文件(document) 5.標準、應用與慣用語(Standards, Practices and Conventions) 6. 審查與稽核(Reviews and Audits) 7.軟體型態管理(Software Configuration Management, SCM) 8.問題報告與修正計畫(Problem Reporting and Corrective Action) 9. 工具、技術與方法論(Tools, Techniques and Methodologies) 10.原始碼控制(Code Control) 11.媒體控制(Media Control) 12.供應商控制(Supplier Control) 13.紀綠蒐集、維護與保存(Records Collection, Maintenance and Retention) 軟體開發各階段SQA主要工作 軟體開發各階段SQA主要工作 軟體品質保證基本活動 審查 (Reviews) 瀏覽 (Walkthrough) 檢驗 (Inspection) 稽核 (Auditing) 審查 (Reviews) 透過會議方式找出潛在的錯誤，以確保品質水準。 目的：事先盡早發現錯誤，以降低失敗成本及提升軟體品質。 審查重點 風險分析 系統需求與限制交替分析 作業順序 架構評估 系統切割 介面 系統規格、功能、品質 測試報告等 正式審查程序 1.開發人員需準備審資料，並事先發給參與人員。 2. 審查人員閱讀資料，以找出潛在問題。 3. 選定會議主席。 4. 開發者提出報告。 5. 審查者逐一審查。 6. 做出審查結論。 7. 記錄結果以累積經驗。 非正式審查 不須召開正式會議，也未必邀請使用者參與。 採私下徵詢同事、同行專家的意見,或透過角色的扮演從不同的角度提出觀點。 優點：時效性佳、成本低、機動性強。 缺點：開發人員必須自行綜合多數人的意見。 瀏覽 (Walkthrough) 針對需求規格文件、設計文件、程式碼、測試計畫，進行內部非正式的快速審查程序。 目的：盡早偵測出一些潛在的錯誤，並立即採取修正的作法。 檢驗 (Inspection) 與審查有相輔相成效果。 較審查深入，由有經驗的專家來檢驗。 深入技術性問題、較複雜問題。 檢驗已完成的設計文件或程式碼。 檢驗須依特定的步驟進行：規劃、簡報、會議前的準備、進行、重作與跟催。 檢驗者須扮演特定角色：召集人、記錄人、閱讀人、原作者。 檢驗過程，原作者應在場並參與檢驗。 稽核 (Auditing) 確保軟體能夠達到合約的規格與標準，定期實施稽核工作，以提早發現軟體的缺失並發現問題的原因。 實施稽核過程: 主持人向接受稽核的單位宣布稽核的工作項目、時間表以及參與的工作人員。 實施稽核作業。 記錄稽核結果，並送給品保單位做進一步分析用途。 比較表 軟體品質保證其他工作 軟體品質保證亦可包含： 軟體型態管理 軟體測試 … 確認與驗證 (VV) Verification – are we building the product correctly? 確認 – 把產品做得正確無誤了嗎? 確認軟體可以正確地執行特定功能的一些活動。 Validation – are we building the correct product? 驗證 – 做了對的產品了嗎? 是否做了使用者真正要的產品。 確認所開發的軟體可以追溯到客戶需求的一些活動。 註：Verification 與 Validation翻譯尚未統一，有些書籍與此翻譯顛倒。 確認與驗證 與