Đề cương ÔN TẬP công NGHỆ PHẦN MỀM NÂNG CAO

Phôtô Ngân Sơn Cổng phụ Khu A

CÂU HỎI ÔN TẬP KỸ NGHỆ PHẦN MỀM NÂNG CAO
Câu2: Cái gì được dùng làm cơ sở để kiểm định chất lượng phần mềm:
Để đánh giá chất lượng phần mềm người ta dựa vào quan điểm chính sau:
• Yêu cầu phần mềm là cơ sở để đo chất lượng:
 Sự phù hợp với yêu cầu là có chất lượng
 Phù hợp yêu cầu cả về số lượng và chất lượng
• Yêu cầu thể hiện bằng đặc tả - đặc tả phải có chuẩn của nó mới kiểm tra được
• Các chuẩn đặc tả xác định một bộ các tiêu chuẩn phát triển, các tiêu chuẩn này hướng
dẫn cách thức làm ra phần mềm: nếu không tuân thủ các tiêu chuẩn đó thì hầu như
chắc chắn là chất lượng sẽ kém
• Luôn có một tập các yêu cầu ngầm thường ít được nhắc đến
 Quá thông dụng, hiển nhiên (sử dụng cửa số)
 Không thể hiện ra ngoài (quy tắc nghiệp vụ)
• Nếu phần mềm chỉ phù hợp với các yêu cầu đã hiển thị mà chưa phù hợp với yêu cầu
ngầm thì chất lượng phần mềm là đáng nghi ngờ
• Cần làm rõ yêu cầu và đưa vào đặc tả càng nhiều càng tốt
Câu 3: Các nhân tố ảnh hưởng lên chất lượng phần mềm có mấy mức độ? Những loại
nhân tố nào ảnh hưởng đến chất lượng?
- Có 2 loại mức độ ảnh hưởng
 Nhân tố trực tiếp
 Nhân tố gián tiếp
- Có 3 loại nhân tố ảnh hưởng đến chất lượng
 Đặc trưng chức năng
 Khả năng đương đầu với những thay đổi
 khả năng thích nghi với môi trường mới.
Câu 4: Nêu các đặc trưng ảnh hưởng lên chất lượng của mỗi loại nhân tố: đặc trưng
chức năng, khả năng thích nghi với thay đổi, khả năng thích nghi với môi
trường
• McCall đề xuất 11 nhân tố và phân thành 3 loại:

(1) đặc trưng chức năng
(2) khả năng đương đầu với những thay đổi
(3) khả năng thích nghi với môi trường mới.
• Loại 1: Các đặc trưng chức năng - (5)
1


Phôtô Ngân Sơn Cổng phụ Khu A

 Tính đúng đắn
- Có làm đúng với cái tôi muốn hay không?
- Có thỏa mãn những điều đã được đặc tả chưa?
- Có thực hiện được những mục tiêu nhiệm vụ của khách hàng chưa?
o Độ đày đủ
o

Độ hòa hợp

o

Độ lần vết được

 Tính tin tưởng được
- mức hy vọng vào sự thực hiện các chức năng dự kiến
- mức chính xác được đòi hỏi
o Độ chính xác
o

Độ phức tạp

o

Độ hòa hợp

o

Độ dung thứ lỗi

o

Độ đo mođun hoá

o

Độ đơn giản – dễ hiểu.

o

Độ lần vết được

 Tính hiệu quả: khối lượng tài nguyên tính toán và mã được đòi hỏi khi thực hiện
các chức năng của chương trình
o Độ súc tích
o

Độ hiệu quả thực hiện

o

Độ dễ thao tác

 Tính toàn vẹn: có thể khống chế được việc truy cập của những người không được
phép tới phần mềm và dữ liệu
o Độ kiểm toán được
o

Trang bị đồ nghề đủ

o

Độ an ninh.

 Tính khả dụng: đo công sức học hiểu, thao tác, chuẩn bị đầu vào, thể hiện đầu ra
của chương trình
o Độ dễ thao tác
o

Độ đo khả năng huấn luyện

• Loại 2: khả năng đương đầu với những thay đổi - (3)
 Tính bảo trì được: nỗ lực đòi hỏi để định vị và xác định được một sai trong
chương trình
o Độ súc tích
o

Độ hoà hợp

o

Trang bị đồ nghề đủ

o

Độ đo mođun hoá
2


Phôtô Ngân Sơn Cổng phụ Khu A
o

Độ tự cấp tài liệu

o

Độ đơn giản - dễ hiểu

 Tính mềm dẻo: nỗ lực đòi hỏi để cải biên một chương trình
o Độ phức tạp
o

Độ súc tích

o

Độ hoà hợp

o

Độ khuếch trương được

o

Độ khái quát

o

Độ đo mođun hoá

o

Độ tự cấp tài liệu

o

Độ đơn giản - dễ hiểu

 Tính thử nghiệm được: nỗ lực đòi hỏi để thử nghiệm một chương trình và bảo
đảm rằng nó thực hiện chức năng được dự định cho nó
o Độ kiểm toán được
o

Độ phức tạp

o

Trang bị đồ nghề đủ

o

Độ đo mođun hoá

o

Độ tự cấp tài liệu

o

Độ đơn giản - dễ hiểu

• Loại 3: khả năng thích nghi với môi trường mới - (3)
 Tính mang chuyển được: nỗ lự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 phần cứng/phần mềm khác
o Độ khái quát
o

Độ độc lập phần cứng

o

Độ đo mođun hoá

o

Độ tự cấp tài liệu

o

Độ độc lập hệ thống phần mềm

 Tính sử dụng lại được: một chương trình (hoặc một phần của nó) có thể được

dùng lại trong một ứng dụng khác
o Độ khái quát
o

Độ độc lập phần cứng

o

Độ đo mođun hoá

o

Độ tự tạo tài liệu

o

Độ độc lập hệ thống phần mềm

 Tính liên tác được: nỗ lực đòi hỏi để ghép đôi một hệ thống vào một hệ thống
khác
o Độ tương đồng giao tiếp
o

Độ tương đồng dữ liệu
3


Phôtô Ngân Sơn Cổng phụ Khu A
o

Độ khái quát

o

Độ đo mođun hoá.

• Có hai mức độ ảnh hưởng
 Nhân tố trực tiếp: có thể thực tiếp đo như lỗi/KLOC/ đơn vị thời gian
 Nhân tố gián tiếp: nhân tố chỉ có thể đo được một cách gián tiếp như tính bảo trì
Nhân tố Đúng
Tin
Hiệu Toàn Khả Bảo Mềm Thử Man
Sử
Liên
đắn
cậy
quả
vẹn
dụn
trì
dẻo nghiệ
g
dụng
tác
được
g
được
m
chuy
lại

được
Độ đo
được
ển
được
được
Kiểm toán
X
x
được
Chính xác
x
Tương đồng
x
giao tiếp
Đầy đủ
X
Phức tạp
x
x
x
Súc tích
x
x
x
Hòa hợp
X
x
x
x

Tương đồng
x
dữ liệu
Dung thứ lỗi
x
Hiệu quả
x
thực hiện
Khuyếch
x
trương được
Độc lập phần
x
x
cứng
Trang bị đủ
X
x
x
đồ nghề
Đo Modul
x
x
x
x
x
x
x
hóa
Dễ thao tác

x
x
An ninh
X
Tự tạo tài
x
x
x
x
x
liệu
Đơn giản x
x
x
x
Dễ hiểu
Độc lập hệ
x
x
thống phần
mềm
Lần vết được
X
x
Khả năng
x
huấn luyện
Khái quát
x
x

