Kỹ nghệ phần mềm nâng cao

Mục Lục
CÂU HỎI ÔN TẬP KỸ NGHỆ PHẦN MỀM NÂNG CAO
1. Chất lượng và đảm bảo chất lượng phần mềm
1.1. Khái niệm về đảm bảo chất lượng
Câu 1. Chất lượng của một sản phẩm phần được sản xuất là gì? Đối với
phần mềm định nghĩa này có đúng không? Làm thế nào để áp dụng định nghĩa đó?
- Chất lượng của sản phẩm được thể hiện bằng các đặc trưng phù hợp với các đặc tả của
nó.
- Định nghĩa này là chung cho mọi sản phẩm. Với phần mềm có một số vấn đề:
• Phần mềm có yêu cầu mà chưa có đặc tả
• Phần mềm có đặc tả nhưng lại mù mờ
• Có những yêu cầu tự nhiên nên không được đặc tả
- Chất lượng phần mềm là:
• việc tuân thủ các yêu cầu chức năng và sự hoàn thiện đã được phát biểu tường minh
• các chuẩn phát triển đã được tư liệu hoá tường minh
• các đặc trưng không tường minh được trông đợi từ tất cả các phần mềm đã được phát
triển theo cách chuyên nghiệp:
Theo quan điểm của người phát triển thì một phần mềm tốt là một phần mềm ít lỗi. Đó
chính là chất lượng của chương trình. Vấn đề là làm thế nào để chương trình chạy giống
như thiết kế. Chất lượng của phần mềm theo quan điểm này chính là quan điểm chất
Đảm Bảo Chất Lượng Phần Mềm (HC)
1
lượng theo kiểu lập trình. Nguời ta cũng gọi chất luợng này là chất lượng theo nghĩa cần
thiết vì nó phản ánh cái bắt buộc phải làm có tính nguyên tắc mặc dù nói chung nguời ta
không đạt được.
Đã có một sự thay đổi lớn trong cách quan niệm chất lượng của phần mềm. Theo quan
điểm của khách hàng, phần mềm tốt là phần mềm đáp ứng tốt yêu cầu của khách hàng và
dễ dùng, dễ bảo trì. Đó là chất lượng theo quan điểm thiết kế. Vấn đề là làm thế nào để
thiết kế đáp ứng đúng nhu cầu của người sử dụng. Người ta cũng nói đó là chất lượng
theo nghĩa hấp dẫn vì nó hướng tới người dùng.
Còn một khía cạnh mới trong quan niệm chất lượng của phần mềm đó là độ tin cậy, được

hiểu là tính chính xác, tính ổn định, tính an toàn của phần mềm. Kể từ khi máy tính trở
thành hạ tầng mới của xã hội, độ tin cậy của phần mềm trở nên hết sức quan trọng đối với
các hoạt động xã hội. Đây là chất lượng theo nghĩa xã hội đo mức độ ảnh hưởng của sản
phấm tới mọi người (không kể chính người phát triển và NSD trực tiếp).
Một phần mềm tốt không những phải đáp ứng nhu cầu của người phát triển mà phải thoả
mãn người sử dụng và có độ tin cậy cao. Vậy có thể định nghĩa: Chất lượng là mức độ
thoả mãn của NSD đối với sản phẩm hay dịch vụ.
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ờ
Đảm Bảo Chất Lượng Phần Mềm (HC)
2
- 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. Để làm cơ sở cho việc kiểm định chất lượng, đặc tả các yêu cầu
phần mềm cần thoả mãn các điều kiện gì? Nêu một vài ví dụ về điều kiện đưa ra.
Yêu cầu phần mềm là cơ sở để đo chất lượng. Yêu cầu thể hiện ra bằng đặc tả và đặ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 chắc chắn là chất lượng sẽ thiếu sót.

Câu 4. 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 5. 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) 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?
Các độ đo liên quan:
Đảm Bảo Chất Lượng Phần Mềm (HC)
3
o Độ đầy đủ
o Độ hòa hợp
o Độ lần vết được
σ (2) Tính tin tưởng đượ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

