Đề Cương Môn Đảm Bảo Chất Lượng Phần Mềm

Câu 1: Chất lượng phần mềm là gì? Cái gì được dùng để làm cơ sở
kiểm định chất lượng phần mềm?
a. Chất lượng phần mềm:
- 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 hóa tường minh.
- Các đặc trưng ko 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 nhà phát triển phần mềm, nhà lập trình thì một
phần mềm được coi là tốt khi phần mềm đó ít lỗi, đây chính là chất
lượng của chương trình. Và làm thế nào để chương trình chạy ít lỗi.
• Theo quan điểm của khác hàng (quan điểm thiết kế) phầm mềm tốt
là phần mềm đáp ứng được nhu cầu, mục đích sử dụng, dễ sử dụng
, dễ bảo trì.
• Chất lượng của phần mềm còn được hiểu là độ tin cậy, tính chính
xác và độ an toàn của phần mềm.
b. Cái gì được dùng để làm cơ sở kiểm định chất lượng phần
mềm:
- Y/C PM là cơ sở để đo chất lượng phần mềm.
+ Sự phù hợp với yêu cầu là có chất lượng.
+ Phù hợp y/c cả về số lượng và chất lượng.
- y/c thể hiện đặ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 t/c 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 skhoong tuân thủ
theo các chuẩn đó thfi hầu như và chắc chắn là chất lượng sẽ kém.
- Luôn có 1 tập hợp các y/c ngầm thường ít được nhắc đến.
+ quá thông dụng, hiển nhiên (sử dụng cử số).
+ không thể hiển ra ngoài (quy tắc nghiệm vụ).
- Nếu pm chỉ phù hợp với các y/c hiển thị mà chưa phù hơp với các
y/c ngầm thì p/m đó là đáng nghi ngờ.

- Cần làm ro các y/c và đưa vào đặc tả càng nhiều càng tốt.
1
Câu 2: Có thể đo trực tiếp chất lượng phần mềm không? Tại sao?
Bằng cách nào?
Có thể đo trực tiếp chất lượng phần mềm, thông qua nhân tố trực
tiếp KLOC (KLOC – Kilo Line Of Code). Bởi vì:
Theo McCall đề xuất thì có tới 11 nhân tố ảnh hưởng đến chất
lựơng phân mềm, trong đó nó được chia ra làm 3 loại chính:
- Loại 1: Đặc trưng về chức năng (5 nhân tố).
- Loại 2: Khả năng đương đầu với những thay đổi (3 nhân tố).
- Loại 3: Khả năng thích nghi với môi trường mới (3 nhân tố).
Trong đó nhân tố trực tiếp ở loại 3 sẽ tác động trực tiếp đến chất
lượng phần mềm.đó là số lỗi gặp phải của chương trình/KLOC/đơn vị
thời gian.Chương trình luôn luôn có lỗi.Những lỗi của chương trình
được thể hiện ở ngay trên những dòng code, đó là những lệnh sai mà
người lập trình mắc phải.
Trong đó KLOC là thước đo kích thước của một chương trình máy
tính. Kích thước được xác định bằng cách đo số lượng các dòng mã
nguồn một chương trình có. Ngôn ngữ cao cấp như C++, sẽ tổng hợp
thành dòng mã máy hơn một ngôn ngữ lắp ráp, C++ là một ngôn ngữ
cấp thấp.
Câu 3: Độ tin cậy của phần mềm là gì? Đo độ tin cậy của phần mềm
như thế nào? Giải thích?
a. Độ tin cậy của phần mềm là:
- Độ tin cậy của phần mềm là một trong những yêu tố quan trọng
trong chất lượng phần mềm.
- Độ tin cậy của phần mềm được định nghĩa theo ngôn 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 đặc biệt với một thời gian xác định rõ”.
b. Đo độ tin cậy của phần mềm bằng cách:

- Đo trực tiếp và được đánh giá qua các dữ liệu phát triển và dữ liệu
lịch sử.
+ Tính xác xuất xuất hiện thành công hay thất bại.
+ Đo độ dài khoảng thời gian trung bình giữa 2 lần thất bại liên
tiếp.
2
+ Khả năng sẵn sang hoạt động lại của hệ thống.
- Để đo tính tin cậy của phần mềm người ta dung công thức
MTBF = MTTF + MTTR
Trong đó:
MTBF: thời gian trung bình giữa các hỏng hóc.
MTTF: Thời gian hỏng hóc.
MTTR: Thơi gian sửa chữa.
Tính sẵn có của phần mềm được xác định bởi
Tính sẵn có = MTTF / (MTTF + MTTR) * 100
c. Giải thích:
- Ví dụ ta có 1 chương trình X với ước lượng có độ tin cậy là 96%
và được thực hiện trong 8h. trong một trường hợp khác chương
trình đó phải thực hiện 100 công việc trong 8h và số công việc
thực hiện thành công là 96.
Câu 4: Trình bày quá trình đo độ tin cậy của phần mềm.
- Xác định sư lược hoạt động: Đầu tiên bạn nghiên cứu các hệ thống
tồn tại của các kiểu như nhau để đưa ra mô tả sơ lược về hoạt
động. Mô tả sơ lược hoạt động nhận biết loại đầu vào hệ thống và
xác xuất xuất hiện các đầu vào này trong trường hợp bình thường.
- Chuẩn bị tập dữ liệu kiểm thử: Sau đó, bạn thiết đặt tâp các dữ liệu
kiểm thử để phản ánh mô tả sơ lược hoạt động. Có ý nghĩa là bạn
tạo ra bộ dữ liệu kiểm thử với xác xuất như nhau (dữ liệu cho hệ
thống mà bạn đã nghiên cứu). thông thường bạn sử dụng máy sinh
dữ liệu để sinh ra bộ dữ liệu kiểm thử này.

