Bài giảng Đảm bảo chất lượng phần mềm - Chương: Quản lý chất lượng phần mềm

 Đảm bảo chất lượng phần mềm 
 Software Quality Assurance 
Quản lý chất lượng phần mềm 
 1 
 Đảm bảo chất lượng phần mềm 
• Đảm bảo chất lượng phần mềm là đảm bảo dự án phần mềm sẽ hoàn 
 thành đúng đặc tả, theo chuẩn mực định trước và các chức năng đòi hỏi, 
 không có hỏng hóc và các vấn đề tiềm ẩn. 
• ĐBCLPM điều khiển và cải tiến tiến trình phát triển phần mềm ngay từ khi 
 dự án bắt đầu. Nó có tác dụng “phòng ngừa” cái xấu, cái kém chất lượng. 
• Mục tiêu cuối cùng của SQA là thỏa mãn khách hàng (costumer 
 satisfaction) 
 – Thời gian 
 – Ngân sách 
 – Chất lượng. 
 3 
Thuật ngữ 
• Error 
• Is a discrepancy between actual value of the output given by the 
 software and the specified correct value of the output for that given 
 input 
• Fault 
• Is a condition that causes a system to fail in performing its 
 required function 
• Failure 
• Is the inability of the software to perform a required function to 
 its specification 
 4 
Mục tiêu hoạt động ĐBCL trong PTPM 
• ĐB mức độ tin cậy là phần mềm sẽ tuân thủ các đặc tả chức năng đòi 
 hỏi. 
• ĐB mức độ tin cậy là phát triển phần mềm sẽ tuân thủ các yêu cầu về 
 quản lí và ngân sách. 
• Kiến tạo và quản lí các hoạt động cho cải tiến hiệu quả phát triển 
 phần mềm và các hoạt động ĐBCL. 
 5 
Đảm bảo chất lượng # testing 
• Đảm bảo chất lượng bao gồm một chuỗi các hoạt động nhằm ngăn 
 ngừa lỗi (defect prevention) 
• Test: Các hoạt động nhằm phát hiện lỗi (bug) trong chương trình 
 thông qua một tập hợp các test case. 
• Test có thể chỉ ra lỗi chứ không thể chứng minh là chương trình không có lỗi 
 6 
Các khía cạnh trong SQA 
• Kế hoạch ĐBCL 
 – Mô tả chất lượng mong muốn, thiết lập các tiêu chuẩn chất lượng và 
 cách đánh giá (đo) các thuộc tính chất lượng. 
 – Định rõ qui trình đánh giá chất lượng. 
 – Định rõ các chuẩn mực về quản lí (dùng chuẩn có sẳn/thiếp lập mới). 
• Kiểm soát chất lượng (Quality control) 
 • Bao gồm chuỗi các hoạt động: thanh tra, kiểm duyệt, kiểm thử để 
 đảm bảo sản phẩm tuân thủ các đặc tả. 
• Đảm bảo chất lượng (Quality assurance) 
 • Xác nhận (auditing) và báo cáo (reporting) về qui trình để cung cấp 
 thông tin quản lí và ra quyết định. 
 7 
Yêu cầu chung của SQA 
• Tuân thủ đặc tả là nền tảng để đo lường chất lượng. 
• Các chuẩn (standards) được xác định trước dùng để phát triển các 
 tiêu chí chất lượng và dẫn dắt quá trình kỹ nghệ. 
• Bên cạnh tuân thủ các yêu cầu tường minh (trong đặc tả), phần mềm 
 phải tuân thủ các đặc tả không tường minh như dễ dùng, dễ bảo trì, 
 tin cậy. 
 8 
Tiến trình ĐBCL 
 9 
Làm thế nào để đảm bảo chất lượng 
 • Nguyên tắc 1 : bài bản 
 • Qui trình đảm bảo chất lượng 
 – Chỉ rõ cách thức tiến hành ĐBCL 
 – Cách thức kiểm tra, giám sát ĐBCL 
 • Có tài liệu, số liệu về công tác ĐBCL: minh chứng 
 – Tài liệu về mọi hoạt động trong qui trình pm 
 – Tài liệu, số liệu kiểm tra giám sát 
 – Tài liệu đánh giá chất lượng: kế hoạch, số liệu 
 10 