Các độ đo liên quan:
o Độ chính xác
o Độ phức tạp
o Độ hòa hợp
o Độ dung thứ lỗi
o Độ mođun hoá
o Độ đơn giản - dễ hiểu.
o Độ lần vết được
σ (3) Tính hiệu quả: Tổ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.
Các độ đo liên quan:
o Độ súc tích
o Độ hiệu quả thực hiện
o Độ dễ thao tác
σ (4) Tính toàn vẹn: là sự 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 của hệ thống.
Các độ đo liên quan:
o Độ kiểm toán được
o Trang bị đồ nghề đủ
o Độ an ninh.
σ (5) 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
Các độ đo liên quan:
Đảm Bảo Chất Lượng Phần Mềm (HC)
4
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)
σ (1)Tính bảo trì đư¬ợc: nỗ lực đòi hỏi để định vị và xác định được một lỗi trong chương
trình là chấp nhận được.

Các độ đo liên quan:
o Độ súc tích
o Độ hoà hợp
o Trang bị đồ nghề đủ
o Độ mođun hoá
o Độ tự cấp tài liệu
o Độ đơn giản - dễ hiểu
σ (2) Tính mềm dẻo: nỗ lực đòi hỏi để cải biên một chương trình là chấp nhận được
Các độ đo liên quan:
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
σ (3) Tính kiểm thử đ¬ược: nỗ lực cần để kiểm thử một chương trình và bảo đảm rằng nó
thực hiện đúng chức năng được dự định là chấp nhận được.
Các độ đo liên quan:
o Độ kiểm toán đư¬ợc
o Độ phức tạp
o Trang bị đồ nghề đủ
o Độ mođun hoá
Đảm Bảo Chất Lượng Phần Mềm (HC)
5
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)
σ (1) 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
Các độ đo liên quan:
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
σ (2) 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
Các độ đo liên quan:
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
σ (3) 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
Các độ đo liên quan:
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ó 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ố
Đảm Bảo Chất Lượng Phần Mềm (HC)
6
Độ đo Đúng đắn Tin cậy được Hiệu quả Toàn vẹn Khả dụng Bảo trì được Mềm dẻo Kiểm
thử được Mang chuyển được Sử dụng lại được Liên tác được
Kiểm toán được X x

Chính xác x
Tương đồng giao tiếp x
Đầ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 dữ liệu x
Dung thứ lỗi x
Hiệu quả thực hiện x
Khuyếch trương được x
Độc lập phần cứng x x
Trang bị đủ đồ nghề X x x
Đo Modul hóa x x x x x x x
Dễ thao tác x x
An ninh X
Tự tạo tài liệu x x x x x
Đơn giản - Dễ hiểu x x x x
Độc lập hệ thống phần mềm x x
Lần vết được X x
Khả năng huấn luyện x
Khái quát x x x x
Câu 6. 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 7. 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ó?
Đảm Bảo Chất Lượng Phần Mềm (HC)
7
• McCall đề xuất 22 độ đo sau:
(1) Độ kiểm toán đư¬ợc: có thể kiểm tra dễ dàng về việc tuân thủ các chuẩn

(2) Độ chính xác: Độ chính xác của tính toán và điều khiển
(3) Độ 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.
(4) Độ đầ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.
(5) Độ phức tạp: tránh dùng chương trình có độ phức tạp cao
(6) Độ súc tích (conciseness): độ gọn của chương trình dưới dạng số dòng mã.
(7) Độ 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.
(8) Độ 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
(9) Độ 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.
(10) Độ hiệu qủa thực hiện: hiệu năng khi chạy của chương trình
(11) Độ 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.
(12) Độ 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.
(13) Độ độ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.
(14) 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
(15) Độ đ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
(16) Độ dễ thao tác: Việc dễ vận hành trong chương trình
(17) Độ an ninh: có sẵn cơ chế kiển soát hay bảo vệ chương trình và dữ liệu.
(18) Độ 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.
Đảm Bảo Chất Lượng Phần Mềm (HC)
8
(19) Độ đơ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.

