Thuyết trình đảm bảo chất lượng phần mềm

Thuyết trình đảm bảo chất lượng phần mềm

THUY T TRÌNH Đ M B O Ế Ả Ả

Thông Tin Nhóm 3

 Diệp Quốc Huy – 070133T

 Trần Nguyễn Minh Cường – 070049T

 Nguyễn Minh Hoàng – 070120T

 Lê Duy – 070069T

Ch ươ ng 24

CRITICAL SYSTEMS VALIDATION

SỰ XÁC MINH CỦA HỆ THỐNG

CHUẨN ĐOÁN

M c tiêu ụ

 Để giải thích làm thế nào để đo độ tin cậy

của hệ thống và độ tin cậy của mô hình mở rộng được sử dụng như thế nào để dự đoán

độ tin cậy

 Để mô tả những đối số an toàn và chúng

được sử dụng như thế nào

 Để thảo luận các vấn đề về bảo đảm an toàn

 Để giới thiệu các trường hợp an toàn và

S xác minh c a h th ng chu n ự ủ ệ ố ẩ

đoán

 Các chi phí thẩm tra, xác nhận cho các hệ thống

phán đoán liên quan đến quá trình xác nhận và phân tích hơn là các hệ thống không chuẩn đoán :

hơn để tìm và loại bỏ những lỗi hơn là trả tiền cho hệ thống khi thất bại

khách hàng hoặc có một điều chỉnh để hệ thống đáp ứng yêu cầu độ tin cậy của nó Trường hợp đáng tin cậy này cần

Chi phí cho s xác minh ự

 Bởi vì có các hoạt động liên quan, các chi phí xác minh cho các hệ thống chuẩn đoán

thường cao hơn nhiều so với các hệ thống

không chuẩn đoán.

 Thông thường, chi phí V & V mất hơn 50%

tổng chi phí phát triển hệ thống.

Xác nh n ậ đ tin c y ộ ậ

 Xác nhận độ tin cậy liên quan đến việc thực hiện các chương trình để đánh giá hay nó đã đạt đến cấp độ yêu cầu về độ tin cậy.

 Điều này không bình thường nó được bao gồm như

là một phần của một quá trình thử nghiệm lỗi vì dữ liệu để kiểm tra lỗi thường không điển hình so với dữ liệu sử dụng thực tế

 Việc đo lường độ tin cậy đòi hỏi một tập hợp dữ liệu thiết kế đặc biệt giúp tạo lại các mô hình đầu vào

Các quá trình đo l ườ đ tin c y ng ộ ậ

Compu te observed reliability

Apply tests to system

Prepare test data set

Identify

operational

profiles

Nh ng ho t đ ng xác minh đ tin ữ ạ ộ ộ

c y ậ

 Thiết lập cấu hình hoạt động cho hệ thống

 Xây dựng dữ liệu thử nghiệm phản ánh cấu hình hoạt động.

 Kiểm tra hệ thống và nhận ra các số lỗi và thời gian để sữa các lỗi đó.

 Tính toán độ tin cậy sau khi thống kê những lỗi đã tìm ra được.

Ki m tra th ng kê ể ố

 Kiểm tra phần mềm với độ tin cậy hơn là

phát hiện lỗi.

 Đo lường số lượng các lỗi để dự đoán được

độ tin cậy của phần mềm Lưu ý rằng, vì lý

do thống kê, có nhiều lỗi được phép có trong việc xác định độ tin cậy.

 Mức độ chấp nhận được về độ tin cậy cần được xác định, và kiểm tra phần mềm phải sửa đổi cho đến khi mà mức độ tin cậy đạt được.

Các v n đ v đo l ấ ề ề ườ ng đ tin c y ộ ậ

 Cấu hình hoạt động không chắc chắn

việc sử dụng thực sự của hệ thống

 Chi phí cao của việc tạo dữ liệu thử nghiệm

 Chi phí có thể rất cao nếu các dữ liệu thử nghiệm cho hệ thống không thể được tạo ra tự động

 Thống kê không chắc chắn

nhưng rất hiếm khi các hệ thống đáng tin cậy sẽ gây ra lỗi.

