Bài giảng Quản lý dự án phần mềm - Chương 2: Quản lý chất lượng - Nguyễn Anh Hào

QUẢN LÝ CHẤT LƯỢNG
 Nguyễn Anh Hào
 Khoa CNTT – HV CNBCVT II
 2005 - 2006
 Lỗi phần mềm là gì ?
• Error: là “sự hư hỏng” trong bản thân chương trình (mã 
 lệnh sai so với ý đồ tạo ra chương trình)
• Fault: là “sự hư hỏng” trong chức năng xử lý của chương 
 trình do error gây ra.
• Failure: là “sự hư hỏng” bộc lộ ra ngoài khi sử dụng chức 
 năng có fault.
• Defect: là khiếm khuyết của chương trình theo cách đánh 
 giá của người dùng.
 2
 Chất lượng phần mềm
• Chất lượng là sự thỏa mãn yêu cầu (Crosby,1979).
 – Sản phẩm có đủ những đặc tính làm thỏa mãn khách 
 hàng để tạo ra sự hài lòng về sản phẩm.
• Không có thiếu sót trong sản phẩm (Juran, 1988).
• Mức độ mà một sản phẩm (hệ thống, một thành phần hay 
 một xử lý) làm thỏa mãn cho các yêu cầu đã được định 
 nghĩa.
• Mức độ mà một sản phẩm làm thỏa mãn cho khách hàng, 
 cho nhu cầu của người sử dụng hoặc cho các kỳ vọng về nó 
 (IEEE, 1991).
 3
Chất lượng PM: Mô hình McCall
 4
 Quản lý chất lượng
• Chất lượng là “mức độ hài lòng về một tập hợp các đặc 
 tính (của sản phẩm/dịch vụ tạo ra từ dự án) dùng để đáp 
 ứng các yêu cầu (từ phía tổ chức/khách hàng)”.
• Triết lý cơ bản của việc quản lý chất lượng:
 1. Làm thỏa mãn “khách hàng”
 2. Ngăn ngừa lỗi sai trong sản phẩm
 3. Cải tiến công việc để cải tiến sản phẩm
 4. Chất lượng là trách nhiệm của mọi người
 5. Quản lý chất lượng dựa trên sự kiện thực tế
• 2 nhóm tiến trình:
 1. Hoạch định chất lượng (Quality Planning)
 2. Bảo đảm chất lượng (Quality Assurance)
 5
 1.Hoạch định chất lượng
 Xác định các tiêu chí chất lượng (mức độ yêu cầu trên các 
 đặc tính có thể nhận biết được) cho cả sản phẩm lẫn tiến 
 trình.
1. Đối với sản phẩm phần mềm
 – Các tiêu chí trên đặc tính cùa phần mềm tạo ra sự hài 
 lòng cho người sử dụng (tương ứng với mong muốn), 
 vd: ít tốn tài nguyên, trực quan cao, linh hoạt,
2. Đối với các tiến trình làm phần mềm
 – Các tiêu chí trên đặc điểm của công việc làm thỏa mãn 
 các yêu cầu và ràng buộc của dự án, vd: đúng kế hoạch, 
 chi phí hợp lý, cách làm có kiễm soát,
 6
 Phân tích nguyên nhân-hậu quả
 INDIVIDUAL PROCESS OUTPUTS CONSEQUENCES
 Vai trò Năng lực Sản phẩm Giá trị 
. Cá nhân: Trách nhiệm (cam kết).
. Tiến trình: Nguồn lực (hiệu quả), ràng buộc (khả thi).
. Đầu ra: Đúng yêu cầu (không thừa, không thiếu).
. Hậu quả: Tác động tốt, xấu đến tổ chức thụ hưởng, hoặc 
 môi trường bên ngoài. Đây là yếu tố chính đưa đến sự hài 
 lòng khi sử dụng.
 7
 Thể hiện của sự hài lòng
1. Hài lòng hoặc không hài lòng: có, không
 – Không trợ giúp cho việc cải tiến sản phẩm.
2. Có phân định mức độ hài lòng: trung bình, khá, tốt
 – Xác định mức độ cần nổ lực để hoàn thiện sản phẩm 
 nhưng vẫn không xác định các vấn đề cải tiến.
3. Có liệt kê các đặc tính của sản phẩm được mong đợi: màu 
 sắc, hình dạng, khối lượng, 
 – Có định hướng cho việc hoàn thiện sản phẩm
