Bài giảng đảm bảo chất lượng phần mềm và kiểm thử (Nguyễn Văn Vy): Phần mở đầu [Chuẩn SEO]

NguyÔn V¨n Vþ XXXXXXXXXXX XXXXXXXXXXX

ĐẠI HỌC QUỐC GIA HÀ NỘI – ĐẠI HỌC CÔNG NGHỆ Bộ môn Công nghệ phần mềm

BÀI GiẢNG

ĐẢM BẢO CHẤT LƯỢNG PHẦN

MỀM VÀ KiỂM THỦ

NguyÔn V¨n Vy Email: vynv@vnu.edu.vn, mobile: 0912.505.291

Hà nội -2005

Bộ môn CNFM – ĐH Công nghệ

2005

Nội dung – Tài liệu

NguyÔn V¨n Vþ

(cid:132) Chất lượng và đảm bảo chất lương

(cid:132) Kiểm thử phần mềm

(cid:153) Roger S. Pressman. Software Engineering, a Practitioner’s Approach. 3th Edition,

McGraw-Hill, 1992, Bản dich của Ngô Trung vIệt, Phần 4, tập 4

(cid:153) Ian Sommerville. Software Engineering, Sixth Edition, Addion Wesley, 2001, Phần

5 và 6.

(cid:153) E.M.Bennatan, Software Project Management : a practitioner’s approach,

McGRAW-HILL Book Company, 2001, Phần 2

Bộ môn CNFM – ĐH Công nghệ

2005

Yêu cầu, đặc điểm môn học

NguyÔn V¨n Vþ

(cid:137) Yêu cầu

(cid:132) Nắm vững khái niệm (cid:132) Các họat động đảm bảo chất lượng (cid:132) Các kỹ thuật kiểm thử

(cid:137) Chuẩn bị: đọc trước, nghe, thảo luân

(cid:137) Kiểm tra đánh giá: (cid:131) Tiểu luận (30%) (cid:131) Vấn đáp (70%)

Bộ môn CNFM – ĐH Công nghệ

2005

1. Khái niệm chất lượng phần mềm-SQA NguyÔn V¨n Vþ

(cid:132) Chất lượng phần mềm (sofware quality assurance -

SQA) là gì?

(cid:131) Chất lượng thiết kế (cid:131) Sự hoàn thiện (cid:131) Sự lâu bền ..

Bộ môn CNFM – ĐH Công nghệ

2005

Chất lượng sản phẩm là mức độ đạt được các đặc trưng hay những thuộc tính náo đó của nó (Từ điển American Heritage). Chẳng hạn:

1. Khái niệm chất lượng phần mềm (t)

NguyÔn V¨n Vþ

(cid:132) Chất lượng phần mềm là gì?

(cid:131) 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 tả của nó[Crosby,1979]

(cid:131) Chất lượng phần mềm là sự đáp ứng yêu cầu chức

Bộ môn CNFM – ĐH Công nghệ

2005

năng, sự hoàn thiện và các chuẩn (đặc tả) được phát triển, các đặc trưng mong chờ từ mọi phần mềm chuyên nghiệp (ngầm định).

1. Khái niệm chất lượng phần mềm (t)

NguyÔn V¨n Vþ

(cid:132) Chất lượng phần mềm là gì?

(cid:131) Định nghĩa trên là chung cho mọi sản phẩm.

(cid:131) Với phần mềm có một số vấn đề:

(cid:190) Phần mềm có yêu cầu mà chưa có đặc tả?

(cid:190) Phần mềm có đặc tả nhưng lại mù mờ?

(cid:190) Có những yêu cầu tự nhiên nên không được đặc tả?

Bộ môn CNFM – ĐH Công nghệ

2005

a. Chất lượng phần mềm là gì?

NguyÔn V¨n Vþ

(cid:132) Chất lượng phần mềm là gì?

(cid:131) Yêu cầu phần mềm phải 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 & chất lượng (cid:131) Yêu cầu thể hiện ra bằng đặc tả - đặc tả phải có

hướng dẫn cách thức làm ra phần mềm.

• Không tuân thủ các tiêu chuẩn đó thì hầu chắc chắn là chất

lượng sẽ kém.

Bộ môn CNFM – ĐH Công nghệ

2005

chuẩn mới kiểm tra được (không mù mờ) • Các chuẩn đặc tả là một bộ các tiêu chuẩn phát triển, và

a. Chất lượng phần mềm là gi?

NguyÔn V¨n Vþ

Chất lượng phần mềm là gì?

(cid:132) 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ụ) (cid:132) Phần mềm chưa phù hợp với các yêu cầu ngầm

thì chất lượng là đáng nghi ngờ

(cid:190)Cần làm rõ yêu cầu và đưa vào đặc tả càng nhiều

Bộ môn CNFM – ĐH Công nghệ

2005

càng tốt

b. Nhân tố ảnh hưởng lên chất lương

NguyÔn V¨n Vþ

(cid:131) Nhân tố trực tiếp (cid:131) Nhân tố gián tiếp

(cid:132) Hai loại mức độ ảnh hưởng