- Áp dụng các dữ liệu vào để kiểm thử hệ thống: bạn sử dụng dữ liệu
đã được sinh ra ở trên và đếm các lỗi sinh ra. Các lỗi sinh ra này
cũng được ghi nhận.
- Tính toán độ tin cậy: tiến hành thống kê xem số lỗi sinh ra và từ đó
tính toán được độ tin cậy của phần mềm thông qua cách tính giá trị
đo độ tin cậy.
3
Câu 5: những khó khan khi đo độ tin cậy của phàn mềm là gì?
Không chắc chắn mô tả sơ lược hoạt động: mô tả sư lược hoạt động dựa
trên kinh nghiệm, với các:
1. hệ thống khác có thể không phản ánh chính xác thực tê sử dụng
của hệ thống.
2. Giá trị cao của dữ liệu kiểm thử sinh ra: để sinh ra mộ bộ dữ liệu
kiểm tra như vậy sẽ tốn rất nhiều thời gian và tiền bạc, giá trị bộ dữ
liệu sinh ra khi đó rấtự đắt.trừ khi quá trình này sinh ra là tự động.
3. Thống kê không chắc chắn khi yêu cầu tính tin cậy cao được chỉ
ra: Bạn phải sinh mộ số lượng thống kê quan trọng các sai sót để
cho phép đo độ tin cậy chính xác. Khi phần mềm đã được xác thực
tính tin cậy, một vài sai sót liên quan xuất hiện và nó khó khan để
sinh ra sai sót mới.
4. Phát triển mô tả sơ lược thao tác chính xac chắc chắn có thể với vài
kiểu thệ thống, như hệ thống truyền thông có một mẫu tiêu chuẩn
hóa được sử dụng. Tuy nhiên, với các loại hệ thống khác cố rất
nhiều người sử dunjgk hác nhau, mỗi người có một cách riêng khi
sử dụng hệ thống. những người dùng khác nhau sẽ có những ấn
tượng khác nhau về độ tin cậy vì họ sử dụng thống theo những
cách khác nhau.
Câu 6: Những mô hình dự đoán tính tin cậy.
Có 5 mô hình dự đoán độ tin cậy của phần mềm:
- Mô hình tiên đoán độ tin cậy của phần mềm 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 thời gian xử lý đã
trôi qua(thời gian vận hành của CPU).
- Mô hình sử dụng phương pháp kịch bản (Scenarios) để dự đoán độ
tin cậy cảu phần mềm.
- Mô hình tin cậy hướng người sử dụng Cheung
- Mô hình sử dụng kịch bản và chuỗi Markov.
4
Câu 7: Nguyên lý của luận chứng tính an toàn của phần mềm.
Hầu hết các kĩ thuật hiệu quả để chứng mìh tính an toàn của hệ
thống là chứng minh bằng phản chứng. Bắt đầu vớ giả thiết rằng trạng
thái ban đầu không an toàn đã được xác định bằng phân tích rủi ro của
hệ thống, có thể được đi đến khi chương trình thực thi. Bạn viết một
thuộc tính để xác định đó là trạng thái không an toàn. Sau đó, một cách
có hệ thống, bạn phân tích mã chương trình và chỉ ra,
với tất cả các đường dẫn chương tình dẫn tới trạng thái đó, điều kiện kết
thúc của các đường dẫn đó ma thuân với thuộc tính trạng thái không an
toàn. Nếu trường hợp đó xảy ra, giả thiết ban đầu của trạng thái không
an toàn là không đúng. Làm lại điều đó nhiefu lần với các định danh
được cho là rủi ro thì phần mềm đó là an toàn.
Để xây dựng những luận chứng về tính ant oàn, bạn xác định điều
kiện cho trạng thái không an toàn, trong trường hợp đó như là
currentDose > maxDose. Sau đó, bạn chứng mình rằng tất cả các đường
dẫn chương tình đa đến sự mâu thuẫn của điều khẳng định tính không an
toàn đó. Nếu đó là một trường hợp, điều kiện không an toàn không thể
đúng. Do đó, hệ thống là an toàn. Bạn có thể cấu trúc và đa ra những
luận chứng về tính an toàn bằng đồ thị như hình dưới.
5
6
Trong các luận chứng về tính an toàn chỉ ra trên hình có ba đường

