Mục tiêu của chương

Chương 24 XÁC ĐỊNH HỆ THỐNG QUAN TRỌNG

(Critical Systems Validation)

GVHD: Lê Mậu Long Nhóm 11: Nguyễn Văn Dũng

Trần Văn Hoài Lưu Văn Minh Tri

Mục tiêu của chương này là để thảo luận xác minh các kỹ thuật được sử dụng trong sự phát triển của hệ thống. Khi bạn đã đọc chương này bạn sẽ :

Hiểu như thế nào về độ tin cậy của một hệ thống phần mềm có thể đo được độ tin cậy, như thế nào là 1 mô hình tăng trưởng và nó có thể được sử dụng để dự đoán một mức độ yêu cầu về độ tin cậy sẽ đạt được.

Hiểu được các nguyên tắc của đối số an toàn và nó được sử dụng như thế nào cùng với nhiều phương pháp khác trong hệ thống đảm bảo sự an toàn.

Hiểu được vấn đề về sự bảo mật cho 1 hệ thống. Các trường hợp lập luận và bằng chứng về hệ thống an toàn.

Mục tiêu của chương

24.1 Xác định độ tin cậy

24.2 Đảm bảo sự an toàn

24.3 Đánh giá độ an toàn

24.4 Sự an toàn và trường hợp tin cậy.

Nội dung của chương(Contents)

Việc xác minh và xác nhận của một hệ thống quan trọng rõ ràng rằng đã có nhiều điểm chung với nhau.V & V là quy trình cần chứng minh rằng hệ thống này đáp ứng các đặc điểm kỹ thuật của nó hay không, và rằng các dịch vụ hệ thống có thực sự hỗ trợ hành động mà khách hàng yêu cầu. Tuy nhiên, với các hệ thống quan trọng cần có trình độ cao về độ tin cậy, thử nghiệm và phân tích thêm là cần thiết để tìm ra bằng chứng cho thấy hệ thống này là đáng tin cậy. Có hai lý do tại sao bạn nên làm điều này:

1. Chi phí của sự thất bại: Các chi phí và hậu quả của sự thất bại của 1 hệ thống quan trọng có khả năng lớn hơn nhiều so với các hệ thống không quan trọng khác. Rũi ro của nó thấp hơn bằng cách chi tiêu nhiều hơn vào hệ thống xác minh và xác nhận. Nó thường là rẻ hơn vì đã tìm và loại bỏ những lỗi trước khi hệ thống được sử dụng.

2. Xác nhận độ tin cậy của hệ thống chính thức để người dùng hiểu rằng hệ thống đáp ứng được yêu cầu của nó. Trong một số trường hợp, có một số điều chỉnh bên ngoài như cơ quan hàng không quốc gia có thể phải xác nhận rằng hệ thống này là an toàn trước khi nó có thể được triển khai. Để có được chứng chỉ này, bạn có thể sẽ phải thiết kế và thu thập bằng chứng về độ tin cậy của hệ thống.

Đối với những lý do này, các chi phí của V & V cho các hệ thống quan trọng thường cao hơn nhiều so với các công đoạn khác của hệ thống.Thường là V & V mất hơn 50% của tổng chi phí phát triển cho các hệ thống phần mềm quan trọng. Chi phí này cần thiết và hợp lý, không thể tránh. Ví dụ, năm 1996 một hệ thống phần mềm tối quan trọng lập trình cho tên lửa Ariane 5 đã thất bại và một số vệ tinh đã bị phá hủy. Các thiệt hại được ước tính hàng trăm triệu đô la. Các cuộc điều tra sau đó phát hiện ra rằng thiếu sót trong hệ thống V & V là một phần trách nhiệm cho thất bại này.

Quá trình xác nhận độ tin cậy

Xác định cấu hình hoạt đồng

Chuẩn bị dữ liệu thử nghiệm

áp dụng thử nghiệm vào hệ

thống

Tính toán quan sát sự tin

cậy

24.1 Xác định độ tin cậyQuá trình đo độ tin cậy của một hệ thống được minh họa trong hình trên. Quá trình này bao gồm bốn giai đoạn:1. Bạn bắt đầu bằng cách nghiên cứu hệ thống hiện có cùng loại để thiết lập một

cấu hình hoạt động. Một hồ sơ hoạt động xác định loại đầu vào hệ thống và khả năng rằng các yếu tố đầu vào sẽ xảy ra trong quá trình sử dụng bình thường.

2. Sau đó bạn xây dựng một tập hợp các dữ liệu thử nghiệm phản ánh thông tin hoạt động. Điều này có nghĩa rằng bạn tạo ra dữ liệu thử nghiệm với các phân bố xác suất tương tự như các dữ liệu thử nghiệm cho các hệ thống mà bạn đã học. Thông thường, bạn sử dụng một bài kiểm tra dữ liệu của máy phát số liệu để hỗ trợ quá trình này.