x
x

4


Phôtô Ngân Sơn Cổng phụ Khu A

Câu 5: Có thể đo trực tiếp chất lượng phần mềm không? Tại sao? Vậy phải đo bằng
cách nào?


Nhân tố trực tiếp: có thể trực tiếp đo như lỗi/KLOC/ đơn vị thời gian

Câu 6: Kể ra các độ đo đặc trưng chất lượng chính của McCall? Giải thích nội dung
của nó?
• McCall đề xuất 22 độ đo sau:
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)

(14)
(15)
(16)
(17)
(18)
(19)

Độ kiểm toán được: có thể kiểm tra dễ dàng về việc tuân thủ các chuẩn
Độ chính xác: Độ chính xác của tính toán và điều khiển
Độ tương đồng giao tiếp: mức độ sử dụng các giao diện, giao thức và giải thông
chuẩn.
Độ đầy đủ: mức độ theo đó các việc cài đặt đầy đủ cho các chức năng yêu cầu đã
được đạt tới.
Độ phức tạp: tránh dùng chương trình có độ phức tạp cao
Độ súc tích (conciseness): độ gọn của chương trình dưới dạng số dòng mã.
Độ hoà hợp (consistancy): việc dùng kỹ thuật thiết kế và tư liệu thống nhất trong
toàn bộ chương trình.
Độ tương đồng dữ liệu: việc dùng các cấu trúc và kiểu dữ liệu chuẩn trong toàn bộ
chương trình
Độ dung thứ lỗi: những hỏng hóc xuất hiện khi chương trình gặp phải một lỗi
được chấp nhận.
Độ hiệu qủa thực hiện: hiệu năng khi chạy của chương trình
Độ khuếch trương được:Mức độ theo đó thiết kế kiến trúc, dữ liệu hay thủ tục có
thể được mở rộng.
Độ khái quát: độ rộng rãi của ứng dụng tiềm năng của các thành phần chương
trình.
Độ độc lập phần cứng: mức độ theo đó phần mềm tách biệt được với phần cứng
mà nó vận hành.
Trang bị đồ nghề đủ (instrumentation):mức độ theo đó chương trình điều phối
thao tác của riêng nó và xác định các lỗi xuất hiện

Độ đo mođun hoá: sự độc lập chức năng của các thành phần trong chương trình
Độ dễ thao tác: Việc dễ vận hành trong chương trình
Độ an ninh: có sẵn cơ chế kiển soát hay bảo vệ chương trình và dữ liệu.
Độ tự tạo tài liệu (self-doccumentation): mức độ theo đó mã gốc cung cấp tài liệu
có ý nghĩa.
Độ đơn giản - dễ hiểu: mức độ theo đó người ta có thể hiểu được chương trình
không khó khăn.

5


Phôtô Ngân Sơn Cổng phụ Khu A
(20)

(21)
(22)

Độ độc lập hệ thống phần mềm: mức độ theo đó chương trình được độc lập với
các tính năng ngôn ngữ lập trình, các đặc trưng hệ điều hành và những ràng buộc
môi trường không chuẩn khác.
Độ lần vết được: khả năng theo dõi các dấu vết của một biểu diễn thiết kế hay
thành phần của chương trình thực hiện so với yêu cầu
Độ đo khả năng huấn luyện: Mức độ theo đó phần mềm trợ giúp làm cho người
dùng mới dùng được hệ thống.

Câu 7: Giải thích nội dung các thuộc tính chất lượng phần mềm sau đây và nêu ra các
độ đo liên quan được sử dụng để đo thuộc tính đó:
 Tính đúng đắn
- Làm đúng với khách hàng mong muốn
- Có thỏa mãn những điều đã được đặc tả (những yêu cầu của đối tượng khác)

o Độ đày đủ
o

Độ hòa hợp

o

Độ lần vết được

 Tính tin cậy được
- Có thể trông đợi vào sự thực hiện các chức năng dự kiến
- mức chính xác được đòi hỏi
o Độ chính xác
o

Độ phức tạp

o

Độ hòa hợp

o

Độ dung thứ lỗi

o

Độ đo mođun hoá

o

Độ đơn giản – dễ hiểu.

o

Độ lần vết được

 Tính hiệu quả: tổng lượng nguồn lực tính toán và mã yêu cầu khi thực hiện các
chức năng của chương trình là thích hợp
o Độ súc tích
o

Độ hiệu quả thực hiện

o

Độ dễ thao tác

 Tính toàn vẹn: là sự khống chế được việc truy cập trái phép tới phần mềm và dữ
liệu hệ thống
o Độ kiểm toán được
o

Trang bị đồ nghề đủ

o

Độ an ninh.

 Tính khả dụng: công sức để học hiểu, thao tác, chuẩn bị đầu vào, thể hiện đầu ra

của chương trình là chấp nhận nhận được
o Độ dễ thao tác
6


Phôtô Ngân Sơn Cổng phụ Khu A
o

Độ đo khả năng huấn luyện

 Tính bảo trì được: nỗ lực cần để định vị và xác định được một lỗi trong chương
trình là chấp nhận được
o Độ súc tích
o

Độ hoà hợp

o

Trang bị đồ nghề đủ

o

Độ đo mođun hoá

o

Độ tự cấp tài liệu

o

Độ đơn giản - dễ hiểu

 Tính mềm dẻo: nỗ lực cần để cải biên một chương trình là chấp nhận được
o Độ phức tạp
o

Độ súc tích

o

Độ hoà hợp

o

Độ khuếch trương được

o

Độ khái quát

o

Độ đo mođun hoá

o

Độ tự cấp tài liệu

o

Độ đơn giản - dễ hiểu

 Tính thử nghiệm được: nỗ lực cần để thử nghiệm một 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
o Độ kiểm toán được
o

Độ phức tạp

o

Trang bị đồ nghề đủ

o

Độ đo mođun hoá

o

Độ tự cấp tài liệu

o

Độ đơn giản - dễ hiểu

 Tính mang chuyển được: nỗ lự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 phần cứng/phần mềm khác là chấp
nhận được
o Độ khái quát

o

Độ độc lập phần cứng

o

Độ đo mođun hoá

o

Độ tự cấp tài liệu

o

Độ độc lập hệ thống phần mềm

 Tính sử dụng lại được: khả năng chương trình (hoặc một phần của nó) có thể
được dùng lại trong một ứng dụng khác
o Độ khái quát
o

Độ độc lập phần cứng
7


Phôtô Ngân Sơn Cổng phụ Khu A
o

Độ đo mođun hoá

o

Độ tự tạo tài liệu

o

Độ độc lập hệ thống phần mềm

 Tính liên tác được: nỗ lực đòi hỏi để ghép hệ thống chương trình vào một hệ
thống khác là chấp nhận được
o Độ tương đồng giao tiếp
o

Độ tương đồng dữ liệu

o

Độ khái quát

o

Độ đo mođun hoá.

Câu 8: Đảm bảo chất lượng phần mềm xuất phát từ đâu? Tiến triển của nó như thế
nào
- 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ừ nhu cầu của khách hàng
• Từ nhà sản xuất: đả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
- Sự phát triển của SQA