C u hình ho t đ ng ấ ạ ộ

 Một cấu hình hoạt động là một tập hợp các dữ liệu thử nghiệm có tần số phù hợp với tần số thực tế của các đầu vào từ việc sử dụng hệ thống bình thường Một kết hợp chặt chẽ với sử dụng thực tế là cần thiết nếu không đo độ tin cậy sẽ không phản ánh được

việc sử dụng thực tế của hệ thống

 Nó có thể được tạo ra từ dữ liệu thực tế thu thập

được từ một hệ thống hiện hành hoặc phụ thuộc vào các giả định thực hiện về các mô hình của việc sử dụng hệ thống

M t c u hình ho t đ ng ộ ấ ạ ộ

Nu mber of inpu ts

Inpu t classes

Vi c t o ra c u hình ho t đ ng ệ ạ ấ ạ ộ

 Sẽ được tạo ra tự động mỗi khi có thể

 Việc tạo ra các cấu hình một cách tự động là khó khăn cho các hệ thống tương tác.

 Có thể đơn giản cho việc các đầu vào bình thường nhưng rất khó để dự đoán đầu vào không chắc chắn và để tạo ra dữ liệu thử

nghiệm cho chúng.

Reliability prediction

Dự đoán độ tin cậy

Reliability prediction

 Trong quá trình xác minh phần mềm, quản lý phải ấn định kết quả đạt được của hệ thống kiểm thử Khi

kiểm thử là rất tốn kém, điều quan trọng là phải

ngừng việc kiểm thử ngay khi có thể và không qua kiểm tra hệ thống Kiểm thử có thể dừng lại khi mức

độ tin cậy cần thiết của hệ thống đã đạt được

 Tất nhiên,đôi khi dự báo tin cậy có thể cho thấy rằng mức yêu cầu về độ tin cậy sẽ không bao giờ đạt

được cần thiết, trong trường hợp này, người quản lý phải đưa ra quyết định khó khăn về viết lại các phần của phần mềm hoặc đàm phán lại hợp đồng của hệ thống

Reliability prediction

 Một mô hình phát triển độ tin cậy là một mô hình về cách thay đổi độ tin cậy của hệ thống theo thời gian trong quá trình kiểm thử Khi các lỗi hệ thống được phát hiện, các lỗi tiềm ẩn gây ra những thất bại được sửa chữa để độ tin cậy của hệ thống sẽ được cải

thiện trong thời gian kiểm thử hệ thống và gỡ rối.

 Để dự đoán được độ tin cậy,các khái niệm mô hình phát triển độ tin cậy phải được dịch ra một mô hình toán học.

Reliability prediction

 Hiện có nhiều mô hình phát triển độ tin cậy khác

nhau đã được chuyển hóa từ những thực nghiệm độ tin cậy trong một số lĩnh vực ứng dụng khác nhau Như Kan (Kan 2003) thảo luận, hầu hết các mô hình này là số mũ, với sự gia tăng độ tin cậy nhanh chóng

là những sai sót được phát hiện và loại bỏ (xem hình 24,5).

 Sự gia tăng này sau đó đạt đến một đoạn bằng như

ít lỗi hơn và ít được phát hiện và loại bỏ trong giai

đoạn cuối của kiểm thử.

Reliability prediction

Reliability prediction

 Sự gia tăng này sau đó đạt đến một đoạn bằng như ít lỗi hơn và ít được phát hiện và loại bỏ trong giai đoạn cuối của kiểm thử.

 Mô hình đơn giản để minh họa khái niệm của sự phát

triển độ tin cậy là một mô hình chức năng bước đi

(Jelinski và Moranda 1972) Tăng độ tin cậy của một

liên tục tăng mỗi khi có lỗi (hoặc một tập các lỗi) được phát hiện và sửa chữa (hình 24,3) và một phiên bản mới của phần mềm được tạo ra, mô hình này giả định rằng phần mềm sửa chữa luôn luôn đúng để thực hiện số lỗi phần mềm và thất bại liên quan giảm trong mỗi phiên

bản mới của hệ thống.