3. Bạn thử nghiệm hệ thống sử dụng các dữ liệu và đếm số lượng và số lần thất bại xảy ra. Các lần thất bại này cũng được lưu lại. Như đã thảo luận trong Chương 9, các đơn vị thời gian mà bạn chọn phải phù hợp với độ tin cậy số liệu được sử dụng.

4. Sau khi bạn đã quan sát thấy một số ý nghĩa thống kê của thất bại, bạn có thể tính toán độ tin cậy phần mềm và đánh giá ra giá trị thích hợp độ tin cậy của số liệu.

Cách tiếp cận này đôi khi được gọi là kiểm tra thống kê. Mục đích của kiểm tra thống kê là đánh giá độ tin cậy của hệ thống. Điều này trái ngược với kiểm tra lỗi, thảo luận trong chương 23, mà mục đích là để phát hiện lỗi cho hệ thống.Cách tiếp cận khái niệm hấp dẫn để đo lường độ tin cậy là không dễ dàng để áp dụng trong thực tế. Những khó khăn chủ yếu phát sinh là do:

1. Hoạt động thông tin không chắc chắn của các cấu hình hoạt động dựa trên kinh nghiệm với các hệ thống khác có thể không phản ánh sự chính xác của việc sử dụng thực sự của hệ thống.

2. Chi phí dữ liệu thử nghiệm này có thể rất đắt tiền để tạo ra khối lượng lớn dữ liệu cần thiết trong một cấu hình hoạt động, trừ khi quá trình này có thể được hoàn toàn tự động.

3. Thống kê không chắc chắn khi độ tin cậy cao được quy định Bạn có để tạo ra một số ý nghĩa thống kê những thất bại để cho phép đo chính xác độ tin cậy. Khi phần mềm đã được tin cậy, những thất bại tương đối ít xảy ra và rất khó để tạo ra những thất bại mới.

Phát triển một cấu hoạt động chính xác chắc chắn có thể cho một số loại hệ thống, chẳng hạn như các hệ thống viễn thông, có một mẫu chuẩn được sử dụng, tuy nhiên, có nhiều người sử dụng khác nhau, mỗi người có cách để sử dụng hệ thống riêng của họ.Nên người sử dụng khác nhau có thể được hiển thị khác khác nhau về độ tin cậy bởi vì họ sử dụng cùng 1 hệ thống theo những cách khác nhau.

Cách rất tốt để tạo ra các dữ liệu lớn cần thiết để đo lường độ tin cậy là sử dụng một bài kiểm tra dữ liệu của máy phát số liệu có thể được thiết lập để tự động tạo ra các đầu vào phù hợp với sơ đồ hoạt động. Tuy nhiên, nó không phải là có thể tự động hoá sản xuất của tất cả các dữ liệu thử nghiệm cho các hệ thống tương tác vì các đầu vào thường tương tác với kết quả đầu ra của hệ thống. Bộ dữ liệu cho các hệ thống này có thể được tạo ra bằng tay, nhưng với chi phí tương ứng cao hơn. Ngay cả khi hoàn toàn có thể là tự động hóa , viết lệnh cho các chương trình phát dữ liệu thử nghiệm có thể mất một số lượng đáng kể thời gian và chi phí.

Thống kê không chính xác là một vấn đề chung trong đo độ tin cậy của hệ thống. Để đưa ra dự đoán chính xác về độ tin cậy, bạn cần phải làm nhiều hơn là chỉ cần gây ra một lỗi hệ thống duy nhất. Nếu độ tin cậy được quy định rất cao, nó thường không đủ thực tế để tạo ra các lỗi hệ thống và để kiểm tra các thông số kỹ thuật được.

24.1.1 Cấu hình hoạt độngCác hồ sơ hoạt động của phần mềm phản ánh như thế nào nó sẽ được sử dụng như vậy trong thực tế. Khi một hệ thống phần mềm mới thay thế một hệ thống hiện có hoặc hệ thống tự động thì chúng ta có thể dễ dàng để đánh giá được các mô hình của việc sử dụng các phần mềm mới. Nó phải tương ứng với hệ thống cũ, và với một số hổ trợ mang lại từ hệ thống mới.

Thông thường, như vậy cấu hình hoạt động mà các yếu tố đầu vào có xác suất cao nhất được tạo ra rơi vào một số ít các lớp, như được hiển thị ở bên trái của hình 24,2. Có một số lượng rất lớn các lớp mà đầu vào là không chắc chắn nhưng không phải không thể có. Đây là những hiển thị trên bên phải của hình 24,2. Các dấu chấm lửng (...) có nghĩa là thường có nhiều hơn nữa các đầu vào khác được hiển thị.

Hình 24.2 một cấu hình hoạt động

Mô hình chức năng bước tăng trưởng độ tin cậy

t1 t2 t3 t4 t5