Làm thế nào để đảm bảo chất lượng 
 • Nguyên tắc 2: không ngừng cải tiến 
 – Kế hoạch 
 – Thực hiện 
 – Kiểm tra 
 – Cải tiến 
 Cải tiến Kế hoạch Costumer 
 satisfaction 
 Kiểm tra Thực hiện 
 11 
Hoạt động của nhóm SQA 
• Lập kế hoạch ĐBCL. 
• Tham gia xây dựng qui trình PM. 
• Xem xét các hoạt động kỹ nghệ để kiểm tra tuân thủ chuẩn mực đã 
 được xác định cho qui trình. 
• Xác nhận mức độ đạt chuẩn mực. 
• Đảm bảo rằng sản phẩm trong quá trình phát triển được tài liệu hóa 
 và được kiểm soát. 
• Ghi nhận và báo cáo mọi sự vi phạm chuẩn mực. 
 12 
Các cách tiếp cận trong SQ 
1. Chứng minh đúng đắn (logic Hoare). 
2. Thống kê chất lượng 
 – Thông tin về hỏng hóc (defects) được thu thập và phân loại 
 – Xác định nguyên nhân hỏng hóc 
 – Áp dụng nguyên lý Pareto (80% of the defects can be traced to 
 20% of the causes) để cô lập nguyên nhân hỏng hóc. 
3. Cleanroom: tổ hợp hai điểm trên 
 Ngăn ngừa hỏng hóc (defect prevention) hơn là loại bỏ lỗi (defect removal) 
 13 
Chất lượng và công tác đảm 
bảo chất lượng 
 14 
Thảo luận 
• Liệt kê các yếu tố chất lượng của phần mềm 
• Liệt kê 
• Nêu ngắn gọn khái niệm 
• Sắp xếp các yêu tố chất lượng theo nhóm 
• Mối quan hệ giữa các yếu tố chất lượng 
 15 
Các yếu tố chất lượng 
• McCall’s quality factor model 
• 11 yếu tố chất lượng, nhóm theo 3 nhóm: 
• Vận hành sản phẩm: Correctness, Efficiency, Integrity, Usability 
• Xem xét lại sản phẩm: Maintainability, Flexibility, Testability 
• Chuyển giao sản phẩm: Portability, Reusability, Interoperability 
 16 
Product operation factors 
Correctness 
• Xác định một danh sách các output được đòi hỏi 
• Ví dụ: 
• The output mission (e.g. red alarms when temperature rises to 100 °C) 
• Required accuracy of the output (e.g. non-accurate output will not exceed 1%) 
• Completeness of the output info (e.g. probability of missing data less than 1%) 
• The up-to-dateness of the info (e.g. it will take no more than 1s for the 
 information to be updated) 
• The availability of the info (e.g. reaction time for queries will be less than 2s on 
 average) 
• The required standards and guidelines (the software and its docs must comply 
 with the client’s guidelines) 
 17 
Product operation factors 
Reliability 
• Định rõ xác suất vận hành không lỗi của một chương trình máy tính trong một 
 đơn vị thời gian hoặc tần suất xuất hiện lỗi cao nhất trong một đơn vị thời 
 gian 
 – Có thể đo bằng dữ liệu quá khứ và dữ liệu thu thập trong quá trình phát triển 
 – Có thể cho toàn bộ hệ thống hoặc cho 1 chức năng trong hệ thống. 
• Ví dụ: 
• Tần suất xuất hiện lỗi của bộ điều khiển nhịp tim là 1/20 năm. 
 18 
Product operation factors 
Efficiency & Integrity 
• Hiệu quả (Efficiency): 
• tài nguyên cần thiết (thời gian, bộ nhớ, lưu trữ) để vận hành nhằm đáp ứng 
 các yêu cầu. 
• Toàn vẹn (Integrity): 
 – Khả năng ngăn chặn truy cập trái phép 
 – Khả năng phục hồi nguyên trạng dữ liệu, trạng thái của hệ thống sau một tác vụ không 
 thành công. 
 19 
Product operation factors 
Usability 
• Tài nguyên con người cần thiết để tập huấn, dùng, vận hành hệ thống. 
• 
• Ví dụ: training of a new employee to operate the system will take no more 
 than 2 working days (16h) 
 20 
