Ch1 Khai Niem Ve Chat Luong Phan Mem Va Cac Yeu To Chat Luong Phan Mem

Chương 1
KHÁI NIỆM VỀ CHẤT LƯỢNG PHẦN MỀM

VÀ
CÁC YẾU TỐ CHẤT LƯỢNG PHẦN MỀM
Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

Nội dung
2
 Khái niệm phần mềm
 Lỗi phần mềm và nguyên nhân gây ra lỗi phần mềm
 Chất lượng phần mềm và những mục tiêu đảm bảo

chất lượng phần mềm
 Phân loại yêu cầu phần mềm với các yếu tố chất
lượng phần mềm

1. Khái niệm phần mềm
3
 Phần mềm là một (bộ) chương trình được cài đặt trên
máy tính
 nhằm thực hiện một nhiệm vụ tương đối độc lập
 nhằm phục vụ cho một ứng dụng cụ thể trong các hoạt động
kinh tế, quốc phòng, văn hóa, giáo dục, giải trí,…

1.1. Sản xuất phần mềm
4
Sản xuất và bảo trì phần mềm phải đảm bảo 4 yêu cầu:
 Đáp ứng yêu cầu người sử dụng
 Đạt được các tiêu chuẩn về chất lượng
 Giá thành phải nằm trong giới hạn đặt ra
 Phải đảm bảo tiến độ.

1.2. Quy trình phát triển phần mềm
5

1.3. Vòng đời phần mềm
6
 Các giai đoạn phát triển

Phân tích yêu cầu
Đặc tả
Thiết kế
Lập trình
Kiểm thử
 Giai đoạn sản phẩm
Vận hành và bảo trì

2. Lỗi phần mềm và nguyên nhân
2.1. Lỗi phần mềm
7

8
 “Lỗi phần mềm là sự không khớp giữa chương trình và đặc

tả của nó.”
 Dựa vào định nghĩa, chúng ta có thể thấy lỗi phần mềm
xuất hiện theo ba dạng sau:
 Sai: Sản phẩm được xây dựng khác với đặc tả.
 Thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong
sản phẩm được xây dựng.
 Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong
đặc tả.
 Thậm chí, một phần mềm khó hiểu, khó sử dụng, thực thi chậm,
… cũng được xem là lỗi.
9
 Lỗi phần mềm là hiển nhiên phải có.

 Thông thường, một lập trình viên loại tốt trung bình có
từ 1 đến 3 lỗi trên 100 dòng lệnh.
 Kiểm định phần mềm chiếm gần nửa thời gian dự án.
 Cần có công nghệ kiểm định phần mềm.

10
 Lỗi phần mềm xảy

ra ở tất cả các
công đoạn

2.2. Nguyên nhân xảy ra lỗi phần mềm
11
Nguyên
nhân khác
Lập trình
60%
Đặc tả
Thiết kế

Lỗi do đặc tả
12
 Định nghĩa các yêu cầu bị lỗi:

 Lỗi này thường do khách hàng đưa ra các yêu không đúng, là
một trong những nguyên nhân chính của các lỗi phần mềm.
 Các lỗi phổ biến nhất loại này là:
 Sai sót trong định nghĩa các yêu cầu.
 Không có các yêu cầu quan trọng.
 Bao gồm các yêu cầu không cần thiết, các chức năng không thực
sự cần thiết trong tương lai gần.

13
 Các lỗi trong giao tiếp giữa khách hàng và nhà phát triển:
 Hiểu lầm trong giao tiếp giữa khách hàng và nhà phát triển là
nguyên nhân bổ sung cho các lỗi ưu tiên áp dụng trong giai
đoạn đầu của quá trình phát triển:
 Hiểu sai các chỉ dẫn của khách hàng như đã nêu trong các tài liệu
yêu cầu.
 Hiểu sai các yêu cầu thay đổi của khách hàng được trình bày với
nhà phát triển bằng văn bản trong giai đoạn phát triển.
 Hiểu sai của các yêu cầu thay đổi của khách hàng được trình bày
bằng lời nói với nhà phát triển trong giai đoạn phát triển.
 Hiểu sai về phản ứng của khách hàng đối với các vấn đề thiết kế