Hình 24.3 bước tăng trưởng tin cậy

Độ tin cậy

Thời gian

24.1.2 Dự đoán độ tin cậyTrong quá trình xác thực phần mềm, Người quản lý phải nỗ

lực để chỉ định thử nghiệm hệ thống. Khi thử nghiệm là rất tốn kém, điều quan trọng kết thúc quá trình kiểm tra càng sớm càng tốt. Thử nghiệm 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 các 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. Trong trường hợp này, người quản lý phải đưa ra quyết định khó khăn là phải viết lại các bộ phận của phần mềm hoặc đàm phán lại hợp đồng về dự án.

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

Hiện có nhiều mô hình tăng trưởng độ tin cậy đã được bắt nguồn từ thí nghiệm độ tin cậy trong một số lĩnh vực ứng dụng khác nhau. Ví dụ như (Kan, 2003) đã thảo luận, hầu hết các mô hình này là hàm mũ, với sự gia tăng độ tin cậy và các khuyết tật nhanh chóng đượ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 tầm cao nên ít lỗi hơn và ít được phát hiện và loại bỏ trong giai đoạn cuối của thử nghiệm

Mô hình đơn giản để minh họa khái niệm về tăng trưởng độ tin cậy do Jelinski và Moranda năm 1972. Tăng độ tin cậy liên tục 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 sau đó được tạo ra.

Hình 24.4

t1 t2 t3 t4 t5

Mô hình ngẫu nhiên về bước tăng trưởng độ tin cậy

Thời gian

Cải thiện độ tin cậy

Sửa chữa lổi cho biết thêm lổi mới và giảm độ tin cậy

Độ tin cậy

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) giảm, như trong hình 24,3. Lưu ý rằng các khoảng thời gian trên trục ngang phản ánh thời gian thử nghiệm giữa các phiên bản của hệ thống 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 thời gian gỡ lỗi, và khi bạn thay đổi một chương trình, bạn đôi khi vô tình tạo thêm các lỗi mới vào nó. Không loại trừ khả năng có những lỗi có thể cao hơn được tạo ra. 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 nó.

Mô hình độ tin cậy tăng trưởng cũng giả định rằng tất cả lỗi đóng góp như nhau đối với cùng độ tin cậy và sửa chữa lỗi sẽ cùng tăng trưởng một lượng độ 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 góp phần làm tăng độ tin cậy hơn so với sửa chữa những lỗi mà chỉ thỉnh thoảng mới 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 thử nghiệm, vì vậy độ tin cậy có thể tăng nhiều hơn khi sau đó, ít có thể xảy ra, và lỗi được phát hiện.

Những mô hình sau đó, ví dụ như mô hình được xây dựng bởi Littlewood và Verrall (Littlewood và Verrall 1973) tính đến những vấn đề này bằng việc giới thiệu một phần tử ngẫu nhiên vào trong sự cải tiến tăng trưởng tin cậy được đem lại bởi một phần mềm sửa chữa. Như vậy, mỗi sự sửa chữa không dẫn đến một số lượng bằng nhau (của) sự cải tiến tin cậy nhưng thay đổi phụ thuộc sự ngẫu nhiên trên (Hình 24.4).

Mô hình của Littlewood và Verrall về độ tin cậy cho phép cho sự tăng trưởng tiêu cực khi một phần mềm cần sửa lổi được thêm vào. Nó cũng mô phỏng thực tế giống như lỗi đã được sửa chữa, cải thiện độ tin cậy trung bình mỗi lần sửa chữa. Lý do của điều này là những lỗi có thể xảy ra và có khả năng được phát hiện sớm trong quá trình thử nghiệm. Những sửa chữa đó có đóng góp lớn vào tăng trưởng độ tin cậy.

24.2 Đảm bảo sự an toànCác quy trình bảo đảm an toàn và xác nhận độ tin cậy có mục tiêu khác nhau. Bạn có thể xác định độ tin cậy về số lượng 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. Trong giới hạn của quá trình đo đạc, bạn biết liệu mức độ yêu cầu về độ tin cậy đã đạt được hay chưa. Tuy nhiên, không thể xác định một cách định lượng và do đó không thể đo được khi hệ thống được thử nghiệm.Bởi vậy sự bảo đảm an toàn được quan tâm với việc thiết lập một mức tin cậy trong hệ thống mà có thể thay đổi từ rất thấp đến rất cao . Đây là một vấn đề cho sự phán quyết chuyên nghiệp được dựa vào một phần lớn chứng cớ về hệ thống, môi trường và những quá trình phát triển của nó..Tuy nhiên, một sự định giá như vậy phải được ghi chép lại các bằng chứng hữu hình từ thiết kế hệ thống, những kết quả của hệ thống . Các quy trình V & V cho các hệ thống 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 được mở rộng thử nghiệm để khám phá như nhiều lỗi càng tốt, và khi thích hợp, kiểm tra thống kê có thể được sử dụng để đánh giá độ tin cậy của hệ thống.