4. Có độ đo trên các đặc tính được mong đợi : “1 xử lý truy 
 vấn dữ liệu không lâu hơn 15 giây”.
 – Có tiêu chuẩn để đo mức độ thỏa mãn yêu cầu (cách 
 đo, phương tiện đo, đơn vị đo, sai số,)
 8
 Quality Baseline
~ là một bộ tiêu chí để đánh giá chất lượng của dự án (gồm các 
 công việc, sản phẩm và dự án), ví dụ:
Đối với công việc:
 – Tần suất lỗi xuất hiện ≤ 2 lỗi / quý
 – Thời gian sửa lỗi ≤ 1 ngày / lỗi
Đối với sản phẩm:
 – Mật độ lỗi ≤ 10-3 / KLOC
 – Lỗi KH phát hiện ≤ 0.3 lỗi / tháng
Đối với dự án:
 – Số task trễ hạn 20% ≤ 5 %
 – Số task quá chi phí ≤ 5 %
 9
 2.Bảo đảm chất lượng (Q.Assurance)
~ Hành động cần thiết để bảo đảm rằng dự án sẽ thỏa 
 mãn tất cả các tiêu chí chất lượng đã hoạch định.
• Gồm có 3 khía cạnh:
 – Verification: chứng minh cách làm đúng
 – Validation: chứng minh cho sản phẩm
 – Qualification: hổ trợ (dự phòng trước từ cách làm 
 sản phẩm) cho bảo trì, nâng cấp để phần mềm tiếp 
 tục có chất lượng
 10
 Verification & Validation
• Verification: “Are we building the product right?”
• Validation: “Are we building the right product?”
 Ví dụ về các hành động V&V
1. Verification (chứng minh cho cách làm)
 – Xem xét mẫu thử để đưa ra các đặc tả yêu cầu
 – Xem xét mối quan hệ giữa các tài liệu phân tích, thiết kế 
 và mã nguồn để phát hiện sai sót trong cách làm
2. Validation (chứng minh cho sản phẩm)
 – Đối chiếu các yêu cầu (ví dụ: xem xét mẫu thử) với mong 
 muốn để phát hiện thiếu sót (defects) 
 – Đối chiếu năng lực của PM so với yêu cầu đã được cam 
 kết để phát hiện lỗi (kiễm thử)
Quan hệ giữa verification & validation
 Verification
 Validation
 (tests)
 Kỹ thuật kiễm tra phần mềm
• System test
 – Integration test (Top down, Bottom up)
 – Module test (White box, Black box, Regression test)
 – Function test (Threat test, Stress test, Peer review)
• User test
 – Acceptance test
 – Alpha test, Beta test
 14
Test case gì cần làm ? bao nhiêu cái ?
• Thiết kế các test-cases
 1. UML Use-case & đặc tả tương tác của usecase
 2. UML lược đồ hoạt động + trạng thái cho usecase
 3. Xem xét các trạng thái chấp nhận được và không 
 chấp nhận được từ mỗi hành động
 4. Lập ra các test-cases (test-suit) cho use-case
 • Control flow graph (CFG)
 • Nguyên lý McCabe: số test-case tối thiểu 
 (→coverage)
• Lập kế hoạch test
 – Chạy theo quá trình phát triễn 15
 – Ghi vết & phân tích kết quả để định vị lỗi
 Pareto Chart 
• Diễn tả mức độ tác động của các nguyên nhân lên kết quả
 40 100 %
 30 75 %
 Cumulative
 mount 20 50 %
 A
 13 %Cumulative 
 10
 10 25 %
 6
 4
 3 2 2
 Common Causes Category 
 16
 Qualification
Có 4 công việc chính trong hoạt động bảo trì :
1. Corrective action: sửa lỗi còn sót lại trong PM, 
 trong khi nó đang được sử dụng.
2. Adaptive action: làm cho PM tương thích với môi 
 trường đã bị thay đổi so với trước đây
3. Perfective action: làm tăng thêm giá trị sử dụng 
 PM.
 – Cải tiến các chức năng & các đặc tính chất lượng
4. Preventive action: ngăn ngừa các rủi ro trước khi 
 chúng xuất hiện
 Bảo trì