• Bảo đảm chất lượng là một hoạt động cốt yếu trong bất kỳ một doanh nghiệp nào
làm ra sản phẩm được người khác dùng
• Lịch sử bảo đảm chất lượng phần mềm (SQA) diễn ra song song với bảo đảm chất
lượng trong chế tạo phần cứng.
• Các chuẩn bảo đảm chất lượng phần mềm đầu tiên được đưa ra trong quân sự, thời
những năm 70 và nhanh chóng lan ra lĩnh vực thương mại
Câu 9:Tại sao cần đảm bảo chất lượng phần mềm? Nó đóng vai trò gì trong một
doanh nghiệp phát triển phần mềm?
Đảm bảo chất lượng phần mềm là các hoạt động nhằm mục tiêu là sản xuất ra phần
mềm có chất lượng cao.
• Phải đảm bảo chất lượng phần mềm vì
•
•
•
•
•
•
•

Từ nhu cầu của khách hàng
Từ nhà sản xuất: đảm bảo tính đồng đều của sản phẩm làm ra
Giúp nhà phân tích có được đặc tả chất lượng cao
Giúp nhà thiết kế có được thiết kế chất lượng cao
Theo dõi chất lượng phần mềm
Đánh giá ảnh hưởng của thay đổi về phương pháp luận và thủ tục lên chất lượng
phần mềm
SQA có những lợi ích sau:
- phần mềm có ít các khiếm khuyết tiềm ẩn hơn và do đó mất ít công sức và thời
gian thử nghiệm và bảo trì
8

Phôtô Ngân Sơn Cổng phụ Khu A

-

Độ tin cậy cao hơn và do đó khách hàng thoả mãn hơn
Giảm phí tổn bảo trì
Giảm phí tổn tổng thể toàn bộ vòng đời của phần mềm

• nó đóng vai trò trong một doanh nghiệp phát triển phần mềm
•

Bảo đảm chất lượng là một hoạt động cốt yếu trong bất kỳ một doanh nghiệp nào
làm ra sản phẩm được người khác dùng

Câu 10: Trong một tổ chức ai là người tham gia vào hoạt động đảm bảo chất lượng?
Vai trò và trách nhiệm của mỗi đối tượng đó là gì?
Những người trong tổ chức có trách nhiệm bảo đảm chất lượng phần mềm:
- các kỹ sư phần mềm,
- các nhà quản lý dự án,
- khách hàng,
- người bán hàng,
- các cá nhân trong nhóm SQA.
• Nhóm SQA đóng vai trò như đại diện của khách hàng - để xem chất lượng phần
mềm với quan điểm khách hàng
• Có đáp ứng được các nhân tố chất lượng không?
• Có tuân theo 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?

Câu 11: Mục tiêu của SQA là gì? Các hoạt động chính đảm bảo chất lượng phần mềm
là những hoạt động nào?
Đảm bảo chất lượng phần mềm là các hoạt động nhằm mục tiêu là sản xuất ra phần
mềm có chất lượng cao.
• Có 7 hoạt động chính:
1.
2.
3.
4.
5.
6.
7.

Áp dụng các phương pháp kỹ thuật tiến bộ
Tiến hành rà soát kỹ thuật chính thức
Thử nghiệm phần mềm
Tuân theo các chuẩn
Khống chế các thay đổi
Đo lường
Báo cáo và bảo quản các báo cáo.

Câu 12: Giải thích nội dung tóm tắt của mỗi hoạt động chính đảm bảo chất lượng?
1. Áp dụng các phương pháp kỹ thuật: giúp cho
- người phân tích có được đặc tả chất lượng cao
- người thiết kế có được thiết kế với chất lượng cao.
9


Phôtô Ngân Sơn Cổng phụ Khu A

2. Tiến hành rà soát kỹ thuật chính thức: được nhóm kỹ thuật tiến hành với mục đích
là phát hiện ra vấn đề chất lượng.
3. Kiểm thử phần mềm: là một chiến lược nhiều bước với một loạt các phương pháp
thiết kế các trường hợp kiểm thử giúp đảm bảo phát hiện ra các lỗi một cách hiệu
quả.
4. Bắt tuân theo các chuẩn: Là hình thức được áp dụng cho tiến trình kỹ nghệ phần
mềm thay đổi tuỳ theo công ty.
5. Khống chế các thay đổi: đóng góp trực tiếp vào chất lượng phần mềm nhờ
+ Chính thức hoá các yêu cầu đổi thay
+ Đánh giá bản chất của sự đổi thay
+ Khống chế các ảnh hưởng của sự đổi thay
+ Đe doạ chủ yếu của chất lượng đến từ sự thay đổi, thay đổi là bản chất của
phần mềm
+ thay đổi tạo ra tiềm năng sinh ra sai và tạo ra hiệu ứng phụ lan truyền
Áp dụng trong suốt quá trình phát triển và trong quá trình bảo trì
6. Đo lường: dùng để theo dõi chất lượng phần mềm và thẩm định tác dụng của những
thay đổi phương pháp luận và thủ tục lên chất lượng phần mềm đã được cải tiến.
7. Báo cáo và bảo quản các báo cáo: Kết quả của các cuộc họp xét duyệt , kiểm toán,
kiểm soát thay đổi, kiểm thử phải trở thành một phần của bản ghi lịch sử cho một
dự án và phải được phân phát cho nhóm phát triển trên cơ sở điều-cần - phải- biết.
Câu 13: Rà soát phần mềm được hiểu là gì (khái niệm, mục tiêu, cách thức áp
dụng)? Nêu các lợi ích của việc ra soát?
• Khái niệm: Rà soát là việc xem xét, đánh giá sản phẩm được tiến hành mỗi giai đoạn
để phát hiện ra những khiếm khuyết cần sửa chữa trước khi sang giai đoạn sau.
• Mục tiêu:
•
•
•

Chỉ ra các chỗ khiếm khuyết cần phải cải thiện

Khẳng định những sản phẩm đạt yêu cầu
Kiểm soát việc đạt chất lượng kỹ thuật tối thiểu của sản phẩm

• Cách thức áp dụng: Rà soát được áp dụng tại các thời điểm khác nhau trong quá trình
phát triển phầm mềm.
• Có nhiều kiểu rà soát khác nhau:
•
•

Các cuộc họp xét duyệt không chính thức
Cuộc trình bày chính thức trước cử tọa gồm khách hàng, nhà quản lý, nhân viên
kỹ thuật. (chỉ tập trung vào các rà soát kỹ thuật chính thức FTR-Format Technical
Review)

• Các lợi ích của việc ra soát
 Lợi ích hiển nhiên của FTR là sớm phát hiện các “khiếm khuyết” phần mềm để
có thể chỉnh sửa từng khiếm khuyết một trước khi bước sang bước tiếp theo của
quá trình phần mềm.
10


Phôtô Ngân Sơn Cổng phụ Khu A

 Các nghiên cứu của công nghiệp phần mềm đã chỉ ra rằng: các hoạt động thiết kế
tạo ra đến 50%-60% tổng số các khiểm khuyết tạo ra trong phát triển phần mềm.
 Chi phí chỉnh sửa một khiếm khuyết tăng lên nhanh chóng sau mỗi giai đoạn.
VD: Lỗi không được phát hiện trong thiết kế tốn phí 1.0 để sửa chữa, trước kiểm
thử nghiệm: 6.5; trong thử nghiệm: 15 và sau khi phân phát sẽ là từ 60.0 đến
100.0
Câu 14: Các hình thức của hoạt động rà soát? trình bày khái niệm, mục tiêu của rà

soát kỹ thuật chính thức?
• Có nhiều kiểu rà soát khác nhau:
•
•

Các cuộc họp xét duyệt không chính thức
Cuộc trình bày chính thức trước khách hàng, nhà quản lý, thành viên kỹ thuật