Parnas, et al, 1990 cho thấy năm loại đánh giá quan trọng được bắt buộc đối với hệ thống an toàn là:

■ Xem xét lại chính xác các chức năng dự định làm

■ Xem xét để duy trì những cấu trúc dễ hiểu

■ 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 hành vi quy định

■ Xem xét sự phù hợp của code, cấu trúc dữ liệu và giải thuật thiết kế.

Một giả thiết rằng khi 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 là ít hơn đáng kể so với tổng số lỗi có thể tồn tại trong hệ thống. Bảo đảm an toàn có thể tập trung vào các lỗi có nguy thể gây nguy hiểm cao. Nếu chứng minh rằng những lỗi khác rất ít xảy ra , hoặc nếu có các mối nguy hiểm được sữa chữa sẽ hạn chế những lỗi khác sau đó hệ thống này là an toàn

24.2.1 Đối số an toànChứng nhận sự chính xác của chương trình như đã thảo luận trong chương

22, đã được đề xuất như là một kỹ thuật kiểm định phần mềm trong hơn 30 năm. Những chương trình chắc chắn chính thức có thể xây dựng cho các hệ thống nhỏ.Tuy nhiên, những khó khăn thực tế của việc chứng minh rằng một hệ thống đáp ứng chi tiết kỹ thuật của nó là rất lớn đến nỗi ít các tổ chức xem rằng những chứng cứ chính xác đó là chi phí.

Tuy nhiên đối với một số ứng dụng quan trọng nó có thể phát triển để chứng minh chính xác để tăng độ tin cậy rằng hệ thống đáp ứng yêu cầu của mình, đặc biệt điều này dùng trong các trường hợp các chức năng an toàn quan trọng có thể bị cô lập trong một hệ thống khá nhỏ mà có thể hình thức của nó được chỉ rõ.

Mặc dù nó có thể không hiệu quả để phát triển chứng minh chính xác đối với hầu hết các hệ thống, đơn giản là đôi khi có thể phát triển các đối số an toàn là chứng minh rằng chương trình này đáp ứng các nghĩa vụ về an toàn của nó.

Trong một đối số an toàn, nó không cần thiết phải chứng minh rằng chức năng của chương trình là theo quy định. Nó chỉ là cần thiết để chứng minh rằng chương trình không thể dẫn đến một luật lệ không an toàn.

Kỹ thuật hiệu quả nhất để chứng minh sự an toàn của hệ thống là bằng chứng của sự mâu thuẫn.

Bạn bắt đầu giả sử rằng một trạng thái không an toàn được phân tích bởi hệ thống phân tích mối nguy hiểm có thể đạt được bằng cách thực hiện chương trình. Bạn viết một xác nhận để xác định trạng thái không an toàn. Sau đó bạn có hệ thống mã phân tích mã và cho thấy rằng, mọi đường dẫn đến trạng thái đó, điều kiện kết thúc của những đường dẫn này mâu thuẫn với xác nhận trạng thái không an toàn.

Nếu đây là trường hợp, các giả định ban đầu của một trạng thái không an toàn là không đúng. Sau đó nếu bạn thiết lập lại điều này cho các mối nguy hiểm được xác định thì phần mềm đó là an toàn

Ví dụ, xem xét các mã trong hình 24.6, có thể là một phần thực hiện các hệ thống phân phối của insulin.

Phát triển một đối số an toàn cho các mã này liên quan đến việc chứng minh rằng liều lượng insulin không bao giờ lớn hơn mức tối đa được thiết lập cho mỗi bệnh nhân bị đái tháo đường.

Vì vậy, không cần phải chứng mỉnh rằng hệ thống cung cấp liều lượng chính xác, chỉ là nó không cung cấp quá liều cho bệnh nhân.

Để xây dựng các đối số an toàn, bạn cần phải xác định điều kiện trước tiên cho trạng thái không an toàn đó, trong trường hợp này là currentDose > maxDose

Sau đó chứng minh rằng tất cả các chương trình dẫn đến một sự mâu thuẫn của sự khẳng định là không an toàn. Nếu là trường hợp này, điều kiện không an toàn có thể là không đúng. Do đó, hệ thống này là hệ thống an toàn, bạn có thể cấu tạo và trình bày lý lẽ an toàn bằng đồ thị như được cho thấy trong hình 24.7.

Hình 24.6

Hình 24.7

If statement 2 then branch

executed

If statement 2 not executed

CurrentDose = maxDose

If statement 2 else branch executed

CurrentDose = 0

administerInsulin

CurrentDose> = minimumDose and CurrentDose <= maxDose CurrentDose =0 CurrentDose =

maxDose

CurrentDoes> maxDose

OverDoes administered

or

