Bài giảng Đảm bảo chất lượng phần mềm và kiểm thử - Nguyễn Văn Vỵ - Phần 3: Thẩm định và xác minh

‰Hệthốngdựa trên máy tính do nhiều bên xây dựng,

người phát triển phần mềm chỉ là một

‰Việc kiểm thửhệthống dễcó nguy cơcác bên tham gia

“đổlỗi cho nhau”.

‰Những sai có thểnảy sinh từ:

• Các dữliệu qua giao diện của các thành phần được

kiểm thử

• Đường xửlý liên kết các thành phần

• Sựtích hợp lỗi từcác thành phần khác nhau

• Những hạn chếkhác đến năng lực do ảnh hưởng từcác

thành phân: chịu lỗi, an toàn, thực thi

pdf82 trang | Chuyên mục: Công Nghệ Phần Mềm | Chia sẻ: dkS00TYs | Lượt xem: 1535 | Lượt tải: 0download
Tóm tắt nội dung Bài giảng Đảm bảo chất lượng phần mềm và kiểm thử - Nguyễn Văn Vỵ - Phần 3: Thẩm định và xác minh, để xem tài liệu hoàn chỉnh bạn click vào nút "TẢI VỀ" ở trên
ổi
‰ Quá trình kiểm soát đổi thay như sau:
Thực hiện thay đổi
Rà soát thay đổi (kiểm toán)
Các (khoản mục) đối tượng cấu hình “check in”
Thiết lập đường mốc giới cho kiểm thử
Tiến hành các hoạt Động bảo đảm chất lượng và kiểm thử
2005 Bộ môn CNFM – Đại học Công nghệ 62
NguyÔn V¨n Vþ
l1 Tiến trình kiểm soát sự thay đổi(t)
Xem lại các thay đổi sẽ được đưa vào trong 
lần phân phối mới
Xây dựng lại phiên bản mới của phần mềm
Rà soát lại sự thay đổi của tất cả
các khoản mục cấu hình (kiểm toán)
Bao gồm các thay đổi vào trong phiên bản mới
Phân phối phiên bản mới
2005 Bộ môn CNFM – Đại học Công nghệ 63
NguyÔn V¨n Vþ
† Khi một yêu cấu thay đổi được đệ trình cần đánh giá
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 & lên các chức năng
hệ thống & lên chi phí dự á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.
l2 Hoạt động kiểm soát sự thay đổi
2005 Bộ môn CNFM – Đại học Công nghệ 64
NguyÔn V¨n Vþ
† 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 mô tả các 
thay đổi cần là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 bảo 
đảm chất lượng phần mềm cần được áp dụng.
† Sau đó đối tượng này được “check in” vào cơ sở dữ
liệu & một cơ chế kiểm soát phiên bản được sử dụng.
l2. Hoạt động kiểm soát sự thay đổi
2005 Bộ môn CNFM – Đại học Công nghệ 65
NguyÔn V¨n Vþ
† Quá trình “check in” và “check out” nhằm thực hiện 
hai mục tiêu quan trọng của kiểm soát đổi thay là: kiểm 
soát truy cập và kiểm soát đồng bộ:
„ kiểm soát truy cập quản trị những cái gì mà người 
kỹ sư có thẩm quyền truy cập và cải biên 1đối tượng 
cấu hình cụ thể.
„ kiểm soát đồng bộ giúp ta bảo đảm rằng các thay 
đổi đồng thời, do những người khác nhau thực hiện 
không viết đè lên nhau.
l2. Hoạt động kiểm soát sự thay đổi
2005 Bộ môn CNFM – Đại học Công nghệ 66
NguyÔn V¨n Vþ
† “check out” một đối tượng cấu hình dựa trên yêu cầu 
thay đổi đã được chấp thuận và lệnh kỹ nghệ thay đổi 
cho phép người kỹ sư phần mềm thực hiện.
† Một chức năng kiểm soát truy cập sẽ bảo đảm rằng 
người kỹ sư phần mềm có thẩm quyền “check out” đối 
tượng & các kiểm soát đồng bộ sẽ khoá đối tượng đó 
trong cơ sở dữ liệu dự án sao cho không ai có thể cập 
nhật cho đến khi phiên bản “check out” này được thay 
thế.
l2. Hoạt động kiểm soát sự thay đổi
2005 Bộ môn CNFM – Đại học Công nghệ 67
NguyÔn V¨n Vþ
† Khi đó các bản sao khác có thể được “check out” 
nhưng không thể được cập nhật.
† Một bản sao của đối tượng đường mốc (gọi là phiên 
bản trích ly) được kỹ sư phần mềm cải biên. Sau khi 
mọi bảo đảm chất lương phần mềm và kiểm thử
hoàn tất, phiên bản đã được cải biên của đối tượng 
sẽ được “check in”, cả đối tượng và đường mốc mới 
này được mở khoá.
l2. Hoạt động kiểm soát sự thay đổi
2005 Bộ môn CNFM – Đại học Công nghệ 68
NguyÔn V¨n Vþ
† đường mốc được tạo ra khi đối tượng đó đã được rà
soát kỹ thuật chính thức & đã được chấp thuận
† Việc kiểm soát đổi thay mức dự án được thực thi. 
Trước hết người phát triển phải được sự chấp thuận 
của người quản lý dự án (nếu dự án là cục bộ) hoặc 
được sự chấp thuận của người có thẩm quyền kiểm 
soát đổi thay (nếu nếu đổi thay ảnh hưởng tới các 
khoản mục cấu hình phần mềm khác).
l2. Hoạt động kiểm soát sự thay đổi
2005 Bộ môn CNFM – Đại học Công nghệ 69
NguyÔn V¨n Vþ
† Quá trình kiểm soát thay đổi với quá nhiều thủ tục 
chặt chẽ có nguy cơ tạo ra sự quan liêu .
† Không tổ chức và kiểm tra tốt, sự kiểm soát thay đổi 
có thể dẫn đến cản trở tiến trình phát triển 
† Hầu hết người phát triển phần mềm đều có cơ chế
kiểm soát đổi thay (cũng nhiều người chẳng có!), họ 
đã tạo ra một số tầng kiểm soát để tránh những vấn 
đề nói trên.
l3. Vấn đề trong kiểm soát sự thay đổi
2005 Bộ môn CNFM – Đại học Công nghệ 70
NguyÔn V¨n Vþ
† Trong 1 số trường hợp, nhiều thủ tục chính thức: các 
yêu cầu, các báo cáo, và các lệnh kỹ nghệ thay đổi 
được bỏ qua. Tuy nhiên, việc đánh giá từng đổi thay 
vẫn được tiến hành và tất cả các đổi thay vẫn được 
theo dõi và được rà soát.
† kiểm soát thay đổi chính thức được hình thành khi sản 
phẩm đã được phân phát cho khách hàng.
† Thẩm quyền kiểm soát thay đổi đóng một vai trò tích 
cực trong tầng thứ hai và thứ ba. Phụ thuộc vào kích 
cỡ và đặc tính của dự án phần mềm
l4. Thực tiễn kiểm soát sự thay đổi
2005 Bộ môn CNFM – Đại học Công nghệ 71
NguyÔn V¨n Vþ
‰ Người có thẩm quyền cần có cái nhìn tổng thể, đánh 
giá được ảnh hưởng của thay đổi đối với các yếu tố
bên ngoài các khoản mục cấu hình phần mềm:
Thay đổi ảnh hưởng tới:
■ phần cứng như thế nào?
■ sự thực thi như thế nào?
■ sự nhìn nhận của khách hàng đối với sản phẩm 
như thế nào?
■ chất lượng và độ tin cậy của sản phẩm như thế
nào?, và nhiều câu hỏi khác nữa 
l4. Thực tiễn kiểm soát sự thay đổi
2005 Bộ môn CNFM – Đại học Công nghệ 72
NguyÔn V¨n Vþ
† Minh định, kiểm soát phiên bản, kiểm soát thay đổi, 
giúp cho người phát triển duy trì 1 trật tự, tránh được 
tình thế hỗn độn.
† Tuy nhiên, ngay khi các cơ cấu kiểm soát thành công
nhất cũng chỉ theo dõi 1 thay đổi cho đến khi 1 đối 
tượng cấu hình kỹ thuật được sinh ra; 
† làm thế nào để bảo đảm sự thay đổi đó thực sự được 
thực thi? Cần có hai hoạt động: 
„ rà soát kỹ thuật chính thức, 
„ kiểm toán cấu hình.
n. Kiểm toán cấu hình
(configuration auditing)
2005 Bộ môn CNFM – Đại học Công nghệ 73
NguyÔn V¨n Vþ
† Một nhân tố quan trọng của quá trình thẩm định là rà
soát cấu hình (configuration review ) - đôi khi được 
gọi là kiểm toán cấu hình. Rà soát này bảo đảm rằng 
các yếu tố của cấu hình phần mềm đã thực sự được 
phát triển, lập danh mục, và có các chi tiết cần thiết 
để trợ giúp pha bảo trì của vòng đời phần mềm
n1. Khái niệm kiểm toán cấu hình
2005 Bộ môn CNFM – Đại học Công nghệ 74
NguyÔn V¨n Vþ
† Rà soát kỹ thuật chính thức tập trung vào sự đúng 
đắn kỹ thuật của đối tượng cấu hình được cải biên.
Người rà soát cần đánh giá:
„ sự phù hợp với các khoản mục cấu hình khác, 
„ sự bỏ sót và các hiệu ứng phụ khác.
† Kiểm toán cấu hình phần mềm bổ sung cho rà soát 
kỹ thuật chính thức bằng cách đánh giá một đối tượng 
cấu hình trên các đặc tính mà thường không được xét 
trong quá trình rà soát.
n1. Khái niệm kiểm toán cấu hình
2005 Bộ môn CNFM – Đại học Công nghệ 75
NguyÔn V¨n Vþ
n2. Sơ đồ truy nhập và kiểm soát đồng bộ
Chect-in
Chect-out
Kiểm soát
truy nhập CSDL dự án
Đối tượng 
cấu hình
Đối tượng 
cấu hình
Đối tượng 
cấu hình
Đối tượng 
cấu hình
Mở khóa
khóa
Thông tin 
kiểm toán
Kỹ sư 
phần mềm
2005 Bộ môn CNFM – Đại học Công nghệ 76
NguyÔn V¨n Vþ
† Kiểm toán = hỏi và trả lời các câu hỏi sau:
ƒ Thay đổi được đặc tả trong lệnh kỹ nghệ thay 
đổi đã được thực hiện hay chưa? Nhưng cải 
biên phụ nào đã được phối hợp?
ƒ Rà soát kỹ thuật chính thức đã được tiến hành 
để đánh giá sự đúng đắn kỹ thuật hay chưa?
ƒ Các chuẩn kỹ nghệ phần mềm đã thực sự được 
tuân thủ chưa?
n3. Câu hỏi của kiểm toán cấu hình 
2005 Bộ môn CNFM – Đại học Công nghệ 77
NguyÔn V¨n Vþ
† Kiểm toán trả lời các câu hỏi sau (tiếp):
 Thay đổi đó đã nổi bật lên trong các khoản mục 