(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.

Bộ môn CNFM – ĐH Công nghệ

2005

(cid:132) McCall đề xuất 11 nhân tố phân thành 3 loại :

b. Nhân tố ảnh hưởng lên chất lương

NguyÔn V¨n Vþ

(cid:132) Loại (1): Các đặc trưng chức năng

Bộ môn CNFM – ĐH Công nghệ

2005

(cid:131) tính đúng đắn, (cid:131) tính tin tưởng được, (cid:131) tính hiệu quả, (cid:131) tính toàn vẹn, (cid:131) tính khả dụng

b. Nhân tố ảnh hưởng lên chất lương

NguyÔn V¨n Vþ

(cid:132) Loại (2)

(cid:132) Loại (3)

(cid:131) (cid:131) (cid:131)

(cid:131) (cid:131) (cid:131) tính bảo trì được, tính mềm dẻo, tính thử nghiệm được

Bộ môn CNFM – ĐH Công nghệ

2005

tính mang chuyển được tính sử dụng lại được tính liên tác được

c. Các độ đo chất lượng

NguyÔn V¨n Vþ

(cid:132) Để đo mức độ ảnh hưởng cần có độ đo

(cid:132) McCall đề xuất 21 độ đo sau:

Bộ môn CNFM – ĐH Công nghệ

2005

1. Độ kiểm toán được, 2. Độ chính xác, 3. Độ tương đồng giao tiếp, 4. Độ đầy đủ, 5. Độ phức tạp, 6. Độ súc tích (conciseness), 7. Độ hoà hợp (consistancy), 8. Độ tương đồng dữ liệu,

c. Các độ đo chất lượng

NguyÔn V¨n Vþ

(cid:132) McCall đề xuất 21 độ đo sau:

9. Độ dung thứ lỗi, 10. Độ hiệu qủa thực hiện, 11. Độ khuếch trương được,

Bộ môn CNFM – ĐH Công nghệ

2005

12. Độc lập phần cứng, 13. Độ trang bị đủ đồ nghề (instrumentation), 14. Độ môđun hoá, 15. Độ dễ thao tác, 16. Độ an ninh,

c. Các độ đo chất lượng

NguyÔn V¨n Vþ

(cid:132) McCall đề xuất 21 độ đo sau:

17. Tự tạo tài liệu (self-doccumentation),

18. Độ đơn giản - dễ hiểu, 19, Độc lập phần mềm, 20. Độ lần vết được,

Bộ môn CNFM – ĐH Công nghệ

2005

21. Khả năng huấn luyện.

d. Tính đúng đắn

NguyÔn V¨n Vþ

(cid:132) Tính đúng đắn Là gì?

(cid:131)

(cid:132) Các độ đo liên quan:

(cid:131) Độ đầy đủ, (cid:131) Độ hoà hợp (cid:131) Độ lần vết được

Bộ môn CNFM – ĐH Công nghệ

2005

làm đúng với cái khách hàng mong muốn thoả mãn những điều đã được đặc tả (những yêu cầu của đối tượng khác)

e. Tính tin cậy được

NguyÔn V¨n Vþ

(cid:132) Tính tin cậy được là gì?: có thể trông đợi vào sự

• Độ mođun hoá, • Độ đơn giản – dễ hiểu, • Độ lần vết được

thực hiện các chức năng dự kiến và mức chính xác được đòi hỏi

Bộ môn CNFM – ĐH Công nghệ

2005

(cid:132) Các độ đo liên quan: • Độ chính xác, • Độ phức tạp, • Độ hoà hợp, • Độ dung thứ lỗi,

f. Tính hiệu quả

NguyÔn V¨n Vþ

(cid:132) Tính hiệu quả Là gì?: tổng lượng nguồn lực tính

(cid:132) Các độ đo liên quan:

(cid:131) Độ súc tích, (cid:131) Độ hiệu qủa thực hiện, (cid:131) Độ dễ thao tác,

Bộ môn CNFM – ĐH Công nghệ

2005

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,

g. Tính toàn vẹn

NguyÔn V¨n Vþ

(cid:139) Tính toàn vẹn Là gì?: 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 của HT

(cid:139) Các độ đo liên quan: (cid:131) Độ kiểm toán được, (cid:131) Trang bị đồ nghề đủ, (cid:131) Độ an ninh,

Bộ môn CNFM – ĐH Công nghệ

2005

h. Tính khả dụng

NguyÔn V¨n Vþ

■ Tính khả dụng Là gì?: 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 được, khả năng nhớ lâu

Bộ môn CNFM – ĐH Công nghệ

2005

■ Các độ đo liên quan: (cid:131) Độ dễ thao tác, (cid:131) Khả năng huấn luyện.

i. Tính bảo trì được

NguyÔn V¨n Vþ

■ Tính bảo trì được là gì?: nỗ lực cần để định vị và xác định được 1 lỗi trong chương trình là chấp nhận được

■ Các độ đo liên quan: (cid:131) Độ súc tích, (cid:131) Độ hoà hợp, (cid:131) Trang bị đồ nghề đủ, (cid:131) Độ mođun hoá,

Bộ môn CNFM – ĐH Công nghệ

2005

(cid:131) Độ tự cấp tài liệu, (cid:131) Độ đơn giản (cid:131) Độ dễ hiểu,

k. Tính mềm dẻo

NguyÔn V¨n Vþ

■ Tính mềm dẻo Là gì? 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: (cid:131) Độ phức tạp, (cid:131) Độ súc tích (cid:131) Độ hoà hợp, (cid:131) Khuếch trương được,

(cid:131) Độ khái quát, (cid:131) Độ mođun hoá, (cid:131) Tự cấp tài liệu, (cid:131) Độ đơn giản - dễ hiểu,

Bộ môn CNFM – ĐH Công nghệ

2005

m. Tính thử nghiệm được

NguyÔn V¨n Vþ

■ Tính thử nghiệm được là gì?: nỗ lực cần để thử nghiệm 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: (cid:131) Độ kiểm toán được, (cid:131) Độ phức tạp, (cid:131) Trang bị đồ nghề đủ, (cid:131) Độ môđun hoá, (cid:131) Tự cấp tài liệu, (cid:131) Độ đơn giản - dễ hiểu,

Bộ môn CNFM – ĐH Công nghệ

2005

l. Tính mang chuyển được

NguyÔn V¨n Vþ ■ Tính mang chuyển được là gì?: 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: (cid:131) Độ khái quát, (cid:131) Độ độc lập phần cứng, (cid:131) Độ mođun hoá, (cid:131) Tự cấp tài liệu, (cid:131) Độc lập hệ thống phần mềm,

Bộ môn CNFM – ĐH Công nghệ

2005

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

NguyÔn V¨n Vþ

■ Tính sử dụng lại được là gì?: Khả năng chương

Bộ môn CNFM – ĐH Công nghệ

2005

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: • Độ khái quát, • Độc lập phần cứng, • Độ môđun hoá, • Tự tạo tài liệu, • Độc lập hệ thống phần mềm,

o. Tính liên tác được

NguyÔn V¨n Vþ

■ Tính liên tác được là gì?: nỗ lực đòi hỏi để ghép HT 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:

• Độ tương đồng giao tiếp, • Độ tương đồng dữ liệu, • Độ khái quát, • Độ môđun hoá.

Bộ môn CNFM – ĐH Công nghệ

2005

p. Các nhân tố chất lượng phần mềm FURPS của Hawlett-Packard 1

NguyÔn V¨n Vþ

(cid:131) F: Functionality - Nhân tố chức năng

(cid:131) U: Usability - Nhân tố khả dụng

(cid:131) R: Reability – Nhân tố tin cậy

(cid:131) P: Performance - Nhân tố thi hành

Bộ môn CNFM – ĐH Công nghệ

2005

(cid:131) S: Supportability – Nhân tố mang chuyển

p1. FURPS: Nhân tố chức năng

NguyÔn V¨n Vþ

Bộ môn CNFM – ĐH Công nghệ

2005

Đượ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

p2. FURPS: Nhân tố khả dụng

NguyÔn V¨n Vþ

Bộ môn CNFM – ĐH Công nghệ

2005

Được định giá bằng việc xem xét các nhân tố con người, thẩm mỹ, sự hoà hợp và tư liệu cung cấp

p3. FURPS: Nhân tố tin cậy

NguyÔn V¨n Vþ

Được đánh giá bằng:

(cid:131) Tần xuất thất bại và độ nghiên trọng của nó (cid:131) Tính chính xác của các kết quả ra, (cid:131) Thời gian trung bình giữa hai thất bại kế nhau, (cid:131) Khả năng phục hồi sau thất bại, (cid:131) Khả năng dự đoán trước được thất bại của chương

trình

Bộ môn CNFM – ĐH Công nghệ

2005

p4. FURPS: Nhân tố thi hành

NguyÔn V¨n Vþ

Được đánh giá bằng:

(cid:131) Tốc độ xử lý, (cid:131) Thời gian đáp ứng, (cid:131) Độ sử dụng nguồn lực, (cid:131) Năng xuất, và Hiệu năng

Bộ môn CNFM – ĐH Công nghệ

2005

p5. FURPS: Nhân tố mang chuyển

NguyÔn V¨n Vþ

Đánh giá bằng tổ hợp các khả năng:

Bảo trì được

Bộ môn CNFM – ĐH Công nghệ

2005

(cid:131) Mở rộng chương trình, (cid:131) Độ thích nghi (cid:131) Phục vụ được (bảo trì được) (cid:131) Thử nghiệm được, (cid:131) Sự tương hợp, (cid:131) 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 đề)

