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

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à

chúng được sử dụng như thế nào trong việc xác nhận an toàn

Các chủ đề

Xác nhận độ tin cậy Sự bảo đảm an toàn Sự đánh giá an toàn An toàn và các trường hợp đáng tin cậy

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 : Các chi phí và hậu quả của thất bại là cao vì vậy nó là rẻ

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

Bạn có thể phải thực hiện một trường hợp chính thức cho 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 xác định rằng các hoạt động V & V được thực hiệ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 xử lý bởi hệ thống.

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

Computeobservedreliability

Apply tests tosystem

Prepare testdata set

Identifyoperational

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

Các cấu hình hoạt động có thể không phản ánh chính xác 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

Bạn cần một số thống kê những lỗi để tính toán độ tin cậy 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

...

Number ofinputs

Input 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


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.


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.


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



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.


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 triển độ tin cậy cũng giả định rằng tất cả lỗi góp phần như nhau đối với độ tin cậy.


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



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


Đơ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:


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.


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 là an toàn. Đây là cơ sở của đối số an toàn mà sẽ được thảo luận trong phần tiếp theo.

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.

Nếu chúng ta lập lại điều này cho mọi mạo hiểm, sau đó phần mềm sẽ an toàn.

Process assurance

Đảm bảo dự án

Process assurance

Đây là bước quan trọng cho tất cả các hệ thống phê bình nhưng nó đặc biệt quan trọng cho những hệ thống chuẩn đoán an toàn

Có hai lý do: Những tai nạn rất hiếm có trong những hệ thống và nó phải

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.

Những yêu cầu an toàn đôi khi ‘sẽ không’ an toàn. Không 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

Chúng bao gồm:

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àn5. 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 và giữ nó trong các tài liệu kỹ thuật có liên quan

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 sự an toàn truyền thông giữa những thành phần của hệ thống.

Đánh giá hệ thống bảo mật

Đánh giá hệ thống bảo mật có nhìu điểm chung với đánh giá an toàn của hệ thống.

Nó được thiết kế để chứng minh rằng hệ thống không thể truy cập vào một số khu vực (không an toàn hoặc không được bảo mật) chứ không phải để chứng minh rằng hệ thống không thể làm được những gì.

Tuy nhiên vẫn có một số điểm khác biệt: Vấn đề về mặt an toàn là ngẫu nhiên, vấn đề về

mặt bảo mật là cố chủ ý. Vấn đề về bảo mật thì quá mơ hồ- nhiều hệ thống

đã chịu thiệt hại vì những vấn đề chung đó; vấn đề về an toàn hầu hết liên quan tới các miền ứng dụng.

Chứng nhận bảo mật Xác nhận dựa trên kinh nghiệm xác thực

Hệ thống được xem xét và phân tích đánh giá đối với các loại hình tấn công dựa trên kinh nghiệm có được của bộ phận xác thực.

Xác thực dựa trên công cụ: Các công cụ bảo mật khác nhau như là kiểm tra passwords

thường được sử dụng để phân tích hệ thống trong hoạt động. Tiger teams

Thành lập một đội để phá vỡ bảo mật và xâm nhập vào hệ thống thông qua việc mô phỏng các cuộc tấn công hệ thống

Xác minh chính thức Hệ thống này được xác thực dựa vào một kỹ thuật bảo mật

chính thức.

Security checklist Liệu tất cả file được tạo ra trong chương trình ứng dụng đã có được

lệnh truy cập thích hợp không? Những lệnh không hợp lệ có thể dẫn đến những file được truy cập bởi những người sử dụng không rõ danh tính.

Liệu hệ thống đã tự động giới hạn những phân vùng của người sử dụng sau một trạng thái ngưng hoạt động không? Những vùng không hoạt động (sessions that are left active) có thể cho phép những truy cập trái phép thông qua máy tính không được giám sát.

Nếu hệ thống được viết với một ngôn ngữ lập trình không có sự kiểm tra mảng ràng buộc(array bound checking), thì liệu những trường hợp khi sự tràn bộ nhớ đệm (buffer overflow) có thể tận dụng hay không? Sự tràn bộ nhớ đệm có thể để cho các tác nhân tấn công gửi các chuỗi mã (code string) đến hệ thống và sau đó điều khiển cả hệ thống.

Nếu password đã được cài, liệu hệ thống đã kiểm tra độ bảo mật của password hay chưa? Password bảo mật cao chưa hỗn hợp nhiều ký tự , số và dấu chấm câu, và không phải là các danh mục từ điển bình thường. Việc phá password có độ bảo mật cao đương nhiên sẽ khó hơn so với các password bình thường.

phương thức an toàn và đáng tin cậy

Phương thức an toàn, tổng quát hơn đây là một hệ thống đáng tin cậy được cấu trúc thông qua các tài liệu đặt ra các đối số chi tiết và là bằng chứng cho thấy đó là một hệ thống an toàn hay đủ mức độ tin cậy theo yêu cầu đã thực hiện được