(20) Độ độ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.
(21) Độ 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
(22) Độ đ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 8. 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 đó:
(1) 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)
Các độ đo liên quan:
o Độ đầy đủ
o Độ hòa hợp
o Độ lần vết được
(2) 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
Các độ đo liên quan:
o Độ chính xác
o Độ phức tạp
o Độ hòa hợp
o Độ dung thứ lỗi
o Độ mođun hoá
o Độ đơn giản - dễ hiểu.
o Độ lần vết được
Đảm Bảo Chất Lượng Phần Mềm (HC)
9
(3) 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
Các độ đo liên quan:
o Độ súc tích
o Độ hiệu quả thực hiện
o Độ dễ thao tác
(4) 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
Các độ đo liên quan:
o Độ kiểm toán được
o Trang bị đồ nghề đủ
o Độ an ninh.
(5) 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
Các độ đo liên quan:
o Độ dễ thao tác
o Độ đo khả năng huấn luyện
(6) 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
Các độ đo liên quan:
o Độ súc tích
o Độ hoà hợp
o Trang bị đồ nghề đủ
o Độ mođun hoá
o Độ tự cấp tài liệu
o Độ đơn giản - dễ hiểu
(7) 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
Các độ đo liên quan:
o Độ phức tạp
Đảm Bảo Chất Lượng Phần Mềm (HC)
10

o Độ súc tích
o Độ hoà hợp
o Độ khuếch trương đư¬ợc
o Độ khái quát
o Độ mođun hoá
o Độ tự cấp tài liệu
o Độ đơn giản - dễ hiểu
(8) Tính kiểm thử đ¬ược: nỗ lực cần để kiểm thử 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
Các độ đo liên quan:
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
(9) 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
Các độ đo liên quan:
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
(10) 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
Các độ đo liên quan:
o Độ khái quát
o Độ độc lập phần cứng
Đảm Bảo Chất Lượng Phần Mềm (HC)

11
o Độ đo mođun hoá
o Độ tự tạo tài liệu
o Độ độc lập hệ thống phần mềm
(11) 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
Các độ đo liên quan:
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 9. Nêu các đặc trưng chất lượng theo Hawlett? Giải thích nội dung mỗi
loại.
Các đặc trưng chất lượng FURPS của Hawlett-Packard 1
- F: Functionality - Nhân tố chức năng
Được định giá bằng tập hợp các tính chất và khả năng của chương trình đó, độ khái quát
các chức năng được thực hiện và độ an ninh của toàn hệ thống.
- U: Usability - Nhân tố khả dụng
Được đánh giá bằng việc xét các nhân tố con người, thẩm mỹ, sự hoà hợp và tư liệu cung
cấp
- R: Reability - Nhân tố tin cậy
Được đánh giá bằng:
+ Tần suất thất bại và độ nghiêm trọng của nó
+ Tính chính xác của các kết quả ra
+ Thời gian trung bình giữa hai thất bại kề nhau
+ Khả năng phục hồi sau thất bại
+ Khả năng đoán trước được thất bại của chương trình
- P: Performance - Nhân tố thi hành
Được đánh giá bằng
+ Tốc độ xử lý

Đảm Bảo Chất Lượng Phần Mềm (HC)
12
+ Thời gian đáp ứng
+ Độ sử dụng nguồn lực
+ Năng suất và hiệu năng
- Supportability - Nhân tố mang chuyển
Đánh giá bằng tổ hợp các khả năng:
+ Mở rộng chương trình
+ Độ thích nghi
+ Phục vụ được (bảo trì được)
+ Kiểm thử được
+ Sự tương hợp
+ Cấu hình được (khả năng tổ chức và khống chế các yếu tố của cấu hình phần mềm, để
dễ dàng cài đặt hệ thống và dễ dàng định vị các chỗ có vấn đề)
1.2. Tiến hóa của hoạt động đảm bảo chất lượng
Câu 10. Đả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?
a) Đảm bảo chất lượng phần mềm xuất phát từ:
(1) 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 (nhu cầu)
• 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
(2) Từ thực tiễn: Kinh nghiệm cho phép hoạtk độ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.
b) 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.

Đảm Bảo Chất Lượng Phần Mềm (HC)
13
• 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 11. 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 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
• SQA đó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 12. Khi nào cần thực hiện các hoạt động đảm bảo chất lượng phần
mềm?
Chất lượng phần mềm được thiết kế bên trong sản phẩm hay hệ thống do đó nó được bắt
đầu ngay từ khi phân tích và nó giúp người phân tích đạt tới đặc tả chất lượng cao và
người thiết kế thì phát triển thiết kế với chất lượng cao.