2. Tiến hóa của hoạt động SQA

NguyÔn V¨n Vþ

(cid:132) Khi phần mềm trở thành sản phẩm có nhu cầu và đòi

(cid:132) Từ thực tiễn: King nghiệm cho phép hoạt động đảm

hỏi đảm bảo chất lượng: (cid:131) Từ khách hàng (nhu cầu) (cid:131) Từ nhà sản xuất (đòi hỏi): đảm bảo tính đồng đều của sản phẩm, cải thiện chất lượng thường xuyên

Bộ môn CNFM – ĐH Công nghệ

2005

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

a. Sự phát triển của SQA

NguyÔn V¨n Vþ

■ 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

■ Đảm bảo chất lượng phần mềm diễn ra song song với

bảo đảm chất lượng trong chế tạo phần cứng.

Bộ môn CNFM – ĐH Công nghệ

2005

■ 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ự vào những năm 70 và nhanh chóng mở rộng thương mại

b. Vai trò và trách nhiệm trong SQA

NguyÔn V¨n Vþ

■ Những người có trách nhiệm bảo đảm chất

lượng phần mềm (trong tổ chức) :

Bộ môn CNFM – ĐH Công nghệ

2005

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

b. Vai trò và trách nhiệm trong SQA

NguyÔn V¨n Vþ

■ Nhóm SQA phải đóng vai trò như đại diện của khách hàng - để xem xét chất lượng phần mềm với quan điểm của khách hàng:

Bộ môn CNFM – ĐH Công nghệ

2005

(cid:131) Có đáp ứng được các nhân tố chất lượng không? (cid:131) Có tuân theo các chuẩn dự định trước không? (cid:131) 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. Các hoạt động SQA