dẫn chương trình có thể dẫn tới việc gọi tới phương thức
administerInsulin. Điều cần chứng mình rằng lượng insulin phân phối
không bao giờ vượt quá maxDose.
Tất cả các đường dẫn chương tình có thể dẫn tới phương thức
administerInsulin đã được xem xét:
1. Không có nhánh nào của câu lệnh if thứ 2 được thực thi. Nó chỉ có
thể xảy re nếu một trong hai điều sau xảy ra: currentDose là lơn
hơn hoặc bằng minimumDose và nhỏ hơn hoặc bằng maxDose.
2. Nhánh then của câu lệnh if thứ 2 được thực thi. Trong trường hợp
đó, việc gán currentDose bằng 0 được thực thi. Do đó, hậ điều
keienj đó là currentDose = 0.
3. Nhánh else-if của câu lệnh if thứ 2 được thực thi. Trong trường
hợp đó, việc gán currentDose bằng maxDose được thực thi. Do đó,
hậu điều kiện đó là currentDose = maxDose.
Trong cả 3 trường hợp trên, các hậy điều kiện mâu thuẫn với các
điều kiện và tính không an toàn lầ liều lượng thuốc được phần phói là
nhiều hơn maxDose, vì vậy hệ thống là an toàn.
Câu 8: các nội dung thuộc tính chất lượng phần mềm:
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ả (yêu cầu của đối tượng
khác)
2. Tính tin cậy được:
- Có thể trong đpị 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.
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 tình là thích hợp
4. Tính toàn vẹn là sự khống chế đơcj việc truy cập trái phép tới phần
mềm và dữ liệu hệ thống
5. Tính khả dụng: công sức để đọ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 được.
7
6. Tính bảo trì được: nỗ lực cần để định vị và xác đinh được một lỗi
trong chương tình là chấp nhận được.
7. Tính mềm deo: nỗ lực cần để cải biên một chương tình là chấp
nhận được.
8. Tính kiểm thử được: nỗ lực cần để kiểm thử một chương tình và
đảm bảo rằng nó thực hiện đúng chức năng dự địh là chấp nhận
được.
9. Tính mang chuyển được: nỗ lực đòi hỏi để chuyển nó từ 1 môi
trường phần cứng/ phần mmeef 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.
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ộ ứng dụng khác
11. Tính liên tác đượ: nỗ lực đòi hỏi để ghép hệ thoogns chương tình
vào một hệ thống khác chập nhận được.
Câu 9: tại sao phải đảm bảo chất lượng 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 hơn.
Phải đảm bảo chất lượng phần mềm vì:
- Từ nhu cầu của khác 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 ta 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ị ích sau:
o 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ì.

o Độ tin cậy cao hơn và do đó khác hàng thỏa mãn hơn
o Giảm phí tổn bảo trì.
o 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:
8
+ Đảm bảo 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: Các hoạt động chính của đảm bảo chất lượng phần mềm?
Giải thích những hoạt động đó.
1. Áp dụng công nghệ kĩ thuật hiệu quả (phươg pháp, công cụ) giúp
để:
- 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 ra soát kỹ thuật chính thức: tac 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ác có hiệu quả. Tuy nhiện, chỉ kiểm thử
pàn mềm không thể tìm ra được hầu hết các lỗi 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 SQS. Tuy nhiên còn tùy thuộc mỗi công ty. Có 2 loại chuẩn và
thủ tục: do khác hàng hay chính quyền quy đinh và tự công ty đặt
ra.
- Đánh giá sự phù hợp với các chunar 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 gpops trực tiếp vào chất lượng phần
mềm nhờ
- Chính thức hóa 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 dọa 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 tron suốt quá trình phát triển và trong
quá trình bảo trị.
9
6. Thực hiện đo lường: dùng để theo dỗi chất njgphanaf 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 mmeef 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à 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ác hoạt động SQA: rà soát, kiểm
tóa, khống chế đổi thay, kiểm thr 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.
Câu 11: Rà soát (review) phần mềm là gì? Tại sao phải tiến hành rà
soát phần mềm?
a. Rà soát phần mềm là:
- 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.
b. Phải tiến hành rà soát phần mềm vì:
- 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.
10
- 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 12: Trình bày danh mục chính của rà soát phần mềm? Danh
mục rà soát từng giai đoạn trong quy trình sx phần mềm?
Danh mục chính rà soát phần mềm
-Rà soát trong kỹ nghệ hệ thống
-Rà soát việc lập kế hoạch
-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
Danh mục rà soát từng giai đoạn trong quy trình sản xuất phần
mềm
a) Rà soát trong kỹ nghệ hệ thống

-Các chức năng chủ yếu đã được xác định đủ và rõ ràng (không mơ hồ)?