Product revision factors 
Maintainability 
• Tính bảo trì được: Công sức bỏ ra để xác định lỗi phần mềm, sửa chữa và kiểm 
 chứng sửa chữa thành công. 
• Tính bảo trì được nhắm vào tính cấu trúc modun của phần mềm và công tác 
 tài liệu hóa. 
 21 
Product revision factors 
Flexibility & Testability 
• Tính mềm dẽo (Flexibility): 
 – Công sức bỏ ra để làm thích ứng phần mềm với một yêu cầu mới. 
 – Ví dụ: man-days required to adapt a software package to a variety of customers of the 
 same trade. 
• Tính kiểm thử được (Testability): 
 – Khả năng có thể khám nghiệm tự động hoặc ghi nhận lỗi tự động (log files) 
 – Ví dụ: a standard test must be run every morning before the production begins 
 22 
Product transition factors 
Portability & Reusability 
• Khả chuyển (Portability): 
• Công sức bỏ ra để làm thích ứng hệ thống trong môi trường mới (hardwares, 
 OS,). 
• Tính dùng lại (Reusability): 
 – Khả năng dùng lại của code, modun, tài liệu 
 – Nhắm vào các yếu tố: tiết kiệm tài nguyên phát triển, rút ngắn thời gian, tăng chất 
 lượng các modun 
 – Ví dụ: GUI của Java hoặc .NET 
 23 
Product transition factors 
Interoperability 
• Tính tương tác: tập trung vào phát triển giao diện với các hệ thống khác 
 hoặc với các thiết bị. 
• Ví dụ: a laboratory equipment is required to process its results 
 (output) according to a standard data structure, which the 
 laboratory information system can then use as an input 
 24 
Hệ thống đảm bảo chất lượng 
• Mục tiêu: 
 – Tối thiểu hóa số lỗi phần mềm 
 – Đạt được mức chất lượng đòi hỏi 
• 6 thành phần trong hệ thống ĐBCL: 
1. Pre-project components 
2. Components of project life cycle activities assessment 
3. Components of infrastructure error prevention and improvement 
4. Components of software quality management 
5. Components of standardization, certification, and SQA system assessment 
6. Organizing for SQA-the human component 
 25 
Pre-project components 
• Kế hoạch về thời gian và ngân sách phải được thiết lập một cách phù hợp (có 
 tương quan với các project khác) 
• Kế hoạch phát triển phần mềm & đảm bảo chất lượng phải được xác định 
 rõ. 
 26 
Components of project life cycle activities assessment 
• Hai giai đoạn : 
 – Phát triển (Development life cycle): verification-validation-qualification, reviews, 
 expert opinions, software testing. 
 – Vận hành, bảo trì (Operation-maintenance): Special maintenance components and life 
 cycle components for improving maintenance tasks) 
• Lưu ý: phải đảm bảo chất lượng của bên thứ 3 (nếu có) trong quá trình phát 
 triển và bảo trì! 
 27 
Components of standardization, certification, and SQA system 
assessment 
• Thiết lập chuẩn quốc tế và chuyên nghiệp trong quản lí tổ chức. 
• Các chuẩn quản lí chất lượng: tập trung vào cái gì (what) được đòi hỏi co 
 một hệ thống quản lí chất lượng, e.g., ISO 9001, SEI CMM assessment 
 standard. 
• Các chuẩn cho qui trình phần mềm: tập trung vào các hướng dẫn về PP 
 (”how”) cho đội ngũ phát triển, e.g. IEEE 1012, ISO/IEC 12207. 
 28 
Organizing for SQA – the human component 
• Tổ chức & phát triển đội ngũ SQA cũng như công tác SQA 
 – Tổ chức cơ bản: người quản lí, đội kiểm thử, đội SQA, 
 – Phát triển và hỗ trợ thiết lập các thành phần SQA (SQA components) 
 – Phát hiện các hệ quả từ thủ tục và phương pháp tiến hành SQA 
 – Cải tiến các thành phần SQA 
• SQA được tổ chức và hoạt động trong lòng một tổ chức nên nó mang đậm 
 dấu ấn của tổ chức. 
 29 
