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

1PGS. TS. Trần Cao Đệ
Bộ môn Công nghệ phần mềm 
Khoa CNTT&TT – Đại học Cần Thơ
Năm 2013
Đảm bảo chất lượng phần mềm
Software Quality Assurance
Chương 2: Quản lí chất 
lượng phần mềm
2SQA
Đảm bảo chất lượng: thiết lập một tập hợp các họat động 
có chủ đích và có hệ thống nhằm mang lại sự tin tưởng 
sẽ đạt được chất lượng đòi hỏi.
“SQA is a systematic, planned set of actions necessary 
to provide adequate confidence that the software 
development process or the maintenance process of a 
software system product conforms to established 
functional technical requirements as well as with the 
managerial requirements of keeping the schedule and 
operating within the budgetary confines”.
3Đả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.
4Thuật ngữ 
• Error: là sự không nhất quán giữa giá trị đầu ra của 
phần mềm so với giá trị đúng tương ứng với một đầu 
vào.
• Fault
một trạng thái là nguyên nhân làm cho hệ thống hỏng 
khi thực hiện chức năng nào đó.
• Failure
sự bất lực của phần mềm khi thực hiện một chức năng 
theo đặc tả
5Mụ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.
6Đả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
7Cá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. 
8Yê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.
9Tiến trình ĐBCL
Software development
process
Quality management
process
D1 D2 D3 D4 D5
Standards and
procedures
Quality
plan
Quality review repor ts
10
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
11
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
Costumer 
satisfaction
Kế hoạchCải tiến
Kiểm tra Thực hiện
12
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. 
13
Các cách tiếp cận trong SQA
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
– Phát triển theo mô hình tăng trưởng (Incremental)
– Đặc tả hình thức
– Kiểm tra tĩnh bằng cách dùng các lí lẽ đúng đắn 
– Kiểm tra động (testing) để xác nhận độ tin cậy.
– Ngăn ngừa hỏng hóc (defect prevention) hơn là loại bỏ lỗi (defect 
removal)
14
Cleanroom process
Construct
structur ed
program
Define
softw are
increments
For mally
verify
code
Integ rate
increment
For mally
specify
system
Develop
oper ational
profile
Design
sta tistical
tests
Test
integ rated
system
Error rewor k
15
Chất lượng và công tác đảm 
bảo chất lượng
16
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
17
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
18
McCall Quality Factors
19
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)
20
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.
21
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.
22
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)
23
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. 
24
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
25
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
26
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
27
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. Tiền dự án (Pre-project components)
2. Đánh giá các hoạt động trong vòng đời dự án (Components of project life cycle activities 
assessment)
3. Thành phần ngăn chặn lỗi và cải tiến (Components of infrastructure error prevention and 
improvement)
4. Thành phần quản lí chất lượng phần mềm (Components of software quality 
management)
5. Thành phần chuẩn hóa, chứng nhận và đánh giá hệ thống ĐBCL (Components of 
standardization, certification, and SQA system assessment)
6. Thành phần tổ chức nhân sự cho ĐBCL (Organizing for SQA-the human component)
28
Tiền dự án
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õ.
29
Đánh giá các hoạt động trong vòng đời 
dự án
• Hai giai đoạn :
– Phát triển (Development life cycle): 
• Kiểm tra – thẩm tra - xác nhận (verification-validation-
qualification)
• Xét duyệt (reviews)
• Ý kiến chuyên gia (expert opinions)
• Kiểm thử (software testing).
– Vận hành, bảo trì (Operation-maintenance): 
• Các thành phần liên quan đến bảo trì và cải tiến hiệu quả 
bảo trì.
• 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ì!
30
Chuẩn hóa, chứng chỉ chất lượng và 
đánh giá hệ thống SQA
• 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 cho 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.
31
Tổ chức nhân sự cho SQA
• 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. 
32
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.)
33
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ể :
– Tìm các lỗi còn sót trong chức năng, logic hoặc cài 
đặt.
– Kiểm tra các tài liệu (software code, specification, 
etc.) thỏa mãn đặc tả
– Đảm bảo phần mềm thỏa các chuẩn mực 
(standards) qui định trước
– Làm cho dự án là quản trị được.
34
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)
35
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
36
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ữ.
37
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
38
Ngăn chặn lỗi hệ thống và cải tiến hiệu 
quả
• 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
39
Quản lí chất lượng
• 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 
trong kế hoạch thời gian và ngân sách
• Các khía cạnh quản lí
– Các độ đo chất lượng (Software quality metrics), 
– Giá của chất lượng (quality cost), 
– Kiểm soát tiến độ (project progress control), etc.
40
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 
41
Câu hỏi thảo luận(10%) 
• Đề tài 1 (3): Các yếu tố ảnh hưởng đến chất lượng phần mềm?
• Đề tài 2 (4): Chất lượng phần mềm là gì?
• Đề tài 3 (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
 Mỗi chủ đề nộp một báo cáo không quá 3 trang in A4, cỡ chữ new time roman 
12pt.
 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. 
 Đánh giá: 
 Điểm báo cáo chung của nhóm (ĐBC)
 Điểm cá nhân = ĐBC + mức độ tham gia và nội dung trả lời.
42
Hết chương!
Liên hệ:
TS. Trần Cao Đệ
Bộ môn Công nghệ Phần mềm 
Khoa CNTT và TT – ĐH Cần Thơ
Email: tcde@cit.ctu.edu.vn
Phone: 0710.831.301 # 228