-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?
-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?
-Các ràng buộc thiết kế đã được thiết lập cho từng phần tử hay chưa?
-Khả năng chọn đã là đã tốt nhất chưa?
-Giải pháp này có khả thi kỹ thuật không?
-Có sự hoà hợp giữa các phần tử của hệ thống hay chưa?
-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
Danh mục rà soát:
11
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?
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?
4. 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
Danh mục rà soát phân tích yêu cầu:
- Phân hoạch vấn đề (hệ con) có đầy đủ hay không?
- Các giao diện trong và ngoài đã thực sự được xác định chưa?
- 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?
- (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ệ?
- Tất cả các yêu cầu có thể lần vết được ở mức hệ thống không?
- Đã làm bản mẫu dành cho người sử dụng (khách hàng) chưa?
- 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?
12
- 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?
- 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ế)
Danh mục rà roát
− Rà soát thiết kế sơ bộ
 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ự modul hoá hiệu quả không?
 Các modul 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 cấu trúc không?

 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?
 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?
− 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?
 Thuật toán có đúng đắn logic không?
 Giao diện có phù hợp với thiết kế kiến trúc không?
 Độ phức tạp logic có phải chăng hay không?
 Sử lý sai đã được đặc tả chưa?
 Cấu trúc dữ liệu cục bộ có thật sự đã được xác định?
 Nguyên lý lập trình cấu trúc đã xuyên suốt chưa?
 Các chi tiết thiết kế đã tuân theo ngôn ngữ thực hiện chưa?
 Dùng hệ điều hành hay ldùng các đặc trưng độc lập ngôn ngữ?
 Có dùng logic component hoặc logic inverse?
 Khả năng bảo trì đã được xét tới chưa
e) Rà soát lập mã phần mềm
Danh mục rà soát
 Thiết kế đã thực sự được dịch thành mã chưa?
 Có các sai sót chính tả hoặc in ấn nào không?
13
 Có thực sự dùng các quy ước ngôn ngữ hay không?
 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ú
 Có ghi chú nào không đúng đắn hoặc mơ hồ?
 Kiểu dữ liệu và khai báo dữ liệu có chính xác hay không?
Các hằng số vật lý có đúng đắn hay không?
 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ử)
Danh mục rà soát kế hoạch kiểm thử phần mềm:
- Các pha kiểm thử chủ yếu có thực sự được định rõ và được xắp xếp
thứ tự hay chưa?
- Tiêu chuẩn yêu cầu kiểm thử 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?
- Các chức năng chủ yếu có được trình diễn sớm không?
- Kế hoạch kiểm thử có phù hợp với kế hoạch dự án tổng thể hay
không?
- Lịch trình kiểm thử có được xác định rõ ràng hay không?
- Nguồn lực và công cụ kiểm thử đã được minh định và đã sẵn sàng
hay chưa?
- Đã thiết lập cơ chế lưu trữ các báo cáo chưa?
- Các thiết bị và các tình huống kiểm thử đã được minh định chưa?
- Công việc phát triển kiểm thử đã được lập lịch chưa?
- Kiểm thử áp lực cho phần mềm đã được đặc tả chưa?
- Cả hai loại kiểm thử hộp trắng và hộp đen đã được đặc tả chưa?
- Có phải tất cả các đường logic độc lập đều được kiểm thử?
- Có phải tất cả các ca kiểm thử đều đã được minh định và lập danh
sách với đủ các kết quả mong đợi?
- Việc xử lý sai có được kiểm thử?
- Các giá trị biên có được kiểm thử?
- Các yêu cầu thời gian và sự diễn tiến có được kiểm thử?
14
- Các biến thể chấp nhận được của kết quả kiểm thử mong đợi đã được
đặc tả chưa?
g) Rà soát bảo trì phần mềm (ứng với kế hoạch và thủ tục kiểm thử)

danh mục rà soát bảo trì phần mềm
- Đã xét đến các hiệu ứng phụ gắn với các đổi thay hay chưa?
- 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?
- Đã báo cáo xem xét sự đổi thay cho tất cả các bên quan tâm hay
chưa?
- Các rà soát kỹ thuật chính thức thích hợp đã được tiến hành hay
chưa?
- 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.
Câu 13: Cấu hình phần mềm là gì? Nội dung các khoản mục chính
trong cấu hình phần mềm gồm những gì?
a. Cấu hình phần mềm là:
- Kết quả của quá trình kỹ nghệ phần mềm là các thông tin có thể
được chia thành 3 loại:
+ Các chương trình máy tính (cả mức nguồn và mức chạy được)
+ Các tài liệu mô tả chương trình máy tính đó (nhằm đến cả những
người thực hành kỹ thuật lẫn những người dùng)
+ Các cấu trúc dữ liệu (cả bên trong và ngoài chương trình)
- Các khoản mục cấu thành lên các thành phần của phần mềm được
tạo ra như là những chế tác (artifact) của tiến trình kỹ nghệ phần
mềm được tập hợp lại trong một cái tên chung gọi là CẤU HÌNH
PHẦN MỀM. Nội dung của các khoản mục đó là :
- Các chế tác này có nhiều mức khác nhau:
- + Bộ phận - tổng thể (phạm vi)
- + Chưa hoàn thiện - hoàn thiện (theo tiến trình, chất lượng)
15
- + Ở các mức tiến hoá khác nhau (các phiên bản - version)
- Các khoản mục cấu hình phần mềm (Software configuration items
- SCI)