NguyÔn V¨n Vþ

■ Có 7 hoạt động chính:

(1) Áp dụng công nghệ kỹ nghệ hiệu quả (phương

pháp, công cụ)

Bộ môn CNFM – ĐH Công nghệ

2005

(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à quản lý các báo cáo.

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

NguyÔn V¨n Vþ

■ Tập hợp các phương pháp và công cụ giúp để:

• giúp phân tích có được đặc tả chất lượng cao, • giúp thiết kế có được thiết kế chất lượng cao.

■ Hoạt động trung tâm là rà soát kỹ thuật chính thức. (tác

dụng không kém gì thử nghiệm để việc phát hiện khiếm khuyết).

■ Kiểm thử phần mềm (chỉ thử nghiệm phần mềm không

Bộ môn CNFM – ĐH Công nghệ

2005

thể tìm ra được hầu hết các sai)

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

NguyÔn V¨n Vþ

■ Áp dụng các chuẩn và các thủ tục chính thức là một 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:

(cid:131) do khách hàng, hay chính quyền quy định. (cid:131) tự công ty đặt ra.

■ Đánh giá 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

Bộ môn CNFM – ĐH Công nghệ

2005

SQA có thể tiến hành kiểm toán (audit) riêng.

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

NguyÔn V¨n Vþ

■ Khống chế đổi thay đó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,

(cid:137) Đe doạ chủ yếu của chất lượng đến từ sự thay đổi.

(cid:131) (cid:131) đánh giá bản chất của sự đổi thay, (cid:131) khống chế các ảnh hưởng của sự đổi thay.

(cid:137) Thay đổi tạo ra tiềm năng sinh ra sai và tạo ra hiệu

Thay đổi là bản chất của phần mềm

Bộ môn CNFM – ĐH Công nghệ

2005

ứng phụ lan truyền.

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

NguyÔn V¨n Vþ

■ 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ì

■ Một mục tiêu quan trọng của SQA:

• Theo dõi chất lượng phần mềm • Đánh giá ảnh hưởng của đổi thay về phương pháp

(cid:137) Muốn vậy phải thu thập các độ đo phần mềm.

luận và thủ tục lên chất lượng phần mềm.

■ Các độ đo phần mềm hướng đến 2 mặt:

Bộ môn CNFM – ĐH Công nghệ

2005

• quản lý (thủ tục) • kỹ thuật (phương pháp)

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

NguyÔn V¨n Vþ

■ Lập và lưu giữ 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:

thử nghiệm,

• rà soát, • kiểm toán, • khống chế đổi thay, • • 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” –

Bộ môn CNFM – ĐH Công nghệ

2005

trong suốt quá trình dự án

3. Rà soát phần mềm

NguyÔn V¨n Vþ

■ 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 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)

■ Áp dụng tại các thời điểm khác nhau trong quá trình

Bộ môn CNFM – ĐH Công nghệ

2005

phát triển phần mềm.

a. Các hình thức rà soát

NguyÔn V¨n Vþ

■ Các kiểu rà soát:

(cid:131) Họp xét duyệt không chính thức, (cid:131) 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. (tập trung vào các rà soát kỹ thuật chính thức - formal technical review - FTR)

Bộ môn CNFM – ĐH Công nghệ

2005

■ 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)

b. Lợi ích của việc rà soát

NguyÔn V¨n Vþ

■ Sớm phát hiện các “khiếm khuyết” của phần mềm để

có thể chỉnh sửa.

■ Các nghiên cứu của công nghiệp phần mềm (TRW, Nippon Electric, Mitre Corp., …) đã chỉ ra: 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 mềm

Bộ môn CNFM – ĐH Công nghệ

2005

■ 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. trong thiết kế tốn phí 1.0, trước kiểm thử: 6.5, trong kiểm thử: 15 và sau phân phối sẽ ltừ 60. đến 100.

b. Chi phí sửa lỗi trong quá trình phát triển

NguyÔn V¨n Vþ

100

Chi phí sửa lỗi

6,5

Thiết kê

trước test

trong test phân phối

Bộ môn CNFM – ĐH Công nghệ

2005

c. Các loại lỗi

NguyÔn V¨n Vþ

■ Ba loại lỗi có ở mỗi bước của quá trình phát triển phần

mềm:

• lỗi mới được sinh ra • lỗi được phóng đại lên do các nhân tố lỗi của các

bước trước

• lỗi còn lại của các bước trước.

Bộ môn CNFM – ĐH Công nghệ

2005

■ Nếu không rà soát lỗi tồn lại gia tăng nhanh, và phí cho việc loại trừ các lỗi ngày càng lớn; Vì vậy vấn đề đặt ra là: “chi phí ngay bây giờ hay để lại sau phải chi phí nhiều hơn?”

d. Rà soát kỹ thuật chính thức

NguyÔn V¨n Vþ

■ Mục tiêu cụ thể là:

■ Rà soát kỹ thuật chính thức (FTR) là hoạt động bảo đảm 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 .

• Phát hiện các lỗi trong chức năng, trong logic,

trong triển khai (implementation).

Bộ môn CNFM – ĐH Công nghệ

2005

• 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

d. Rà soát kỹ thuật chính thức

NguyÔn V¨n Vþ

■ Mục tiêu cụ thể là (tiếp):

(cid:131) Bảo đảm rằng phần mềm phù hợp với các chuẩn đã

định sẵn.

(cid:131) Đả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)

Bộ môn CNFM – ĐH Công nghệ