Xét duyệt trong SQA 
• Xét duyệt (review): 
 – Formal Technical Review (FTR), Formal Design Review, Inspection, 
 Walkthrough, Peer Review, etc. 
 – Phát triển bởi by Michael Fagan in the 1970’s (IBM) 
 – Kỹ thuật họp: nhóm làm việc 
• Mục đích: tìm lỗi từ các tài liệu viết (specification, code, etc.) 
 30 
Mục tiêu của xét duyệt 
• Phát hiện và loại bỏ lỗi sớm trong dự án phần mềm. 
• Dự án được chia nhỏ thành các giai đoạn để thấy rõ lộ trình của dự án. 
• Mục tiêu cụ thể : 
 – Uncover errors in functions, logic or implementation 
 – To verify that the document (software code, specification, etc.) meets its 
 requirements 
 – To ensure that the software has been represented according to the pre-
 defined standards 
 – To make projects more manageable 
 31 
Tổ chức xét duyệt 
• Các tài liệu mang ra xét duyệt phải thích hợp, chính đáng, không quá nhiều 
• Các người tham gia phải có đủ thời gian tiếp cận tài liệu 
• Số lượng người tham gia hợp lí, ít nhất có thể được (không có người không 
 cần thiết) 
 32 
Thực hiện họp xét duyệt 
• Người trình bày: thường là người sản xuất ra tài liệu, review leader, thư kí. 
• Tập trung vào tìm ra vấn đề (lỗi) hơn là giải quyết vấn đề 
• Xét duyệt sản phẩm, không xét duyệt người sx. 
• Hạn chế tranh luận 
• Càng nhiều lỗi được phát hiện, cuộc họp càng có chất lượng 
 33 
Sau cuộc họp xét duyệt 
• Chấp nhận sản phẩm (không cần thiết sửa đổi) 
• Loại bỏ sản phẩm (lỗi nặng) 
• Chấp nhận tạm thời (lỗi nhỏ, cần sửa đổi nhưng không cần họp lại) 
• Tất cả các kết luận đều được ghi nhận và lưu trữ. 
 34 
Họp là cần thiết? 
• Hầu hết lỗi (errors) được tìm thấy trong giai đoạn sớm của dự án. 
• Nhà sản xuất hiểu rõ hơn về tính đúng đắn của công việc của họ. 
• Không phải tất cả mọi vấn đề đều có thể được bởi kiểm thử (testing). Ví dụ: 
 lỗi về kiểu cách viết chương trình, code không cần thiết. 
• Một số vấn đề cần lưu ý: 
 – Thêm việc thêm tiền. 
 – Hiệu quả của inspection 
 – Thiếu chuẩn bị cho meeting 
 35 
Components of infrastructure error prevention and 
improvement 
• Mục tiêu là hạ thấp tỷ lệ lỗi (fault) và cải tiến hiệu quả (productivity). Thiết 
 lập (và cải tiến): 
 – Qui trình và qui tắc làm việc, 
 – Đào tạo cán bộ 
 – Quản lí cấu hình và kiểm soát tài liệu 
 – Áp dụng nhất quán cho toàn bộ tổ chức 
 36 
Components of software quality management 
• Mục tiêu là kiểm soát các hoạt động phát triển và bảo trì và trợ giúp quản trị 
 sớm nhằm tối thiếu hóa thất bại 
• Các khía cạnh quản lí 
 – Software quality metrics, 
 – quality cost, 
 – project progress control, etc. 
 37 
Tổng kết chương 
1. Mục tiêu SQA: thỏa mãn khách hàng 
2. Nguyên tắc SQA: bài bản, không ngừng cải tiến 
3. Các yếu tố chất lượng McCall 
4. Các thành phần của một hệ thống chất lượng 
 38 
Thảo luận 
• Đề tài 2: Chất lượng phần mềm là gì? 
• Đề tài 3: làm thế nào để đảm bảo chất lượng phần mềm? 
Nhóm thảo luận và viết báo cáo thảo luận theo nhóm 
 . Báo cáo dạng câu hỏi và trả lời (nội dung thảo luận) 
 . Trong báo cáo ghi rõ người tham gia và mỗi ý trả lời cần ghi tên người tham 
 gia thảo luận. 
 39