- ♣ Đặc tả hệ thống (system specification)
- ♣ Kế hoạch dự án phần mềm (project baseline)
- ♣ Đặc tả yêu cầu (software requiements)
- ♣ Đặc tả yêu cầu phần mềm
- ♣ Nguyên mẫu thi hành được hoặc nguyên mẫu "giấy tờ"
- ♣ Sổ tay sử dụng sơ đẳng
- ♣ Các đặc tả thiết kế (design specification):
- ♣ Dữ liệu (data design)
- ♣ Kiến trúc (architectural design)
- ♣ Modul (modul design)
- ♣ Giao diện (interface design)
- ♣ Đối tượng (object design - nếu dùng kĩ thuật hướng đối tượng)
- ♣ Mã nguồn (source code) và kiểm thử (test)
- ♣ Kế hoạch và thủ tục kiểm thử
- ♣ Các ca kiểm thử và các kết quả được ghi lại
- ♣ Các sổ tay vận hành và sổ tay lắp đặt
- ♣ Chương trình thi hành được
- ♣ Các mođun và mã thi hành được
16
- ♣ Các mođun đã liên kết
- ♣ Mô tả cơ sở dữ liệu
- ♣ Lược đồ và cấu trúc các file
- ♣ Nội dung hồ sơ ban đầu
- ♣ Sổ tay người sử dụng
- ♣ Các tài liệu bảo trì
- ♣ Các báo cáo những vấn đề phần mềm
- ♣ Các yêu cầu bảo trì
- ♣ Đặt thay đổi kỹ nghệ
- ♣ Các chuẩn và các thủ tục cho kỹ nghệ phần mềm
Câu 14:Quản Lý cấu hình phần mềm là gì?. Trình bày các hoạt

động của quản lý cấu hình phần mềm?
a. Quản lý cấu hình phần mềm:
+ Là tập các hoạt động để quản lý các thay đổi trong suốt vòng đời
phần mềm
+ Là một hoạt động đảm bảo chất lượng phần mềm, được áp dụng
cho tất cả các pha của kỹ nghệ.
+ Bao trùm suốt tiến trình phát triển và tiến hoá của phần mềm.
b. Nội dung của hoạt động quản lý cấu hình phần mềm:
+ Xác định các thay đổi
+ Kiểm soát các thay đổi
+ Đảm bảo các thay đổi đã được thực hiện
+ Báo cáo các thay đổi cho người quan tâm.
Quản lý cấu hình khác bảo trì phần mềm:
- Bảo trì phần mềm là các hoạt động kỹ nghệ xuất hiện sau khi
phân phối phần mềm và nó đi vào hoạt động.
17
- Quản lý cấu hình phần mềm là các hoạt động theo dõi và kiểm
soát, từ bắt đầu dự án phát triển phần mềm và chỉ kết thúc khi mà phần
mềm không hoạt động nữa.
Câu 15: Mục Tiêu của quản lý cấu hình là gì?. Năm nhiệm vụ của
quản lý cấu hình phần mềm:
- Mục tiêu nguyên thuỷ của quản lý cấu hình phần mềm là kiểm soát các
thay đổi.
- Sau này có thêm các mục tiêu:
+ Xác định các khoản mục cấu hình, các version của phần mềm.
+ Kiểm toán cấu hình phần mềm cũng bảo đảm rằng phần mềm đã
được phát triển đúng và báo cáo tất cả các thay đổi là được áp dụng cho
cấu hình đó.
Năm nhiệm vụ của quản lý cấu hình phần mềm:
♣ Xác định cấu hình

♣ Kiểm soát version
♣ Kiểm soát thay đổi
♣ Kiểm toán cấu hình
♣ Báo cáo thay đổi
Câu 16: Phiên bản là gì? Làm thế nào để kiểm soát phiên bản phần
mềm?
a. Phiên bản là:
- Phiên bản là một thực thể mới của một CI (Configuration Item) sau khi
đã qua một hoặc nhiều lần xem xét và thay đổi.
- Kiểm soát các phiên bản = tổ hợp các thủ tục và các công cụ để quản lý
các phiên bản khác nhau của các đối tượng cấu hình (đã được tạo ra
trong quá trình kỹ nghệ phần mềm).
- Quản lý cấu hình cho phép người sử dụng đặc tả các cấu hình thay thế
của hệ thống phần mềm = lựa chọn các phiên bản thích hợp và gắn kết
với các thuộc tính; nhờ đó mà cho phép đặc tả một cấu hình bằng mô tả
tập các thuộc tính mong muốn.
18
- Để xây dựng một biến thế thích hợp của một phiên bản của một
chương trình, mỗi thành phần của phiên bản được gán một "bộ thuộc
tính" - là một danh sách các đặc trưng.
- Một phiên bản hay biến thể được xây dựng cần xác định thành phần
nào được dùng hay cần thay đổi.
- Một các cách khác để hình thành khái niệm về quan hệ giữa các thành
phần, các biến thể, các phiên bản là biểu diễn chúng như một pool đối
tượng.
- Mỗi thành phần được cấu tạo bởi một bộ các đối tượng trong cùng một
mức xét duyệt. Mỗi biến thể là một bộ các dối tượng trong cùng một
mức xét duyệt. Xác định khi các thay đổi mỗi phiên bản chủ yếu đã
được thực hiện đối với một vài đối tượng.
Câu 17: CMM và CMMi là gì?