Reliability prediction

 Khi sửa chữa được thực hiện, tỷ lệ xuất hiện của lỗi phần mềm (ROCOF) vì thế giảm, như trong hình 24,3 Lưu ý rằng khoảng thời gian trên trục ngang phản ánh thời gian giữa các phiên bản của hệ thống để kiểm thử vì vậy chúng thường có độ dài không bằng nhau

 Tuy nhiên, trong thực tế, lỗi phần mềm không phải luôn luôn cố định trong quá trình gỡ lỗi, và khi bạn thay đổi một chương trình, đôi khi bạn cho vào các lỗi mới vào nó Xác suất xảy ra các lỗi có thể cao hơn xác suất xảy ra các lỗi đã được sửa chữa

 Do đó, độ tin cậy hệ thống đôi khi có thể xấu đi trong một phiên bản mới hơn là cải thiện các bước đơn giản bằng mô hình phát

Reliability prediction

 Tuy nhiên, không phải tất cả lỗi đều có thể xảy ra Sửa chữa các lỗi phổ biến nhất góp phần nhiều hơn để phát triển độ tin cậy

hơn so với không sửa chữa những lỗi mà chỉ thỉnh thoảng xảy

ra Bạn cũng có thể tìm thấy những lỗi có thể xảy ra sớm trong quá trình kiểm thử, vì vậy độ tin cậy có thể tăng nhiều hơn ngay sau đó, ít có thể xảy ra, lỗi được phát hiện

 Các mô hình sau đó, chẳng hạn như được đề xuất bởi

Littlewood và Verrall (Littlewood và Verrall, 1973) lấy những vấn

đề này đưa vào tính toán bằng cách giới thiệu một yếu tố ngẫu nhiên vào việc cải thiện phát triển độ tin cậy thực hiện theo một sửa chữa phần mềm Vì vậy, mỗi sửa chữa không gây ra một số tiền bằng nhau cải thiện độ tin cậy, nhưng thay đổi tùy theo các

lo lắng ngẫu nhiên (hình 24,4)

Reliability prediction

Reliability prediction

 Mô hình độ tin cậy của Littlewood và Verrall cho phép cho sự phát triển tiêu cực khi một việc sửa chữa phần mềm đưa vào thêm lỗi Cũng như vậy mô hình thực tế là những lỗi được sửa chữa, cải thiện trung bình

độ tin cậy, sửa chữa mỗi giảm đi Lý do cho điều này là những lỗi có thể xảy ra nhất là khả năng được phát hiện sớm trong quá trình kiểm

thử.việc sửa chữa những điểu này góp phần lớn vào phát triển độ tin cậy

 Các mô hình trên là mô hình riêng biệt phản ánh sự phát triển gia tăng

độ tin cậy Khi một phiên bản mới của phần mềm với các lỗi sửa chữa được giao để kiểm thử, nó nên ghét một tỷ lệ thấp hơn xảy ra thất bại

so với phiên bản trước đó Tuy nhiên, để dự đoán độ tin cậy rằng sẽ đạt được sau khi một kiểm thử số lượng nhất định, mô hình toán học liên tục là cần thiết Nhiều mô hình bắt nguồn từ lĩnh vực ứng dụng khác nhau, đã được đề xuất và so sánh (Littlewood, 1990)

Reliability prediction

 Đơn giản, bạn có thể dự đoán độ tin cậy bằng cách kết hợp đo

độ tin cậy dữ liệu với một mô hình độ tin cậy được biết đến Sau

đó, ngoại suy các mô hình đến mức yêu cầu về độ tin cậy và

nhận ra khi mức độ yêu cầu về độ tin cậy sẽ đạt được (Hình

24.5)

 Do đó, kiểm tra và gỡ lỗi phải tiếp tục cho đến thời điểm đó Việc

dự đoán độ tin cậy của hệ thống từ một mô hình phát triển độ tin cậy có hai lợi ích chính:

Reliability prediction

 1 Kế hoạch kiểm thử: Với lịch trình kiểm định hiện hành, bạn có thể dự đoán khi nào kiểm thử sẽ được hoàn thành Nếu điều này là sau khi lên kế hoạch ngày giao hàng cho hệ thống sau