• Rà soát do các kỹ sư phần mềm thực hiện, là một phương tiện hiệu quả để cải thiện
chất lượng phần mềm.
Rà soát kỹ thuật chính thức(FTR):
- Khái niệm: là hoạt động đảm bảo chất lượng phần mềm do những người đang
tham gia phát triển phần mềm thực hiện.
- Mục tiêu:
(1) Phát hiện các lỗi trong chức năng, trong logic, trong triển khai.
(2) Kiểm thử sự phù hợp của phần mềm với yêu cầu
(3) Bảo đảm rằng phần mềm phù hợp với các chuẩn đã định sẵn
(4) Đảm bảo “ phần mềm đã được phát triển theo một cách thức nhất quán.
(5) Làm cho dự án dễ quản lý hơn
(6) Ngoài ra dùng để làm cơ sở huấn luyện các kỹ sư trẻ và có ích ngay cả
cho những kỹ sư đã có kinh nghiệm.

Câu 15: Vẽ sơ đồ tiến trình hoạt động rà soát va giải thích sơ bộ nội dung mỗi bước?

Giải thích:

11


Phôtô Ngân Sơn Cổng phụ Khu A

-

Mỗi cá nhân phát triển phải thông báo cho lãnh đạo dự án biết rằng sản phẩm
đã hoàn tất và cần phải rà soát.
Lãnh đạo dự án thông báo cho người chịu trách nhiệm rà soát biết
Người chịu trách nhiệm lãnh đạo rà soát:
o Xem xét sản phẩm để đọc, rà soát
o Tạo ra các bản sao của sản phẩm , phân cho 2,3 người ra soát
o Thiết lập chương trình họp rà soát

-

Những thực hiện rà soát: thường tốn 1-2 giờ để rà soát viết các bản ghi chú :
tham gia cuộc họp rà soát.

Câu 16: Trình bày nội dung cơ bản một cuộc họp rà soát: thành phần, thời gian, công
việc cần làm, phương châm , sản phẩm?
Bất kể thế nào, mọi cuộc họp rà soát phải:
• Thành phần: Có từ 3 đến 5 người liên quan tới việc rà soát, gồm có:
•
•
•

lãnh đạo rà soát
tất cả các cá nhân rà soát
người tạo ra sản phẩm được rà soát

• Thời gian:
•

•

Phải có sự chuẩn bị trước, tuy nhiên mỗi người không quá 2 giờ chuẩn bị.
Cuộc họp nên ít hơn 2 giờ. Mỗi cuộc họp rà soát chỉ hạn chế trong một phần nhỏ,
cụ thể.

• Công việc cần làm:
•

•

•

Trọng tâm của các cuộc họp rà soát là về sản phẩm: một thành phần (một thành
phần của đặc tả yêu cầu, một thiết kế modul chi tiết, một danh sách mã nguồn cho
một modul)
Phải đưa ra một trong 3 quyết định sau đây:
- Chấp nhận sản phẩm không cần chỉnh sửa
- Khước từ sản phẩm vì những lỗi nghiêm trọng
- Chấp nhận cho chỉnh sửa sản phẩm, sau khi chỉnh sửa phải có cuộc họp rà soát
lại
Mọi thành viên tham gia cuộc họp phải ký vào quyết định

• Phương châm rà soát:
•

•

Cần thiết lập trước phương châm rà soát, phân phát cho những người làm nhiệm
vụ rà soát, thống nhất tán thành và tuân thủ. Một rà soát mà không khống chế

được thì có thể còn xấu hơn là không rà soát
10 điều tối thiểu trong phương châm rà soát kỹ thuật chính thức:
(1) rà soát sản phẩm, không rà soát người làm nó
(2) Lập chương trình nghị sự và duy trì nó.
12


Phôtô Ngân Sơn Cổng phụ Khu A
(3)

(4)

(5)
(6)
(7)

(8)

(9)
(10)

Hạn chế tranh luận và bác bỏ: các vấn đề tranh luận nên để ghi nhớ cho các
thảo luận tiếp tục
Trình bày rõ ràng mạch lạc các vùng có vấn đề nhưng không được gượng ép
giải quyết mọi vấn đề nhận thấy: FTR không giải quyết vấn đề, việc giải quyết
vấn đề sau FTR và thường do chính người làm ra sản phẩm thực hiện, có thể
nhờ sự trợ giúp của vài cá nhân khác.
Nên có ghi chú trên bảng tường
Giới hạn số người tham dự và kiên trì các dự kiến
Lập một danh sách các kiểm tra cho từng sản phẩm sẽ được rà soát:

 Giúp nhà lãnh đạo rà soát cấu trúc các cuộc họp FTR
 Giúp người rà soát tập trung vào các vấn đề quan trọng
 Danh sách kiểm tra lập cho từng loại sản phẩm:ành cho việc phân tích, thiết
kế, mã hoá kiểm tra và bảo trì
 Một tập thể các đại diện sẽ xem lại danh sách này để trình.
Cấp phát nguồn lực và thời biểu cho các FTR: xem nó là một nhiệm vụ trong
quá trình phát triển phần mềm, và cũng phải dự tính các cải biên cần thiết
cho sự kiện chưa dự đoán được
Cần phải tiến hành huấn luyện chính thức cho các cá nhân ra soát
Rà soát lại các rà soát trước đây.

Câu 17: Các sản phẩm của cuộc họp rà soát là gì? Nội dung, vai trò của mỗi sản
phẩm đó?
Sản phẩm của cuộc họp rà soát là:
• Báo cáo các vấn đề nảy sinh do các cá nhân rà soát nêu ra
• Một danh sách các vấn đề cần giải quyết do cuộc họp thống nhất.
 để nhận ra vùng có vấn đề trong sản phẩm được rà soát
 dùng như một danh sách các khoản mục hành động để chỉ cho người làm ra
sản phẩm cần chỉnh sửa
 Cần thiết lập một thủ tục để bảo đảm rằng các khoản mục trong danh sách
đó sẽ được chỉnh sửa thực sự
• Một văn bản tổng kết cuộc họp rà soát đó, văn bản này phải chỉ rõ
 Rà soát cái gì
 Ai rà soát
 Tìm thấy cái gì? và kết luận
Câu 18: Khi nào tiến hành rà soát? Cần rà soát những sản phẩm gì
-

Mọi sản phẩm tạo ra ở mỗi bước đều được rà soát (không chỉ sản phẩm cuối
cùng)

-

Rà soát được tiến hành suốt quá trình phát triển
13


Phôtô Ngân Sơn Cổng phụ Khu A

-

Tiến trình phát triển chung nhất gồm 4-5 giai đoạn:
 Kỹ nghệ hệ thống
 Phân tích, xác định yêu cầu phần mềm
 Thiết kế phần mềm
 Kiểm thử phần mềm
 Bảo trì (với sản phẩm đặt hàng)
Rà soát bám theo các sản phẩm của rà soát này

Câu 19: Trình bày nội dung danh mục rà soát của?
Danh mục rà soát trong kỹ nghệ hệ thống:
Bảo đảm chất lượng mức này là đánh giá yêu cầu thẩm duyệt ở mức hệ thống: Một cuộc
họp lớn gồm đại diện các đơn vị liên quan
(1) Các chức năng chủ yếu đã được xác định đủ và rõ ràng(không mơ hồ)?
(2) Các giao diện giữa các hệ con của hệ thống đã được xác định đủ và đúng hay chưa?
(3) Các ràng buộc thực thi đã được thiết lập cho toàn hệ thống và cho từng phần tử hay
chưa?
(4) Các ràng buộc thiết kế đã được thiết lập cho từng phần tử hay chưa?
(5) khả năng chọn đã là đã tốt nhất chưa?
(6) Giải pháp này có khả thi kỹ thuật không?