Chúng thường phải đạt được những yêu cầu theo quy định bắt buộc trước khi chúng được chứng nhận cho phép sử dụng.

Trường hợp an toàn của hệ thống Nó thường được áp dụng cho các trường hơp an toàn chính thức,

cái mà tất cả các hệ thống an toàn quan trọng trên máy tinh đã yêu cầu. Ví dụ như: tín hiệu đường sắt hoặc kiểm soát không lưu…

Một trường hợp an toàn là: Một tài liệu nếu có đầy đủ chứng cứ để chứng minh rằng nó đã

cung cấp được các đối số thuyết phục và hợp lệ, để thiết lập 1 hệ thống hoàn toàn an toàn nhằm áp dụng vào một ứng dụng nhất định trong môi trường nhất định.

Sự tranh luận trong trường hợp an toàn hoặc đáng tin cậy có thể dựa trên những bằng chứng cụ thể, thiết kế ban đầu, lập luận an toàn…các yếu tố quy trình cũng có thể được tính đến.

Các thành phần của 1 trường hợp an toànComponent Description

System description An overview of the system and a description of its critical components.

Safety requirements The safety requirements abstracted from the system requirementsspecification.

Hazard and riskanalysis

Documents describing the hazards and risks that have been identifiedand the measures taken to reduce risk.

Design analysis A set of structured arguments that justify why the design is safe.

Verification andvalidation

A description of the V & V procedures used and, where appropriate,the test plans for the system. Results of system V &V.

Review reports Records of all design and safety reviews.

Team competences Evidence of the competence of all of the team involved in safety-related systems development and validation.

Process QA Records of the quality assurance processes carried out during systemdevelopment.

Changemanagementprocesses

Records of all changes proposed, actions taken and, where appropriate,justification of the safety of these changes.

Associated safetycases

References to other safety cases that may impact on this safety case.

Cấu trúc của đối số

EVIDENCE

EVIDENCE

EVIDENCE

<< ARGUMENT >> CLAIM

Đối số của máy bơm Insulin

Yêu cầu: công xuất duy nhất tối đa tính bằng bơm insulin sẽ không vượt quá chỉ số maxDose;

Dẫn chứng: đối số an toàn cho máy bơm insulin;

Dẫn chứng: Thử nghiệm bộ dữ liệu cho máy bơm insulin

Dẫn chứng: phân tích báo cáo phần mềm máy bơm insulin

Lập luận: lập luận an toàn đã trình bày cho ta thấy rằng công xuất tối đa của insulin có thể được tính bằng với chỉ số maxDose,.Trong 400 thử

nghiệm các số liệu của công xuât được tính toán một cách chính xác và không bao giờ vượt quá chỉ số maxDose

Việc phân tích tĩnh của phần mềm kiểm soát cho thấy không có điều gì bất thường. Nói chung, đó là hợp lý khi giả định rằng yêu cầu bồi thường là hợp lý

Hệ thống phân cấp yêu cầu

The maximum singledose computed bythe pump softwarewill not exceedmaxDose

maxDose is set upcorrectly when thepump is configured

maxDose is a safedose for the user ofthe insulin pump

The insulin pumpwill not deliver asingle dose of insulinthat is unsafe

In normaloperation, themaximum dosecomputed will notexceed maxDose

If the software fails,the maximum dosecomputed will notexceed maxDose

Key points Đo lường độ tin cậy dựa vào thực hiện các hệ thống thông qua

sử dụng các cấu hình hoạt động- một mô phỏng các tập input phù hợp với thực tế sử dụng của hệ thống.

Sự đáng tin cậy của mô hình tăng trưởng hiển thị sự thay đổi trong độ tin cậy là lỗi bị loại bỏ từ phần mềm trong quá trình thử nghiệm. Các mô hình đáng tin cậy có thể được sử dụng để dự đoán được độ tin cậy cần thiết sẽ đạt được.

Đối số hoặc bằng chứng của sự an toàn là một sản phẩm hiệu quả bảo đảm an toàn kỹ thuật. Chúng cho thấy một tình trạng nguy hiểm được xác định có thể sẽ không bao giờ xảy ra. Chúng thường đơn giản hơn là đua ra một chương trình đáp ứng đặc điểm kỹ thuật của nó.

Key points

Điều quan trọng là phải có một quy định, quy trình chứng nhận tốt cho sự phát triển các hệ thống bảo vệ. Quá trình phải bao gồm việc xác định và giám sát các mối nguy hiểm tiềm năng.

Các xác nhận về bảo mật có thể được thực hiện bằng cách sử dụng những kinh nghiện phân tích đã có, công cụ phân tích dựa trên “tiger team”, công cụ này mô phỏng các cuộc tấn công vào hệ thống thu thập..

Các phương thức an toàn phải thu thập các bằng chứng để thể hiện rằng hệ thống hoàn toàn an toàn.