2005

(cid:131) Làm cho dự án dễ quản lý hơn (cid:131) 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

e. Tiến trình hoạt động rà soát

NguyÔn V¨n Vþ

Người phát triển

Người thực hiện

rà soát, lập báo cáo

Cá nhân báo cáo sản phẩm cần rà soát

Xem xét, yêu cầu rà soát

sao chép, phân công rà soát

Người quản lý

Họp rà soát, Lập báo cáo

Lập chương trình họp rà soát

Hội đồng rà soát

Bộ môn CNFM – ĐH Công nghệ

2005

e. Các bước tiến hành

NguyÔn V¨n Vþ

■ Cá nhân phát triển thông báo cho lãnh đạo dự án biết

sản phẩm đã hoàn tất và cần 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;

tạo ra các bản sao sản phẩm, phân cho 2,3 người rà soát;

• xem xét sản phẩm để đọc, rà soát • • Thiết lập chương trình họp rà soát

■ người chịu trách nhiệm lãnh đạo rà soát:

■ những thực hiện rà soát: thường tốn 1-2 giờ để rà soát,

Bộ môn CNFM – ĐH Công nghệ

2005

viết các bản ghi chú; tham gia cuộc họp rà soát

f. Cuộc họp rà soát

NguyÔn V¨n Vþ

■ Mọi cuộc họp rà soát phải:

• Có từ 3 đến 5 người liên quan tới việc rà soát. • Phải chuẩn bị trước, tuy nhiên mỗi người không quá

2 giờ chuẩn bị.

• Cuộc họp không 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ể.

Bộ môn CNFM – ĐH Công nghệ

2005

• 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 phần của đặc tả yêu cầu, một thiết kế môđun chi tiết, một danh sách mã nguồn cho 1 môđun)

f. Cuộc họp rà soát

NguyÔn V¨n Vþ

■ Thành phần gồm: lãnh đạo rà soát, tất cả các cá nhân rà

soát và người tạo ra sản phẩm được rà soát.

■ Cuối buổi phải đưa ra 1 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

Bộ môn CNFM – ĐH Công nghệ

2005

■ Mọi thành viên tham gia cuộc họp phải ký vào quyết định

f. Cuộc họp rà soát

NguyÔn V¨n Vþ

■ 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 đó.

■ Văn bản tổng kết họp rà soát phải chỉ rõ:

Bộ môn CNFM – ĐH Công nghệ

2005

• Rà soát cái gì • Ai rà soát • Tìm thấy cái gì? và Kết luận

f. Cuộc họp rà soát

NguyÔn V¨n Vþ

■ Bản danh sách các vấn đề tồn tại phục vụ cho:

• Nhận ra các 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 để chỉ cho các người làm ra sản phẩm cần chỉnh sửa

Bộ môn CNFM – ĐH Công nghệ

2005

• 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ự

g. Phương châm rà soát

NguyÔn V¨n Vþ

■ 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

Bộ môn CNFM – ĐH Công nghệ

2005

chính thức:

g. 10 phương châm rà soát

NguyÔn V¨n Vþ

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 đề cần tranh

luận được 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.

Bộ môn CNFM – ĐH Công nghệ

2005

FTR không giải quyết vấn đề. Giải quyết vấn đề sau FTR và thường do chính người làm sản phẩm thực hiện, có thể nhờ sự trợ giúp của vài cá nhân khác.

g. 10 phương châm rà soát

NguyÔn V¨n Vþ

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

7. Lập một danh sách kiểm tra (checklist) cho từng sản

(cid:131) giúp lãnh đạo rà soát cơ cấu các cuộc họp FTR,

(cid:131) giúp người rà soát tập trung vào các vấn đề quan trọng.

(cid:131) 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 thử và bảo trì.

(cid:131) Một tập thể các đại diện xem lại danh sách này để trình.

Bộ môn CNFM – ĐH Công nghệ

2005

phẩm sẽ được rà soát:

g. 10 phương châm rà soát

NguyÔn V¨n Vþ

8. Cấp phát nguồn lực & thời gian biểu cho các FTR:

(cid:131) là một nhiệm vụ trong quá trình phát triển

(cid:131) 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 tiến hành huấn luyện chính thức cho các cá nhân

rà soát.

Bộ môn CNFM – ĐH Công nghệ

2005

10.Rà soát lại các rà soát trước đây.

h. Sản phẩm cần rà soát

NguyÔn V¨n Vþ

■ Mọi sản phẩm được tao 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

(cid:131) Kỹ nghệ hệ thống (lập KH triển khai) (cid:131) Phân tích, xác định yêu cầu phần mềm (cid:131) Thiết kế phần mềm (cid:131) Kiểm thử phần mềm (cid:131) Bao trì (với sản phẩm đặt hàng) Rà soát bám sát theo sản phẩm của các giai đoạn này

Bộ môn CNFM – ĐH Công nghệ

2005

■ Tiến trình phát triển chung nhất gồm 4 -5 giai đoạn:

i. Danh mục rà soát trong kỹ nghệ hệ thống NguyÔn V¨n Vþ

■ Bảo đảm chất lượng mức này là đánh giá các yêu cầu thẩm duyệt ở mức hệ thống: một cuộc họp lớn gồm các đại diện các đơn vị liên quan.

■ Danh mục rà soát kỹ nghệ hệ thống:

a) Các chức năng chủ yếu đã được xác định đủ & rõ

ràng (không mơ hồ) ?

b) Các giao diện giữa các hệ con của hệ thống đã