(7) Cơ chế kiểm chứng và thẩm duyệt đã đwợc thiết lập hay chưa?
(8) Có sự hoà hợp giữa các phần tử của hệ thống hay chưa?
Rà soát việc lập kế hoạch
Lập kế hoạch dự án phần mềm dựa trên sản phẩm của kỹ nghệ hệ thống để đưa ra các nội
dung chủ yếu:
+ Phạm vi công việc kiểm tra thực hiện
+ ước lượng nguồn lực, giá cả, thời gian công việc
+ Lịch biểu thực hiện
+ Tổ chức, nhân sự, cơ chế triển khai
+ đánh giá rủi ro và kế hoạch khác
Danh mục
(1) Phạm vi của phần mềm đã xác định đúng đắn chưa? có bị hạn chế hay không?
(2) Thuật ngữ có trong sáng không?
(3) Các nguồn lực (người, chi phí, thời gian): có đủ tương xứng với phạm vi đó
không? Các nguồn lực đã có sẵn sàng chưa?cơ sở dự đoán giá cả có hợp lý không?
dữ liệu năng xuất và chất lượng trước đây có được sử dụng không? Sự khác biệt
của ước lượng đã được sử lý chưa?
14


Phôtô Ngân Sơn Cổng phụ Khu A
(4)

(5)
(6)

(7)

(8)

Các công việc lên lịch biểu đã: xác định thích hợp chưa? Sắp xếp trình tự thực hiện
đúng logic chưa? bố trí song song có phù hợp với các nguồn lực đã sẵn có hay
không?
Phương án tổ chức và nhân sự đã hợp lý chưa?
Các rủi ro trong tất cả các hạng mục quan trọng đã: xác định và đánh giá đầy đủ
chưa? Lập kế hoạch quản lý và kế hoạch thích hợp chưa?
Các nhiệm vụ đã thật sự được xác định và sắp xếp tuần tự chưa?, tính song song
có hợp lý đối với các nguồn lực đã sẵn có hay chưa?
Ngân sách và giới hạn chót được dự kiến: có hiện thực hay không? có phù hợp với
lịch biểu không?

Trình bày những nội dung cơ bản (mục tiêu, nội dung, danh mục) của
- rà soát phân tích yêu cầu phần mềm
- rà soát thiết kế phần mềm ( tương ứng với từng giai đoạn thiết kế)
- rà soát lập mã phần mềm
- rà soát kiểm thử phần mềm (tương ứng với kế hoạch và thủ tục kiểm thử)
- rà soát bảo trì phần mềm (ứng với kế hoạch và thủ tục kiểm thử)
TL
• rà soát phân tích yêu cầu phần mềm
♦ Mục tiêu: thẩm định và xác minh yêu cầu phần mềm
− phải chỉ ra các nhu cầu của người dùng là được thoả mãn
− Các yêu cầu phải nhất quán, nghĩa là không mâu thuẫn nhau
− Các yêu cầu phải đầy đủ: chúng phải chứa mọi chức năng và mọi ràng buộc mà
người dùng đã nhắm đến
− Các yêu cầu phải là hiện thực, tức là có khả năng thực hiện được
♦

Nội dung:
− tập trung vào khả năng viết ra các yêu cầu hệ thống phần mềm (chức năng, phi
chức năng, ngoại lai)

− sự phù hợp và tính đúng đắn của mô hình phân tích.
− Với các hệ thống lớn cần tăng cường:

♦

Các rà soát kỹ thuật chính thức
việc đánh giá các nguyên mẫu cũng như các cuộc họp với khách hàng
Danh mục: xem xét các chủ đề sau:
(1) Phân hoạch vấn đề (hệ con) có đầy đủ hay không?
(2) Các giao diện trong và ngoài đã thực sự được xác định chưa?
(3) Phân tích lĩnh vực thông tin có đầy đủ, phi mâu thuẫn và chính xác hay ko?
(4) Mô hình dữ liệu đã thực sự phản ánh các đối tượng dữ liệu, các thuộc tính và các
quan hệ?
(5) Tất cả các yêu cầu có thể lần vết được ở mức hệ thống không?
(6) Đã làm bản mẫu dành cho người sử dụng (khách hàng) chưa?
15


Phôtô Ngân Sơn Cổng phụ Khu A

Liệu có thực hiện được với những ràng buộc quy định bởi các phần tử hệ thống
khác hay không?
(8) Các yêu cầu có phù hợp với lịch biểu, nguồn lực và kinh phí hay không?
(9) Các chuẩn thẩm định có đầy đủ hay không?
(7)

• rà soát thiết kế phần mềm ( tương ứng với từng giai đoạn thiết kế)
♦ Mục tiêu: Hướng đến thiết kế đảm bảo hai yêu cầu
− Phản ánh đúng các yêu cầu đặc tả





Đủ các phần
Đủ chức năng và ràng buộc
Dữ liệu đủ, phù hợp

− Có chất lượng tốt
Cấu trúc tốt (phân hoạch, giao diện, modul hoá)

Thuật toán tốt (ít phức tạp, tốc độ cao, dễ hiểu)

Dữ liệu tốt (cấu trúc, biểu diễn)

Có thể lần vết được (dễ hiểu, dễ kiểm tra)
Nội dung:


♦

− Rà soát kỹ thuật chính thức cho khâu thiết kế tập trung vào:




thiết kế dữ liệu
thiết kế kiến trúc
thiết kế thủ tục.

− Có 2 kiểu rà soát thiết kế (phù hợp với bước triển khai):

rà soát thiết kế sơ bộ - preliminary design review (đánh giá việc dịch các yêu
cầu thành thiết kế dữ liệu và thiết kế kiến trúc),

rà soát thiết kế trọn vẹn - design walkthrough (tập trung vào tính đúng đắn
của thuật toán).
Danh mục


♦

− Rà soát thiết kế sơ bộ
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)

Các yêu cầu phần mềm có được phản ánh trong kiến trúc phần mềm hay không?
Có đạt được sự môđun hoá hiệu quả không? Các môđun có độc lập chức năng
hay không
Kiến trúc chơng trình có được phân tách không?
Các giao diện đã được xác định cho các môđun và các phần tử hệ thống ngoại
lai chưa?
Cấu trúc dữ liệu có phù hợp với lĩnh vực thông tin chưa?
Cấu trúc dữ liệu có phù hợp với yêu cầu phần mềm chưa?
Khả năng bảo trì đã được xem xét chưa?
Các nhân tố chất lượng đã được đánh giá rõ ràng chưa?

16


Phôtô Ngân Sơn Cổng phụ Khu A

− Rà soát thiết kế toàn bộ
Thuật toán có hoàn thành chức năng mong muốn không?
(2) Thuật toán có đúng đắn logic không?
(3) Giao diện có phù hợp với thiết kế kiến trúc không?
(4) Độ phức tạp logic có phải chăng hay không?
(5) Sử lý sai đã được đặc tả chưa?
(6) Cấu trúc dữ liệu cục bộ có thật sự đã được xác định?
(7) Kiến tạo lập trình cấu trúc đã xuyên suốt chưa?
(8) Các chi tiết thiết kế đã tuân theo ngôn ngữ thực hiện chưa?
(9) Dùng các đặc điểm hệ điều hành hay là phụ thuộc ngôn ngữ?
(10) Đó dùng logic compound hoặc logic inverse?
(11) Khả năng bảo trì đã được xét tới chưa
• rà soát lập mã phần mềm
♦ Mục tiêu: rà soát hướng đến mã nguồn đạt được
(1)