Trong ví dụ này, điều bạn cần quan tâm ngay lập tức là tập có giá trị có thể có của currentDose trước khi điều hành phương pháp insulin được thực thi.Trong các đối số an toàn trong hình 24.7, có 3 đường dẫn chương trình tới việc gọi hàm điều hành phương pháp insulin.

Chúng ta chứng minh rằng liệu lượng insulin được giao không bao giờ vượt quá maxDose. Tất cả các chương trình có thể dẫn đến điều hành insulin được xem là:

1. Không một nhánh nào của if-statement 2 được thực hiện. Điều này chỉ có thể xảy ra nếu currentDose lớn hơn hoặc bằng minimumDose và nhỏ hơn hoặc bằng maxDose.

2. Các chi nhánh sau của if-statement 2 được thực hiện. Trong trường hợp này, việc phân lập currentDose không được thực thi. Do đó điều kiện của bài là currentDose = 0

3. Các nhánh else-if của if-statement 2 được thực thi. Trong trường hợp này, việc phân lập currentDose để maxDose được thực thi. Do đó, điều kiện của bài là maxDose = currentDose

Trong 3 trường hợp này, điều kiện của bài mâu thuẩn với điều kiện không an toàn là liều dùng lớn hơn maxDose, do đó hệ thống này an toàn.

24.2.2 Quy trình đảm bảoQuy trình đảm bảo liên quan đến việc xác định một quá trình tin cậy và

đảm bảo rằng quá trình này theo sau trong một quá trình phát triển hệ thống.Việc sử dụng an toàn quá trình là một cơ chế để giảm cơ hội mà lỗi được

đưa vào hệ thống.1. Tai nạn là sự kiện hiếm hoi trong các hệ thống quan trọng và có thể

không thực tế để mô phỏng chúng trong việc thử nghiệm một hệ thống. Bạn không thể dựa vào thử nghiệm rộng rãi để nhân rộng các điều kiện có thể dẫn đến tai nạn

2. Yêu cầu an toàn, đôi khi sẽ không yêu cầu mà loại trừ hành vi hệ thống không an toàn. Không thể để chứng minh kết luận thông qua hoạt động kiểm tra và xác nhận rằng các yêu cầu khác đã được đáp ứng.

Một chu trình phát triển hệ thống an toàn phát triển làm cho nó rõ ràng rằng sự chú ý phải được thanh toán trong từng giai đoạn của quá trình phần mềm. Điều này có nghĩa là cụ thể hoạt động đảm bảo an toàn phải được bao gồm trong tiến trình. Chúng bao gồm:

- Việc tạo ra một hệ thống gây nguy hiểm, đăng nhập và theo dõi dẫu vết 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.

- 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 dự án.

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

- Việc tạo ra một hệ thống chứng nhận an toàn, theo đó sự an toàn của các thành phần quan trọng là chính thức xác nhận.Sự sử dụng một hệ thống quản lý cấu hình rất chi tiết mà được dùng để theo dõi mọi tài liệu liên quan an toàn và giữ nó trong bước

Yêu cầu thiết kế hệ thống an toàn:1. Hệ thống bao gồm tự kiểm thử phần mềm này sẽ kiểm tra các

cảm biến của hệ thống, đồng hồ và cung cấp insulin của hệ thống.2. Các phần mềm tự kiểm tra được thực hiện một lần mỗi phút3. Trong trường hợp của phần mềm tự kiểm tra phát hiện một lỗi

bất kỳ trong bất kỳ thành phần của hệ thống, một cảnh báo âm thanh được phát hành và bơm hiển thị nên ghi rõ tên của các thành phần

mà lỗi có được phát hiện. Việc phân phối của insulin nên bị đình chỉ4. Hệ thống được kết hợp một hệ thống cho phép ghi đè lên hệ

thống người sử dụng để thay đổi tính toán liều insulin mà được phân phối bởi hệ thống.

5. Số tiền ghi đè lên nên được giới hạn, không được lớn hơn một tập tiền giá trị được thiết lập khi hệ thống được cấu hình bởi nhân viên y tế.

Thời gian chạy kiểm tra an toànTrong quá trình thực hiện chương trình, kiểm tra an toàn có thể được kết hợp như xác nhận để kiểm tra rằng chương trình đang thực hiện có trong hoạt động an toàn hay khôngKhẳng định được xem như là một chú thích. Mã có thể được tạo ra để kiểm tra khẳng định