trình bày của nhà phát triển.
14
 Sai lệch có chủ ý từ các yêu cầu phần mềm:

 Trong một số trường hợp, các nhà phát triển có thể cố tình đi
chệch khỏi các yêu cầu trong tài liệu.
 Các tình huống thường gặp nhất là:
 Phát triển các module phần mềm, các thành phần sử dụng lại lấy
từ một dự án trước đó mà không cần phân tích đầy đủ về những
thay đổi và thích nghi cần thiết để thực hiện một cách chính xác tất
cả các yêu cầu mới.
 Do thời gian hay áp lực ngân sách, nhà phát triển quyết định bỏ
qua một phần của các yêu cầu các chức năng.
 Nhà phát triển khởi xướng các cải tiến cho phần mềm, mà không
có sự chấp thuận của khách hàng.
Các lỗi thiết kế logic
15
 Định nghĩa các yêu cầu phần mềm bằng các thuật toán sai
lầm.
 Quy trình định nghĩa có chứa lỗi.
 Thiếu sót trong các trạng thái hệ thống phần mềm được yêu
cầu.
 Thiếu sót trong định nghĩa các hoạt động trái pháp luật
trong hệ thống phần mềm.
 Giao diện module không phù hợp.
Thiết kế
giao diện

Các lỗi thiết kế logic
16
 Ví dụ:
 Chương trình quản lý tính vốn vay, khi ngân hàng cho vay vốn thì
việc tính lãi được qui định theo hai phương thức là tính lãi đơn và
tính lãi kép.
 Nhưng khi thiết kế thì chương trình chỉ tính lãi đơn không tính lãi
kép.
 Do vậy, chương trình không đưa vào ứng dụng ngay được mà phải
sửa chữa cập nhật lại.

Các lỗi coding
17
 Một loạt các lý do các lập trình viên có thể gây ra các
lỗi code:
 Vi phạm các chuẩn lập trình,
 Hiểu lầm các tài liệu thiết kế,
 Sai sót trong việc áp dụng các CASE và các công cụ phát triển
khác,
 Sai sót trong lựa chọn dữ liệu
 …

Các lỗi coding
18
 Ví dụ:
 Chương trình tính tiền lương được đặc tả cho từng nhân viên
theo qui định làm tròn đến hàng đơn vị, với công thức (1.1)
Lươngi = round(hsli*lcb(1- 0.06),0 ) (1.1)
 Nhưng khi lập trình:

Lươngi = round(hsli *lcb(1- 0.06),-2 ) (1.2)

Các lỗi coding
19
 Ví dụ:
 Kết quả dẫn đến sai số như sau
Chênh lệnh
Stt Học và tên hsl CT(1.1) CT(1.2) tiền
lương
1 Lê Ngọc Anh 3,99 1.312.710 1.312.700 -10
2 Trần Thị Bình 2,34 769.860 769.900 +40
3 Nguyễn Văn Nam 4,32 1.421.280 1.421.300 +20

4 Bùi Anh Vũ 2,67 878.430 878.400 -30
Tổng cộng 4.382.280 4.382.300 +20

Một số lỗi khác
20
 Thử nghiệm sai hoặc không đầy đủ
 Các lỗi về tài liệu (viết không đầy đủ hoặc không chính xác)
 Do thay đổi môi trường, công nghệ
 Do thay đổi phần cứng, hạ tầng phức tạp
 Tương tác nhiều hệ thống

2.3. Chi phí cho việc sửa lỗi
21
 Kiểm thử và sửa lỗi có thể được thực hiện tại bất kỳ giai
đoạn nào của vòng đời phần mềm
 Chi phí cho việc tìm và sửa lỗi tăng một cách đáng kể theo
quá trình phát triển:
 Không đáng kể khi thay đổi yêu cầu ở lần duyệt yêu cầu
đầu tiên
 Tăng lên gấp bội khi thay đổi yêu cầu lúc đã lập trình
 Không đáng kể nếu lập trình viên tự phát hiện lỗi của
mình

2.3. Chi phí cho việc sửa lỗi
22
 “Sửa một lỗi trước khi phát hành một phần mềm sẽ tốn chi
phí ít hơn rất nhiều so với việc khắc phục nó sau khi đã
phát hành.”
 Lỗi được phát hiện càng muộn thì chi phí cho việc sữa lỗi