• Bản chất : gây ra yêu cầu sửa đổi (modify) trên phần 
 mềm.
 – Sự sửa đổi thực tế thường tốn kém hơn người ta 
 nghĩ (do mối liên kết phức tạp trong phần mềm
 • Ie, cần cân nhắc kỹ về chi phí trước khi cam kết
 – Yêu cầu sửa đổi này không thể biết trước trong 
 quá trình tạo sản phẩm (ie, không có yêu cầu cụ 
 thể để đưa ra giải pháp cụ thể) → CNPM chỉ có 
 giải pháp tổng quát cho các yêu cầu này
 • Mô hình nào hổ trợ cho vấn đề này ?
 • Phương pháp, kỹ thuật nào hổ trợ vấn đề này ?
 Giải pháp chung: maintenance = evolution
1. Các mô hình xoắn ốc, UP, Agile và những mô hình 
 sau này đều lưu giữ các SCI để tiếp tục cập nhật cho 
 phiên bản phần mềm mới
 – IEEE định nghĩa PM = tập các SCI của nó
2. Thay thế việc sửa lệnh,dữ liệu bằng việc tháo lắp 
 các môđun được thiết kế ít phụ thuộc nhau
 – Hướng đối tượng phục vụ cho mục đích này
3. Chuẩn hóa kết cấu của phần mềm, để nhận sự hổ trợ 
 phát triễn nó từ cộng đồng
 – Các phần mềm mã nguồn mở đều thiết kế theo 
 chuẩn
 Corrective maintenance
• Nguyên nhân còn sót lỗi là do cách làm phần mềm khá phức tạp dể 
 gây lỗi khó phát hiện, và việc kiễm thử trong dự án không đủ thời gian 
 để phát hiện hết lỗi.
Trong CNPM:
• Verification & Validation : làm càng sớm càng tốt
• Có phương pháp, kỹ thuật, công cụ hổ trợ, giống như làm phần mềm 
 (design, test, analysis, actions)
• Cấu trúc cho các tài liệu đặc tả thuận lợi cho việc dò vết (tracing) để 
 định vị và sửa lỗi dể
• Cơ chế phát hiện lỗi và mô tả tình huống gây lỗi được sử dụng trong 
 suốt chu kỳ phát triễn.
 Adaptive maintenance
• Thiết kế để phần mềm ít phụ thuộc vào môi trường
 – vd: Portable là phần mềm chạy được trên nhiều lớp nền 
 khác nhau
 – vd: ứng dụng java trên nền JRE
• Giới hạn sự phụ thuộc vào các bất biến của môi trường
 – vd: yêu cầu nghiệp vụ lấy từ quy định (luật) của nhà 
 nước thay cho quy tắc riêng của tổ chức
• Chuẩn hóa các đặc tả yêu cầu và áp dụng chuẩn của thế giới 
 (vd: dùng công nghệ chuẩn, giao tiếp chuẩn, trừu tượng hóa 
 yêu cầu cụ thể thành vấn đề phổ biến)
 Perfective maintenance
Phát biểu các yêu cầu thành các bài toán chuẩn hoặc phổ 
 biến để dùng pattern (kiểu mẫu) có sẵn
• Thiết kế PM thành các thành phần (sub-system hoặc 
 package) hướng đối tượng để có khả năng sử dụng lại cao 
• Sử dụng cơ chế đa hình để thêm mới thay vì sửa
• Thiết kế phần mềm có tính tùy biến cao bằng thông số cấu 
 hình bên ngoài
 – Vd: Các quy tắc tính toán, xử lý dữ liệu,.. của nghiệp vụ được khai 
 báo trong file .ini hoặc CSDL thay vì viết thành mã lệnh.
 Preventive maintenance
• Undo là giải pháp tổng quát cho các thay đổi có thể gây hại 
 đến hệ thống
 – Được cài đặt trong MS Office
 – Cài đặt trong hệ quản trị CSDL của Oracle 
• Fault tolerance được cài đặt để giúp cho hệ thống chịu đựng 
 các hư hỏng từ phần cứng
• Control chart là cơ chế phát hiện sự bất thường có thể gây 
 hại cho hệ thống
• 
 Đánh giá chất lượng 
~ Xem xét lại một cách khách quan các tiến trình của dự án 
 để biết chúng có phù hợp với các mục tiêu chất lượng đã 
 đặt ra hay không.
• Đánh giá tính hiệu lực của các quy định
• Đánh giá tính hiệu quả của quy trình đang áp dụng.
• Đánh giá các cải tiến (thay đổi) trên quy trình và quy định.
 24
 Các hệ thống chất lượng
A. ISO 9000
B. CMM
 25