THUYẾT TRÌNH ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

1. THUYẾT TRÌNH ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

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

3. Chương 24 CRITICAL SYSTEMS VALIDATION SỰ XÁC MINH CỦA HỆ THỐNG CHUẨN ĐOÁN

4. 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ậncá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ậnan toàn

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

6. 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àycần xác định rằng các hoạt động V & V được thực hiện.

7. Chi phí cho sự xác minh • Bởi vì có các hoạt độngliê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.

8. Xác nhận độ tin cậy • Xác nhận độ tin cậyliê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ệmlỗi vì dữ liệu để kiểm tra lỗithườ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.

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

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

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

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

13. 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ôngphả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ặcphụ 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.

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

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

16. Reliability prediction Dự đoán độ tin cậy

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

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

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

20. Reliability prediction

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

22. 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ạncho 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.

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

24. Reliability prediction

25. 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ệcsử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).

26. 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ậydữ 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:

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

28. Reliability prediction

29. Safety assurance Bảo đảm an toàn

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

31. 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ệurõ 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ậnsự 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.

32. 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. Pamaset sl. (Parnas, et al, 1990.) Cho thấy năm loại đánh giá sau phải được bắt buộccho các hệ thống phán đoán an toàn:

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

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

35. Safety arguments Đối số an toàn

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

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

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

41. Process assurance Đảm bảo dự án

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

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

44. Process assurance • Chúng bao gồm: 1. Việc tạo ra một hệ thống gây nguy hiểmvà 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 và giữ nó trong các tài liệu kỹ thuật có liên quan

45. Run-time safety checking Sự kiểm tra an toàn thời gian thực

46. 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ộtkhẳ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.

47. Đá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.

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

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

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