Đảm Bảo Chất Lượng Phần Mềm (HC)
14
Câu 13. Trong một tổ chức, những ai 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,
- Thành viê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 14. 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) Áp dụng công nghệ kĩ thuật hiệu quả (phương pháp, công cụ)
(2) Tiến hành rà soát kỹ thuật chính thức
(3) Thực hiện kiểm thử nhiều tầng
(4) Tuân theo các chuẩn phát triển
(5) Kiểm soát tài liệu Fm và thay đổi của chúng
(6) Thực hiện đo l¬ường
(7) Báo cáo và bảo quản lý các báo cáo.
Câu 15. 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ông nghệ kĩ thuật hiệu quả (phương pháp, công cụ) giúp để:
Đảm Bảo Chất Lượng Phần Mềm (HC)
15
- 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.
(2) Tiến hành rà soát kỹ thuật chính thức: tác dụng không kém gì kiểm thử để phát hiện
khiếm khuyết
(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ả. Tuy
nhiên, chỉ kiểm thử phần mềm không thể tìm ra được hầu hết các sai
(4) Tuân theo các chuẩn và các thủ tục chính thức là nhu cầu và điều kiện cho SQA. Tuy
nhiên còn tuỳ thuộc mỗi công ty. Có 2 loại chuẩn và thử tục: do khách hàng hay chính
quyền quy định; tự công ty đặt ra.
- Đánh gí sự phù hợp với các chuẩn là một phần của việc rà soát chính thức
- Khi cần phải kiểm chứng (verification) sự phù hợp, nhóm SQA có thể tiến hành kiểm toán
(audit) riêng.
(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
- Khống chế thay đổi áp dụng trong suốt quá trình phát triển và trong quá trình bảo trì.
(6) Thực hiện đo l¬ường: dùng để theo dõi chất lượng phần mềm đánh giá ảnh hưởng
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.
- Các độ đo phần mềm hướng đến 2 mặt: quản lý (thủ tục); kĩ thuật (phương pháp)
(7) Báo cáo và bảo quản lý các báo cáo:
- Lập và lưu trữ báo cáo về SQA: phổ biến các thông tin SQA (người cần có thể biết); cung
cấp các thủ tục để thu thập thông tin.
- Đối tượng báo cáo là kết quả của các hoạt động SQA: rà soát, kiểm toán, khống chế đổi

thay, kiểm thử và các hoạt động SQA khác.
- Người phát triển sử dụng theo quy tắc "cần-thì-biết" trong suốt quá trình dự án.
Đảm Bảo Chất Lượng Phần Mềm (HC)
16
1.3. Rà soát phần mềm
Câu 16. 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?Nếu không thực hiện rà soát thì sao?
• 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 phần 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ó diện mạo không đổi, ổn
định)
• 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á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.
• 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 kiểm thử: 6.5;
trong kiểm thử: 15 và sau khi phân phối sẽ là từ 60.0 đến 100.0
Câu 17. 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ác kiểu rà soát:
• Họp xét duyệt không chính thức
• Họp chính thức trước với các thành viên: 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)
• Rà soát kĩ thuật chính thức FTR chủ yếu 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.
Đảm Bảo Chất Lượng Phần Mềm (HC)
17
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:
• Phát hiện các lỗi trong chức năng, trong logic, trong triển khai (implementation).
• Kiểm thử sự phù hợp của phần mềm với yêu cầu
• Khẳng định phần đã đạt yêu cầu
• Bảo đảm rằng phần mềm phù hợp với các chuẩn đã định sẵn
• Đảm bảo " phần mềm đã được phát triển theo một cách thức nhất quán" (uniform
manner)
• Làm cho dự án dễ quản lý hơn
• 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 18. 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:
- 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:
• Xem xét sản phẩm để đọc, rà soát
• Tạo ra các bản sao của sản phẩm, phân cho 2,3 người ra soát
• 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 19. 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?
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ó:
Đảm Bảo Chất Lượng Phần Mềm (HC)
18
• 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)
• Cuối buổi 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ó.
(3) 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