càng lớn

3. Định nghĩa chất lượng phần mềm và đảm bảo chất
lượng phần mềm (SQA – Software Quality Assurance)
23
 Thế nào là phần mềm được gọi là đúng?
 Để đánh giá CẤP ĐỘ ĐÚNG của phần mềm, phải kiểm tra
CHẤT LƯỢNG PHẦN MỀM
 Mục đích của nhóm phát triển PM là có PM chất lượng
cao
 Hạn chế thấp nhất việc phát sinh lỗi
 Đảm bảo chất lượng phần mềm là một hoạt động có hệ thống
và kế hoạch

3.1. Định nghĩa chất lượng phần mềm
24
 Theo IEEE, chất lượng phần mềm được định nghĩa như sau:
 Chất lượng phần mềm là:
 Mức độ mà một hệ thống, thành phần hoặc một tiến trình đạt được
yêu cầu đã đặc tả
 Mức độ mà một hệ thống, thành phần hoặc một tiến trình đạt được
những nhu cầu hay mong đợi của khách hàng hoặc người sử dụng.
 Theo Daniel Galin, khái niệm đảm bảo chất lượng phần mềm
được xác định như sau:
 Đảm bảo chất lượng phần mềm là một tập các hoạt động đã
được lập kế hoạch và có hệ thống, cần thiết để cung cấp đầy đủ
sự tin cậy vào quy trình phát triển phần mềm hay quy trình bảo
trì phần mềm của sản phẩm hệ thống phần mềm phù hợp với
các yêu cầu chức năng kỹ thuật cũng như với các yêu cầu quản
lý.
3.2. Xác minh, thẩm định phần mềm
25
 Verification: “Are we building the product right?”

 Kiểm tra phần mềm làm ra có đúng đặc tả (yêu cầu, thiết kế)
hay không.
 Phát hiện lỗi lập trình
 Validation: “Are we building the right product?”

 Kiểm tra phần mềm có đáp ứng đúng yêu cầu người dùng
không.
 Phát hiện lỗi phân tích, thiết kế
Xác minh và thẩm định là hai hoạt động cốt yếu để đảm bảo chất
lượng phần mềm, diễn ra suốt quá trình phát triển.
26
 V&V (Verification and Validation):

 Mục tiêu là phát hiện và sửa lỗi phần mềm, đánh giá tính dùng
được của phần mềm.
 Thứ tự thực hiện: Vertification  Validation.
 Verification chiếm 80%, Validation chiếm 20% công việc
 Validation tác động 80% hiệu quả chung.

27
 Các hoạt động xác minh

28
 Các hoạt động thẩm định
thẩm định
thẩm định

4. Các yếu tố chất lượng phần mềm
29
 Những đặc trưng của phần mềm

 Phần mềm là vô hình
 Phần mềm không mòn cũ, hỏng hóc, nhưng thoái hóa
 Phần mềm thay đổi theo thời gian
 Vấn đề đặt ra cho đảm bảo chất lượng phần mềm
 Làm sao làm lộ ra những đặc trưng chất lượng?
 Những yếu tố nào ảnh hưởng đến các đặc trưng đó?
 Làm sao nhận biết và đo được các đặc trưng?
 Làm thế nào kiểm soát các yếu tố không đo được?

30
 Theo McCall, các yếu tố ảnh hưởng đến chất lượng phần
mềm được chia làm ba loại theo cây mô hình:
1. Đặc trưng chức năng: 5 nhân tố
2. Khả năng đương đầu với tính bảo trì,
linh hoạt, có
những thay đổi: 3 nhân tố thể test được
3. Khả năng thích nghi với
môi trường mới: 3 nhân tố
Tính khả chuyển, có khả năng sử
dụng lại, có khả năng giao tác
Tính chính xác, tin cậy,

hiệu quả, tính toàn vẹn,
sử dụng được
Các độ đo chất lượng
31
 McCall đề xuất 21 độ đo: 11. Độ khuếch trương được