24.3 Đánh giá bảo mậtViệc đánh giá hệ thống an ninh ngày càng trở nên quan trọng khi ngày càng nhiều hệ thống quan trọng là Internet cho phép và có thể truy cập bất cứ ai kết nối mạng. Có những câu chuyện hàng ngày của cuộc tấn công vào các hệ thống dựa trên Web, các virus thường xuyên được phân phối bằng cách sử dụng giao thức Internet.Tất cả các điều này có nghĩa là các quá trình xác minh và xác nhận cho các hệ thống dựa trên web phải tập trung và đánh giá bảo mật, nơi mà khả năng của hệ thống để chống lại loại hình tấn công được thử nghiệm. Tuy nhiên đánh giá bảo mật là rất khó khăn để thực hiện. Do đó, hệ thống thường được triển khai với lỗ hổng bảo mật mà kẻ tấn công sử dụng để truy cập vào hoặc hư hỏng các hệ thống này .Về cơ bản, lý do bảo mật rất khó đánh giá được rằng các yêu cầu bảo mật, như một số yêu cầu an toàn, sẽ không được yêu cầu. Đó là vì chúng đã xác định những gì không nên xảy ra hơn là chức năng hệ thống hoặc các hành vi cần thiết. Nó thường không thể định nghĩa hành vi này không mong muốn như các ràng buộc đơn giản mà có thể được kiểm tra bởi hệ thống.

24.4 An toàn và các trường hợp đáng tin cậyAn toàn và các trường hợp tin cậy, tài liệu tổng quát hơn, trường hợp tin

cậy được cấu trúc thiết lập ra. Chi tiết lập luận và bằng chứng cho thấy một hệ thống được an toàn hay một cấp độ yêu cầu của tin cậy đã đạt được. Đối với nhiều loại hệ thống quan trọng, việc sản xuất của một trường hợp an toàn là một yêu cầu pháp lý, và các trường hợp phải đáp ứng một số cơ quan chứng nhận trước khi hệ thống có thể được triển khai.

Điều chỉnh được tạo ra bởi chính phủ để đảm bảo rằng ngành công nghiệp tư nhân không lợi nhuận bằng cách không theo tiêu chuẩn quốc gia về an toàn, an ninh, và vv. Có điều trong nhiều ngành công nghiệp khác nhau. Ví dụ, hãng hàng không được quy định bởi cơ quan hàng không quốc gia như FAA (ở Mỹ) và các CAA (tại Anh). Quản lý đường sắt tồn tại để đảm bảo sự an toàn của đường sắt, và điều tiết hạt nhân phải xác nhận sự an toàn của một nhà máy hạt nhân trước khi nó có thể đi trên đường. Trong lĩnh vực ngân hàng, các ngân hàng quốc gia phục vụ như quản lý, thiết lập các thủ tục và thực hành để giảm khả năng gian lận và bảo vệ khách hàng của ngân hàng từ hoạt động rủi ro của ngân hàng. Là hệ thống phần mềm đã trở nên ngày càng quan trọng trong các cơ sở hạ tầng quan trọng của quốc gia, các nhà quản lý đã trở nên ngày càng quan tâm đến an toàn và độ tin cậy các trường hợp cho các hệ thống phần mềm.

Vai trò của một điều chỉnh là để kiểm tra xem một hệ thống hoàn thành là an toàn như thực tế, do đó, họ chủ yếu tham gia khi phát triển một dự án hoàn tất. Tuy nhiên, nhà quản lý và phát triển hiếm khi làm việc trong cô lập, họ giao tiếp với nhóm phát triển để thiết lập những gì đã được bao gồm trong các trường hợp an toàn. Các điều chỉnh và phát triển cùng nhau xem xét quy trình và thủ tục để đảm bảo rằng được ban hành và tài liệu đến sự hài lòng của điều chỉnh.

Tất nhiên, phần mềm tự nó không nguy hiểm. Đó là chỉ khi nó được nhúng vào trong một hệ thống lớn, máy tính hay kỹ thuật xã hội mà sự thất bại phần mềm có thể dẫn đến thất bại của các thiết bị khác hoặc các quá trình có thể gây thương tích hoặc tử vong. Do đó, một trường hợp phần mềm an toàn luôn luôn là một phần trong trường hợp hệ thống an toàn hơn chứng tỏ sự an toàn của hệ thống tổng thể. Khi xây dựng một trường hợp phần mềm an toàn, lỗi phần mềm liên quan đến lỗi hệ thống rộng lớn hơn và chứng minh rằng là một trong hai.

Thành phần ( Component) Mô tả ( Description)

- Mô tả hệ thống

- Yêu cầu an toàn

- Nguy hiểm và phân tích rủi ro  - Thiết kế phân tích 

- Xác minh và xác nhận 

- Xem xét các báo cáo

- Tổng quan về hệ thống và mô tả một thành phần quan trọng của nó- Các yêu cầu an toàn trừu tượng hóa từ các đặc tả yêu cầu hệ thống-Tài liệu mô tả các mối nguy hiểm và rủi ro đã được xác định và các biện pháp thực hiện để giảm nguy cơ

-Một tập hợp các tham số cấu trúc mà biện minh cho lý do tại sao thiết kế này là an toàn

-Một mô tả về các thủ tục V & V được sử dụng và khi nào là thích hợp, kiểm tra các kế hoạch cho hệ thống

