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.
AMBIENT/
Chủ đề:
Nội dung Text: 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
- 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 %
% Cumulative
30 75 %
Amount
Cumulative
20 50 %
13
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.
Thêm vào BST
Báo xấu
Download
Vui lòng tải xuống để xem tài liệu đầy đủ