CMM là viết tắt của Capability Maturity Model
CMMI là viết tắt của Capability Maturity Model Integration, tức Chuẩn
quản lý quy trình chất lượng.
CMM và CMMi là chuẩn quản lý quy trình chất lượng của các sản phẩm
phần mềm được áp dụng cho từng loại hình công ty khác nhau. Hay nói
cách khác đây là các phương pháp phát triển hay sản xuất ra các sản
phẩm phầm mềm.
CMM và CMMi là một bộ khung (framework)những chuẩn đề ra cho
một tiến trình sản xuất phần mềm hiệu quả, mà nếu như các tổ chức áp
dụng nó sẽ mang lại sự khả dụng về mặt chi phí, thời gian biểu, chức
năng và chất lượng sản phẩm phần mềm.
Mô hình CMM và mô tả các nguyên tắc và các thực tiễn nằm bên trong
tính “thành thục ” quá trình phần mềm và chủ ý giúp đỡ các công ty
phần mềm hoàn thiện khả năng thuần thụ c quá trình sản xuất phần
mềm, đi từ tự phát, hỗn độn tới các quá trình phần mềm thành thục, có
kỷ luật.
Bằng việc thực hiện CMM các công ty thu được những lợi ích xác thực,
giảm được rủi ro trong phát triển phần mềm và tăng đượ c tính khả báo -
do đó trở thành đối tác hay một nhà cung ứng hấp dẫn hơn đối với các
khách hàng trên toàn thế giới. Tuy nhiên, CMM không phải không đòi
19
hỏi chi phí. Những ngu ồn lực đáng kể của công ty phải được dành cho
việc hướng tới các vùng tiến trình then chốt, cần thiết để lên từng bậc
thang của chứ ng nhận CMM. CMM đưa ra một loạt các mức độ để
biểu thị mức độ thành thục đã đạt được. Mức 1 ứng với mức độ thành
thục thấp nhất và mức 5 ứng với mức độ thành thục cao nhất. Gần đây,
SEI đã xúc tiến CMMi, một mô hình kế thừa CMM và CMMi hiện nay
các công ty cũng đang bắt đầu triển khai việc sử dụng mô hình này.
Câu 18 Trình bày 5 level trong CMM
5 levels của CMM như sau:

1: Initial, 2: Repeatable,3: Defined,4: Managed, 5: Optimising
Level 1
Level 1 là bước khởi đầu của CMM, mọi doanh nghi ệp, công ty phần
mềm, cá nhân đều có thểđạt đượ c. Ở lever này CMM chưa yêu cầu bất
kỳ tính năng nào.
Ví dụ: không yêu cầu quy trình, không yêu cầu con người, miễn là cá
nhân, nhóm, doanh nghiệp… đều làm về phầm mềm đều có thể đạt tới
CMM này.
Level 2
Có 6 KPA nó bao gồm như sau
- Requirement Management (Lấy yêu cầu khách hàng, quản lý các yêu
cầu đó)
- Software Project Planning (Lập các kế hoạch cho dự án)
- Software Project Tracking (Theo dõi kiể m tra tiến độ dự án)
- Software SubContract Managent (Quản trị hợp đồng phụ phần mềm)
- Software Quality Assurance (Đảm bảo chất lượng sản phẩm)
- Software Configuration Management (Quản trị cấu hình sản phẩm=>
đúng yêu cầu của khách hàng không)
Khi ta áp dụng Level 2, KPA 2(Software Project Planning), ta sẽ có
những common feature(đặc điểm đặc trưng) như sau:
+ Mục tiêu(Goal): các hoạt động và những đề xuất của ột dự án phần
mềm phải được lên kế hoạch và viết tài liệu đầy đủ
20
+ Đề xu ất/ Xem xét (Commitment): dự án phải tuân thủ theo các qui
tắc của tổ chức khi hoạch định
+ Khả năng(Ability): Việc thực hiện lập kế hoạch cho dự án phần mềm
phải là bước thực hiện từrất sớm khi dự án đưọc bắt đầu
+ Đo lường(Measument): Sự đo lường luôn được thực thi và sửdụng
chúng ta luôn có thể xác định và kiểm soát được tình trạng các hoạt
động trong tiến trình thực hiện dự án