1. Độ kiểm toán được 12. Độc lập phần cứng
2. Độ chính xác 13. Độ trang bị đủ đồ nghề
3. Độ tương đồng giao tiếp 14. Độ môđun hóa
4. Độ đầy đủ 15. Độ dễ thao tác
5. Độ phức tạp 16. Độ an ninh
6. Độ súc tích 17. Độ tự cấp tài liệu
7. Độ nhất quán 18. Độ đơn giản – dễ hiểu
8. Độ tương đồng dữ liệu 19. Độ độc lập phần mềm
9. Độ dung thứ lỗi 20. Độ lần vết được
10. Độ hiệu quả thực hiện 21. Khả năng huấn luyện
32
1. Tính đúng đắn?

 Làm đúng với khách hàng mong muốn
 Thỏa mãn những điều đã được đặc tả (những yêu cầu của đối
tượng khác)
 Các độ đo liên quan:

 Độ đầy đủ
 Độ nhất quán
 Độ lần vết được

33
2. Tính tin cậy?

 Có thể trông đợi vào sự thực hiện các chức năng dự kiến và
mức chính xác được đòi hỏi

 Độ chính xác  Độ môđun hóa
 Độ phức tạp  Độ đơn giản – dễ hiểu
 Độ nhất quán  Độ lần vết được
 Độ dung thứ lỗi

34
3. Tính hiệu quả?

 Tổng lượng nguồn lực tính toán và mã yêu cầu để thực hiện các
chức năng của chương trình là thích hợp.

 Độ súc tích
 Độ hiệu quả thực hiện
 Độ dễ thao tác

35
4. Tính toàn vẹn?

 Sự khống chế được việc truy cập trái phép tới phần mềm và dữ
liệu của hệ thống.

 Độ kiểm toán được
 Độ trang bị đủ đồ nghề
 Độ an ninh

36
5. Tính khả dụng?

 Công sức để đọc hiểu, thao tác dễ, chuẩn bị đầu vào, thể hiện
đầu ra của chương trình và chấp nhận được, khả năng nhớ lâu.

 Độ dễ thao tác
 Khả năng huấn luyện

37
6. Tính bảo trì được?

 Nỗ lực cần để định vị và xác định được 1 lỗi trong chương
trình là chấp nhận được. Dễ thay đổi và mở rộng.

 Độ súc tích  Độ tự cấp tài liệu
 Độ nhất quán  Độ đơn giản - dễ hiểu
 Độ trang bị đủ đồ nghề
 Độ môđun hóa

38
7. Tính mềm dẻo?

 Có thể cải biên chương trình và nỗ lực cần để cải biên là chấp
nhận được.

 Độ phức tạp  Độ khái quát
 Độ súc tích  Độ môđun hóa
 Độ nhất quán  Độ tự cấp tài liệu
 Độ khuếch trương được  Độ đơn giản - dễ hiểu

39
8. Tính kiểm thử được?

 Công sức cần để kiểm thử chương trình và bảo đảm rằng nó
thực hiện đúng chức năng dự định là chấp nhận được.

 Độ kiểm toán được  Độ môđun hóa
 Độ phức tạp  Độ tự cấp tài liệu
 Độ trang bị đủ đồ nghề  Độ đơn giản - dễ hiểu

40
9. Tính mang chuyển được?

 Công sức đòi hỏi để chuyển nó từ một môi trường (phần cứng,
phần mềm) này sang một môi trường khác là chấp nhận được.

 Độ khái quát  Độ tự cấp tài liệu
 Độ độc lập phần cứng  Độ độc lập phần mềm

41
10. Tính sử dụng lại được?

 Khả năng hệ thống hoặc một phần của nó có thể được dùng lại
trong một ứng dụng khác.

 Độ khái quát  Độ tự cấp tài liệu
 Độ độc lập phần cứng  Độ độc lập phần mềm

42
11. Tính liên tác được?

 Công sức đòi hỏi để ghép nối hệ thống phần mềm với một hệ
thống khác là chấp nhận được.

 Độ tương đồng giao tiếp
 Độ tương đồng dữ liệu
 Độ khái quát

5. Tiến hóa của hoạt động SQA
43
 Khi phần mềm trở thành sản phẩm có nhu cầu và đòi hỏi
đảm bảo chất lượng:
 Từ khách hàng (nhu cầu)
 Từ nhà sản xuất (đòi hỏi): đảm bảo tính đồng đều của sản