đó bạn có thể triển khai nguồn lực bổ sung cho kiểm thử và gỡ rối để đẩy nhanh tốc độ phát triển độ tin cậy

 2 Đàm phán khách hàng: đôi khi mô hình về độ tin cậy cho thấy

mô hình cho sự phát triển của độ tin cậy là rất chậm.Nó có thể

là giá trị đàm phán lại các yêu cầu về độ tin cậy với khách hàng Ngoài ra, nó có thể là mô hình dự đoán rằng độ tin cậy cần thiết

sẽ có lẽ không bao giờ đạt được Trong trường hợp này, bạn sẽ phải đàm phán lại các yêu cầu về độ tin cậy với khách hàng cho

hệ thống

Reliability prediction

Safety assurance

Bảo đảm an toàn

Safety assurance

 Các quy trình bảo đảm an toàn và xác minh độ tin cậy có mục tiêu khác nhau Bạn có thể xác định định lượng độ tin cậy bằng cách sử dụng một số số liệu và sau đó đo được độ tin cậy của hệ thống hoàn thành Trong các giới hạn của quá trình đo lường, bạn biết liệu mức độ yêu cầu về độ tin cậy đã đạt được hay chưa

 Tuy nhiên, an toàn không thể có ý nghĩa xác định một cách định lượng

và do đó không thể được đo khi hệ thống được kiểm thử Đảm bảo an toàn vì thế liên quan đến thiết lập một mức độ tin cậy trong hệ thống có thể khác nhau từ rất ‘thấp' thành ' rất cao’.

 Trong nhiều trường hợp, sự tín nhiệm này một phần là dựa trên kinh nghiệm của tổ chức phát triển hệ thống Nếu một công ty trước đây đã phát triển một số hệ thống điều khiển đã hoạt động một cách an toàn, sau đó nó là hợp lý để giả định rằng họ sẽ tiếp tục phát triển hệ thống

an toàn của dạng này

Safety assurance

 Tuy nhiên, như thế đánh giá phải được sao lưu bởi dấu hiệu rõ ràng từ các thiết kế hệ thống, kết quả của hệ thống V & V và các quá trình phát triển hệ thống đã được sử dụng, Đối với một số

hệ thống, dấu hiệu rõ ràng này là được tập hợp trong một

trường hợp an toàn (xem Phần 24,4) cho phép một bộ điều

chỉnh bên ngoài đi đến một kết luận sự tin cậy của các nhà phát triển vào sự an toàn của hệ thống là hợp lý

 Các quy trình V & V cho các hệ thống phán đoán an toàn có

nhiều điểm chung với các quá trình so sánh của bất kỳ hệ thống khác với yêu cầu độ tin cậy cao Phải mở rộng kiểm thử để tìm thấy như nhiều lỗi càng tốt, và khi thích hợp, thống kê kiểm thử

có thể được sử dụng để đánh giá độ tin cậy của hệ thống

Safety assurance

 Tuy nhiên, do tỷ lệ thất bại cực thấp cần thiết trong nhiều hệ

thống phán đoán an toàn, thống kê thử nghiệm có thể không

phải luôn luôn cung cấp một ước tính định lượng độ tin cậy của

hệ thống Các thử nghiệm đơn giản là cung cấp một số dấu

hiệu, được sử dụng với các dấu hiệu khác như kết quả của

đánh giá và kiểm tra tĩnh (xem Chương 22), để thực hiện một sự đánh giá về sự an toàn hệ thống

 Mở rộng đánh giá là rất cần thiết trong dự án phát triển định

hướng an toàn để ra phần mềm cho những người sẽ xem xét nó

từ những quan điểm khác nhau Pamas et sl (Parnas, et al,

1990.) Cho thấy năm loại đánh giá sau phải được bắt buộc cho các hệ thống phán đoán an toàn:

Safety assurance

 1, Xem xét lại cho đúng chức năng dự định

 2, Xem xét lại cho duy trì được, cấu trúc dễ hiểu

 3, Xem xét lại để xác minh rằng các thuật toán và