được xác định đủ & đúng hay chưa?

c) Các ràng buộc thực thi đã được thiết lập cho toàn

Bộ môn CNFM – ĐH Công nghệ

2005

hệ thống và cho từng phần tử hay chưa?

i.Danh mục rà soát trong kỹ nghệ hệ thống NguyÔn V¨n Vþ

(cid:132) Danh mục rà soát trong kỹ nghệ hệ thống (tiếp): a) Các ràng buộc thiết kế đã được thiết lập cho từng

phần tử hay chưa?

b) Khả năng lựa chọn đã là tốt nhất chưa? c) Giải pháp này có khả thi kỹ thuật không? d) Có sự hoà hợp giữa các phần tử của hệ thống

hay chưa?

e) Cơ chế kiểm chứng & thẩm duyệt đã được thiết

Bộ môn CNFM – ĐH Công nghệ

2005

lập hay chưa?

k. Danh mục rà soát lập kế hoạch

NguyÔn V¨n Vþ

■ Lập kế hoạch dự án phần mềm dựa trên sản phẩm của

• Phạm vi công việc triển khai 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 & kế hoạch khắc phục • Các kế hoạch khác

Bộ môn CNFM – ĐH Công nghệ

2005

kỹ nghệ hệ thống để đưa ra các nội dung chủ yếu:

k. Danh mục rà soát lập kế hoạch(t)

NguyÔn V¨n Vþ

■ Danh mục rà soát cho việc lập kế hoạch dự án

phần mềm bao gồm: a. Phạm vi của phần mềm đã xác định đúng đắn

Bộ môn CNFM – ĐH Công nghệ

2005

chưa? có bị hạn chế hay không? b. Thuật ngữ có trong sáng không? c. 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? • đã sẵn sàng chưa? • cơ sở dự toán giá cả có hợp lý hay không?

k. Danh mục rà soát lập kế hoạch(t)

NguyÔn V¨n Vþ

• dữ liệu năng xuất & chất lượng trước đây có

được sử dụng hay không?

• sự khác biệt của ước lượng đã xử lý chưa?

d. 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

Bộ môn CNFM – ĐH Công nghệ

2005

đã sẵn có hay không?

k. Danh mục rà soát lập kế hoạch

NguyÔn V¨n Vþ

e. Phương án tổ chức và nhân sự hợp lý chưa?

f. 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ý & KH thích hợp chưa?

g. Ngân sách và thời hạn chót dự kiến:

Bộ môn CNFM – ĐH Công nghệ

2005

• có hiện thực hay không? • có phù hợp với lịch biểu không?

4. Rà soát phân tích yêu cầu phần mềm NguyÔn V¨n Vþ

(cid:131) tập trung vào khả năng viết ra các yêu cầu hệ thống (cid:131) sự phù hợp và đúng đắn của mô hình phân tích.

■ Rà soát phân tích yêu cầu phần mềm

(cid:131) các rà soát kỹ thuật chính thức (cid:131) 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

■ Với các hệ thống lớn thì cần tăng cường:

(cid:131) Yêu cầu chức năng (cid:131) Yêu cầu phi chức năng (cid:131) Yêu cầu ngoại lai

Bộ môn CNFM – ĐH Công nghệ

2005

■ Các yêu cầu của hệ thống phần mềm

a. Nhiệm vụ rà soát yêu cầu

NguyÔn V¨n Vþ

(cid:131) Phải chỉ ra các nhu cầu người dùng được thỏa mãn chưa. (cid:131) Các yêu cầu phải nhất quán: không mâu thuẫn nhau. (cid:131) 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.

(cid:131) Các yêu cầu phải hiện thực: có khả năng thực hiện được. (cid:131) Sự tương hợp với mô hình hệ thống và kế hoạch triển khai

■ Nội dung thẩm định yêu cầu phần mềm:

■ Rà soát phân tích yêu cầu là phục vụ việc thẩm định

Bộ môn CNFM – ĐH Công nghệ

2005

và xác minh

a. Danh mục rà soát phân tích yêu cầu

NguyÔn V¨n Vþ

■ Rà soát kỹ thuật chính thức cho khâu phân tích xem

b) Các giao diện trong và ngoài đã thực sự được xác định

chưa?

c) 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?

d) Mô hình dữ liệu đã thực sự phản ánh đầy đủ các đối

tượng dữ liệu, các thuộc tính và các quan hệ?

Bộ môn CNFM – ĐH Công nghệ

2005

xét các chủ đề sau đây: a) Phân hoạch vấn đề (hệ con) có đầy đủ hay không?

a. Danh mục rà soát phân tích yêu cầu (t)

NguyÔn V¨n Vþ

e) Tất cả các yêu cầu có thể lần vết được ở mức hệ thống

không?

f) Đã làm bản mẫu dành cho người sử dụng (khách hàng)

chưa?

g) Có thực hiện được những ràng buộc quy định bởi các phần

tử hệ thống khác hay không?

h) 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?

i) Các chuẩn thẩm định có đầy đủ hay không?

Bộ môn CNFM – ĐH Công nghệ

2005

b. Rà soát thiết kế phần mềm

NguyÔn V¨n Vþ

■ Rà soát kỹ thuật chính thức cho khâu thiết kế tập trung

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

(cid:131)

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ế chính), 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, giao diện cấu trúc DL).

Bộ môn CNFM – ĐH Công nghệ

2005