- Hồ sơ của tất cả đánh giá thiết kế và an toàn

Hình 24.11 Các thành phần của một trường hợp phần mềm an toàn

- Nhóm nghiên cứu năng lực 

- Quy trình bảo đảm chất lượng  - Thay đổi quy trình quản lý  

- Trường hợp liên quan đến an toàn

-Bằng chứng về thẩm quyền của tất cả các đội tham gia vào việc phát triển hệ thống an toàn, liên quan và xác nhận- Hồ sơ các quy trình đảm bảo chất lượng thực hiện trong quá trình phát triển hệ thống-Hồ sơ của tất cả các thay đổi được đề xuất, hành động và khi nào thích hợp, sự biện hộ của sự an toàn của những thay đổi này- Tài liệu tham khảo cho các trường hợp an toàn khác có thể tác động đến trường hợp an toàn này

Một trường hợp an toàn là một tập hợp các tài liệu đó bao gồm một mô tả của hệ thống, mà đã được chứng nhận, thông tin về các quy trình được sử dụng để phát triển hệ thống và, quan, lập luận hợp lý để chứng minh rằng hệ thống này có thể sẽ là an toàn. Cách ngắn gọn hơn, Đức Giám mục Bloomfield xác định một trường hợp an toàn như:- Căn cứ vào tài liệu mà cung cấp một đối số thuyết phục và hợp lệ mà hệ thống đầy đủ các chức năng an toàn cho một ứng dụng nhất định trong môi trường nhất địnhCác tổ chức và nội dung của một trường hợp an toàn phụ thuộc vào kiểu của hệ thống đó là để được chứng và bối cảnh của nó hoạt động. Hình 24.11 cho thấy một tổ chức có thể cho một trường hợp phần mềm an toàn.

Một thành phần chính của một trường hợp an toàn là một tập hợp các tham số hợp lý cho hệ thống an toàn. Đây có thể là đối số tuyệt đối (sự kiện X sẽ hoặc sẽ không xảy ra) hoặc lập luận xác suất (xác suất của X là sự kiện O.Y); khi kết hợp,chúng cần chứng minh an toàn. Như trong hình 24,12, tham số là một mối quan hệ giữa những gì được cho là trường hợp (một yêu cầu bồi thường) và một cơ thể bằng chứng đã được thu thập.

Thảo luận cơ bản giải thích lý do tại sao các yêu cầu bồi thường (mà thường là một cái gì đó là an toàn) có thể được suy ra từ các bằng chứng sẵn có. Đương nhiên, do đa tính chất của hệ thống, yêu cầu được tổ chức trong hệ thống phân cấp một. Để chứng minh rằng một yêu cầu cao cấp có giá trị, trước tiên bạn phải làm việc thông qua các đối số cho các đơn xin cấp dưới. Hình 24,13 cho thấy một phần của hệ thống phân cấp này yêu cầu bồi thường cho các máy bơm insulin

Là một thiết bị y tế, hệ thống máy bơm insulin có thể có được từ bên ngoài chứng nhận. Ví dụ, ở Anh, các thiết bị y tế Ban giám đốc phải cấp giấy chứng nhận an toàn cho bất kỳ thiết bị y tế được bán trong các đối số Anh khác nhau có thể có được sản xuất để chứng minh sự an toàn của hệ thống này. Ví dụ, tham số sau đây có thể là một phần trong trường hợp an toàn cho các máy bơm insulin.

NgheĐọc ngữ âmYêu cầu (Claim): liều duy nhất tối đa tính bằng bơm insulin sẽ không vượt quá

maxDose.

Bằng chứng (Evidence): An toàn đối số cho máy bơm insulin (hình 24,7)Bằng chứng (Evidence): Thử nghiệm bộ dữ liệu cho máy bơm insulinBằng chứng (Evidence): phân tích tĩnh báo cáo cho phần mềm máy bơm insulinĐối số (Argument): Đối số an toàn được trình bày cho thấy rằng liều lượng tối đa của insulin có thể được tính bằng maxDose.

Trong 400 thử nghiệm, giá trị của liều được tính toán một cách chính xác và không bao giờ vượt quá 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ó dị thường. Nói chung, đó là hợp lý để giả định rằng yêu cầu bồi thường là hợp lý.

Tất nhiên, đây là một lập luận rất đơn giản, và trong một trường hợp thực sự an toàn tài liệu tham khảo chi tiết để chứng cứ sẽ được trình bày. Do tính chất chi tiết của họ, các trường hợp an toàn do đó tài liệu rất dài và phức tạp. công cụ phần mềm khác nhau có sẵn để giúp đỡ xây dựng của họ, và tôi đã bao gồm các liên kết đến những công cụ này trong các trang web của cuốn sách.

Hình 24.13 hệ thống cấp bậc yêu cầu bồi thường trong trường hợp máy bơm insulin an toàn (the claim hierarchy in the insulin pump safety case)

