§¹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

Nội dung – Tài liệu

NguyÔn V¨n Vþ

(cid:132) Độ do chất lượng

(cid:132) Độ tin cậy

(cid:132) An toàn

(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 4,5 và 6. chương 16,17,19, 21,24,25

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

approach, McGRAW-HILL Book Company, 2001

2005 Bộ môn CNFM – Đại học Công nghệ 2

I. Đo chất lượng phần mềm

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 chất lượng phần mềm.

■ Chỉ đo được một cái gì đó biểu thị chất lượng phần mềm mà thôi – Đó là các độ đo của đặc trưng từng mặt chất lượng phần mềm.

2005 Bộ môn CNFM – Đại học Công nghệ 3

a. Chỉ số chất lượng cấu trúc: DSQI

NguyÔn V¨n Vþ

(cid:132) Chỉ số chất lượng về cấu trúc thiết kế - DSQI

(Design Structured Quanlity Index - IEEE Standard 982.1-1988)

(cid:132) Các đại lượng được dùng dể tính DSQI :

(cid:131) S1 = tổng số các môđun trong kiến trúc chương trình (cid:131) S2 = số môđun có chức năng phụ thuộc vào:

• nguồn dữ liệu đầu vào • thủ tục sinh ra dữ liệu ở ngoài môđun.

2005 Bộ môn CNFM – Đại học Công nghệ 4

a. Chỉ số chất lượng cấu trúc: DSQI

NguyÔn V¨n Vþ

(cid:132) Mô tả hai đại lượng:

(cid:131) S1 = tổng số các môđun, (cid:131) S2 = các môđun phụ thuộc vào nguồn dữ liệu vào

s2 = 3

2005 Bộ môn CNFM – Đại học Công nghệ 5

a. Chỉ số chất lượng cấu trúc: DSQI

NguyÔn V¨n Vþ

(cid:132) Các đại lượng để tính chỉ số chất lượng cấu trúc

thiết kế (tiếp):

(cid:131) S3 = số các môđun chức năng phụ thuộc vào xử lý

trước đó.

(cid:131) S4 = tổng số các khoản mục dữ liệu (các đối tượng dữ liệu, tất cả các tính chất xác định các đối tượng đó).

(cid:131) S5 = số các khoản mục dữ liệu đáng chú ý.

2005 Bộ môn CNFM – Đại học Công nghệ 6

a. Chỉ số chất lượng cấu trúc: DSQI

NguyÔn V¨n Vþ

(cid:132) Các giá trị được dùng dể tính chỉ số chất lượng cấu

trúc thiết kế (tiếp):

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

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

2005 Bộ môn CNFM – Đại học Công nghệ 7

a. Chỉ số chất lượng cấu trúc: DSQI

NguyÔn V¨n Vþ

(cid:132) Các giá trị để tính chỉ số chất lượng cấu trúc thiết

kế (tiếp)

(cid:131) S3 = số các môđun phụ thuộc vào xử lý trước đó. (cid:131) S7 = 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 = 3, s7= 4

2005 Bộ môn CNFM – Đại học Công nghệ 8

a. Chỉ số chất lượng cấu trúc: DSQI

NguyÔn V¨n Vþ

(cid:132) Những giá trị trung gian cần tính:

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

(cid:131) D2 ( Độ độc lập dữ liệu của môđun) = 1- (S2/S1).

(cid:131) D3 (Độ độc lập xử lý của môđun) = 1- (S3/S1).

(cid:131) D4 (kích cỡ cơ sở dữ liệu) = 1- (S5/S4).

(cid:131) D5 (Độ phân chia cơ sở dữ liệu) = 1- (S6/S4).

(cid:131) D6 (đặc trưng vào/ra của môđun) = 1- (S7/S1).

2005 Bộ môn CNFM – Đại học Công nghệ 9

a. Chỉ số chất lượng cấu trúc: DSQI

NguyÔn V¨n Vþ

(cid:132) Công thức tính chỉ số chất lượng cấu trúc thiết kế:

DSQI = Swi.Di

i Với i chạy từ 1 đến 6 và Swi =1

i

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

(cid:131) Nếu DSQI lần này thấp hơn nhiều so với giá trị trung bình đó thì cần phải tiếp tục công việc thiết kế và rà soát.

2005 Bộ môn CNFM – Đại học Công nghệ 10

b. Chỉ số chất lượng phần mềm: SMI

NguyÔn V¨n Vþ

(cid:132) Chỉ số trưởng thành phần mềm: SMI (Sofware 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

(cid:132) Những tham số cần để tính SMI:

(cid:131)

T = số các môđun phát hành lần này

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

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

2005 Bộ môn CNFM – Đại học Công nghệ 11

b. Chỉ số chất lượng sự ổn định: SMI

NguyÔn V¨n Vþ

(cid:132) Chỉ số trưởng thành phần mềm (SMI) được tính

như sau:

MT – Fa - Fc - Fd

SMI = ------------------------------

MT

(cid:132) Khi SMI gần bằng 1 thì sản phẩm bắt đầu ổn

định

2005 Bộ môn CNFM – Đại học Công nghệ 12

c. Khoa học phần mềm của Halstead NguyÔn V¨n Vþ

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

(cid:131)

(cid:131)

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

(cid:131) N1 là tổng số lần xuất hiện của các toán tử (cid:131) N2 là tổng số lần xuất hiện của các phép toán cơ

bản

2005 Bộ môn CNFM – Đại học Công nghệ 13

c. Khoa học phần mềm của Halstead NguyÔn V¨n Vþ

(cid:132) Lý thuyết của Halstead dùng các số đo cơ

bản sau:

(cid:131) Độ dài chương trình N = N1.log2 n1 + N2.log2 n2 (cid:131) Dung lượng chương trình = N log2 (n1+n2)

Dung lượng tối thiểu của chương trình

2

-------------------------------------------------------------- =

x

----

n2 ----

Dung lượng thực sự của chương trình

n1

N2

2005 Bộ môn CNFM – Đại học Công nghệ 14

c. Khoa học phần mềm của Halstead NguyÔn V¨n Vþ

Halsstead cho rằng mỗi ngôn ngữ có một mức ngôn ngữ l. xác định quy mô trung bình của đơn vị chương trình. Số này chỉ phụ thuộc vào chính ngôn ngữ lập trình, nhiều người xem rằng nó phụ thuộc cả vào người lập trình nữa, thực nghiệm cho hay:

Ngôn ngữ PL1 ALGOL 68 FORTRAN Assembler

Mức 1,53 2,12 1,14 0,88

2005 Bộ môn CNFM – Đại học Công nghệ 15

d. Số đo độ phức tạp của McCabe

NguyÔn V¨n Vþ

(cid:132) McCabe xác định số đo độ phức tạp của

chương trình dựa trên độ phức tạp chu trình trong đồ thị chương trình của một môđun.

(cid:131) Số chu trình có chu trình lồng nhau (3) (cid:131) Số chu trình trong một chu trình (5)

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

2005 Bộ môn CNFM – Đại học Công nghệ 16

e. Đảm bảo chất lượng thống kê

NguyÔn V¨n Vþ

(cid:132) 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. Công việc gồm:

(cid:131) Thu thập và phân loại các thông tin về các khiếm

khuyết phần mềm .

(cid:131) Cố gắng lần vết để tìm nguyên nhân (cid:131) Dùng nguyên lý Pareto cô lập 20% khiếm khuyết (cid:131) Sau khi tìm được nguyên nhân sẽ chỉnh sửa các

nguyên nhân của khiếm khuyết

2005 Bộ môn CNFM – Đại học Công nghệ 17

e. Đảm bảo chất lượng thống kê

NguyÔn V¨n Vþ

(cid:132) Các nguyên nhân gây ra khiếm khuyết có thể là:

(cid:131) Đặc tả không đầy đủ hoặc sai sót (IES). (cid:131) Hiểu nhầm khi giao tiếp với khách hàng (MCC). (cid:131) Lệch hướng dự định khi đặc tả (IDS). (cid:131) Vi phạm các chuẩn lập trình (VPS). (cid:131) Sai trong biểu diễn dữ liệu (EDR). (cid:131) Không phù hợp của giao diện môđun (IMI). (cid:131) Sai trong logic thiết kế (EDL).

2005 Bộ môn CNFM – Đại học Công nghệ 18

e. Đảm bảo chất lượng thống kê (t)

NguyÔn V¨n Vþ

(cid:132) Các nguyên nhân gây ra khiếm khuyết có thể là:

(cid:131) Thử nghiệm sai hoặc không đầy đủ (IET) (cid:131) Tài liệu viết không đầy đủ hoặc không chính xác (IID) (cid:131) Sai khi dịch thiết kế sang ngôn ngữ lập trình (PLT) (cid:131) Giao diện người máy mơ hồ hoặc không phù hợp.

(HCI)

(cid:131) Các linh tinh khác (MIS)

2005 Bộ môn CNFM – Đại học Công nghệ 19

e. Đảm bảo chất lượng thống kê (t)

NguyÔn V¨n Vþ

(cid:132) Người phát triển cần phải tính chỉ số khiếm khuyết cho mỗi bước chính trong phát triển phần mềm.

(cid:132) Các thông tin để tính mức độ khiếm khuyết:

(cid:131) Di = tổng số các khiểm khuyết (cid:131) Si = số các khiếm khuyết nghiêm trọng (cid:131) Mi = số các khiếm khuyết vừa phải (cid:131) Ti = số các khiếm khuyết nhỏ

2005 Bộ môn CNFM – Đại học Công nghệ 20

e. Đảm bảo chất lượng thống kê (t)

NguyÔn V¨n Vþ

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

2005 Bộ môn CNFM – Đại học Công nghệ 21

e. Đảm bảo chất lượng thống kê (t)

NguyÔn V¨n Vþ

(cid:132) Chỉ số khiếm khuyết DI được tính như sau:

DI = (PI1 + 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: các khiếm khuyết càng về sau càng

nhân với hệ số lớn

2005 Bộ môn CNFM – Đại học Công nghệ 22

e. Tiếp cận hình thức cho SQA

NguyÔn V¨n Vþ

(cid:132) 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, cách tiếp cận này sẽ bổ sung cho các hoạt động mô tả ở trên

(cid:132) 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 thành chương trình..làm tăng chất lượn

2005 Bộ môn CNFM – Đại học Công nghệ 23

f. Chứng minh tính đúng đắn (t)

NguyÔn V¨n Vþ

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

(cid:132) IBM đã nghiên cứu và sử dụng thành công ngôn ngữ Z, với sự chứng minh tính đúng đắn nhờ các nhà toán học.

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

2005 Bộ môn CNFM – Đại học Công nghệ 24

g. Quá trình phòng sạch – CLEAROOM NguyÔn V¨n Vþ

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

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

(cid:132) Cơ sởt 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.

2005 Bộ môn CNFM – Đại học Công nghệ 25

g. Quá trình phòng sạch – CLEAROOM NguyÔn V¨n Vþ

(cid:132) 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 đã được từ trước khi thử nghiệm chương trình lần đầu tiên

(cid:132) Đế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.

2005 Bộ môn CNFM – Đại học Công nghệ 26

II. Độ tin cậy của phần mềm

NguyÔn V¨n Vþ

A. Khái niệm

(cid:134) Độ 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.

(cid:134) Độ 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ử.

(cid:134) Độ tin cậy phần mềm được định nghĩa theo thuật ngữ thống kê: “xác suất thao tác không thất bại của 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 đã định rõ”

2005 Bộ môn CNFM – Đại học Công nghệ 27

a. Khái niệm về độ tin cậy phần mềm NguyÔn V¨n Vþ

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

(cid:132) Thất bại vì vậy có nhiều thang bậc:

(cid:131) Mức độ: có khi chỉ là sự phiền phức, có khi là một

thảm hoạ.

(cid:131) Thời gian: Để loại trừ một thất bại có khi chỉ vài giây,

có khi mất cả tuần, cả tháng.

(cid:131) Hậu quả: Khi loại bớt một thất bại thì có thể lại sinh

ra lỗi khác và kéo theo thất bại khác.

2005 Bộ môn CNFM – Đại học Công nghệ 28

a. Độ tin cậy và độ sẵn sàng

NguyÔn V¨n Vþ

(cid:134) Với các hệ thống dựa trên máy tính thì một số đo

đơn giản về độ tin cậy 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 là thời gian hoạt động liên tục trung bình

MTTR là thời gian sửa xong lỗi trung bình

2005 Bộ môn CNFM – Đại học Công nghệ 29

a. Độ tin cậy và độ sẵn sàng

NguyÔn V¨n Vþ

MTTF = (t11+ t21+ … tn1)/n MTTR =(t12+ t22+ … tn2)/n

t1

t5

t3

t31

t41

t42

t51

t52 …

t12

t21

t22

t12

t11

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ệ 30

b. Độ tin cậy MTBF

NguyÔn V¨n Vþ

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

(cid:132) Các lỗi trong chương trình không có cùng mức độ (số

các lỗi chỉ cho một chỉ số nhỏ về độ tin cậy):

(cid:131) Phần lớn lỗi tìm thấy sau khi vận hành 14 tháng, (cid:131) Có rất ít lỗi chỉ được phát hiện sau dăm chục năm, (cid:131) Các lỗi còn lại với MTBF khoảng 18-24 tháng

2005 Bộ môn CNFM – Đại học Công nghệ 31

c. Độ sẵn sàng

NguyÔn V¨n Vþ

(cid:132) Độ 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%

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

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

2005 Bộ môn CNFM – Đại học Công nghệ 32

d. Các mô hình độ tin cậy

NguyÔn V¨n Vþ

(cid:132) Có hai loại mô hình độ tin cậy phần mềm:

(cid:131) Mô hình tiên đoán độ tin cậy như là một hàm

của thời gian lịch.

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

2005 Bộ môn CNFM – Đại học Công nghệ 33

d. Các mô hình độ tin cậy(t)

NguyÔn V¨n Vþ

(cid:132) Các mô hình độ tin cậy dựa trên các giả thiết:

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

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

(cid:131) Nhịp độ thất bại giữa các lỗi là không thay đổi.

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

2005 Bộ môn CNFM – Đại học Công nghệ 34

d. Các mô hình độ tin cậy(t)

NguyÔn V¨n Vþ

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

(cid:132) 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 định số khởi phát các lỗi được tin rằng có trong chương trình đã cho”.

2005 Bộ môn CNFM – Đại học Công nghệ 35

d. Các mô hình độ tin cậy(t)

NguyÔn V¨n Vþ

(cid:132) Các mô hình gieo hạt có thể dùng như một chỉ

báo của độ tin cậy phần mềm; hoặc thực tiễn hơn 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.

(cid:132) Gieo một cách ngẫu nhiên một số các lỗi (K) hiệu chuẩn (calibration) vào một 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

2005 Bộ môn CNFM – Đại học Công nghệ 36

d. Các mô hình độ tin cậy(t)

NguyÔn V¨n Vþ

(cid:132) 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á:

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

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

2005 Bộ môn CNFM – Đại học Công nghệ 37

d. Các mô hình độ tin cậy(t)

NguyÔn V¨n Vþ

(cid:132) Tiêu chuẩn của Iannino:

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

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

(cid:131) Độ đơ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á.

2005 Bộ môn CNFM – Đại học Công nghệ 38

III. An toàn phần mềm

NguyÔn V¨n Vþ

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

(cid:132) 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í là gây ra thất bại của toàn hệ thống.

2005 Bộ môn CNFM – Đại học Công nghệ 39

a. Khái niệm an toàn phần mềm

NguyÔn V¨n Vþ

(cid:132) 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 đề.

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

(cid:132) 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ệ 40

a. Khái niệm an toàn phần mềm

NguyÔn V¨n Vþ

(cid:132) Để 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.

(cid:132) 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ệ 41

b. Các phương pháp phân tích an toàn NguyÔn V¨n Vþ

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

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

2005 Bộ môn CNFM – Đại học Công nghệ 42

b. Các phương pháp phân tích an toàn NguyÔn V¨n Vþ

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

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

2005 Bộ môn CNFM – Đại học Công nghệ 43

b. Các phương pháp phân tích an toàn NguyÔn V¨n Vþ

(cid:132) Sau khi minh định và phân tích các hiểm họa, đặc tả

các yêu cầu liên quan đến an toàn phần mềm.

(cid:132) Đặc tả có thể chứa một danh sách các sự kiện không mong muốn và các đáp ứng của hệ thống. Như vậy vai trò của phần mềm trong việc quản lý các sự kiện không mong muốn là đã được chỉ rõ.

(cid:132) Xem xét các con đường có thể dẫn đến kết quả thất bại; Tìm các gải pháp có thể ngăn ngừa các khả năng xẩy ra

2005 Bộ môn CNFM – Đại học Công nghệ 44

Một cách đảm bảo chất lượng phần mềm

NguyÔn V¨n Vþ

(cid:132) Nhiều nhà quản lý và thực hành không muốn thiết lập các chức năng bảo đảm chất lượng phần mềm do:

(cid:131) Vì phải miễn cưỡng tự tạo ra khoản mục chi. (cid:131) Các nhà thực hành cảm thấy mình đã làm đủ mọi

việc cần làm.

(cid:131) Không ai biết đặt một chức năng đó như thế nào

2005 Bộ môn CNFM – Đại học Công nghệ 45

a. Khảo sát nhu cầu SQA

NguyÔn V¨n Vþ

(cid:132) Mọi tổ chức phát triển phần mềm đều có cơ chế đánh giá

chất lượng.

(cid:132) Ở mức thấp nhất, chất lượng là trách nhiệm của tinh thần cá nhân các kỹ sư, người rà soát, người thử nghiệm ở từng mức thích hợp.

(cid:132) Ở mức cao nhất, một nhóm SQA chuyên môn hoá với

trách nhiệm thiết lập các chuẩn và các thủ tục để đạt được chất lượng phần mềm và có trách nhiệm bảo đảm các chuẩn và thủ tục đó được tuân thủ.

(cid:132) Câu hỏi cho mọi tổ chức là: Ta đang ở đâu?

2005 Bộ môn CNFM – Đại học Công nghệ 46

a. Khảo sát nhu cầu SQA

NguyÔn V¨n Vþ

(cid:132) Trước khi thiết lập các thủ tục bảo đảm chất lượng chính thức, mọi tổ chức phát triển phần mềm nên chấp nhận các thủ tục, phương pháp và các công cụ công nghệ phần mềm.

(cid:132) Bước đầu tiên như một phần cố gắng để tạo ra các thủ tục bảo đảm chất lượng phần mềm là một kiểm toán SQA/SCM

(cid:132) Cái trạng thái hiện thời của SQA và SCM (quản lý cấu

hình phần mềm) được đánh giá qua việc khảo sát ba chủ đề sau.

2005 Bộ môn CNFM – Đại học Công nghệ 47

a. Khảo sát nhu cầu SQA

NguyÔn V¨n Vþ

(cid:132) Kiểm kê các chính sách SQA: chính sách, thủ tục,chuẩn nào đã có trong các pha phát triển?

(cid:132) Đánh giá vai trò của kỹ nghệ phần mềm, bảo đảm chất lượng trong tổ chức hiện tại có quyền lực đến đâu? (cid:132) Đánh giá mối quan hệ SQA: Giao diện chức năng

giữa SQA với các đơn vị khác như là thế nào? với các người thực hiện rà soát kỹ thuật chính thức, quản lý cấu hình và thử nghiệm

2005 Bộ môn CNFM – Đại học Công nghệ 48

a. Khảo sát nhu cầu SQA

NguyÔn V¨n Vþ

(cid:132) Một khi ba câu hỏi trên đã được trả lời thì mức

độ mạnh hay yếu đã được minh định.

(cid:132) Nếu có nhu cầu SQA thì cần phải tiến hành đánh

giá cẩn thận bằng quy tắc bỏ phiếu.

2005 Bộ môn CNFM – Đại học Công nghệ 49

a. Khảo sát nhu cầu SQA

NguyÔn V¨n Vþ

(cid:132) SQA có những lợi ích sau đây:

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

(cid:131) Độ tin cậy cao hơn và do đó khách hàng thoả

mãn hơn

(cid:131) Giảm phí tổn bảo trì

(cid:131) Giảm phí tổn tổng thể toàn bộ vòng đời của

phần mềm

2005 Bộ môn CNFM – Đại học Công nghệ 50

a. Khảo sát nhu cầu SQA

NguyÔn V¨n Vþ

(cid:132) SQA có những vấn đề sau đây:

(cid:131) Khó thiết lập trong một tổ chức nhỏ: khó có nguồn lực để thực hiện các hoạt động cần thiết mà hiện chưa có

(cid:131) Nó biểu thị một thay đổi có tính văn hoá:

nên chẳng bao giờ dễ dàng thực hiện

(cid:131) Nó đòi hỏi tiêu tốn không ít tiền

2005 Bộ môn CNFM – Đại học Công nghệ 51

a. Khảo sát nhu cầu SQA

NguyÔn V¨n Vþ

(cid:132) Nguyên tắc Chi phí: ở mức cơ bản SQA được xem

là hiệu quả về chi phí nếu

C3 > C1 + C2

Ở đây: (cid:131) C3 là chi phí từ các sai do không có SQA (cid:131) C1 là chi phí cho SQA của chương trình (cid:131) C2 là chi phí do các sai không tìm thấy khi chương

trình đã có SQA

2005 Bộ môn CNFM – Đại học Công nghệ 52

b. Lập kế hoạch và chuẩn SQA

NguyÔn V¨n Vþ

(cid:132) ANSI/IEEE STANDARDS 30-1984 và 983-1986

Kế hoạch SQA

(cid:131) Mục đích của kế hoạch (cid:131) Tài liệu tham khảo (cid:131) Quản lý

• Tổ chức • Các nhiệm vụ • Các trách nhiệm

2005 Bộ môn CNFM – Đại học Công nghệ 53

b. Lập kế hoạch và chuẩn SQA

NguyÔn V¨n Vþ

Kế hoạch SQA: (cid:132) Tài liệu

(cid:131) Mục đích (cid:131) Tài liệu công nghệ phần mềm được yêu cầu (cid:131) Các tài liệu khác

(cid:132) Các chuẩn, các luật lệ và các quy ước

(cid:131) Mục đích (cid:131) Các quy ước

2005 Bộ môn CNFM – Đại học Công nghệ 54

b. Lập kế hoạch và chuẩn SQA

NguyÔn V¨n Vþ

(cid:132) Rà soát và kiểm toán

(cid:131) Mục đích (cid:131) Các rà soát

• Rà soát yêu cầu phần mềm • Rà soát thiết kế • Rà soát kiểm chứng và thẩm định • Kiểm toán chức năng • Kiểm toán vật lý • Kiểm toán bên trong quá trinh • Kiểm toán quản lý

2005 Bộ môn CNFM – Đại học Công nghệ 55

b. Lập kế hoạch và chuẩn SQA

NguyÔn V¨n Vþ

(cid:132) Kế hoạch khác SQA

(cid:131) Quản lý cấu hình phần mềm (cid:131) Báo cáo và chỉnh sửa (cid:131) Khống chế mã (cid:131) Khống chế phương tiện (cid:131) Khống chế nhà cung cấp (cid:131) Thu thập, bảo trì và bảo quản các báo cáo

2005 Bộ môn CNFM – Đại học Công nghệ 56

b. Lập kế hoạch và chuẩn SQA

NguyÔn V¨n Vþ

(cid:132) Các chuẩn SQA

công nghệ phần mềm

đánh giá chất lượng phần mềm

chuẩn SQA cho FAA

(cid:131) DOD-STD-2167A: (cid:131) DOD-STD-2168: (cid:131) FAA-STD-018: (cid:131) IEEE Sst. 730-1984: kế hoạch SQA (cid:131) IEEE Sst. 983-1986: lập kế hoạch SQA (cid:131) IEEE Sst. 1028-1988: kiểm toán và rà soát phần mềm (cid:131) IEEE Sst. 1012-1986: kế hoạch kiểm thử và thẩm định phần mềm

2005 Bộ môn CNFM – Đại học Công nghệ 57