vào: (cid:131) thiết kế kiến trúc, (cid:131) Thiết kế giao diện (cid:131) thiết kế dữ liệu, (cid:131) thiết kế thủ tục.

b1. Tiến trình thiết kế theo quản lý

NguyÔn V¨n Vþ

Thiết kế sơ bộ

khía cạnh quản lý

Thiết kế chi tiết

thiết kế kiến trúc, hệ con

thiết kế dữ liệu

khía cạnh kỹ thuật

thiết kế giao diện

thiết kế thủ tục

Thiết kế vật lý

Thiết kế lôgic

Tiến trình thiết kế nhìn theo các cách khác nhau

Bộ môn CNFM – ĐH Công nghệ

2005

b2. Tiến trình thiết kế theo kỹ thụật

NguyÔn V¨n Vþ

thiết kế kiến trúc

kiến trúc hệ thống

Đặc tả các yêu cầu

đặc tả trừu tượng

đặc tả phần mềm

đặc tả giao diện

thiết kế giao diện

đặc tả thành phần

thiết kế thành phần

đặc tả cấu trúc dữ liệu

thiết kế cấu trúc dữ liệu

đặc tả thuật toán

thiết kế thuật toán

Bộ môn CNFM – ĐH Công nghệ

2005

b2. Định hướng rà soát thiết kế

NguyÔn V¨n Vþ

Mục tiêu: Hướng đến thiết kế đảm bảo hai yêu cầu:

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

■ Phản ánh đúng các yêu cầu đặc tả

(cid:131) Cấu trúc tốt (phân hoạch, giao diện, mô đun hóa) (cid:131) Thuật toán tốt (ít phức tạp, tốc độ cao, dễ hiểu) (cid:131) Dữ liệu tốt (cấu trúc, biểu diễn) (cid:131) Có thể lần vết được (dẽ hiểu, dễ kiểm tra)

Bộ môn CNFM – ĐH Công nghệ

2005

■ Có chất lượng tốt

b3. Rà soát danh mục thiết kế sơ bộ

NguyÔn V¨n Vþ

a) 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?

b) Có đạt được sự môđun hoá hiệu quả không? c) Các môđun có độc lập chức năng hay không? d) Kiến trúc chương trình có được phân tách cấu

trúc không?

e) Các giao diện đã được xác định cho các môđun

Bộ môn CNFM – ĐH Công nghệ

2005

và các phần tử hệ thống ngoại lai chưa?

b3. Rà soát danh mục thiết kế sơ bộ (t)

NguyÔn V¨n Vþ

f) Cấu trúc dữ liệu có phù hợp với lĩnh vực thông

tin chưa?

g) Cấu trúc dữ liệu có phù hợp với yêu cầu phần

mềm chưa?

h) Khả năng bảo trì đã được xem xét chưa? i) Các nhân tố chất lượng đã được đánh giá rõ

Bộ môn CNFM – ĐH Công nghệ

2005

ràng chưa?

b4. Rà soát danh mục thiết kế toàn bộ(t)

NguyÔn V¨n Vþ

a) 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?

b) Độ phức tạp logic có phải chăng hay không?

c) Giao diện có phù hợp với thiết kế kiến trúc không?

d) Xử lý lỗi đã được đặc tả chưa?

e) Cấu trúc dữ liệu cục bộ có thật sự đã được xác

định?

Bộ môn CNFM – ĐH Công nghệ

2005

f) Nguyên lý lập trình cấu trúc đã xuyên suốt chưa?

. b4. Rà soát danh mục thiết kế toàn bộ(t)

NguyÔn V¨n Vþ

i) Các chi tiết thiết kế đã tuân theo ngôn ngữ thực hiện

chưa?

j) Dùng hệ điều hành hay là dùng các đặc trưng độc lập

ngôn ngữ?

k) Có dùng logic component hoặc logic inverse?

Bộ môn CNFM – ĐH Công nghệ

2005

l) Khả năng bảo trì đã được xét tới chưa?

c. Rà soát kỹ thuật chính thức khâu lập mã NguyÔn V¨n Vþ

■ Mục tiêu: rà soát hướng đến mã nguồn đạt được

(cid:131) Phản ánh đầy đủ, phù hợp với thiết kế (cid:131) Phù hợp với ngôn ngữ sử dụng (chuẩn, cú pháp,

khai báo dữ liệu,..)

Bộ môn CNFM – ĐH Công nghệ

2005

(cid:131) 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 ..)

c. Rà soát kỹ thuật chính thức khâu lập mã NguyÔn V¨n Vþ

■ Danh mục rà soát bao gồm:

a) Thiết kế đã thực sự được dịch thành mã chưa?

b) Có các sai sót chính tả hoặc in ấn nào không?

c) Có thực sự dùng các quy ước ngôn ngữ hay

không?

d) 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ú . . .

Bộ môn CNFM – ĐH Công nghệ

2005

e) Có ghi chú nào không đúng đắn hoặc mơ hồ?

c. Rà soát kỹ thuật chính thức khâu lập mã NguyÔn V¨n Vþ

f) Kiểu dữ liệu và khai báo dữ liệu có chính xác

hay không?

g) Các hằng số vật lý có đúng đắn hay không?

Bộ môn CNFM – ĐH Công nghệ

2005

h) 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 hơn trước hay không?

d. Rà soát kiểm thử phần mềm

NguyÔn V¨n Vþ

■ Để làm đày đủ và hiệu quả cho việc kiểm thử cần phải đá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

