Bài giảng Quản lý dự án phần mềm - Quản lý chất lượng

Nội dung text: Bài giảng Quản lý dự án phần mềm - Quản lý chất lượng

1. QUẢN LÝ CHẤT LƯỢNG Nguyễn Anh Hào Khoa CNTT – HV CNBCVT II 2005 - 2006
2. 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
3. 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
4. Chất lượng PM: Mô hình McCall 4
5. 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
6. 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
7. 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
8. 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
9. 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
10. 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
11. Verification & Validation • Verification: “Are we building the product right?” • Validation: “Are we building the right product?”
12. 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ử)
13. Quan hệ giữa verification & validation Verification Validation (tests)
14. 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
15. 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
16. 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
17. 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
18. 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 ?
19. 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
20. 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.
21. 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)
22. 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.
23. 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 •
24. Đá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
25. Các hệ thống chất lượng A. ISO 9000 B. CMM 25