+ Kiểm chứng(Verification): Các hoạt động khi lập kế hoạch dự án
phải được sự reviewed của cấp senior manager
-Để từ level 1 đến level 2 cần:
Trước tiên nó phải thỏa mãn các điều kiện ở level1
Tiếp theo là phải chú trọng tới các phần sau
1. Môi trường làm việc :
- Đảm bảo điều kiện làm việc
- Tạo hứng thú trong công việc
- Không bị ảnh hưởng, mất tập trung bởi các nhân tố khác
2. Thông tin:
Xây dựng cơ chế truyền tin thông suốt từ trên xuống dưới và ngược lại
nhằm giúp cá nhân trong tổ chức chia sẽ thông tin, kiến thức, kinh
nghiệm, các kỹ năng giao tiếp phối hợp và làm việc hiệu quả
3. Xây dựng đội ngũ nhân viên:
Ngay từ khâu tuyển dụng, lựa chọn kỹ càng và định hướng, thể chế
hóa quy trình tuyển dụng
4. Quản lý thành tích :
Đẩy mạnh thành tích, công nhận năng l ực, thành tích bằng cách thiết
lập các tiêu chí khách quan để đánh giá và liên tục khuyến khích khả
năng làm việc, tập trung phát triển sự nghiệp, xây dựng các mục tiêu tiếp
theo.
5. Đào tạo:
Không chỉ đào tạo các kiến thức chuyên môn phục vụ cho dự án mà còn
mở rộng đào tạo các kỹ năng then chốt, cần thiết như kỹ năng làm việc
đội, nhóm, kỹ năng quản lý… nhằm tạo cơ hội cho người lao động phát
huy khả năng, cơ hội học hỏi và phát triển bản thân.
6. Chế độ đãi ngộ :
21
Hoạch đị nh chiến lược đãi ngộ, thu thập ý kiến lực lượng lao động và
công bố công khai. Chế độ đãi ngộ cần tập trung vào việc trả l ương

cho công nhân viên dựa vào vai trò, vị trí của họ (Position), Con người
(Person) – thái độ và tác phong làm việc và Thành tích (Performance)
mà họ đạt được, cống hiến cho tổ chức. Đưa ra được chính sách
lương, thưỏng, phụ cấp các các quyền lợi khác để khuyến khích các cá
nhân dựa trên sự đóng góp của họ và cấp độ phát triển của toàn tổ chứ
c.
Level 3
Các vùng tiến trình chủ chốt ở mức 3 nhằm vào cả hai vấn đề về dự
án và tổ chức, vì một tổ chức (công ty) tạo nên cấu trúc hạ tầng thể chế
các quá trình quản lý và sản xuất phần mềm hiệu quả qua tất cả các dự
án. Chúng gồm có Tập trung Tiến trình Tổ chức (Organization Process
Focus), Phân đị nh Tiến trình Tổ chứ c (Organization Process
Definition), Chương trình Đào tạo (Training Program), Quản trị Phần
mềm Tích hợp (Integrated Software Management), Sản xuất
Sản phẩm Phần mềm (Software Product Engineering), Phối hợp nhóm
(Intergroup Coordination), và Xét duyệt ngang hàng (Peer Reviews).
Để đạt đượ c level 3 thì người quản lý phải biến đổi cải tiến các hoạt
động đang diễn ra, cải tiến môi trường làm việc. Lực lượng lao động sở
hữu những kiến thức, kỹ năng cốt lõi
KPA chú trọng tới các yếu tố sau :
+ Văn hóa cá thể
+ Công việc dựa vào kỹ năng
+ Phát triển sự nghiệp
+ Hoạch đị nh nhân sự
+ Phân tích kiến thức và kỹ năng
Level 4
Các vùng tiến trình chủ yếu ở mức 4 tập trung vào thiết lập hiểu biết
định lượng của cả quá trình sản xuất phần mềm và các sản phẩm phần
mềm đang đượ c xây dựng. Đó là Quản lý quá trình định lượng
(Quantitative Process Management) và Quản lý chất lượng phần mềm

22
(Software Quality Management). Lực lượng lao động làm việc theo
đội, nhóm và đượ c quản lý một cách định lượng.
Các KPA của level 4 chú trọng tới:
+ Chuẩn hóa thành tích trong tổ chức
+ Quản lý năng lực tổ chức
+ Công vi ệ c dựa vào cách làm việc theo nhóm
+ Xây dựng đội ngũ chuyên nghiệp
+ Cố vấn
Để đạt được level 4 thì phải đo lường và chuẩn hóa. Đo lường hiệu
quả đáp ứng công việc, chuẩn hoặc phát triển các kỹ năng, năng lực cốt
lõi . Level 4 này sẽ chú trọng vào những người đứng đầu của một công
ty, họ có khả năng quản lý các công việc nh ư thế nào
Level 5
Các vùng tiến trình chủ yếu ở mức 5 bao trùm các vấn mà cả tổ chức và
dự án phải nhắm tới để thực hiện hoàn thiện quá trình sản xuất phần
mềm liên tục, đo đếm được. Đó là Phòng ngừ a lỗi (Defect
Prevention), Quản trị thay đổi công nghệ (Technology Change
Management), và Quản trị thay đổi quá trình (Process Change
Management) Để đạt đượ c level 4 thì phải đo lường và chuẩn hóa.
Đo lường hiệu quả đáp ứng công việc, chu ẩn hoặc phát triển các kỹ
năng, năng lực cốt lõi
Để đạt được Level 5 thì doanh nghiệp đó phải liên tục cải tiến hoạt
động tổ chức, tìm kiếm các phương pháp đổi mới để nâng cao năng lực
làm việc của lực lượng lao động trong tổ chứ c, hỗ trợ các nhân phát
triển sở trường chuyên môn.
Chú trọng vào việc quản lý, phát triển năng lực của nhân viên
Huấn luyện nhân viên trở thành các chuyên gia
Câu 19 Sự khác biệt CMM và CMMi
CMM CMMi