(cid:131) Kiểm thử đơn vị (mô đun) (cid:131) Kiểm thử tích hợp (chức năng) (cid:131) Kiểm thử hệ thống (cid:131) Kiểm thử chấp nhận (alpha, beta)

Bộ môn CNFM – ĐH Công nghệ

2005

■ Loại hình kiểm thử:

d1. Nội dung và phương pháp kiểm thử

NguyÔn V¨n Vþ

■ Chiến lược kiểm thử: (cid:131) Từ trên xuống (cid:131) Từ dưới lên (cid:131) Vụ nổ lớn (Big Bang)

(cid:131) Kiểm thử hộp đen (cid:131) Kiểm thử hộp trắng (cid:131) Kiểm thử áp lực (cid:131) Kiểm thử luồn sợi (cho hệ thời gian thực) (cid:131) Sử dụng CASE

Bộ môn CNFM – ĐH Công nghệ

2005

■ Kỹ thuật kiểm thử:

d1. Nội dung và phương pháp kiểm thử(t) NguyÔn V¨n Vþ

1. Giới thiệu chung

(cid:131) Mô tả hệ thống cần kiểm thử (cid:131) Các mục tiêu kiểm thử (cid:131) Phương pháp sử dụng (cid:131) Tài liệu hỗ trợ

2. Kế hoạch

(cid:131) Thời gian, địa điểm (cid:131) Tài liệu kiểm thử: các ca kiểm thử, tiến trình, lịch trình (cid:131) Điều kiện

3. Các yêu cầu: phần cứng, phần mềm, nhân sự 4. Kiểm soát quá trình kiểm thử

Bộ môn CNFM – ĐH Công nghệ

2005

■ Kế hoạch kiểm thử tổng thể:

d1. Danh mục rà soát kế hoạch kiểm thử

NguyÔn V¨n Vþ

Danh mục rà soát kế hoạch kiểm thử phần mềm : a) Các pha kiểm thử chủ yếu có thực sự được xác định

và sắp xếp thứ tự hay chưa?

b) 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ác chức năng chủ yếu có được trình diễn sớm

Bộ môn CNFM – ĐH Công nghệ

2005

không?

d1. Danh mục rà soát kế hoạch kiểm thử

NguyÔn V¨n Vþ

d) Kế hoạch kiểm thử có phù hợp với kế hoạch dự

án tổng thể hay không?

e) Lịch trình kiểm thử có được xác định rõ ràng hay

không?

f) Nguồn lực và công cụ kiểm thử đã được minh

định và đã sẵn sàng hay chưa?

Bộ môn CNFM – ĐH Công nghệ

2005

g) Đã thiết lập cơ chế lưu trữ báo cáo chưa?

d1. Danh mục rà soát kế hoạch kiểm thử

NguyÔn V¨n Vþ

h) Các thiết bị và các tình huống kiểm thử đã được

minh định chưa?

i) Công việc phát triển kiểm thử đã được lập lịch

chưa?

j) Thử nghiệm áp lực cho phần mềm đã được đặc tả

chưa?

k) Cả hai loại kiểm thử hộp trắng và hộp đen đã được

Bộ môn CNFM – ĐH Công nghệ

2005

đặc tả chưa?

d1. Danh mục rà soát kế hoạch kiểm thử .

NguyÔn V¨n Vþ

k) Có phải tất cả các đường logic độc lập đều được

kiểm thử?

l) 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 qủa mong đợi?

m)Việc xử lý sai có được kiểm thử?

Bộ môn CNFM – ĐH Công nghệ

2005

n) Các giá trị biên có được kiểm thử?

. d1. Danh mục rà soát kế hoạch kiểm thử

NguyÔn V¨n Vþ

n) Các yêu cầu thời gian và sự diễn tiến có được

kiểm thử?

o) Các biến thể chấp nhận được của kết quả kiểm

Bộ môn CNFM – ĐH Công nghệ

2005

thử mong đợi đã được đặc tả chưa?

d2. Vấn đề liên quan đến rà soát kiểm thử

NguyÔn V¨n Vþ

■ Ngoài việc rà soát kế hoạch và thủ tục kiểm thử

còn cần rà soát:

(cid:131) các cơ chế dịch vụ cho việc làm phần mềm,

(cid:131) đánh giá tính đầy đủ & hữu hiệu của việc huấn

luyện,

(cid:131) đánh giá chất lượng của các tài liệu kỹ thuật &

cho người sử dụng,

(cid:131) điều tra về sự ứng dụng được & sự sẵn sàng

Bộ môn CNFM – ĐH Công nghệ

2005

của các công cụ phần mềm

e. Danh mục rà soát bảo trì phần mềm

NguyÔn V¨n Vþ

■ Danh mục rà soát cho phát triển phần mềm cũng

như cho bảo trì phần mềm đã được xem xét ở từng phần, ngoài ra cần chú ý thêm:

a) Đã tính đến các hiệu ứng phụ gắn với các thay

đổi chưa?

b) Xem xét yêu cầu thay đổi đã được lập tài liệu, được đánh giá & được chấp thuận hay chưa?

c) Đã báo cáo việc xem xét sự thay đổi cho tất cả

Bộ môn CNFM – ĐH Công nghệ

2005

các bên quan tâm hay chưa?

. e. Danh mục rà soát bảo trì phần mềm

NguyÔn V¨n Vþ

d) Các rà soát kỹ thuật chính thức thích hợp đã

được tiến hành hay chưa?

Bộ môn CNFM – ĐH Công nghệ

2005

e) Mỗi 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 & được thay thế hay chưa?