phần mềm chưa? Có đặc tả ngày & tác giả của 
thay đổi đó? Các thuộc tính của đối tượng cấu 
hình đó đã phản ánh được đổi thay đó chưa?
 Các thủ tục quản lý cấu hình để giám sát, ghi lại 
và báo cáo về nó có được tuân thủ hay không?
 Tất cả các khoản mục cấu hình phần mềm liên 
quan đã thực sự được cập nhật chưa?
n3. Câu hỏi của kiểm toán cấu hình
2005 Bộ môn CNFM – Đại học Công nghệ 78
NguyÔn V¨n Vþ
† Thông thường, các câu hỏi kiểm toán như là 1 phần 
của rà soát kỹ thuật phần mềm; nhưng khi quản lý cấu 
hình phần mềm trở thành hoạt động chính thức, thì
kiểm toán cấu hình phần mềm được tiến hành tách 
riêng cho 1 nhóm bảo đảm chất lượng
n4. Tiến hóa của kiểm toán cấu hình
2005 Bộ môn CNFM – Đại học Công nghệ 79
NguyÔn V¨n Vþ
† Báo cáo hiện trạng cấu hình (configuration status 
reporting – CSR) - (còn gọi là kiểm toán hiện trạng) là
một nhiệm vụ quản lý cấu hình phần mềm; nó trả lời 
các câu hỏi sau:
ƒ Cái gì đã xảy ra?
ƒ Ai làm?
ƒ Xảy ra khi nào?
ƒ Sẽ còn ảnh hưởng nào khác nữa?
‰ Thông tin báo cáo tình trạng cấu hình gắn chặt với các 
nhiệm vụ trong kiểm soát đổi thay
Báo cáo hiện trạng
2005 Bộ môn CNFM – Đại học Công nghệ 80
NguyÔn V¨n Vþ
† Mỗi khi 1 khoản mục cấu hình phần mềm được ấn 
định mới hoặc được cập nhật trở lại thì 1 nội dung 
(entry) được tạo ra trong CSDL.
† Mỗi khi 1 khoản mục cấu hình phần mềm được chấp 
thuận quyền thay đổi cấu hình (1 mệnh lệnh thay đổi 
kỹ nghệ được phát ra) thì 1 nội dung cũng được tạo ra
† Mỗi khi 1 kiểm toán cấu hình được tiến hành thì các 
kết quả của nó được báo cáo như là 1 phần của 
nhiệm vụ báo cáo hiện trạng cầu hình.
a. Khái niệm về báo cáo hiện trạng
2005 Bộ môn CNFM – Đại học Công nghệ 81
NguyÔn V¨n Vþ
† Báo cáo hiện trạng cấu hình có thể được đặt trên 
một cơ sở dữ liệu trực tuyến để người phát triển hay 
bảo trì có thể truy cập ngay các thông tin đổi thay.
† Báo cáo hiện trạng cấu hình đóng một vai trò cốt tử
cho thắng lợi của 1 dự án phát triển phần mềm lớn.
† Báo cáo hiện trạng cấu hình giúp loại trừ vấn đề bất 
cập liên quan đến nhiều người bằng cách cải thiện 
giao tiếp giữa tất cả họ
a. Khái niệm về báo cáo hiện trạng
2005 Bộ môn CNFM – Đại học Công nghệ 82
NguyÔn V¨n Vþ
† Vấn đề bất cập:
„ Xây dựng phần mềm cho 1 đặc tả mà phần cứng 
tương ứng đã không còn dùng nữa. 
„ Tiến hành 1 đổi thay đề xuất mà nó đã được 
thực hiện.
„ Sử dụng 1 thành phần đang sửa đổi vì có lỗi
„ Cải biên cùng 1 khoản mục cấu hình với những ý 
định khác nhau, thậm chí là mâu thuẫn nhau.
b. Những bất cập thiếu báo cáo hiện trạng

File đính kèm:

  • pdfBài giảng Đảm bảo chất lượng phần mềm và kiểm thử - Nguyễn Văn Vỵ - Phần 3 Thẩm định và xác minh.pdf