phẩm, cải thiện chất lượng thường xuyên
 Từ thực tiễn: Kinh nghiệm cho phép hoạt động đảm bảo
chất lượng phần mềm ngày càng được hoàn thiện. Hiểu về
vai trò của nó và tăng thêm các hoạt động đảm bảo chất
lượng.

5.1. Sự phát triển của SQA
44
 Đảm bảo chất lượng là hoạt động cốt yếu của mọi doanh
nghiệp làm ra sản phẩm hàng hóa.
 Đảm bảo chất lượng phần mềm diễn ra song song với đảm
bảo chất lượng trong chế tạo phần cứng.
 Các chuẩn đảm bảo chất lượng phần mềm là cơ sở đo chất
lượng (Chúng đầu tiên được đưa ra trong quân sự vào
những năm 70 và nhanh chóng mở rộng trong thương mại).

5.2. Vai trò và trách nhiệm trong SQA
45
 Những người có trách nhiệm đảm bảo chất lượng phần

mềm (trong tổ chức):
 Kỹ sư phần mềm
 Nhà quản lý dự án
 Khách hàng
 Người bán hàng
 Thành viên trong nhóm SQA.

5.2. Vai trò và trách nhiệm trong SQA
46
 Nhóm SQA phải đóng vai trò như đại diện của khách hàng
– để xem xét chất lượng phần mềm:
 Có đáp ứng được các nhân tố chất lượng không?
 Có tuân thủ các chuẩn dự định trước không?
 Các thủ tục, phương pháp, kỹ thuật có thực sự đóng vai trò của
chúng trong hoạt động SQA.

5.3. Các hoạt động SQA
47

5.4. Vai trò của các hoạt động SQA
48

49

50

51

5.5. Mục tiêu của các hoạt động SQA
52

Hết Chương 1

Ch1 Khai Niem Ve Chat Luong Phan Mem Va Cac Yeu To Chat Luong Phan Mem

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ch1 Khai Niem Ve Chat Luong Phan Mem Va Cac Yeu To Chat Luong Phan Mem

Uploaded by

Copyright:

Available Formats

Chương 1

KHÁI NIỆM VỀ CHẤT LƯỢNG PHẦN MỀM

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

 Khái niệm phần mềm

 Lỗi phần mềm và nguyên nhân gây ra lỗi phần mềm

 Chất lượng phần mềm và những mục tiêu đảm bảo

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

 Đạt được các tiêu chuẩn về chất lượng

 Giá thành phải nằm trong giới hạn đặt ra

 Phải đảm bảo tiến độ.

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

 Các giai đoạn phát triển

 Giai đoạn sản phẩm

Vận hành và bảo trì

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

 “Lỗi phần mềm là sự không khớp giữa chương trình và đặc

 Lỗi phần mềm là hiển nhiên phải có.

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

 Lỗi phần mềm xảy

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

 Định nghĩa các yêu cầu bị lỗi:

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

 Sai lệch có chủ ý từ các yêu cầu phần mềm:

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

 Nhưng khi lập trình:

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

1 Lê Ngọc Anh 3,99 1.312.710 1.312.700 -10

2 Trần Thị Bình 2,34 769.860 769.900 +40

3 Nguyễn Văn Nam 4,32 1.421.280 1.421.300 +20

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

 Thử nghiệm sai hoặc không đầy đủ

 Do thay đổi môi trường, công nghệ

 Do thay đổi phần cứng, hạ tầng phức tạp

 Tương tác nhiều hệ thống

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

 Thế nào là phần mềm được gọi là đúng?

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

 Verification: “Are we building the product right?”

 Validation: “Are we building the right product?”

 V&V (Verification and Validation):

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

 Các hoạt động xác minh

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

 Các hoạt động thẩm định

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

 Những đặc trưng của phần mềm

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

Tính chính xác, tin cậy,

 McCall đề xuất 21 độ đo: 11. Độ khuếch trương được

1. Tính đúng đắn?

 Các độ đo liên quan:

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

2. Tính tin cậy?

 Các độ đo liên quan:

Bài giảng Chất lượng và Kiểm thử phần mềm 25/08/2019

3. Tính hiệu quả?