− phản ánh đầy đủ, phù hợp với thiết kế
− phù hợp với ngôn ngữ sử dụng (chuẩn, cú pháp, khai báo dữ liệu...)
− Văn bản chương trình tốt (không lỗi chính tả, có cấu trúc, nhất quán ...)
Nội dung
♦ Danh mục
(1) Thiết kế có thực sự được dịch thành mã chưa?
(2) Có các sai sót chính tả hoặc in ấn nào không?
(3) Có thực sự dùng các quy ước ngôn ngữ hay không?
(4) Có phục tùng về các chuẩn mẫu lập mã đối với phong cách ngôn ngữ, ghi chú ...

(5) Có ghi chú nào không đúng đắn hoặc mơ hồ?
(6) Kiểu dữ liệu và khai báo dữ liệu có chính xác hay không?
(7) Các hằng số vật lý có đúng đắn hay không?
(8) Có phải tất cả các khoản mục của danh sách rà soát thiết kế trọn vẹn là được áp
dụng lại hay không?
• rà soát kiểm thử phần mềm (tương ứng với kế hoạch và thủ tục kiểm thử)
♦ Mục tiêu:
♦

− Đánh giá một cách phê phán các kế hoạch kiểm thử và các thủ tục kiểm thử

♦

− hướng đến đảm bảo các phương pháp, các chiến lược và các kỹ thuật được sử
dụng và kế hoạch tốt
Nội dung:
− chiến lược kiểm thử




từ trên xuống
từ dưới lên
vụ nổ lớn (big bang)
17


Phôtô Ngân Sơn Cổng phụ Khu A

− kỹ thuật kiểm thử







kiểm thử hộp đen
kiểm thử hộp trắng
kiểm thử tải trọng
kiểm thử luồn sợi (cho hệ thời gian thực)
sử dụng CASE

− Kế hoạch kiểm thử tổng thể
Giới thiệu chung
 Mô tả hệ thống cần kiểm thử
 Các mục tiêu kiểm thử
 Phương pháp sử dụng
 Tài liệu hỗ trợ

Kế hoạch
 Thời gian, địa điểm
 Tài liệu kiểm thử: các ca kiểm thử, tiến trình, lịch trình
 Điều kiện

Các yêu cầu: phần cứng, phần mềm, nhân sự

Kiểm soát quá trình kiểm thử
Danh mục:
(1) Các pha thử nghiệm chủ yếu có thực sự được định rõ và được xắp xếp tuần tự
hay không?

(2) Theo dõi các yêu cầu (tiêu chuẩn) có được thiết lập như một phần của pha phân
tích yêu cầu phần mềm hay không?
(3) Các chức năng chủ yếu có được trình diễn sớm không?
(4) Kế hoạch thử nghiệm có phù hợp với kế hoạch dự án tổng thể hay không?
(5) Lịch trình thử nghiệm có được xác định rõ ràng hay không?
(6) Nguồn lực và công cụ thử nghiệm đã đợc minh định và đã sẵn sàng hay chưa?
(7) Đã thiết lập cơ chế lưu trữ các báo cáo chưa?
(8) Các bộ lái (driver) và các cuống (stub) thử nghiệm đã được minh định chưa?;
công việc phát triển chúng đã được lập lịch chưa?
(9) Thử nghiệm cường độ chịu áp lực cho phần mềm đã được đặc tả chưa?
(10) Cả hai loại thử nghiệm hộp trắng và hộp đen đã được đặc tả chưa?
(11) Có phải tất cả các đường logic độc lập đều được thử nghiệm?
(12) Có phải tất cả các ca thử nghiệm đều đã được minh định và lập danh sách với đủ
các kết qủa chờ mong?
(13) Việc xử lý sai có được thử nghiệm?
(14) Các giá trị biên có được thử nghiệm?
(15) Các yêu cầu thời gian và sự diễn tiến có được thử nghiệm?


♦

18


Phôtô Ngân Sơn Cổng phụ Khu A

Các biến thể chấp nhận được của kết quả thử nghiệm mong đợi đã được đặc tả
chưa?
• rà soát bảo trì phần mềm (ứng với kế hoạch và thủ tục kiểm thử)
(1) Đã xét đến các hiệu ứng phụ gắn với các đổi thay hay chưa?

(2) Xem xét yêu cầu đổi thay đã được lập tài liệu, được đánh giá và được chấp thuận
hay chưa?
(3) Báo cáo xem xét sự đổi thay cho tất cả các bên quan tâm hay chưa?
(4) Các rà soát kỹ thuật chính thức thích hợp đã được tiến hành hay chưa?
(5) Một rà soát chấp thuận cuối cùng đã được thực hiện để bảo đảm rằng toàn bộ phần
mềm đã thực sự được cập nhật, được thử nghiệm và được thay thế hay chưa?
(16)

−

D6: Đặc trưng vào/ra của mô dun D6=1-s7/s1

19


Phôtô Ngân Sơn Cổng phụ Khu A

Câu20:Số đo độ phức tạp của McCabedựa trên cái gì và những đại lượng cụ thể
nào?
- Số đo dựa trên độ phức tạp chu trình trong đồ thị chương trình của một modun
+ Số chu trình có chu trình lồng nhau
+ Số chu trình trong một chu trình
- Người ta cũng dùng các miền phẳng của đồ thị phẳng để biểu diễn đồ thị chương
trình
Câu21: Đảm bảo chất lượng phần mềm dựa trên thống kê nghĩa là gì?Nó gồm
những công việc gì? Kể ít nhất năm nguyên nhân của những khuyết điểm trong
phần mềm?
Là bảo đảm chất lượng thống kê phản ánh một xu thế ngày càng tăng trong công
nghiệp.
Công việc bao gồm:

- Thu thập và phân loại thông tin khiếm khuyết phần mềm.
- Cố gắng lần vết để tìm ra nguyên nhân
- Dùng nguyên lý Pare cô lập 20% khiếm khuyết
- Sau khi tìm được nguyên nhân sẽ chỉnh sửa các nguyên nhân của khiếm khuyết
Các nguyên nhân gây ra khiếm khuyết có thể là:
- Đặc tả không đầy đủ hoặc sai sót (IES)
- Hiểu nhầm khi giao tiếp với khách hàng (MCC)
- Lệch hướng dự định khi đặc tả (IDS)
- Vi phạm các chuẩn lập trình (VPS)
- Sai trong biểu diễn dữ liệu (EDR)
- Không phù hợp với giao diện modun (IMI)
- Sai trong logic thiết kế (EDL)
- Thử nghiệm sai hoặc không đầy đủ (IET). . .
Câu 22: Tiếp cận hình thức cho SQA nghĩa là gì? Quá trình phòng sạch là gì?
Phương châm của kỹ thuật này là gì?
Người ta nhận thấy cần phải dùng một cách tiếp cận hình thức hơn trong việc bảo
đảm chất lượng phần mềm, cách tiếp cận này sẽ bổ sung cho các hoạt động mô tả
ở trên
Tiếp cận hình thức hoá: đặc tả hình thức cho phép chứng minh tính đúng đắn,
kiểm tra lỗi, chuyển tự động thành chương trình . . . làm tăng chất lượng.
- Kiểm chứng chương trình một cách hình thức (chứng minh tính đúng đắn) và bảo
đảm chất lượng phần mềm thống kê hợp lại với nhau cho ta ta một kỹ thuật cải
thiện chất lượng sản phẩm, được gọi là quá trình phòng sạch.
- Phương châm của kỹ thuật này là: Phòng khiếm khuyết hơn là trừ khiếm khuyết
Câu23: Độ tin cậy của phần mềm là cái gì? Đo độ tin cậy dựa trên những dữ liệu
nào?
20