thiết kế cấu trúc dữ liệu phù hợp với các cách xử lý xác định

 4, Xem xét lại tính thống nhất của đoạn mã và thuật toán và thiết kế cấu trúc dữ liệu

 5, Xem xét tính đầy đủ trong các trường hợp kiểm tra

hệ thống

Safety assurance

 Một giả thiết rằng nguyên nhân cơ bản làm việc trong

hệ thống an toàn là số lượng các lỗi hệ thống mà có thể dẫn đến mối nguy hiểm an toàn quan trọng là ít

hơn đáng kể so với tổng số lỗi có thể tồn tại trong hệ thống, đảm bảo an toàn có thể tập trung vào các lỗi có tiềm năng gây nguy hiểm

 Nếu nó có thể được chứng minh rằng những lỗi có thể không xảy ra, hoặc, nếu chúng làm, các mối nguy hiểm liên quan sẽ không gây ra tai nạn, sau đó hệ thống này

Safety arguments

Đối số an toàn

Safety arguments

 Những sự chứng minh của tính chính xác chương trình đã được đề xướng như một kỹ thuật thẩm định phần mềm trong hơn 30 năm.

 Những sự chứng minh chương trình có thể chắc

chắn được xây dựng cho những hệ thống nhỏ.

 Tuy nhiên, việc chứng minh hệ thống thì thường gặp phải nhiều khó khăn, vài tổ chức cho rằng những sự chứng minh chính xác thì rất tốn kém.

Safety arguments

 Tuy vậy, phát triển những sự chứng minh

tính chính xác để tăng sự tin cậy cho hệ

thống hay tăng độ an toàn cho hệ thống

 Chức năng phê bình có thể được cô lập

trong một hệ thống mức dưới khá nhỏ mà có thể chỉ rỏ hình thức của nó.

Safety arguments

 Kỹ thuật có hiệu quả nhất để bảo đảm an

toàn cho một hệ thống là việc chứng minh các mâu thuẫn

 Chúng ta bắt đầu bởi việc giả thiết rằng một trạng thái không an toàn, mà được xác định bởi hệ thống phân tích mạo hiểm, có thể có được bởi việc thực thi chương trình.

Process assurance

Đảm bảo dự án

phê bình, không thể mô phỏng thực tế nó trong thời gian testing một hệ thống Bạn không thể tin cậy việc kiểm tra khái quát để phát hiện những điều kiện có thể dẫn tới một tai nạn.

thể nào chứng minh và kết luận trong suốt thời gian kiểm thử và phê chuẩn mà những yêu cầu này đã được gặp.

Process assurance

 Mô hình vòng cho việc phát triển hệ thống

an toàn thì rất quan trọng vì nó làm cho hệ thống rõ ràng hơn.

 Đảm bảo an toàn phải được thực hiện trong

các dự án.

Process assurance

1 Việc tạo ra một hệ thống gây nguy hiểm và theo dõi các dấu

vết của mối nguy hiểm từ phân tích mối nguy hiểm sơ bộ thông qua hệ thống để kiểm tra và xác nhận.

2 Việc bổ nhiệm của các kỹ sư an toàn dự án có trách nhiệm

rõ ràng cho các khía cạnh an toàn của hệ thống

3 Việc sử dụng rộng rãi các đánh giá an toàn trong suốt quá

trình phát triển

4 Việc tạo ra một hệ thống chứng nhận an toàn

5 Việc sử dụng hệ thống quản lý cấu hình chi tiết, được sử

dụng để theo dõi tất cả các tài liệu liên quan đến an toàn

Run-time safety checking

Sự kiểm tra an toàn thời gian thực

Run-time safety checking

 Kiểm tra mã (Checking code) có thể được thêm vào

hệ thống để kiểm tra một ràng buộc an toàn Nó sẽ ném ra một ngoại lệ nếu vi phạm các ràng buộc

 Những ràng buộc an toàn phải được giữ tại những điểm đặc biệt trong một chương trình có thể được thể hiện như một khẳng định

 Chúng được xác định để đảm bảo hành vi an toàn hơn là hành vi phù hợp với đặc điểm kỹ thuật

 Những sự khẳng định có giá trị trong việc đảm bảo