hoa cuong có thì sử dụng – thích thì lao vào

<span class='text_page_counter'>(1)</span><div class='page_container' data-page=1>

<b>Chương 24</b>

<b> XÁC ĐỊNH HỆ THỐNG QUAN TRỌNG</b>

<b> </b>

<b>(Critical Systems Validation)</b>

GVHD: Lê Mậu Long

Nhóm 11: Nguyễn Văn Dũng

Trần Văn Hoài

</div>
<span class='text_page_counter'>(2)</span><div class='page_container' data-page=2>

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ự đố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 tồ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.

</div>
<span class='text_page_counter'>(3)</span><div class='page_container' data-page=3>

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

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

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

</div>
<span class='text_page_counter'>(4)</span><div class='page_container' data-page=4>

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.

</div>
<span class='text_page_counter'>(5)</span><div class='page_container' data-page=5></div>
<span class='text_page_counter'>(6)</span><div class='page_container' data-page=6>

<b>Quá trình xác nhận độ tin cậy</b>

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

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

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

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

thống

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

</div>
<span class='text_page_counter'>(7)</span><div class='page_container' data-page=7>

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

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

</div>
<span class='text_page_counter'>(8)</span><div class='page_container' data-page=8>

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 hồn
tồ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

</div>
<span class='text_page_counter'>(9)</span><div class='page_container' data-page=9>

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 hố 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 hồn tồ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ự đố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ó

</div>
<span class='text_page_counter'>(10)</span><div class='page_container' data-page=10>

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

Cá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ệ

</div>
<span class='text_page_counter'>(11)</span><div class='page_container' data-page=11>

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

<b>Hình </b>
<b>24.2 </b>

</div>
<span class='text_page_counter'>(12)</span><div class='page_container' data-page=12>

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

t1 t2 t3 t4 t5

<b>Hình 24.3 bước </b>

tăng trưởng tin
cậy

Độ
tin
cậy

</div>
<span class='text_page_counter'>(13)</span><div class='page_container' data-page=13>

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

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

</div>
<span class='text_page_counter'>(14)</span><div class='page_container' data-page=14>

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

</div>
<span class='text_page_counter'>(15)</span><div class='page_container' data-page=15>

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
Độ

</div>
<span class='text_page_counter'>(16)</span><div class='page_container' data-page=16>

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

</div>
<span class='text_page_counter'>(17)</span><div class='page_container' data-page=17>

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

</div>
<span class='text_page_counter'>(18)</span><div class='page_container' data-page=18>

24.2 Đảm bảo sự an tồn

Các quy trình bảo đảm an tồ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 .

</div>
<span class='text_page_counter'>(19)</span><div class='page_container' data-page=19>

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

</div>
<span class='text_page_counter'>(20)</span><div class='page_container' data-page=20>

24.2.1 Đối số an tồn

Chứ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 tồ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õ.

</div>
<span class='text_page_counter'>(21)</span><div class='page_container' data-page=21>

Trong một đối số an tồ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 tồ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 tồ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 tồn.

</div>
<span class='text_page_counter'>(22)</span><div class='page_container' data-page=22>

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 tồn đó, trong trường hợp này là currentDose
> maxDose

</div>
<span class='text_page_counter'>(23)</span><div class='page_container' data-page=23></div>
<span class='text_page_counter'>(24)</span><div class='page_container' data-page=24>

<b>Hình 24.7</b>

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

</div>
<span class='text_page_counter'>(25)</span><div class='page_container' data-page=25>

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 tồ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 <b>= 0</b>

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<b> = currentDose</b>

</div>
<span class='text_page_counter'>(26)</span><div class='page_container' data-page=26>

24.2.2 Quy trình đảm bảo

Quy 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 tồn q 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 tồn, đơi khi sẽ khơng u cầu mà loại trừ hành vi hệ thống

</div>
<span class='text_page_counter'>(27)</span><div class='page_container' data-page=27>

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 tồ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 tồn trong suốt q 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 tồn của
các thành phần quan trọng là chính thức xác nhận.

</div>
<span class='text_page_counter'>(28)</span><div class='page_container' data-page=28></div>
<span class='text_page_counter'>(29)</span><div class='page_container' data-page=29>

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út

3. 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 tốn liều insulin mà được phân phối
bởi hệ thống.

</div>
<span class='text_page_counter'>(30)</span><div class='page_container' data-page=30>

Thời gian chạy kiểm tra an toàn