Phôtô Ngân Sơn Cổng phụ Khu A

- Độ tin cậy của phần mềm là một yếu tố quan trọng trong chất lượng phần mềm.
- Độ tin cậy phần mềm được định nghĩa theo thuật ngữ thống kê: “xác suất thao tác
không thất bại của chương trình máy tính trong một môi trường đặt biệt với một thời gian
đã định rõ”.
- Độ tin cậy của phần mềm được đo trực tiếp và được đánh giá qua các dữ liệu phát
triển và các dữ liệu lịch sử.
Câu 24: Nêu chỉ tiêu để tính độ tin cậy? Nêu công thức tính độ sẵn sàng? Giải thích ý
nghĩa của nó?
- Với các hệ thống dựa trên máy tính thì một số đo đơn giản về độ tin cậy chính là thời
gian trung bình giữa hai lần thất bại kế tiếp (MTBF- Mean Time Between Failure):
MTBF = MTTF + MTTR
- MTTF (Mean Time To Failure) là thời gian hoạt động liên tục trung bình
- MTTR (Mean Time To Repair) là thời gian sửa xong lỗi trung bình
• Ý nghĩa:
MTBF là cách đo hữu ích hơn nhiều so với tỷ số “số khiếm khuyết”/KLOC (LOCLine Of Code) vì người dùng cuối cùng quan tâm tới những thất bại chứ không quan tâm
đếm lỗi (nhà nghiên cứu).
Do các lỗi trong chương trình không có cùng mức độ (nặng, nhẹ khác nhau) nên số
các lỗi chỉ cho ta một chỉ số nhỏ về độ tin cậy của hệ thống.
VD: Khi đưa 1 chương trình vào vận hành trong 14 tháng , trong các lỗi chưa được
phát hiện có lỗi chỉ được phát hiện sau dăm chục năm, các lỗi còn lại với MTBF khoảng
18-24 tháng
- Độ sẵn sàng phần mềm là xác suất để chương trình vận hành đúng với yêu cầu ở các
thời điểm đã định và được tính như sau:
MTTF/(MTTF + MTTR) x100%
Ý nghĩa
Thể hiện tỷ lệ thời gian làm việc trung bình trong tổng thời gian vận hành
Là độ đo gián tiếp về khả năng bảo trì được (số này càng gần 100 là đã bảo trì tốt)
Câu 25: Có những mô hình độ tin cậy nào? Nó dựa trên tham biến nào và trên giả
thiết nào? Mô hình độ tin cậy gieo hạt dựa trên ý tưởng nào? Mục tiêu để làm

gì
• Có hai mô hình độ tin cậy phần mềm:
- Mô hình tiên đoán độ tin cậy như là một hàm của thời gian lịch
- Mô hình tiên đoán độ tin cậy như là một hàm của thời gian xử lý đã trôi qua (thời
gian vận hành của CPU). Loại này được coi là tốt hơn.
• Các mô hình độ tin cậy phần mềm dựa trên các giả thiết:
- Thời gian gỡ lỗi giữa các xuất hiện sai có phân phối mũ với nhịp độ xuất hiện sai,
nhịp độ này tỷ lệ thuận với số các lỗi còn lại
MT –21Fa – Fc -Fd
MT


Phôtô Ngân Sơn Cổng phụ Khu A

- Mỗi lỗi bị phát hiện sẽ được loại trừ ngay lập tức và số lỗi còn lại giảm đi 1
- Nhịp độ thất bại giữa các lỗi là không thay đổi
• Các giả thiết này còn phải bàn: vì một lỗi được loại trừ thì có thể nhiều lỗi khác lại
được sinh ra.
• Một lớp các mô hình độ tin cậy phần mềm dựa vào các đặc trưng tồn tại của một
chương trình và tính toán số dự đoán các sai tồn tại trong phần mềm
• Các mô hình này dựa trên các quan hệ định lưwngj như một hàm của độ đo tính phức
tạp, chúng liên kết thiết kế đặc chủng hoặc các thuộc tính hướng mã của chương trình
với “một ước định số khải phát các lỗi được tin rằng có trong chương trình đã cho”
Mô hình độ tin cậy gieo hạt dựa trên ý tưởng nào? Mục tiêu để làm gì?
• Ý tưởng: Một chương trình được gieo một cách ngẫu nhiên một số các lỗi(k) hiệu
chuẩn (calibration) vào một chương trình; sau đó đem kiểm thử (bằng một số ca thử
nghiệm); tính xác suất tìm được j lỗi trong tập J lỗixem như tương ứng với xác suất
tìm được k lỗi đã gieo trong K lỗi đã nhúng vào chương trình.
j/J=k/K
• Mục đích:

- dùng như một chỉ báo của độ tin cậy phần mềm;
- hoặc một cách thực tiễn hơn như một độ đo “năng lực phát hiện sai” của một tập hợp
các ca thử nghiệm.
Câu 26: Độ an toàn phần mềm là cái gì?Có những phương pháp nào để phân tích độ
an toàn?
• An toàn phần mềm là một hoạt động bảo đảm chất lượng phần mềm tập trung vào việc
minh định và đánh giá các mối nguy hiểm tiềm ẩn có thể gây ảnh hưởng phản tác dụng
thậm chí là gây ra thất bại của toàn hệ thống.
• Độ an toàn phần mềm xem xét lại cách thức lỗi nảy sinh trong một điều kiện nào đó có
thể dẫn tới rủi ro. Nghĩa là lỗi không được xem xét trong chân không mà được đánh
giá trong hoàn cảnh của toàn bộ hệ thống dựa trên máy tính.
Có các phương pháp như:
• Phân tích cây lỗi:
 dựng lên một mô hình đồ thị các tổ hợp tuần tự và song song các sự kiện dẫn đến
một sự kiện hay một trạng thái hệ thống mạo hiểm.
 Dùng một cây lỗi phát triển tốt có thể quan sát được hậu quả của một dãy các thất
bại liên kết với nhau, xuất hiện trong các thành phần khác nhau của hệ thống.
• Logic thời gian thực: xây dựng mô hình hệ thống bằng các đặc tả các sự kiện và các
hành động tương ứng. Mô hình sự kiện – hành động có thể được phân tích bằng cách
dùng các toán tử logic để thử nghiệm các quyết đoán an toàn đối với các thành phần
của hệ thống và định thời cho chúng
• Mô hình lưới petry: dùng để xác định xem lỗi nào là nghiêm trọng nhất
22


Phôtô Ngân Sơn Cổng phụ Khu A

Câu 27: Khảo sát nhu cầu SQA gồm những nội dung gì? nhằm trả lời các câu hỏi gì?
nếu có nhu cầu thì mình làm gì?
- Gồm ba nội dung nhằm trả lời ba câu hỏi

