Bài giảng Đảm bảo chất lượng phần mềm và kiểm thử

§¹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 CAO HỌC ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM VÀ KiỂM THỦ NguyÔn V¨n Vþ Email: vynv@coltech.vnu.vn, mobile: 0912.505.291 Hà nội -2005 2005 Bộ môn CNFM – Đại học Công nghệ 2 NguyÔn V¨n Vþ „ Độ do chất lượng „ Độ tin cậy „ An toàn ™ 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 ™ Ian Sommerville. Software Engineering, Sixth Edition, Addion Wesley, 2001, Phần 4,5 và 6. chương 16,17,19, 21,24,25 ™ E.M.Bennatan, Software Project Management : a practitioner’s approach, McGRAW-HILL Book Company, 2001 Nội dung – Tài liệu 2005 Bộ môn CNFM – Đại học Công nghệ 3 NguyÔn V¨n Vþ ■ Chất lượng phần mềm thường được phát biểu như những đặc trưng định tính: mềm dẻo, dễ bảo trì,.. ■ Không thể đo trực tiếp đặc trưng, mà chỉ có thể đo gián tiếp: đo các thể hiện của chúng. ■ Chỉ đo được một số cái gì đó là thể ra của chất lượng – độ đo của đặc trưng từng mặt chất lượng phần mềm. ■ Ngoài đo đạc cần các hoạt động SQA khác I. Đo chất lượng phần mềm 2005 Bộ môn CNFM – Đại học Công nghệ 4 NguyÔn V¨n Vþ „ Chỉ số chất lượng về cấu trúc thiết kế - DSQI (Design Structured Quanlity Index - IEEE Standard 982.1-1988) „ Thành phần nào tạo thành cấu trúc Hệ thống? „ Các đại lượng nào liên quan đến DSQI ? a. Chỉ số chất lượng cấu trúc: DSQI 2005 Bộ môn CNFM – Đại học Công nghệ 5 NguyÔn V¨n Vþ Hệ thống phần mềm có 2 thành phần chính: „ Chương trình: ■ Các thành phần (môđun) và đặc trưng mỗi loại ■ Mối quan hệ giữa các thành phần „ Dữ liệu: ■ Các file ■ Cấu trúc file ■ Đặc trưng dữ liệu a1. Yếu tố tạo nên cấu trúc 1. Cần chọn những đại lượng nào? 2. Tính như thế nào? 2005 Bộ môn CNFM – Đại học Công nghệ 6 NguyÔn V¨n Vþ Các đại lượng đo được để tính DSQI : ƒ S1 = tổng số các môđun trong kiến trúc chương trình ƒ S2 = số môđun có chức năng phụ thuộc dữ liêu vào: • dữ liệu vào từ nguồn • dữ liệu vào do thủ tục ngoài môđun sinh ra. a3. Các đại lượng đặc trưng thành phần 2005 Bộ môn CNFM – Đại học Công nghệ 7 NguyÔn V¨n Vþ „ Mô tả hai đại lượng: ƒ S1 = tổng số các môđun, ƒ S2 = các môđun phụ thuộc nguồn dữ liệu vào a3. Các đặc trưng cấu trúc thành phần(t) 1 3 2 s2 = 3 2005 Bộ môn CNFM – Đại học Công nghệ 8 NguyÔn V¨n Vþ „ Các đại lượng dùng để tính DSQI (tiếp): ƒ S3 = số các môđun chức năng phụ thuộc vào xử lý trước đó. ƒ S4 = số các môđun với lối vào và lối ra duy nhất (xử lý ngoại lệ không được xem là lối ra bội). a3. Các đặc trưng cấu trúc thành phần(t) 2005 Bộ môn CNFM – Đại học Công nghệ 9 NguyÔn V¨n Vþ „ Mô tả các đại lượng: ƒ S3 = số các môđun phụ thuộc vào xử lý trước đó. ƒ S4 = số các môđun với lối vào và lối ra duy nhất. xử lý xử lý xử lý S3 = 4, s4= 3 a3. Các đặc trưng cấu trúc thành phần(t) 2005 Bộ môn CNFM – Đại học Công nghệ 10 NguyÔn V¨n Vþ „ Các giá trị được dùng để tính DSQI(tiếp): ƒ S5 = tổng số các khoản mục dữ liệu (các đối tượng dữ liệu, các file và tất cả các thuộc tính xác định chúng). ƒ S6 = số các khúc dữ liệu (các bản ghi khác nhau hoặc các đối tượng đơn lẻ). ƒ S7 = số các khoản mục dữ liệu đáng chú ý. a4. Các đặc trưng cấu trúc dữ liệu ======== ======== ==--&&--= ==--&&--= ==--&&--= **--%%--$$== S6=3 2005 Bộ môn CNFM – Đại học Công nghệ 11 NguyÔn V¨n Vþ „ Những giá trị trung gian cần tính: ƒ D1 (cấu trúc chương trình) =1 khi thiết kế kiến trúc dùng chỉ 1 phương pháp nhất định; và =0 khi khác. ƒ D2 ( Độ độc lập dữ liệu của môđun) = 1- (S2/S1). ƒ D3 (Độ độc lập xử lý của môđun) = 1- (S3/S1). ƒ D4 (đặc trưng vào/ra của môđun) = 1- (S4/S1). ƒ D5 (kích cỡ cơ sở dữ liệu) = 1- (S6/S5). ƒ D6 (Độ phân chia cơ sở dữ liệu) = 1- (S7/S5). a5. Các chỉ số chất lượng cấu trúc 2005 Bộ môn CNFM – Đại học Công nghệ 12 NguyÔn V¨n Vþ „ Công thức tính chỉ số SQ của thiết kế: DSQI = Swi.Di , Swi =1 ƒ Cần ghi lại DSQI của các thiết kế thành công trước đây, tính trung bình của chúng ƒ Nếu DSQI lần này xa giá trị trung bình đó thì cần tiếp tục công việc thiết kế và rà soát. a6. Công thức tính DSQI i=1 6 i=1 6 2005 Bộ môn CNFM – Đại học Công nghệ 13 NguyÔn V¨n Vþ „ Lý thuyết của Halstead dùng các chỉ số cơ bản sau để đo khối lượng chương trình- mã nguồn ƒ n1 là số các toán tử (operator) khác nhau có mặt trong chương trình ƒ n2 là số các phép toán cơ bản (operand) khác nhau có mặt trong chương trình ƒ N1 là tổng số lần xuất hiện của các toán tử ƒ N2 là tổng số lần xuất hiện của các phép toán cơ bản b. Khoa học phần mềm của Halstead 2005 Bộ môn CNFM – Đại học Công nghệ 14 NguyÔn V¨n Vþ „ Lý thuyết của Halstead đo các độ đo cơ bản: ƒ Độ dài chương trình N = N1.log2 n1 + N2.log2 n2 ƒ Dung lượng chương trình = N log2 (n1+n2) ƒ Độ tốt về dung lượng chương trình đạt được: Dung lượng tối thiểu của chương trình 2 n2 -------------------------------------------------------------- = ---- x ---- Dung lượng thực tế của chương trình n1 N2 b1. Độ đo về mã nguồn L = luôn nhỏ hơn 1 và Xét đối với một ngôn ngữ cụ thể. Gần 1 là tốt 2005 Bộ môn CNFM – Đại học Công nghệ 15 NguyÔn V¨n Vþ Ngôn ngữ Mức PL1 1,53 ALGOL 68 2,12 FORTRAN 1,14 Assembler 0,88 b2. Sè ®o mức của ng«n ngữ Halsstead cho rằng mỗi ngôn ngữ có một mức ngôn ngữ Nó xác định quy mô trung bình của 1 đơn vị chương trình. Số này chỉ phụ thuộc vào chính ngôn ngữ lập trình. Có người cho rằng nó phụ thuộc cả vào người lập trình nữa. Thực nghiệm đo được như sau: Tính được khối lượng chương trình dựa trên đánh giá số đợn vị chương trình 2005 Bộ môn CNFM – Đại học Công nghệ 16 NguyÔn V¨n Vþ „ McCabe xác định số đo độ phức tạp của chương trình (mã nguồn) dựa trên độ phức tạp chu trình trong đồ thị chương trình của một môđun. ƒ Số chu trình có chu trình lồng nhau (=3) ƒ Số chu trinh nhiều nhất trong một chu trình (=5) „ Người ta cũng dùng các miền phẳng của đồ thị phẳng để biểu diễn đồ thị chương trình c. Số đo độ phức tạp của McCabe 2005 Bộ môn CNFM – Đại học Công nghệ 17 NguyÔn V¨n Vþ „ Chỉ số trưởng thành phần mềm: SMI (Software Mutirity Index) (IEEE Standard 982.1-1988): cho biết tính ổn định của sản phẩm phần mềm được phát triển „ Sự trưởng thành của phần mềm liên quan đến sự phát triển quy mô và tính ổn định liên quan đến sự thay đổi các thành phần cấu trúc của phần mềm theo thời gian „ Đây là độ đo bảo trì d. Chỉ số chất lượng bảo trì: SMI 2005 Bộ môn CNFM – Đại học Công nghệ 18 NguyÔn V¨n Vþ „ Các tham số sử dụng để tính SMI: ƒ T = số các môđun phát hành lần này ƒ Fc = số các môđun có thay đổi trong lần này ƒ Fa = số các môđun được thêm vào trong lần này ƒ Fd = số các môđun của lần phát hành trước bị bỏ đi trong lần này d1. Các đại lượng tham gia SMI 2005 Bộ môn CNFM – Đại học Công nghệ 19 NguyÔn V¨n Vþ „ Chỉ số trưởng thành phần mềm (độ đo bảo trì) được tính như sau: „ Khi SMI gần bằng 1 thì sản phẩm bắt đầu ổn định MT – Fa - Fc - Fd SMI = ------------------------------ MT d2. Công thức tính và ý nghĩa của SMI 2005 Bộ môn CNFM – Đại học Công nghệ 20 NguyÔn V¨n Vþ „ Bảo đảm chất lượng thống kê phản ánh một xu thế ngày càng tăng trong công nghiệp. „ Thế nào là đảm bảo chất lượng dựa trên thống kê? e. Đảm bảo chất lượng thống kê 2005 Bộ môn CNFM – Đại học Công nghệ 21 NguyÔn V¨n Vþ „ Bằng cách thống kê dữ liệu khiếm khuyết phần mềm khi phát triển và tìm cách khử bỏ nó. xxxxxxx sssssss sssnnn ffffffvnvvvv kkkk mmmvvvv iipiuu bbthhjkkk e1. Khái niệm đảm bảo chất lượng thống kê Thu thập & phân loại DL khiểm khuyết Lần vết tìm nguyên nhân Các nguyên nhân nhân Cô lập 20% nguyên nhân Loại bỏ 20% nguyên nhân Cô lập->80% lỗi 20%Nguyên nhân xxxxxxx sssssss sssnnn ffffffvnvvvv kkkk mmmvvvv iipiuu bbthhjkkkNguyên lý Pareto 2005 Bộ môn CNFM – Đại học Công nghệ 22 NguyÔn V¨n Vþ Công việc bao gồm: ƒ Thu thập và phân loại các thông tin về các khiếm khuyết phần mềm. ƒ Lần vết để tìm nguyên nhân ƒ Dùng nguyên lý Pareto cô lập 20% nguyên nhân có thể tương ứng với 80 khiếm khuyết ƒ Tiến hành chỉnh sửa để loại bỏ nguyên nhân của khiếm khuyết e2. Công việc đảm bảo chất lượng thống kê 2005 Bộ môn CNFM – Đại học Công nghệ 23 NguyÔn V¨n Vþ „ Các nguyên nhân gây ra khiếm khuyết có thể là: ƒ Đặc tả không đầy đủ hoặc sai sót (IES). ƒ Hiểu nhầm khi giao tiếp với khách hàng (MCC). ƒ Lệch hướng dự định khi đặc tả (IDS). ƒ Vi phạm các chuẩn lập trình (VPS). ƒ Sai trong biểu diễn dữ liệu (EDR). ƒ Không phù hợp của giao diện môđun (IMI). ƒ Sai trong logic thiết kế (EDL). e3. Các nguyên nhân của khiếm khuyết 2005 Bộ môn CNFM – Đại học Công nghệ 24 NguyÔn V¨n Vþ „ Các nguyên nhân gây ra khiếm khuyết có thể là: ƒ Thử nghiệm sai hoặc không đầy đủ (IET) ƒ Tài liệu viết không đầy đủ hoặc không chính xác (IID) ƒ Sai khi dịch thiết kế sang ngôn ngữ lập trình (PLT) ƒ Giao diện người máy mơ hồ hoặc không phù hợp. (HCI) ƒ Các linh tinh khác (MIS) e3. Các nguyên nhân của khiếm khuyết (t) 2005 Bộ môn CNFM – Đại học Công nghệ 25 NguyÔn V¨n Vþ „ Tính chỉ số khiếm khuyết cho mỗi bước chính trong phát triển phần mềm. „ Các thông tin để tính mức độ khiếm khuyết: ƒ Di = tổng số các khiểm khuyết ƒ Si = số các khiếm khuyết nghiêm trọng ƒ Mi = số các khiếm khuyết vừa phải ƒ Ti = số các khiếm khuyết nhỏ e4. Tham số khiếm khuyết mỗi bước 2005 Bộ môn CNFM – Đại học Công nghệ 26 NguyÔn V¨n Vþ „ Với mỗi bước chính trong phát triển phần mềm cần tính chỉ số pha PIi: Pli = w1.(Si/Di) + w2.(Mi/Di) + w3.(Ti/Di) Trong đó w1, w2, w3 là trọng số tương ứng với các khiếm khuyết nghiêm trọng, vừa phải và nhỏ. Trọng số này ước lượng mức thiệt hại mà loaị đó mang lại e5. Chỉ số khiếm khuyết mỗi bước 2005 Bộ môn CNFM – Đại học Công nghệ 27 NguyÔn V¨n Vþ „ Chỉ số khiếm khuyết tổng hợp tính như sau: DI = (1PI1 + 2PI2 + 3PI3 + . . . + iPIi)/PS Trong đó PS là kích cỡ của sản phẩm (là LOC = số dòng mã, hoặc số tuyên bố thiết kế, hoặc số trang tài liệu) tuỳ theo từng bước Theo công thức: hệ số khiếm khuyết càng về bước sau càng lớn. Tại sao? e6. Chỉ số khuyếm khuyết tổng thể 2005 Bộ môn CNFM – Đại học Công nghệ 28 NguyÔn V¨n Vþ „ Người ta nhận thấy cần phải dùng một cách tiếp cận hình thức hơn trong việc bảo đảm chất lượng phần mềm. Nó sẽ bổ sung cho các hoạt động mô tả ở trên „ Tiếp cận hình thức hóa: đặc tả hình thức cho phép chúng minh tính đúng đắn, kiểm tra lỗi, chuyển tự động đặc tả thành chương trình… „ Nhờ vậy làm tăng chất lượng đáng kể f. Tiếp cận hình thức cho SQA 2005 Bộ môn CNFM – Đại học Công nghệ 29 NguyÔn V¨n Vþ „ Từ cuối thập kỷ 70 Dijkstra và nhiều người khác đã nghiên cứu về tính đúng đắn của chương trình (cho lập trình có cấu trúc) là xét hệ phương trình đệ quy. „ IBM nghiên cứu và sử dụng thành công ngôn ngữ Z để chứng minh tính đúng đắn „ Ngôn ngữ đặc tả hình thức RAISE, với một công cụ tự động chứng minh tính đúng đắn. „ Chứng minh tính đúng đắn để đảm bảo đặc tả tốt: đầy đủ, chính xác, không mâu thuẫn và thực thi được. f1. Chứng minh tính đúng đắn đặc tả 2005 Bộ môn CNFM – Đại học Công nghệ 30 NguyÔn V¨n Vþ Phương pháp hình thức hóa bao gồm: „ Tìm công cụ đặc tả hình thức phần mềm (thường với các công cụ toán học) „ Cho phép chứng minh được tính đúng đắn của đặc tả „ Xây dựng các phép biến đổi để từng bước chuyển đặc tả thành chương trình. „ Chứng minh được các phép biến đổi là đúng đắn: luôn cho đặc tả đúng về hệ thống. f2. Phương pháp hình thức hóa 2005 Bộ môn CNFM – Đại học Công nghệ 31 NguyÔn V¨n Vþ „ Kiểm chứng chương trình một cách hình thức (chứng minh tính đúng đắn) + bảo đảm chất lượng phần mềm thống kê = quá trình phòng sạch (CLEANROOM) „ Phương châm của kỹ thuật này là: phòng khiếm khuyết hơn trừ khiếm khuyết „ Cơ sở lý luận rằng: Nên dành nhiều thời gian cho kiểm chứng chương trình toán học hơn là cho gỡ lỗi. g. Quá trình phòng sạch – CLEAROOM 2005 Bộ môn CNFM – Đại học Công nghệ 32 NguyÔn V¨n Vþ „ Dùng quá trình này thì số khiếm khyết trong mỗi KLOC giảm đáng kể: với các dự án phần mềm có kích cỡ từ 1000 đến 50000 LOC,dùng quá trình phòng sạch đã tìm thấy 90% khiếm khuyết trước khi kiểm thử chương trình lần đầu tiên „ Đến 1992 công nghệ phần mềm phòng sạch vẫn chưa được áp dụng rộng rãi trong công nghiệp. Cần phải có các thay đổi thực chất trong cả quản lý cũng như trong kỹ thuật trước khi áp dụng phương pháp này. g. Quá trình phòng sạch – CLEAROOM(t) 2005 Bộ môn CNFM – Đại học Công nghệ 33 NguyÔn V¨n Vþ A. Khái niệm † Độ tin cậy phần mềm là một nhân tố quan trọng của chất lượng phần mềm. † Độ tin cậy phần mềm được đo trực tiếp & được đánh giá qua các dữ liệu phát triển và các dữ liệu lịch sử. † Độ tin cậy phần mềm được định nghĩa theo thuật ngữ thống kê là “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” II. Độ tin cậy của phần mềm 2005 Bộ môn CNFM – Đại học Công nghệ 34 NguyÔn V¨n Vþ „ “thất bại” được hiểu là việc không thi hành đúng các yêu cầu phần mềm. „ Các thang bậc thất bại: ƒ Mức độ: từ một sự phiền phức đến một thảm hoạ. ƒ Thời gian: Để loại trừ một thất bại có khi chỉ vài giây đến cả tuần, cả tháng. ƒ Hậu quả: loại bớt một thất bại có thể lại sinh ra lỗi khác và kéo theo thất bại khác. a. Khái niệm về độ tin cậy phần mềm 2005 Bộ môn CNFM – Đại học Công nghệ 35 NguyÔn V¨n Vþ †Độ tin cậy của các hệ thống dựa trên máy tính là “thời gian trung bình giữa hai lần thất bại kế tiếp” (MTBF) mà: MTBF = MTTF + MTTR Trong đó: MTTF: thời gian hoạt động liên tục trung bình MTTR: thời gian sửa xong lỗi trung bình b. Độ tin cậy 2005 Bộ môn CNFM – Đại học Công nghệ 36 NguyÔn V¨n Vþ MTTF = (t11+ t21+ … tn1)/n MTTR =(t12+ t22+ … tn2)/n b1. Công thức độ tin cậy t11 t12 t21 t22 t31 t12 t41 t42 t51 t52 … t1 t5t3 t2 t4 Minh họa các lần thất bại xẩy ra (t1, t2, t3, …tn = nhịp độ lỗi, ti1= làm việc , ti2= sửa lỗi ) 2005 Bộ môn CNFM – Đại học Công nghệ 37 NguyÔn V¨n Vþ „ MTBF là hữu ích hơn nhiều so với tỷ số “số khiếm khuyết / KLOC”: vì người dùng cuối chỉ quan tâm tới thất bại họ gặp, không quan tâm tới đếm lỗi. „ Các lỗi trong chương trình không có cùng mức độ (số lỗi chỉ cho một chỉ số nhỏ về độ tin cậy): ƒ Phần lớn lỗi tìm thấy sau khi vận hành 14 tháng, ƒ Rất ít lỗi chỉ được phát hiện sau hàng chục năm, ƒ Các lỗi còn lại với MTBF khoảng 18-24 tháng b2. Ý nghĩa độ tin cậy MTBF 2005 Bộ môn CNFM – Đại học Công nghệ 38 NguyÔn V¨n Vþ „ Độ sẵn sàng phần mềm là xác suất để chương trình vận hành đúng với yêu cầu ở các thời điểm đã định và được tính như sau: MTTF/(MTTF + MTTR) x 100% ƒ Thể hiện tỷ lệ thời gian làm việc trung bình trong tổng thời gian vận hành ƒ Là độ đo gián tiếp về khả năng bảo trì được (số này càng gần 100 là đã bảo trì tốt). c. Độ sẵn sàng 2005 Bộ môn CNFM – Đại học Công nghệ 39 NguyÔn V¨n Vþ „ Độ tin cậy là đặc trưng của toàn hệ thống. Cần xây dựng mô hình dự đoán độ tin cậy. „ Có hai loại mô hình độ tin cậy phần mềm: ƒ Mô hình tiên đoán độ tin cậy như là một hàm của thời gian lịch. ƒ Mô hình tiên đoán độ tin cậy như là một hàm của thời gian xử lý đã trôi qua (thời gian vận hành của CPU). Musa cho rằng loại hai tốt hơn. d. Các mô hình độ tin cậy 2005 Bộ môn CNFM – Đại học Công nghệ 40 NguyÔn V¨n Vþ „ Các mô hình độ tin cậy dựa trên các giả thiết: ƒ Thời gian gỡ lỗi giữa các xuất hiện sai có phân phối mũ với nhịp độ xuất hiện sai, nhịp độ này tỷ lệ thuận với số các lỗi còn lại. ƒ Mỗi lỗi được phát hiện sẽ được loại trừ ngay lập tức và số lỗi còn lại giảm đi 1. ƒ Nhịp độ thất bại giữa các lỗi là không thay đổi. „ Các giả thiết này còn phải bàn: vì một lỗi được loại trừ thì có thể nhiều lỗi khác lại được sinh ra. d1. Các giả thiết mô hình độ tin cậy 2005 Bộ môn CNFM – Đại học Công nghệ 41 NguyÔn V¨n Vþ „ Một lớp khác các mô hình độ tin cậy phần mềm dựa vào các đặc trưng nội tại của 1 chương trình và tính toán số dự đoán các sai tồn tại trong phần mềm. „ Các mô hình này dựa trên các quan hệ định lượng như một hàm của độ đo tính phức tạp, chúng liên kết thiết kế đặc chủng hoặc các thuộc tính hướng mã của chương trình với “một ước lượng số khởi phát các lỗi được tin rằng có trong chương trình đã cho”. d2. Các mô hình độ tin cậy khác 2005 Bộ môn CNFM – Đại học Công nghệ 42 NguyÔn V¨n Vþ „ Các mô hình gieo hạt dùng như một chỉ báo của độ tin cậy phần mềm; hoặc như một độ đo “năng lực phát hiện sai” của một tập hợp các ca thử nghiệm. „ Gieo một cách ngẫu nhiên một số các lỗi (K) hiệu chuẩn (calibration) vào 1 chương trình; sau đó đem kiểm thử (bằng một số ca kiểm thử), tính xác suất tìm được j lỗi trong tập J lỗi xem như tương ứng với xác suất tìm được k lỗi đã gieo trong K lỗi đã nhúng vào chương trình. j/J = k/K (tỷ lệ lỗi đã phát hiện) d3. Mô hình gieo hạt độ tin cậy 2005 Bộ môn CNFM – Đại học Công nghệ 43 NguyÔn V¨n Vþ „ Có các mô hình ngẫu nhiên phức tạp hơn cho độ tin cậy phần mềm. Iannino đã đưa ra một tập hợp các tiêu chuẩn để so sánh và đánh giá chúng: ƒ Độ hiệu lực tiên đoán: khả năng mô hình tiên đoán được tình trạng thất bại trong tương lai dựa trên các dữ liệu thu thập được từ các pha kiểm thử và vận hành. ƒ Năng lực: khả năng mô hình sinh ra dữ liệu sẵn sàng ứng dụng được cho các cố gắng phát triển phần mềm công nghiệp thực dụng. d4. Mô hình độ tin cậy ngẫu nhiên 2005 Bộ môn CNFM – Đại học Công nghệ 44 NguyÔn V¨n Vþ „ Tiêu chuẩn của Iannino: ƒ Chất lượng các giả thiết: tính có vẻ hợp lý của các giả thiết mà cơ sở toán học dựa vào đó và mức độ thấp nhất của mô hình khi các giới hạn của các giả thiết đạt được. ƒ Độ ứng dụng được: mức độ mà mô hình độ tin cậy phần mềm dùng được trong các kiểu và các lĩnh vực ứng dụng phần mềm khác nhau. ƒ Độ đơn giản: mức độ giản dị của việc thu thập dữ liệu cho mô hình, mức độ trực giác của toán học và cách thức và mức độ có thể tự động hoá. e. Tiêu chuẩn các mô hình độ tin cậy 2005 Bộ môn CNFM – Đại học Công nghệ 45 NguyÔn V¨n Vþ „ Nhiều lĩnh vực sử dụng phần mềm (điều khiển lò phản ứng hạt nhân, dẫn đường máy bay, hệ thống vũ khí, quá trình công nghiệp phạm vi rộng . . .) đòi hỏi sự an toàn cao. „ An toàn phần mềm là một hoạt động bảo đảm chất lượng phần mềm tập trung vào việc minh định và đánh giá các mối nguy hiểm tiềm ẩn có thể gây ảnh hưởng phản tác dụng, thậm chí gây ra thất bại toàn hệ thống. III. An toàn phần mềm 2005 Bộ môn CNFM – Đại học Công nghệ 46 NguyÔn V¨n Vþ a. Khái niệm an toàn phần mềm „ Quá trình mô hình hoá và phân tích được thực hiện như một phần của an toàn phần mềm nhằm phát hiện vấn đề. „ Thoạt tiên minh định và đánh giá có phê phán các rủi ro, các mối nguy hiểm tiềm ẩn. „ Sau đó dùng các kỹ thuật phân tích để đánh giá độ nghiêm trọng và xác suất xuất hiện. 2005 Bộ môn CNFM – Đại học Công nghệ 47 NguyÔn V¨n Vþ a. Khái niệm an toàn phần mềm (t) „ Để có hiệu quả, cần phải phân tích phần mềm trong ngữ cảnh của toàn hệ thống. „ Có thể dùng các kỹ thuật phân tích như “phân tích cây lỗi”, logic thời gian thực, mô hình lưới PETRY 2005 Bộ môn CNFM – Đại học Công nghệ 48 NguyÔn V¨n Vþ „ Phân tích cây lỗi: dựng lên một mô hình đồ thị của các tổ hợp tuần tự và song song các sự kiện dẫn đến một sự kiện mạo hiểm hoặc một trạng thái hệ thống mạo hiểm. „ Dùng một cây lỗi phát triển tốt có thể quan sát được hậu quả của một dãy các thất bại liên kết với nhau, xuất hiện trong các thành phần khác nhau của hệ thống. b. Các phương pháp phân tích an toàn 2005 Bộ môn CNFM – Đại học Công nghệ 49 NguyÔn V¨n Vþ „ Dùng Logic thời gian thực xây dựng mô hình hệ thống bằng cách đặc tả các sự kiện và các hành động tương ứng. Mô hình sự kiện – hành động có thể được phân tích bằng cách dùng các toán tử logic để thử nghiệm các quyết đoán an toàn đối với các thành phần của hệ thống và định thời gian cho chúng.. „ Mô hình lưới PETRY có thể dùng để xác định xem lỗi nào là nghiêm trọng nhất. b. Các phương