(4) Trình bày rõ ràng mạch lạc các vùng có vấn đề nhưng không 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.
(5) Nên có ghi chú trên bảng tường
(6) Giới hạn số người tham dự và kiên trì các dự kiến
Đảm Bảo Chất Lượng Phần Mềm (HC)
19
(7) Lập một danh sách các kiểm tra (checklist) 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: 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.
(8) 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 (sẽ xuất hiện do một FTR)
(9) Cần phải tiến hành huấn luyện chính thức cho cá nhân ra soát
(10) Rà soát lại các rà soát trước đây.
Câu 20. 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.
σ Một văn bản tổng kết cuộc họp rà soát đó
Nội dung, vai trò của mỗi sản phẩm:
• Bản danh sách các vấn đề tồn tại
σ 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
σ Thiết lập 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
Đảm Bảo Chất Lượng Phần Mềm (HC)
20
Câu 21. 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
- Tiến trình phát triển chung nhất gồm 4-5 giai đoạn:
σ Kỹ nghệ hệ thống (lập kế hoạch triển khai)
σ 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 22. Trình bày nội dung, danh mục rà soát
a) 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ó sự hoà hợp giữa các phần tử của hệ thống hay chư¬a?

(8) Cơ chế kiểm chứng và thẩm duyệt đã đư¬ợc thiết lập hay chư¬a?
b) 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
Đảm Bảo Chất Lượng Phần Mềm (HC)
21
+ 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 phục
+ Các kế hoach khác
Danh mục rà soát:
(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?
(4) 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?
(5) Phương án tổ chức và nhân sự đã hợp lý chưa?
(6) 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?
(7) 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?
(8) 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?
c) Rà soát phân tích yêu cầu phần mềm
- Rà soát phân tích yêu cầu phần mềm: tập trung bào khả năng viết ra các yêu cầu hệ

thống; sự phù hợp và đúng đắn của mô hình phân tích.
- Với các hệ thống lớn thì 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.
- Các yêu cầu của hệ thống phần mềm: yêu cầu chức năng, yêu cầu phi chức năng, yêu
cầu ngoại lai.
- Rà soát phân tích yêu cầu là phục vụ việc thẩm định và xác minh.
• Nội dung thẩm định yêu cầu phần mềm:
Đảm Bảo Chất Lượng Phần Mềm (HC)
22
- Phải chỉ ra các nhu cầu người dùng được thoả mãn chưa
- Các yêu cầu phải nhất quán: không mâu thuẫn nhau
- Các yêu cầu phải đầy đủ: 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 hiện thực: có khả năng thực hiện được.
- Sự tương hợp với mô hình hệ thống và kế hoạch triển khai
• Danh mục rà soát phân tích yêu cầu:
(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 không?
(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?
(7) 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?
d) 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
(1) 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
(2) 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)
Đảm Bảo Chất Lượng Phần Mềm (HC)
23
♣ 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 2 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, gaio diện cấu trúc DL).
• Danh mục rà roát
− Rà soát thiết kế sơ bộ
(1) 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?
(2) Có đạt đ¬ược sự modul hoá hiệu quả không?
(3) Các modul có độc lập chức năng hay không
(4) Kiến trúc ch¬ương trình có đư¬ợc phân tách cấu trúc không?
(5) Các giao diện đã đư¬ợc xác định cho các modul và các phần tử hệ thống ngoại lai
ch¬ưa?
(6) Cấu trúc dữ liệu có phù hợp với lĩnh vực thông tin chưa?
(7) Cấu trúc dữ liệu có phù hợp với yêu cầu phần mềm ch¬ưa?

(8) Khả năng bảo trì đã đư¬ợc xem xét chư¬a?
(9) Các nhân tố chất l¬ượng đã đ¬ược đánh giá rõ ràng chưa?
− Rà soát thiết kế toàn bộ
(1) 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?
Đảm Bảo Chất Lượng Phần Mềm (HC)
24
(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) Nguyên lý 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 hệ điều hành hay ldùng các đặc trưng độc lập ngôn ngữ?
(10) Có dùng logic component hoặc logic inverse?
(11) Khả năng bảo trì đã đ¬ược xét tới chưa
e) 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
− 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ó phong cách tốt: cấu trúc, nhất quán, định
dạng chuẩn...)
• Danh mục rà soát
(1) Thiết kế đã 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 thiết kế trọn vẹn là được áp dụng rộng rãi
hon trước hay không?
f) 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, chiến lược và kỹ thuật được sử dụng và kế
hoạch tốt
• Nội dung:
Đảm Bảo Chất Lượng Phần Mềm (HC)
25