+ Kiểm kê các chính sách SQA: chính sách, thủ tục, chuẩn nào đã có trong các pha
phát triển?
+ Đánh giá vai trò của kỹ nghệ phần mềm, bảo đảm chất lượng trong tổ chức hiện
tại có quyền lực đến đâu?
+ Đánh giá mối quan hệ SQA: Giao diện chức năng giữa SQA với các đơn vị khác
như thế nào? với các người thực hiện rà soát kỹ thuật chính thức, quản lý cấu hình và thử
nghiệm
- Nếu có nhu cầu thì cần phải tiến hành đánh giá cẩn thận bằng quy tắc bỏ phiếu.
Câu 28: Có những vấn đề gì đạt ra khi triển khai SQA? Lợi íchcủa SQA là gì? Nguyên
tắc chi phí hiệu quả của SQA là gì?
- SQA có những vấn đề sau đây
+ Khó thiết lập trong một tổ chức nhỏ: khó có nguồn lực để thực hiện các hoạt
động cần thiết mà hiện chưa có.
+ Nó biểu thị một thay đổi có tính văn hoá: nên chẳng bao giờ dễ dàng thực hiện
+ Nó đòi hỏi tiêu tốn không ít tiền
- SQA có những lợi ích sau đây:
+ Phần mềm có ít các khiếm khuyết tiềm ẩn hơn và do đó mất ít công sức và thời
gian kiểm thử và bảo trì.
+ Độ tin cậy cao hơn và do đó khách hàng thoả mãn hơn
+ Giảm phí tổn bảo trì
+ Giảm phí tổn tổng thể toàn bộ vòng đời của phần mềm
- Nguyên tắc chi phí: Ở mức cơ bản SQA được xem là hiệu quả về chi phí nếu
C3>C1 + C2
Ở đây:
+ C3 là chi phí từ các sai do không có SQA
+ C1 là chi phí cho SQA của chương trình
+ C2 là chi phí do các sai không tìm thấy khi chương trình đã có SQA
Câu 29: Tại sao phải kiểm thử phần mềm? Mục tiêu kiểm thử là gì? Từ đó có quan
niệm già sai về kiểm thử phần mềm?
Kiểm thử phần mềm là yếu tố quyết định của SQA và khâu điển hình của rá soát đặc tả

thiết kế và lập mã
• Lý do cần kiểm thử phần mềm:
 muốn nhìn thấy phần mềm như là một phần tử của hệ thống hoạt động
 Hạn chế chi phí phải trả cho các thất bại do lỗi gây ra sau này
23


Phôtô Ngân Sơn Cổng phụ Khu A

 có kế hoạch tốt cho suốt quá trình phát triển
o Tầm quan trọng. Kiểm thử chiếm:
- 40% tổng công sức phát triển
- >=30% tổng thời gian phát triển
Với phần mềm ảnh hưởng tới sinh mạng chi phí có thể gấp từ 3 dến 4 lần tổng chi
phí khác cộng lại
• Mục tiêu kiểm thử (Glen Myers): Kiểm thử là một quá trình vận hành chương trình
để tìm ra lỗi. Vì vậy:
 Một ca kiểm thử tốt là ca kiểm thử có xác suất cao trong việc tìm ra một lỗi
chưa được phát hiện
 Một ca kiểm thử thắng lợi là một ca kiểm thử làm lộ ra được ít nhất một lỗi
còn chưa được phát hiện
Một ca kiểm thử thắng lợi làm lộ ra khiếm khuyết, đồng thời mang lại các lợi ích phụ:
 chứng tỏ rằng các chức năng phầm mềm làm việc tương ứng với đặc tả,
 chứng tỏ các yêu cầu thực thi là phù hợp
 có thêm các chỉ số độ tin cậy phần mềm và các chỉ số về chất lượng phần mềm nói
chung
“Kiểm thử không thể chứng minh được việc không có khiếm khuyết, nó chỉ có thể
chứng minh rằng khiếm khuyết phần mềm hiện hữu”
• Người ta thường có những quan niệm sai gì về kiểm thử phần mềm?
- Người phát triển không tham gia kiểm thử

- Phần mềm được công bố một cách rộng rãi để người lạ kiểm thử nó một cách tàn
nhẫn
- Người kiểm thử chỉ quan tâm khi kiểm bắt đầu
- Kiểm thử có thể chứng minh được phần mềm không có khiếm khuyết
- Phép kiểm thử thành công là kiểm thử không tìm ra lỗi nào
- Chỉ cần kiểm thử một lần
Câu 30: Thế nào là một ca kiểm thử tốt? ca kiểm thử thành công? Lợi ích phụ kiểm
thử là gì
 Một ca kiểm thử tốt là ca kiểm thử có xác suất cao trong việc tìm ra một lỗi chưa
được phát hiện
 Một ca kiểm thử thắng lợi là một ca kiểm thử làm lộ ra được ít nhất một lỗi còn
chưa được phát hiện
Một ca kiểm thử thắng lợi làm lộ ra khiếm khuyết, đồng thời mang lại các lợi ích phụ:
 chứng tỏ rằng các chức năng phầm mềm làm việc tương ứng với đặc tả,
 chứng tỏ các yêu cầu thực thi là phù hợp
 có thêm các chỉ số độ tin cậy phần mềm và các chỉ số về chất lượng phần mềm nói
chung
24


Phôtô Ngân Sơn Cổng phụ Khu A

Câu 31: Biểu đồ dòng thông tin kiểm thử mô tả cái gì? vẽ biểu đồ của nó?
Biểu đồ dòng thông tin kiểm thử tuân theo hình mẫu được mô tả như sau:
Hai lớp được cung cấp cho tiến trình kiểm thử:
(1) Cấu hình phần mềm: Bản Đặc tả yêu cầu phần mềm, bản Đặc tả thiết kế, chương
trình gốc
(2) Cấu hình kiểm thử: Kế hoạch và thủ tục kiểm thử, các công cụ kiểm thử dự định
dùng, các ca kiểm thử cùng kết quả dự kiến.

Cấu hình
phần mềm

Cấu hình
kiểm thử

Kiểm thử

Gỡ lỗi

Đánh giá

Mô hình độ
tin cậy

Phần mềm
chỉnh sửa

Độ tin cậy
dự đoán

Kiểm thử được tiến hành và tất cả các kết quả được đánh giá bằng cách so sánh
với kết quả dự kiến. Khi phát hiện lỗi, việc gỡ lỗi bắt đầu được tiến hành.
Tiến trình gỡ lỗi thường không dự kiến được thời gian nên việc lập lịch kiểm thử
trở nên khó khăn.Ví dụ: 1 lỗi chỉ ra sự sai biệt độ 0.01% giữa kết quả trông đợi và
thực tại có thể mất 1 giờ, 1 ngày hay 1 tháng để chuẩn đoán và sửa chữa.
Khi các kết quả kiểm thử được thu thập và đánh giá thì chất lượng và độ tin cậy
phần mềm dần được khẳng định. Nếu hay gặp phải lỗi nghiêm trọng yêu cầu sửa đổi
thết kế thì chất lượng và độ tin cậy là đáng ngờ và cần kiểm thử thêm.
Mặt khác, nếu các chức năng phần mềm dường như làm việc đúng và lỗi gặp phải

là dễ sửa thì có thể rút ra một trong hai kết luận:
(1) Chất lượng và độ tin cậy phần mềm chấp nhận được
(2) Kiểm thử không tương xứng để làm lộ ra những lỗi nghiêm trọng.
Nếu việc kiểm thử không làm lộ ra lỗi nào thì có thể hoài nghi rằng cấu hình kiểm
thử chưa được cân nhắc đúng mức, các lỗi vẫn còn ẩn núp trong phần mềm và sẽ bị
phát hiện bởi người dùng.
Câu 32: Kể các đối tượng và phương pháp kiểm thử phần mềm? Mỗi phương pháp đó
thường được sử dụng vào giai đọan nào của quá trình phát triển?
Đối tượng và phương pháp kiểm thử
Loại
Đơn vị
Tích hợp
Thẩm định
Hệ thống
Đối tượng
Mã
Thiết kế
Yêu cầu
Toàn hệ thống
Phương pháp Hộp trắng Hộp đen và trắng
Hộp đen
Mô hình
Mỗi phương pháp đó thường được sử dụng vào giai đoạn nào của quá trình phát triển:
25