An toàn đối số hoặc chứng minh được một cách để chứng minh rằng một điều kiện độc hại không bao giờ xảy raĐiều quan trọng là phải có một quá trình đáng tin cậy cho hệ thống quan trọng phát triển an toàn. Quá trình nên bao gồm xác định nguy cơ và hoạt động giám sátXác nhận bảo an có thể liên quan đến kinh nghiệm dựa trên phân tích, dựa trên công cụ phân tích hoặc sử dụng các đội ngủ để tấn công hệ thốngTrường hợp an toàn thu thập cùng các bằng chứng lập một hệ thống an toàn

Những điểm chính

Exercises24.1 Làm thế nào bạn mô tả về chứng thực độ tin cậy đặc tả cho một hệ

thống siêu thị mà bạn quy định tại Exercise 9.8. Câu trả lời của bạn nên bao gồm một mô tả của bất kỳ công cụ xác thực rằng: có thể được sử dụng

24.2 Giải thích lý do tại sao thực tế không thể để xác nhận độ tin cậy khi các chi tiết kỹ thuật được thể hiện trong điều khoản của một số rất ít những thất bại trong cuộc đời của một hệ thống tổng.

24.3 Sử dụng các tài liệu là thông tin cơ bản, viết báo cáo cho quản lý (người không có kinh nghiệm trong lĩnh vực này) về việc sử dụng các mô hình tăng trưởng độ tin cậy.

24.4 Một kỹ sư đồng ý để cung cấp một hệ thống phần mềm với các lỗi được khách hàng biết đến ? Có phải vì bất kỳ sự khác biệt nếu khách hàng nói về sự tồn tại của lỗi này trước? Liệu đó là hợp lý để thực hiện yêu cầu về độ tin cậy của phần mềm trong hoàn cảnh như vậy?

24.5 Giải thích tại sao hệ thống bảo đảm độ tin cậy không bảo đảm an toàn hệ thống.

24.6 Các khóa cửa điều khiển cơ chế trong một cơ sở lưu trữ chất thải hạt nhân được thiết kế cho hoạt động an toàn. Nó đảm bảo rằng mục nhập vào kho chỉ được phép khi lá chắn bức xạ được đưa ra hoặc khi mức độ bức xạ trong phòng giảm xuống dưới một số giá trị đã cho (nguy cấp). Đó là: (i) Nếu lá chắn bức xạ điều khiển từ xa được đưa ra trong một căn phòng, cửa ra vào có thể được mở ra bởi một nhà điều hành có thẩm quyền.

(ii) Nếu mức độ bức xạ trong một căn phòng dưới một giá trị quy định, cánh cửa được mở bởi một nhà điều hành có thẩm quyền.

(iii) Một nhà điều hành có thẩm quyền được xác định bởi các đầu vào của một mã số nhập cảnh có thẩm quyền cửa.Các mã java thể hiện trong hình 24,14 kiểm soát cơ chế khóa cửa. Lưu ý rằng nhà nước an toàn là mục đó không được cho phép. Phát triển một đối số an toàn cho thấy rằng mã này là không an toàn. Sửa đổi mã để làm cho nó an toàn.24.7 Sử dụng đặc tả kỹ thuật cho việc tính toán liều lượng được đưa ra trong Chương 10 (Hình 10,11), viết các phương pháp tính toán lnsulin Java như được sử dụng trong hình 24,6. Xây dựng một đối số an toàn thức rằng mã này là an toàn.24.8 Đề nghị làm thế nào bạn sẽ đi về xác thực một hệ thống bảo vệ mật khẩu cho một ứng dụng mà bạn đã phát triển. Giải thích chức năng của bất kỳ công cụ mà bạn nghĩ có thể hữu ích.

24.9 Tại sao nó cần thiết bao gồm chi tiết về thay đổi hệ thống trong một trường hợp phần mềm an toàn?

24.10 Danh sách bốn loại hệ thống sẽ yêu cầu trường hợp hệ thống an toàn phần mềm.

24.11 Giả sử bạn là một phần của một đội mà phát triển phần mềm cho một nhà máy hóa chất, mà thất bại một cách nào đó, gây ra một sự cố ô nhiễm nghiêm trọng. Ông chủ của bạn được phỏng vấn trên truyền hình và nói rằng quá trình xác nhận là toàn diện và rằng không có lỗi trong phần mềm. Cô khẳng định rằng những vấn đề phải là do thủ tục hoạt động kém. Một tờ báo phương pháp bạn cho ý kiến của bạn. Thảo luận làm thế nào bạn nên xử lý như một cuộc phỏng vấn.NgheĐọc ngữ âm

24.12 các đối số là gì và chống lại việc cấp phép của các kỹ sư phần mềm?

Cảm ơn các bạn đã lắng nghe bài thuyết trình của nhóm!