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

Bài giảng Quản lý dự án phần mềm: Quản lý chất lượng cung cấp cho người học các kiến thức: Chất lượng phần mềm, quản lý chất lượng, hoạch định chất lượng, bảo đảm chất lượng (Q.Assurance),... Mời các bạn cùng tham khả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 ? • Error: “sự hư hỏng” thân chương trình (mã lệnh sai so với ý đồ tạo chương trình) • Fault: “sự hư hỏng” chức xử lý chương trình error gây • Failure: “sự hư hỏng” bộc lộ ngồi sử dụng chức có fault • Defect: khiếm khuyết chương trình theo cách đánh giá người dùng Chất lượng phần mềm • Chất lượng thỏa mãn yêu cầu (Crosby,1979) – Sản phẩm có đủ đặc tính làm thỏa mãn khách hàng để tạo hài lòng sản phẩm • Khơng có thiếu sót sản phẩm (Juran, 1988) • Mức độ mà sản phẩm (hệ thống, thành phần hay xử lý) làm thỏa mãn cho yêu cầu định nghĩa • Mức độ mà sản phẩm làm thỏa mãn cho khách hàng, cho nhu cầu người sử dụng cho kỳ vọng (IEEE, 1991) Chất lượng PM: Mơ hình McCall Quản lý chất lượng • Chất lượng “mức độ hài lòng tập hợp đặc tính (của sản phẩm/dịch vụ tạo từ dự án) dùng để đáp ứng yêu cầu (từ phía tổ chức/khách hàng)” • Triết lý việc quản lý chất lượng: Làm thỏa mãn “khách hàng” Ngăn ngừa lỗi sai sản phẩm Cải tiến công việc để cải tiến sản phẩm Chất lượng trách nhiệm người Quản lý chất lượng dựa kiện thực tế • nhóm tiến trình: Hoạch định chất lượng (Quality Planning) Bảo đảm chất lượng (Quality Assurance) 1.Hoạch định chất lượng Xác định tiêu chí chất lượng (mức độ u cầu đặc tính nhận biết được) cho sản phẩm lẫn tiến trình Đối với sản phẩm phần mềm – Các tiêu chí đặc tính cùa phần mềm tạo hài lòng cho người sử dụng (tương ứng với mong muốn), vd: tốn tài nguyên, trực quan cao, linh hoạt,… Đối với tiến trình làm phần mềm – Các tiêu chí đặc điểm cơng việc làm thỏa mãn yêu cầu ràng buộc dự án, vd: kế hoạch, chi phí hợp lý, cách làm có kiễm sốt,… Phân tích ngun nhân-hậu     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, mơi trường bên ngồi Đây yếu tố đưa đến hài lịng sử dụng Thể hài lòng Hài lịng 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 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 không xác định vấn đề cải tiến Có liệt kê đặc tính sản phẩm mong đợi: màu sắc, hình dạng, khối lượng, … – Có định hướng cho việc hồn thiện sản phẩm Có độ đo đặc tính mong đợi : “1 xử lý truy vấn liệu khơng lâu 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ố,…) Quality Baseline ~ tiêu chí để đánh giá chất lượng dự án (gồm công việc, sản phẩm dự án), ví dụ: Đối với cơng việc: – Tần suất lỗi xuất ≤ lỗi / quý – Thời gian sửa lỗi ≤ ngày / lỗi Đối với sản phẩm: – Mật độ lỗi ≤ 10-3 / KLOC – Lỗi KH phát ≤ 0.3 lỗi / tháng Đối với dự án: – Số task trễ hạn 20% ≤ 5% – Số task chi phí ≤ 5% 2.Bảo đảm chất lượng (Q.Assurance) ~ Hành động cần thiết để bảo đảm dự án thỏa mãn tất tiêu chí chất lượng hoạch định • Gồm có khía cạnh: – Verification: chứng minh cách làm – 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ụ hành động V&V Verification (chứng minh cho cách làm) – Xem xét mẫu thử để đưa đặc tả yêu cầu – Xem xét mối quan hệ tài liệu phân tích, thiết kế mã nguồn để phát sai sót cách làm Validation (chứng minh cho sản phẩm) – Đối chiếu yêu cầu (ví dụ: xem xét mẫu thử) với mong muốn để phát thiếu sót (defects) – Đối chiếu lực PM so với yêu cầu cam kết để phát lỗi (kiễm thử) Quan hệ 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 cần làm ? ? • Thiết kế test-cases UML Use-case & đặc tả tương tác usecase UML lược đồ hoạt động + trạng thái cho usecase Xem xét trạng thái chấp nhận không chấp nhận từ hành động Lập 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 trình phát triễn – Ghi vết & phân tích kết để định vị lỗi 15 Pareto Chart 40 100 % 30 75 % Cumulative 20 50 % 13 10 10 Common Causes % Cumulative Amount • Diễn tả mức độ tác động nguyên nhân lên kết 25 % 2 Category 16 Qualification Có cơng việc hoạt động bảo trì : Corrective action: sửa lỗi cịn sót lại PM, sử dụng Adaptive action: làm cho PM tương thích với mơi trường bị thay đổi so với trước Perfective action: làm tăng thêm giá trị sử dụng PM – Cải tiến chức & đặc tính chất lượng Preventive action: ngăn ngừa rủi ro trước chúng xuất Bảo trì • Bản chất : gây yêu cầu sửa đổi (modify) phần mềm – Sự sửa đổi thực tế thường tốn người ta nghĩ (do mối liên kết phức tạp phần mềm • Ie, cần cân nhắc kỹ chi phí trước cam kết – Yêu cầu sửa đổi khơng thể biết trước q trình tạo sản phẩm (ie, khơng có u cầu cụ thể để đưa giải pháp cụ thể) → CNPM có giải pháp tổng qt cho u cầu • Mơ hình hổ trợ cho vấn đề ? • Phương pháp, kỹ thuật hổ trợ vấn đề ? Giải pháp chung: maintenance = evolution Các mơ hình xoắn ốc, UP, Agile mơ hình sau lưu giữ SCI để tiếp tục cập nhật cho phiên phần mềm – IEEE định nghĩa PM = tập SCI Thay việc sửa lệnh,dữ liệu việc tháo lắp môđun thiết kế phụ thuộc – Hướng đối tượng phục vụ cho mục đích Chuẩn hóa kết cấu phần mềm, để nhận hổ trợ phát triễn từ cộng đồng – Các phần mềm mã nguồn mở thiết kế theo chuẩn Corrective maintenance • Ngun nhân cịn sót lỗi cách làm phần mềm phức tạp dể gây lỗi khó phát hiện, việc kiễm thử dự án không đủ thời gian để phát hết lỗi Trong CNPM: • Verification & Validation : làm sớm tốt • Có phương pháp, kỹ thuật, cơng cụ hổ trợ, giống làm phần mềm (design, test, analysis, actions) • Cấu trúc cho tài liệu đặc tả thuận lợi cho việc dò vết (tracing) để định vị sửa lỗi dể • Cơ chế phát lỗi mơ tả tình gây lỗi sử dụng suốt chu kỳ phát triễn Adaptive maintenance • Thiết kế để phần mềm phụ thuộc vào mơi trường – vd: Portable phần mềm chạy nhiều lớp khác – vd: ứng dụng java JRE • Giới hạn phụ thuộc vào bất biến môi trường – vd: yêu cầu nghiệp vụ lấy từ quy định (luật) nhà nước thay cho quy tắc riêng tổ chức • Chuẩn hóa đặc tả yêu cầu áp dụng chuẩn 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 yêu cầu thành toán chuẩn phổ biến để dùng pattern (kiểu mẫu) có sẵn • Thiết kế PM thành thành phần (sub-system package) hướng đối tượng để có khả sử dụng lại cao • Sử dụng chế đa hình để thêm thay sửa • Thiết kế phần mềm có tính tùy biến cao thơng số cấu hình bên ngồi – Vd: Các quy tắc tính tốn, xử lý liệu, nghiệp vụ khai báo file ini CSDL thay viết thành mã lệnh Preventive maintenance • Undo giải pháp tổng quát cho thay đổi gây hại đến hệ thống – Được cài đặt MS Office – Cài đặt hệ quản trị CSDL Oracle • Fault tolerance cài đặt để giúp cho hệ thống chịu đựng hư hỏng từ phần cứng • Control chart chế phát bất thường gây hại cho hệ thống • … Đánh giá chất lượng ~ Xem xét lại cách khách quan tiến trình dự án để biết chúng có phù hợp với mục tiêu chất lượng đặt hay khơng • Đánh giá tính hiệu lực quy định • Đánh giá tính hiệu quy trình áp dụng • Đánh giá cải tiến (thay đổi) quy trình quy định 24 Các hệ thống chất lượng A ISO 9000 B CMM 25 ... phẩm Chất lượng trách nhiệm người Quản lý chất lượng dựa kiện thực tế • nhóm tiến trình: Hoạch định chất lượng (Quality Planning) Bảo đảm chất lượng (Quality Assurance) 1.Hoạch định chất lượng. .. Quản lý chất lượng • Chất lượng “mức độ hài lịng tập hợp đặc tính (của sản phẩm/dịch vụ tạo từ dự án) dùng để đáp ứng u cầu (từ phía tổ chức/khách hàng)” • Triết lý việc quản lý chất lượng: Làm... 0.3 lỗi / tháng Đối với dự án: – Số task trễ hạn 20% ≤ 5% – Số task chi phí ≤ 5% 2.Bảo đảm chất lượng (Q.Assurance) ~ Hành động cần thiết để bảo đảm dự án thỏa mãn tất tiêu chí chất lượng hoạch