Công bố chính thức năm 1990 Được manh mún nhắc đến từ trước
1990 (chính xác hơn là từ 1979-
Crosby’s maturity grid (Quality is
Free)) thông qua cấu trúc
23
Continuous & Staged.
Có thể nói CMMI là một phiên bản
cải thiện tất yếu của CMM.
Được hoàn thiện và phát triển bởi
viện SEI của Mĩ
Là sản phẩm cộng tác giữa viện
này và chính phủ Mĩ
Mô hình CMM trước đây gồm có 5
mức: khởi đầu, lặp lại được, được
định nghĩa,
được quản lý và tối ưu.
Cũng có 5 mức: khởi đầu, lặp lại
được, được định nghĩa, được quản
lý và tối ưu
Như vậy các đặc điểm khác nhau quan trọng nhất giữ a CMM và
CMMI là:
- CMMI đưa ra cụ thể hơn 2 khái niệm đối ứng stageds VS continuous
- Chu kỳ phát triển của CMMI được phát triển sớm hơn.
- Nhiều khả năng tích hợp (Integration) hơn
- Sự đo lường, định lượng được định nghĩa hẵn là một Process area
(vùng tiến trình). Chứ không hẳn chỉ là một đặc trưng cơ bản.
- Bao hàm nhi ều Process Areas hơn.
- Đạt được thành quả dễ dàng hơn với mỗi Process area
Câu 20 Trình bày cấu trúc CMMi
CMMi được tích hợp từ nhiều mô hình khác nhau, phù hợp cho cả

những doanh nghiệp phần cứng và tích hợp hệ
thống,chứ không chỉ đơn thuần áp dụng cho doanh nghiệp sản xuất
phần mềm như CMM trước đây.
Có 4 mô hình áp dụng CMMi là CMMi-SW (dành cho công nghệ phần
mềm), CMMi-SE/SW (dành cho công nghệ hệ thống và phần mềm),
CMMi-SE/SW/IPPD (dành cho công nghệ hệ thống + công nghệ phần
mềm với việc phát triển sản phẩm và quy trình tích hợp),CMMi-
SE/SW/IPPD/SS (dành cho công nghệ hệ thống + công nghệ phần mềm
với việc phát triển sản phẩ m và quy trình tích hợp có sử dụ ng thầu ph
ụ )
24
Có 2 cách diễn đạt và sử d ụng CMMi: Staged (phù hợp cho tổ chức có
trên 100 người) và Continuos (phù hợp cho tổ chức dưới 40 người).
CMMI đưa ra cụ thể các mô hình khác nhau cho từng mục đích sử
dụng có đặc riêng bao gồm :
- CMMI-SW mô hình chỉ dành riêng cho ph ần mềm.
- CMMI-SE/SW mô hình tích hợp dành cho các hệ thống và kỹ sư phần
mềm.
- CMMI-SE/SW/IPPD mô hình dành cho các hệ thống, kỹ sư phần mềm
và việc tích hợp sản phẩm cùng quá trình phát triển nó.
- Cấu trúc CMMI gồm:
+ Mức độ trưởng thành (dùng cho stage presentation) và Mức độ nỗ
lực (dùng cho continuous presentation).
+ Miền quy trình (Process Areas – PA).
+ Mục tiêu: tổng quan và cụ thể (Generic Goals và Specific Goals).
+ Các đặc tính thông dụng (Common Features)
+ Các bài Luyện tập: tổng quan và Cụ thể (Generic Practices và
Specific Practices).
Câu 21: Trình bày tiến trình kiểm soát sự thay đổi.
Biểu đồ tiến trình kiểm soát sự thay đổi

- Khi một yêu cầu thay đổi được đệ trình cần định giá trị nhằm: sử dụng
kĩ thuật thích hợp; hiệu ứng phụ có thể có, ảnh hưởng lên tổng thể các
đối tượng cấu hình khác và lên các chức năng hệ thống và lên chi phí sự
án vì thay đổi đó
- Kết quả đánh giá về sự đổi thay được báo cáo cho người có thẩm
quyền kiểm soát đổi thay (change control authority - CCA), có quyền tối
hậu về tình trạng & quyết định đổi thay.
- Mệnh lệnh kĩ nghệ thay đổi (ECO) được tạo ra cho từng thay đổi được
chấp thuận. Lệnh này được mô tả các thay đổi cần tìm, các ràng buộc
phải tuân theo, các tiêu chuẩn rà soát và kiểm toán.
- Đối tượng cần thay đổi được "check out" khỏi cơ sở dữ liệu dự án,
được thay đổi, và các hoạt động đảm bảo chất lượng phần mềm cần
được áp dụng.
25