Trong q trình thực hiện chương trình, kiểm tra an tồ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 tồn hay khơng

</div>
<span class='text_page_counter'>(31)</span><div class='page_container' data-page=31></div>
<span class='text_page_counter'>(32)</span><div class='page_container' data-page=32>

24.3 Đánh giá bảo mật

Việ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 q 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 .

</div>
<span class='text_page_counter'>(33)</span><div class='page_container' data-page=33></div>
<span class='text_page_counter'>(34)</span><div class='page_container' data-page=34>

24.4 An toàn và các trường hợp đáng tin cậy

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

</div>
<span class='text_page_counter'>(35)</span><div class='page_container' data-page=35>

Vai trò của một điều chỉnh là để kiểm tra xem một hệ thống hồn

thành là an tồ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.

</div>
<span class='text_page_counter'>(36)</span><div class='page_container' data-page=36>

<b>Thành phần ( Component)</b> <b>Mô tả ( Description)</b>

- Mơ tả hệ thống
- u cầu an tồ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 tồn trừu tượng hóa từ các đặc tả 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 tồ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

tồn

</div>
<span class='text_page_counter'>(37)</span><div class='page_container' data-page=37>

- 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

</div>
<span class='text_page_counter'>(38)</span><div class='page_container' data-page=38>

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ư:

<i>- 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ệ </i>

<i>mà hệ thống đầy đủ các chức năng an toàn cho một ứng dụng nhất định </i>
<i>trong môi trường nhất định</i>

Các tổ chức và nội dung của một trường hợp an toàn phụ thuộc vào
<b>kiểu của hệ thống đó là để được chứng và bối cảnh của nó hoạt động. Hình </b>

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

</div>
<span class='text_page_counter'>(39)</span><div class='page_container' data-page=39></div>
<span class='text_page_counter'>(40)</span><div class='page_container' data-page=40>

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 tồ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 ngồ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 tồ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.

<b>Nghe</b>

<b>Đọc ngữ âm</b>

<b>Yê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á </b>

</div>
<span class='text_page_counter'>(41)</span><div class='page_container' data-page=41>

<b>Bằng chứng (Evidence): An tồn đối số cho máy bơm insulin (hình 24,7)</b>

<b>Bằng chứng (Evidence): Thử nghiệm bộ dữ liệu cho máy bơm insulin</b>

<b>Bằng chứng (Evidence): phân tích tĩnh báo cáo cho phần mềm máy bơm insulin</b>
<b>Đố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 </b>

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 tốn một cách chính xác và
khơng bao giờ vượt q maxDose.

Việc phân tích tĩnh của phần mềm kiểm số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 tồ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.

<b>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 </b>

</div>
<span class='text_page_counter'>(42)</span><div class='page_container' data-page=42></div>
<span class='text_page_counter'>(43)</span><div class='page_container' data-page=43>

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 q trình đáng tin cậy cho hệ thống quan
trọng phát triển an tồn. Q trình nên bao gồm xác định nguy cơ và hoạt
động giám sát

Xá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ống

Trường hợp an tồn thu thập cùng các bằng chứng lập một hệ thống an
tồn

</div>
<span class='text_page_counter'>(44)</span><div class='page_container' data-page=44>

 <b>Exercises</b>

<b>24.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 </b>

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

<b>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 </b>

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.

<b>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 </b>

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.

<b>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 </b>

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?

<b>24.5 Giải thích tại sao hệ thống bảo đảm độ tin cậy khơng bảo đảm an tồn hệ </b>

</div>
<span class='text_page_counter'>(45)</span><div class='page_container' data-page=45>

<b>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 </b>

nhân được thiết kế cho hoạt động an tồ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 sốt cơ chế khóa cửa. Lưu ý rằng
nhà nước an tồ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 tồn. Sửa đổi mã để làm cho nó an tồn.

<b>24.7 Sử dụng đặc tả kỹ thuật cho việc tính tốn liều lượng được đưa ra trong </b>

Chương 10 (Hình 10,11), viết các phương pháp tính tố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.

<b>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 </b>

</div>
<span class='text_page_counter'>(46)</span><div class='page_container' data-page=46>

<b>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 </b>

trường hợp phần mềm an toàn?

<b>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 </b>

phần mềm.

<b>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 </b>

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 q trình xác
nhận là tồ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.

<b>Nghe</b>

<b>Đọc ngữ âm</b>

</div>
<span class='text_page_counter'>(47)</span><div class='page_container' data-page=47>



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

</div>

<!--links-->