Tiêu chuẩn Quốc gia TCVN 11391:2016 EN 50128:2011 Ứng dụng đường sắt - Hệ thống xử lý và thông tin tín hiệu - Phần mềm cho các hệ thống phòng vệ và điều khiển đường sắt

TIÊU CHUẨN QUỐC GIA

TCVN 11391:2016

EN 50128:2011

ỨNG DỤNG ĐƯỜNG SẮT - HỆ THỐNG XỬ LÝ VÀ THÔNG TIN TÍN HIỆU - PHẦN MỀM CHO CÁC HỆ THỐNG PHÒNG VỆ VÀ ĐIỀU KHIỂN ĐƯỜNG SẮT

Railway applications - Communication, signalling and processing systems - Software for railway control and protection systems

MỤC LỤC

1  Phạm vi áp dụng

2  Tài liệu viện dẫn

3  Thuật ngữ, định nghĩa và các từ viết tắt

3.1  Thuật ngữ và định nghĩa

3.2  Từ viết tắt

4  Mục đích, sự phù hợp và mức toàn vẹn về an toàn phần mềm

5  Quản lý và tổ chức phần mềm

5.1  Tổ chức, vai trò và trách nhiệm

5.2  Năng lực cá nhân

5.3  Vấn đề vòng đời và lưu trữ

6  Đảm bảo phần mềm

6.1  Kiểm thử phần mềm

6.2  Thẩm tra phần mềm

6.3  Thẩm định phần mềm

6.4  Đánh giá phần mềm

6.5  Đảm bảo chất lượng phần mềm

6.6  Cải tiến và kiểm soát sự thay đổi

6.7  Các ngôn ngữ và chương trình hỗ trợ

7  Phát triển phần mềm chung

7.1  Vòng đời và tài liệu ghi lại đối với phần mềm chung

7.2  Các yêu cầu phần mềm

7.3  Cấu trúc và thiết kế

7.4  Thiết kế thành phần

7.5  Chạy và kiểm thử thành phần

7.6  Tích hợp

7.7  Kiểm thử tổng thể phần mềm / Thẩm định lần cuối

8  Phát triển các thuật toán hoặc dữ liệu ứng dụng: hệ thống được cấu hình bằng các thuật toán hoặc dữ liệu ứng dụng

8.1  Mục tiêu

8.2  Tài liệu đầu vào

8.3  Tài liệu đầu ra

8.4  Các yêu cầu

9  Triển khai và bảo trì phần mềm

9.1  Triển khai phần mềm

9.2  Bảo trì phần mềm

Phụ lục A  Tiêu chí lựa chọn các kỹ thuật và biện pháp

Phụ lục B  Vai trò và trách nhiệm của các bên liên quan đối với phần mềm chủ chốt

Phụ lục C  Tóm tắt việc kiểm soát các tài liệu

Phụ lục D  Danh mục các kỹ thuật

Lời nói đầu

TCVN 11391:2016 hoàn toàn tương đương với tiêu chuẩn EN 50128:2011

TCVN 11391: 2016 do Cục Đăng kiểm Việt Nam biên soạn, Bộ Giao thông vận tải đề nghị, Tổng cục Tiêu chuẩn - Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.

ỨNG DỤNG ĐƯỜNG SẮT - HỆ THỐNG XỬ LÝ VÀ THÔNG TIN TÍN HIỆU - PHẦN MỀM CHO CÁC HỆ THỐNG PHÒNG VỆ VÀ ĐIỀU KHIỂN ĐƯỜNG SẮT

Railway applications - Communication, signalling and processing systems - Software for railway control and protection systems

1  Phạm vi áp dụng

1.1  Tiêu chuẩn này quy định các yêu cầu về quá trình và kỹ thuật đối với việc phát triển phần mềm cho các hệ thống điện tử có thể lập trình sử dụng trong các ứng dụng điều khiển và phòng vệ đường sắt. Mục đích là để sử dụng trong tất cả các lĩnh vực có khả năng liên quan tới an toàn. Những hệ thống này có thể hoạt động sử dụng các bộ vi xử lý chuyên dụng, bộ điều khiển logic có thể lập trình, các hệ thống đa xử lý phân tán, các hệ thống xử lý trung tâm quy mô lớn hoặc các cấu trúc khác.

1.2  Tiêu chuẩn này có thể áp dụng riêng cho phần mềm và sự tương tác giữa phần mềm và hệ thống chứa phần mềm đó.

1.3  Tiêu chuẩn này không liên quan tới phần mềm được xác định là không ảnh hưởng tới an toàn, ví dụ: phần mềm có các hư hỏng không thể ảnh hưởng tới bất kì các chức năng an toàn nào đã được xác định.

1.4  Tiêu chuẩn này áp dụng cho tất cả các phần mềm liên quan tới an toàn được sử dụng trong các hệ thống điều khiển và phòng vệ đường sắt, bao gồm:

- Lập trình ứng dụng;

- Các hệ điều hành;

- Các chương trình hỗ trợ;

- Chương trình cơ sở điều khiển thiết bị.

Việc lập trình ứng dụng bao gồm lập trình cấp cao, lập trình cấp thấp và lập trình cho mục đích đặc biệt (ví dụ: bộ lập trình điều khiển ngôn ngữ bậc thang).

1.5  Tiêu chuẩn này cũng đề cập tới việc sử dụng các chương trình và phần mềm hiện có. Những phần mềm này có thể được sử dụng nếu đáp ứng đầy đủ các yêu cầu cụ thể trong mục 7.3.4.7 và 6.5.4.16 đối với phần mềm và chương trình hiện có trong mục 6.7.

1.6  Phần mềm được xây dựng theo tiêu chuẩn này sẽ được xem là phù hợp và không phụ thuộc vào các yêu cầu của phần mềm hiện có.

1.7  Tiêu chuẩn này cho rằng thiết kế ứng dụng hiện đại thường sử dụng phần mềm chung phù hợp làm cơ sở cho các ứng dụng khác nhau. Phần mềm chung này sau đó được cấu hình theo dữ liệu, thuật toán, hoặc cả hai để tạo ra phần mềm có thể thực hiện ứng dụng. Nhìn chung từ Điều 1 đến Điều 6 và Điều 9 của tiêu chuẩn này áp dụng cho phần mềm chung cũng như cho các thuật toán và dữ liệu ứng dụng. Điều 7 chỉ áp dụng cụ thể cho phần mềm chung trong khi Điều 8 đưa ra các yêu cầu cụ thể cho các thuật toán và dữ liệu ứng dụng.

1.8  Tiêu chuẩn này không đề cập tới các vấn đề thương mại. Vấn đề này nên được đưa ra xem xét trong thỏa thuận hợp đồng. Nên xem xét cẩn thận tất cả các nội dung của tiêu chuẩn này trong mọi tình huống có tính chất thương mại.

1.9  Tiêu chuẩn này không áp dụng cho các hệ thống hiện đang sử dụng mà chủ yếu áp dụng cho các hệ thống xây dựng mới và chỉ áp dụng toàn bộ cho các hệ thống hiện có nếu có những thay đổi quan trọng. Đối với những thay đổi nhỏ, chỉ áp dụng mục 9.2. Đơn vị đánh giá phải phân tích các bằng chứng được cung cấp trong hồ sơ phần mềm để xác nhận tính đầy đủ trong việc xác định bản chất và phạm vi của các thay đổi phần mềm. Tuy nhiên, khuyến nghị cao việc ứng dụng tiêu chuẩn này trong việc nâng cấp và bảo trì phần mềm hiện có.

2  Tài liệu viện dẫn

Các tài liệu tham khảo sau là cần thiết đối với việc ứng dụng tài liệu này. Đối với các tham khảo có năm, chỉ áp dụng các phiên bản được trích dẫn. Đối với các tham khảo không có năm, phiên bản mới nhất của văn bản được khuyến nghị áp dụng (bao gồm cả phần bổ sung).

TCVN 10935-1 (EN 50126-1:1999), Ứng dụng đường sắt - Quy định và chứng minh độ tin cậy, tính sẵn sàng, khả năng bảo dưỡng và độ an toàn - Phần 1: Các yêu cầu cơ bản và quy trình chung.

EN 50129:2003, Railway applications - Safety related electronic systems for signalling (Ứng dụng đường sắt - Các hệ thống điện tử liên quan đến an toàn cho hệ thống tín hiệu).

TCVN ISO 9000, Hệ thống quản lý chất lượng - Các nguyên tắc cơ bản và từ vựng.

TCVN ISO 9001, Hệ thống quản lý chất lượng - Các yêu cầu.

ISO/IEC 90003:2004, Software engineering - Guidelines for the application of ISO 9001:2000 to computer software (Kỹ thuật phần mềm - Hướng dẫn áp dụng ISO 9001:2000 cho phần mềm máy tính).

ISO/IEC 9126 series, Software engineering - Product quality (Kỹ thuật phần mềm - Chất lượng sản phẩm)

3  Thuật ngữ, định nghĩa và các từ viết tắt

3.1  Thuật ngữ và định nghĩa

Đối với tiêu chuẩn này, áp dụng những thuật ngữ dưới đây.

3.1.1  Đánh giá (Assessment)

Quá trình phân tích để xác định liệu phần mềm (bao gồm các thành phần phần cứng và/hoặc phần mềm của hệ thống con, hệ thống, tài liệu, quá trình) có đáp ứng các yêu cầu được quy định và để đưa ra kết luận phần mềm phù hợp với mục đích dự định sử dụng. Việc đánh giá an toàn sẽ tập trung nhưng không giới hạn ở các đặc tính an toàn của hệ thống.

3.1.2  Đơn vị đánh giá (Assessor)

Người hoặc tổ chức thực hiện việc đánh giá.

3.1.3  Phần mềm thương mại phổ biến (commercial off-the-shelf (COTS))

Phần mềm được xác định theo nhu cầu của thị trường, sẵn có trên thị trường và sự phù hợp với mục đích đã được chứng minh bởi nhiều người sử dụng.

3.1.4  Thành phần (component)

Là một phần để tạo thành phần mềm có các giao diện và sự hoạt động được định nghĩa rõ ràng về mặt thiết kế và cấu trúc phần mềm và đáp ứng các tiêu chí sau:

- Được thiết kế tuân theo “Các thành phần” (xem Bảng A.20);

- Bao gồm một nhóm cụ thể các yêu cầu phần mềm;

- Được xác định rõ ràng và có phiên bản độc lập bên trong hệ thống quản lý cấu hình hoặc thuộc nhóm các thành phần có phiên bản độc lập (ví dụ: các hệ thống con).

3.1.5  Đơn vị quản lý cấu hình (configuration manager)

Tổ chức hoặc cá nhân chịu trách nhiệm thực hiện và tiến hành các quá trình để quản lý cấu hình các tài liệu, phần mềm và các công cụ liên quan, bao gồm cả quản lý sự thay đổi.

3.1.6  Khách hàng (Customer)

Tổ chức hoặc cá nhân mua hệ thống phòng vệ và điều khiển đường sắt có bao gồm phần mềm.

3.1.7  Đơn vị thiết kế (Designer)

Tổ chức hoặc cá nhân thực hiện phân tích và chuyển đổi các yêu cầu được quy định thành các giải pháp thiết kế có thể chấp nhận được và có mức toàn vẹn về an toàn yêu cầu.

3.1.8  Tổ chức hoặc cá nhân (Entity)

Cá nhân, nhóm người hoặc tổ chức đáp ứng vai trò như được nêu ra trong tiêu chuẩn này.

3.1.9  Lỗi, sự cố (Error, fault)

Khuyết tật, lỗi hoặc sự không chính xác mà có thể gây ra hư hỏng hoặc sai khác so với tính năng hoạt động dự định.

3.1.10  Hư hỏng (Failure)

Sai khác không thể chấp nhận giữa tính năng hoạt động được yêu cầu và tính năng hoạt động thực hiện.

3.1.11  Khả năng chấp nhận sự cố (Fault tolerance)

Khả năng được xây dựng sẵn trong một hệ thống để đáp ứng sự cung cấp dịch vụ chính xác liên tục như quy định, khi xuất hiện của một số lượng nhất định các sự cố phần cứng hoặc phần mềm.

3.1.12  Chương trình cơ sở điều khiển thiết bị (Firmware)

Phần mềm được lưu trữ trong bộ nhớ (chỉ được đọc) hoặc trong bộ nhớ bán vĩnh cửu (bộ nhớ flash), độc lập về mặt chức năng đối với phần mềm ứng dụng.

3.1.13  Phần mềm chung (Generic software)

Phần mềm có thể được sử dụng cho các cài đặt khác nhau, đơn giản chỉ bằng việc đưa ra các thuật toán và/hoặc dữ liệu ứng dụng cụ thể.

3.1.14  Đơn vị thực hiện (implementer)

Tổ chức hoặc cá nhân thực hiện chuyển đổi các thiết kế đã được quy định thành sản phẩm thực tế.

3.1.15  Sự tích hợp (integration)

Quá trình lắp ráp các hạng mục phần mềm và/hoặc phần cứng, theo chỉ dẫn cấu trúc và thiết kế, và kiểm thử đối tượng được tích hợp.

3.1.16  Đơn vị tích hợp (integrator)

Tổ chức hoặc cá nhân thực hiện việc tích hợp phần mềm.

3.1.17  Phần mềm hiện có (pre-existing software)

Phần mềm được xây dựng trước đây, bao gồm COTS và phần mềm mã nguồn mở.

3.1.18  Phần mềm mã nguồn mở (open source software)

Mã nguồn có sẵn sử dụng rộng rãi mà không có bản quyền hoặc hết thời hạn về bản quyền trước đó.

3.1.19  Bộ điều khiển logic có thể lập trình (Programmable logic controller)

Hệ thống vi điều khiển có một bộ nhớ lập trình theo người sử dụng để lưu trữ các chỉ lệnh thực hiện các chức năng cụ thể.

3.1.20  Quản lý dự án (project management)

Là việc điều hành dự án về mặt hành chính và/hoặc kỹ thuật, bao gồm các vấn đề về an toàn.

3.1.21  Đơn vị quản lý dự án (project manager)

Cá nhân hoặc tổ chức thực hiện việc quản lý dự án.

3.1.22  Độ tin cậy (Reliability)

Khả năng của một hạng mục thực hiện một chức năng theo yêu cầu dưới các điều kiện đã định trong một khoảng thời gian cho trước.

3.1.23  Độ chắc chắn (robustness)

Khả năng một hạng mục phát hiện và xử lý các tình huống bất thường.

3.1.24  Đơn vị quản lý các yêu cầu (requirements manager)

Tổ chức hoặc cá nhân thực hiện việc quản lý các yêu cầu.

3.1.25  Quản lý các yêu cầu (requirements management)

Quá trình đưa ra, ghi chép, phân tích, xếp hạng, thỏa thuận về các yêu cầu và sau đó kiểm soát sự thay đổi và liên kết với các đơn vị liên quan. Đây là quá trình liên tục xuyên suốt trong một dự án.

3.1.26  Rủi ro (Risk)

Sự kết hợp của tỉ lệ xuất hiện các tai nạn và các sự cố gây hại (do một nguy hiểm tạo ra) và mức độ nghiêm trọng của thiệt hại đó.

3.1.27  An toàn (Safety)

Trạng thái không tồn tại các mức độ rủi ro gây thiệt hại cho con người không thể chấp nhận được.

3.1.28  Cơ quan quản lý về an toàn (Safety Authority)

Cơ quan chịu trách nhiệm đối với việc chứng nhận phần mềm hoặc dịch vụ liên quan tới an toàn phù hợp với các yêu cầu về an toàn theo quy định của pháp luật liên quan.

3.1.29  Chức năng an toàn (safety function)

Chức năng mà thực hiện một phần hoặc toàn bộ một yêu cầu an toàn.

3.1.30  Phần mềm liên quan tới an toàn (Safety-related software)

Phần mềm thực hiện các chức năng an toàn.

3.1.31  Phần mềm (Software)

Là sản phẩm trí tuệ bao gồm các chương trình, quy trình, quy tắc, dữ liệu và mọi tài liệu ghi chép kết hợp liên quan tới sự vận hành của hệ thống.

3.1.32  Cơ sở phần mềm (software baseline)

Tập hợp hoàn chỉnh và thống nhất mã nguồn, các tệp chạy chương trình, các tệp cấu hình, các đoạn mã cài đặt và tệp lưu trữ cần thiết để phát hành phần mềm. Các thông tin về trình biên dịch, hệ điều hành, phần mềm hiện có và các chương trình phụ thuộc được lưu trữ như là một phần của cơ sở phần mềm. Cơ sở phần mềm sẽ giúp cho tổ chức có thể tái lập ra các phiên bản xác định và là đầu vào cho các phát hành phần mềm sau này khi tăng cường hoặc khi nâng cấp ở trong giai đoạn bảo trì.

3.1.23  Triển khai phần mềm (software deployment)

Việc chuyển đổi, cài đặt và kích hoạt cơ sở phần mềm chuyển giao mà đã được phát hành và đánh giá.

3.1.24  Vòng đời phần mềm (Software life cycle)

Các hoạt động xuất hiện trong một khoảng thời gian bắt đầu khi phần mềm được chuyển giao và kết thúc khi phần mềm không còn có thể sử dụng. Thông thường, vòng đời phần mềm bao gồm giai đoạn các yêu cầu, giai đoạn thiết kế, giai đoạn kiểm thử, giai đoạn tích hợp, giai, đoạn triển khai và giai đoạn bảo trì.

3.1.35  Khả năng bảo trì phần mềm (Software maintainablity)

Khả năng hiệu chỉnh phần mềm để sửa chữa các sự cố, cải tiến tính năng hoạt động hoặc các thuộc tính khác, hoặc thay đổi cho phù hợp với môi trường khác.

3.1.36  Bảo trì phần mềm (Software maintenance)

Hoạt động hoặc một loạt các hoạt động được tiến hành trên phần mềm sau khi được người sử dụng cuối cùng chấp nhận. Mục đích của nó là cải tiến, tăng cường và/hoặc sửa chữa chức năng của nó.

3.1.37  Mức toàn vẹn về an toàn phần mềm (Software safety integrity level)

Một chỉ số phân loại xác định rõ các kỹ thuật và các biện pháp phải được áp dụng cho phần mềm.

3.1.38  Nhà cung cấp (supplier)

Tổ chức hoặc cá nhân thiết kế và xây dựng hệ thống điều khiển và phòng vệ đường sắt, bao gồm phần mềm hoặc các phần tương ứng.

3.1.39  Mức toàn vẹn về an toàn hệ thống (System safety integrity level)

Một chỉ số thể hiện mức độ tin cậy yêu cầu mà một hệ thống được tích hợp gồm cả phần cứng và phần mềm sẽ đáp ứng các yêu cầu về an toàn quy định.

3.1.40  Đơn vị kiểm thử (tester)

Tổ chức hoặc cá nhân thực hiện việc kiểm thử.

3.1.41  Kiểm thử (testing)

Quá trình chạy phần mềm dưới các điều kiện được kiểm soát để xác nhận sự hoạt động và hiệu năng của nó khi so sánh với chỉ dẫn các yêu cầu tương ứng.

3.1.42  Loại chương trình T1 (tool class T1)

Chương trình không tạo các đầu ra có thể tham gia trực tiếp hoặc gián tiếp vào mã chạy chương trình (bao gồm dữ liệu) của phần mềm.

Chú thích: Ví dụ về T1 bao gồm: một bộ hiệu chỉnh ký tự hoặc một yêu cầu hoặc một chương trình hỗ trợ thiết kế không có khả năng tự tạo mã tự động, các chương trình kiểm soát cấu hình.

3.1.43  Loại chương trình T2 (tool class T2)

Chương trình hỗ trợ cho việc kiểm thử hoặc thẩm tra thiết kế hoặc mã chạy chương trình, khi các lỗi trong chương trình có thể không phát hiện ra sai sót nhưng không thể trực tiếp tạo ra lỗi trong phần mềm chạy.

Chú thích: Ví dụ về T2 bao gồm: bộ hỗ trợ kiểm thử, chương trình đo đạc phạm vi kiểm thử; chương trình phân tích tĩnh.

3.1.44  Loại chương trình T3 (tool class T3)

Chương trình tạo các đầu ra có thể tham gia trực tiếp hoặc gián tiếp vào mã chạy chương trình (bao gồm dữ liệu) của hệ thống liên quan tới phần mềm.

Chú thích: Ví dụ về T3 bao gồm: một trình biên dịch mã nguồn, một trình biên dịch dữ liệu/thuật toán, một chương trình thay đổi các điểm set-point trong quá trình vận hành hệ thống, một trình biên dịch tối ưu khi có mối liên kết không rõ ràng giữa chương trình mã nguồn và mã đối tượng được tạo ra; một trình biên dịch kết hợp gói chạy chương trình vào mã chạy chương trình.

3.1.45  Khả năng theo dõi theo vết (Traceability)

Mức độ của mối quan hệ có thể được thiết lập giữa hai hoặc nhiều sản phẩm của quá trình phát triển, đặc biệt những sản phẩm có mối quan hệ cũ/mới hoặc chính/phụ với sản phẩm khác.

3.1.46  Thẩm định (Validation)

Quá trình phân tích để đưa ra kết luận dựa trên bằng chứng để xác định một hạng mục (ví dụ: quá trình tài liệu, phần mềm hoặc ứng dụng) phù hợp với yêu cầu của người sử dụng, đặc biệt là về an toàn và chất lượng và nhấn mạnh vào sự phù hợp của hoạt động với mục đích của hạng mục đó trong môi trường dự định.

3.1.47  Đơn vị thẩm định (Validator)

Người hoặc tổ chức chịu trách nhiệm đối với việc thẩm định.

3.1.48  Thẩm tra (Verification)

Quá trình kiểm tra để đưa ra kết luận dựa trên bằng chứng về các hạng mục đầu ra (quá trình, tài liệu, phần mềm hoặc ứng dụng) của một giai đoạn phát triển cụ thể đáp ứng các yêu cầu của giai đoạn đó về mặt hoàn chỉnh, chính xác và thống nhất.

3.1.49  Đơn vị thẩm tra (Verifier)

Cá nhân hoặc tổ chức chịu trách nhiệm cho một hoặc nhiều hoạt động thẩm tra.

3.2  Từ viết tắt

Trong tiêu chuẩn này, sử dụng các từ viết tắt dưới đây.

4  Mục đích, sự phù hợp và mức toàn vẹn về an toàn phần mềm

4.1  Việc phân bổ các chức năng của hệ thống liên quan tới an toàn cho phần mềm, cũng như các giao diện phần mềm phải được xác định trong tài liệu hệ thống. Hệ thống có chứa phần mềm phải được xác định đầy đủ các vấn đề sau đây:

- Các chức năng và các giao diện;

- Các điều kiện ứng dụng;

- Cấu hình hoặc cấu trúc của hệ thống;

- Các nguy hiểm được kiểm soát;

- Các yêu cầu về tính toàn vẹn an toàn;

- Việc phân bổ các yêu cầu và phân bổ SIL cho phần mềm và phần cứng

- Các ràng buộc về thời gian.

Chú thích: Việc phân bổ các yêu cầu về tính toàn vẹn về an toàn có thể dẫn đến các SIL khác nhau cho các bộ phận phần mềm và phần cứng được phân tách tốt của một hệ thống con. Việc phân bổ này sẽ phụ thuộc vào sự tham gia của các bộ phận phần mềm và phần cứng của hệ thống con trong các tính năng liên quan tới an toàn và cơ chế giảm thiểu hư hỏng, bao gồm sự phân chia chức năng có các SIL khác nhau.

4.2  Tính toàn vẹn về an toàn phần mềm phải được quy định là 1 trong 5 mức, từ SIL 0 (mức thấp nhất) cho tới SIL 4 (mức cao nhất).

4.3  Mức toàn vẹn về an toàn phần mềm yêu cầu phải được quyết định và đánh giá ở mức độ hệ thống, trên cơ sở mức toàn vẹn về an toàn hệ thống và mức độ rủi ro liên quan khi sử dụng phần mềm trong hệ thống.

4.4  Tối thiểu, các yêu cầu về SIL 0 trong tiêu chuẩn này phải được đáp ứng cho bộ phận phần mềm của các chức năng có tác động tới an toàn dưới SIL 1. Do sẽ tồn tại sự không chắc chắn trong việc đánh giá rủi ro, và cả trong việc xác định các nguy hiểm. Để xử lý các vấn đề không chắc chắn, phải cẩn trọng khi xác định mức toàn vẹn về an toàn thấp (được thể hiện bằng SIL 0), ngoài các đối tượng không có mức toàn vẹn về an toàn.

4.5  Để phù hợp tiêu chuẩn này, phải thể hiện cho thấy được các yêu cầu đã được đáp ứng theo mức toàn vẹn về an toàn phần mềm đã xác định trước và thỏa mãn điều khoản mục tiêu đề ra.

4.6  Khi một yêu cầu đủ điều kiện cho cụm từ “theo mức toàn vẹn về an toàn phần mềm được yêu cầu” có nghĩa là có thể sử dụng các kỹ thuật và các biện pháp để thỏa mãn yêu cầu này.

4.7  Khi áp dụng mục 4.6, phải sử dụng các bảng trong Phụ lục A để hỗ trợ cho việc lựa chọn các kỹ thuật và các biện pháp phù hợp theo mức toàn vẹn về an toàn phần mềm. Việc lựa chọn phải được ghi lại trong Kế hoạch đảm bảo chất lượng phần mềm hoặc trong tài liệu khác được tham chiếu trong Kế hoạch đảm bảo chất lượng phần mềm. Hướng dẫn về những kỹ thuật này được đưa ra trong Phụ lục tham khảo D.

4.8  Nếu không sử dụng một kỹ thuật hoặc một biện pháp được xếp hạng là khuyến nghị cao (HR) trong các bảng thì lý do cho việc sử dụng kỹ thuật thay thế phải được nêu chi tiết và được ghi lại trong Kế hoạch đảm bảo chất lượng phần mềm hoặc trong các tài liệu khác được tham chiếu trong Kế hoạch đảm bảo chất lượng phần mềm. Điều này sẽ không cần thiết nếu sử dụng kết hợp các kỹ thuật được phê duyệt đưa ra trong bảng tương ứng. Các kỹ thuật được lựa chọn phải được chứng minh là áp dụng đúng và chính xác.

4.9  Nếu một kỹ thuật hoặc biện pháp được đề nghị sử dụng mà không có trong các bảng thì tính hiệu quả và khả năng phù hợp của nó khi đáp ứng các yêu cầu cụ thể và mục đích tổng thể của nội dung mục đó phải được kết luận và ghi lại trong Kế hoạch đảm bảo chất lượng phần mềm hoặc trong tài liệu khác tham chiếu khác từ Kế hoạch đảm bảo chất lượng phần mềm.

4.10  Phải thẩm tra sự phù hợp với các yêu cầu của một điều khoản cụ thể và các kỹ thuật và các biện pháp tương ứng của nó được nêu chi tiết trong các bảng, bằng cách kiểm tra các tài liệu được yêu cầu theo tiêu chuẩn này. Nếu phù hợp phải tính tới các bằng chứng khách quan khác, các đánh giá và chứng kiến kiểm thử.

5  Quản lý và tổ chức phần mềm

5.1  Tổ chức, vai trò và trách nhiệm

5.1.1  Mục đích

Để đảm bảo tất cả các cá nhân chịu trách nhiệm về phần mềm được tổ chức, giao quyền và đủ khả năng hoàn thành các trách nhiệm đó.

5.1.2  Các yêu cầu

5.1.2.1  Tối thiểu, nhà cung cấp phải thực hiện các nội dung của TCVN ISO 9001 đối với việc tổ chức và quản lý các cá nhân và trách nhiệm.

5.1.2.2  Các trách nhiệm phải phù hợp với các yêu cầu được xác định trong Phụ lục B.

5.1.2.3  Cá nhân được chỉ định các vai trò liên quan đến việc phát triển hoặc bảo trì phần mềm phải có tên và được ghi lại.

5.1.2.4  Đơn vị đánh giá phải được nhà cung cấp, khách hàng hoặc Cơ quan quản lý về an toàn chỉ định.

5.1.2.5  Đơn vị đánh giá phải độc lập với nhà cung cấp, hoặc theo chỉ đạo của Cơ quan quản lý về an toàn thuộc tổ chức của nhà cung cấp hoặc tổ chức của khách hàng.

5.1.2.6  Đơn vị đánh giá phải độc lập với dự án.

5.1.2.7  Đơn vị đánh giá phải được trao thẩm quyền thực hiện việc đánh giá phần mềm.

5.1.2.8  Đơn vị thẩm định phải đưa ra sự đồng ý/không đồng ý khi phát hành phần mềm.

5.1.2.9  Trong toàn bộ vòng đời phần mềm, việc chỉ định vai trò cho các cá nhân phải phù hợp với mục 5.1.2.10 đến 5.1.2.14 theo mức SIL phần mềm yêu cầu.

Hình 2 - Minh họa cấu trúc tổ chức ưu tiên

5.1.2.10  Sơ đồ tổ chức khuyến nghị cho mức SIL 3 và SIL 4 là

a) Đơn vị quản lý các yêu cầu. Đơn vị thiết kế và Đơn vị thực hiện đối với một thành phần phần mềm có thể là cùng một đơn vị.

b) Đơn vị quản lý các yêu cầu, Đơn vị thiết kế và Đơn vị thực hiện thành phần phần mềm phải báo cáo cho Đơn vị quản lý dự án.

c) Đơn vị tích hợp và Đơn vị kiểm thử thành phần mềm có thể là cùng một đơn vị.

d) Đơn vị tích hợp và Đơn vị kiểm thử thành phần phần mềm có thể báo cáo cho Đơn vị quản lý dự án hoặc cho Đơn vị thẩm định.

e) Đơn vị thẩm tra có thể báo cáo cho Đơn vị quản lý dự án hoặc cho Đơn vị thẩm định.

f) Đơn vị thẩm định không phải báo cáo cho Đơn vị quản lý dự án, ví dụ: Đơn vị quản lý dự án phải không tác động đến các quyết định của Đơn vị thẩm định, nhưng Đơn vị thẩm định phải thông báo cho Đơn vị quản lý dự án về các quyết định của mình.

g) Người làm quản lý các yêu cầu, thiết kế hoặc thực hiện thành phần phần mềm phải không phải là Đơn vị kiểm thử, cũng không phải là Đơn vị tích hợp cho cùng một thành phần phần mềm.

h) Người làm tích hợp hoặc kiểm thử thành phần phần mềm phải không là Đơn vị quản lý các yêu cầu, thiết kế hoặc thực hiện đối với cùng một thành phần phần mềm.

i) Người làm Thẩm tra phải không phải là Đơn vị quản lý các yêu cầu, thiết kế, thực hiện tích hợp, kiểm thử hoặc thẩm định.

j) Người làm Thẩm định phải không phải là đơn vị quản lý các yêu cầu, thiết kế, thực hiện, tích hợp, kiểm thử hoặc thẩm tra.

k) Người làm quản lý dự án có thể thực hiện bổ sung các vai trò của Đơn vị quản lý các yêu cầu, thiết kế, thực hiện, tích hợp, kiểm thử hoặc thẩm tra, miễn là các yêu cầu về sự độc lập giữa các vai trò bổ sung này phải được tôn trọng.

l) Đơn vị quản lý dự án, Đơn vị quản lý các yêu cầu, Đơn vị thiết kế, Đơn vị thực hiện, Đơn vị tích hợp, Đơn vị kiểm thử, Đơn vị thẩm tra và Đơn vị thẩm định có thể thuộc cùng một tổ chức.

m) Đơn vị đánh giá phải độc lập và độc lập về mặt tổ chức với vai trò của Đơn vị quản lý dự án, Đơn vị quản lý các yêu cầu, Đơn vị thiết kế, Đơn vị thực hiện, Đơn vị tích hợp, Đơn vị kiểm thử, Đơn vị thẩm tra và Đơn vị thẩm định.

Tuy nhiên, có thể áp dụng các lựa chọn sau:

n) Người làm thẩm định cũng có thể thực hiện vai trò của Đơn vị thẩm tra, nhưng vẫn duy trì sự độc lập với Đơn vị quản lý dự án. Trong trường hợp này, các tài liệu đầu ra của Đơn vị thẩm tra phải được một cá nhân khác có đủ khả năng xem xét ở cùng mức độ độc lập như Đơn vị thẩm định. Lựa chọn về mặt tổ chức phải tùy thuộc vào sự chấp thuận của Đơn vị đánh giá.

o) Người làm thẩm tra cũng có thể thực hiện vai trò của Đơn vị tích hợp và kiểm thử, trong trường hợp này, vai trò của Đơn vị thẩm định phải kiểm tra sự phù hợp của bằng chứng được ghi lại từ quá trình tích hợp và kiểm thử với các mục tiêu thẩm tra được quy định, từ đó duy trì 2 mức độ kiểm tra trong tổ chức dự án.

5.1.2.11  Sơ đồ tổ chức khuyến nghị cho mức SIL 1 và SIL 2 là:

a) Đơn vị quản lý các yêu cầu, Đơn vị thiết kế và Đơn vị thực hiện cho một thành phần phần mềm có thể là cùng một người và báo cáo cho Đơn vị quản lý dự án.

b) Đơn vị tích hợp và Đơn vị kiểm thử thành phần phần mềm có thể là cùng một người.

c) Đơn vị tích hợp và Đơn vị kiểm thử thành phần phần mềm có thể báo cáo cho Đơn vị quản lý dự án hoặc cho Đơn vị thẩm định.

d) Đơn vị thẩm tra và Đơn vị thẩm định có thể là cùng một người.

e) Đơn vị thẩm tra và đơn vị thẩm định có thể báo cáo cho Đơn vị quản lý dự án.

f) Người làm Quản lý các yêu cầu, thiết kế hoặc thực hiện thành phần phần mềm phải không phải là Đơn vị kiểm thử, cũng không phải là Đơn vị tích hợp cho cùng một thành phần phần mềm.

g) Người làm tích hợp hoặc kiểm thử thành phần phần mềm phải không là Đơn vị quản lý các yêu cầu, thiết kế hoặc thực hiện đối với cùng một thành phần phần mềm.

h) Người làm Thẩm tra hoặc thẩm định phải không phải là Đơn vị quản lý các yêu cầu, thiết kế, thực hiện, tích hợp, kiểm thử.

i) Người làm quản lý dự án có thể thực hiện bổ sung các vai trò của Đơn vị quản lý các yêu cầu, thiết kế, thực hiện, tích hợp, kiểm thử, thẩm tra hoặc thẩm định, miễn là các yêu cầu về sự độc lập giữa các vai trò bổ sung này được tôn trọng.

j) Đơn vị quản lý dự án, Đơn vị quản lý các yêu cầu, Đơn vị thiết kế, Đơn vị thực hiện, Đơn vị tích hợp, Đơn vị kiểm thử, Đơn vị thẩm tra và Đơn vị thẩm định có thể thuộc cùng một tổ chức.

k) Đơn vị đánh giá phải độc lập và độc lập về mặt tổ chức với vai trò của Đơn vị quản lý dự án, Đơn vị quản lý các yêu cầu, Đơn vị thiết kế, Đơn vị thực hiện, Đơn vị tích hợp, Đơn vị kiểm thử, Đơn vị thẩm tra và Đơn vị thẩm định.

Tuy nhiên, có thể áp dụng các lựa chọn sau:

l) Người làm Thẩm tra cũng có thể thực hiện vai trò của Đơn vị tích hợp và kiểm thử, trong trường hợp này, vai trò của Đơn vị thẩm định phải bao gồm việc xem xét các tài liệu kết quả của Đơn vị thẩm tra, từ đó duy trì 2 mức độ kiểm tra trong tổ chức dự án.

m) Người làm Thẩm định cũng có thể thực hiện vai trò của Đơn vị thẩm tra, tích hợp và kiểm thử. Trong trường hợp này, các tài liệu kết quả của Đơn vị thẩm tra phải được một cá nhân khác có đủ khả năng xem xét ở cùng mức độ độc lập như Đơn vị thẩm định. Lựa chọn về mặt tổ chức phải tùy thuộc vào sự chấp thuận của Đơn vị đánh giá.

5.1.2.12  Kết cấu tổ chức khuyến nghị cho mức SIL 0:

a) Đơn vị quản lý các yêu cầu, Đơn vị thiết kế và Đơn vị thực hiện cho một thành phần phần mềm có thể là cùng một người và phải được quản lý bởi cùng Đơn vị quản lý dự án.

b) Đơn vị tích hợp và Đơn vị kiểm thử, Đơn vị thẩm tra và Đơn vị thẩm định cho thành phần phần mềm có thể là cùng một người.

c) Đơn vị tích hợp và Đơn vị kiểm thử, đơn vị thẩm tra và đơn vị thẩm định có thể được quản lý bởi cùng đơn vị quản lý dự án.

d) Người làm Quản lý các yêu cầu, thiết kế hoặc thực hiện thành phần phần mềm phải không phải là Đơn vị kiểm thử, cũng không phải là đơn vị tích hợp cho cùng một thành phần phần mềm.

e) Người làm Thẩm tra hoặc thẩm định phải không phải là đơn vị quản lý các yêu cầu, thiết kế, thực hiện.

f) Người làm quản lý dự án có thể thực hiện bổ sung các vai trò của Đơn vị quản lý các yêu cầu, thiết kế, thực hiện, tích hợp, kiểm thử, thẩm tra hoặc thẩm định, miễn là các yêu cầu về sự độc lập giữa các vai trò bổ sung này được tôn trọng.

g) Đơn vị quản lý dự án, Đơn vị quản lý các yêu cầu, Đơn vị thiết kế, Đơn vị thực hiện, Đơn vị tích hợp, Đơn vị kiểm thử, Đơn vị thẩm tra và Đơn vị thẩm định có thể thuộc cùng một tổ chức.

h) Đơn vị đánh giá phải độc lập và độc lập về mặt tổ chức với vai trò của Đơn vị quản lý dự án, Đơn vị quản lý các yêu cầu, Đơn vị thiết kế, Đơn vị thực hiện, Đơn vị tích hợp, Đơn vị kiểm thử, Đơn vị thẩm tra và Đơn vị thẩm định.

Tuy nhiên, có thể áp dụng các lựa chọn thay thế sau:

i) Đơn vị quản lý các yêu cầu, Đơn vị thiết kế, Đơn vị thực hiện, Đơn vị tích hợp và Đơn vị kiểm thử có thể là cùng một người.

j) Đơn vị thẩm định và Đơn vị thẩm tra cũng có thể là cùng một người.

k) Người làm thẩm tra hoặc thẩm định phải không được là Đơn vị quản lý các yêu cầu, thiết kế hay thực hiện.

5.1.2.13  Vai trò của Đơn vị quản lý các yêu cầu, Đơn vị thiết kế và thực hiện đối với một thành phần có thể thực hiện vai trò của Đơn vị kiểm thử và Đơn vị tích hợp cho một thành phần khác.

5.1.2.14  Vai trò của Đơn vị thẩm tra và thẩm định phải được xác định theo mức độ dự án và phải duy trì không thay đổi xuyên suốt quá trình phát triển dự án.

5.2  Năng lực cá nhân

5.2.1  Mục tiêu

5.2.1.1  Để đảm bảo tất cả các cá nhân có trách nhiệm đối với phần mềm có đủ năng lực để thực hiện các trách nhiệm, bằng cách chứng minh khả năng thực hiện các nhiệm vụ liên quan một cách chính xác, hiệu quả và thống nhất với chất lượng cao và theo các điều kiện thay đổi khác nhau.

5.2.2  Các yêu cầu

5.2.2.1  Phụ lục B xác định các năng lực chính cần thiết cho từng vai trò trong quá trình phát triển phần mềm. Nếu cần phải có kinh nghiệm, năng lực hoặc khả năng bổ sung cho một vai trò nào đó trong vòng đời phần mềm thì những năng lực này phải được xác định trong Kế hoạch đảm bảo chất lượng phần mềm.

5.2.2.2  Bằng chứng ghi lại về năng lực cá nhân, bao gồm kiến thức kỹ thuật, các chứng chỉ, kinh nghiệm liên quan và các quá trình đào tạo phù hợp phải được tổ chức của nhà cung cấp lưu giữ để chứng minh cơ cấu tổ chức an toàn là phù hợp.

5.2.2.3  Tổ chức phải duy trì các quy trình để quản lý năng lực cá nhân để phù hợp với các vị trí tương ứng theo các tiêu chuẩn chất lượng hiện hành.

Khi đã chứng minh được cho đơn vị đánh giá thấy sự thỏa mãn hoặc bằng việc chứng nhận năng lực của tất cả các cá nhân đã được chứng minh ở các vai trò khác nhau, từng cá nhân cần phải thể hiện quá trình duy trì và phát triển năng lực liên tục. Việc này có thể được chứng minh qua sổ ghi chép thể hiện hoạt động được thực hiện chuẩn xác thường xuyên, và các quá trình đào tạo bổ sung được thực hiện phù hợp với TCVN ISO 9001 và ISO/IEC 90003:2004, mục 6.2.2.

5.3  Vấn đề vòng đời và lưu trữ

5.3.1  Mục tiêu

5.3.1.1  Để tổ chức được việc phát triển phần mềm thành các giai đoạn và các hoạt động xác định.

5.3.1.2  Để ghi lại tất cả thông tin thích hợp với phần mềm trong suốt vòng đời phần mềm.

5.3.2  Các yêu cầu

5.3.2.1  Phải lựa chọn một mô hình vòng đời đối với việc phát triển phần mềm. Phải nêu chi tiết trong Kế hoạch đảm bảo chất lượng phần mềm, phù hợp với mục 6.5 của tiêu chuẩn này.

Ví dụ về hai mô hình vòng đời được đưa ra trong Hình 3 và Hình 4.

5.3.2.2  Mô hình vòng đời phải tính tới khả năng lặp lại trong và giữa các giai đoạn.

5.3.2.3  Các quy trình bảo đảm chất lượng phải tiến hành song song với các hoạt động vòng đời và sử dụng cùng các thuật ngữ.

5.3.2.4  Kế hoạch đảm bảo chất lượng phần mềm, Kế hoạch thẩm tra phần mềm, Kế hoạch thẩm định phần mềm và Kế hoạch quản lý cấu hình phần mềm phải được đưa ra ngay khi bắt đầu dự án và được duy trì xuyên suốt vòng đời phát triển phần mềm.

5.3.2.5  Tất cả các hoạt động được thực hiện trong suốt một giai đoạn phải được xác định và được lên kế hoạch trước khi bắt đầu giai đoạn đó.

5.3.2.6  Tất cả các tài liệu phải được cấu trúc sao cho có thể mở rộng liên tục song song với quá trình thiết kế.

5.3.2.7  Việc theo dõi theo vết các tài liệu phải có trong từng tài liệu và có chung thống nhất các tham chiếu và mối quan hệ xác định được ghi lại với các tài liệu khác.

5.3.2.8  Mỗi thuật ngữ, nhóm từ hoặc từ viết tắt phải có cùng nghĩa trong tất cả các tài liệu. Nếu việc này không thể thực hiện được do các lý do liên quan tới lịch sử quá trình, các ý nghĩa khác nhau phải được liệt kê và các tham chiếu phải được đưa ra.

5.3.2.9  Ngoại trừ các tài liệu liên quan tới phần mềm hiện có trước đó (xem mục 7.3.47), từng tài liệu phải được lập thành văn bản theo các quy tắc sau:

- Phải có hoặc thực hiện tất cả các điều kiện và các yêu cầu có thể áp dụng của tài liệu trước đây mà có mối liên quan về phân cấp;

- Phải không trái ngược lại với tài liệu trước đó.

5.3.2.10  Từng khái niệm hoặc hạng mục phải được tham chiếu theo cùng tên hoặc mô tả trong mỗi tài liệu.

5.3.2.11  Nội dung của tất cả các tài liệu phải được ghi lại theo mẫu phù hợp để xử lý, giải quyết và lưu trữ.

5.3.2.12  Khi các tài liệu do các cá nhân đảm nhiệm các vai trò khác nhau lập ra được kết hợp thành một tài liệu duy nhất, mối quan hệ giữa các phần được mọi cá nhân độc lập lập ra phải được theo dõi theo vết trong tài liệu.

5.3.2.13  Các tài liệu có thể được kết hợp hoặc phân chia theo mục 5.3.2.12. Một số bước xây dựng có thể kết hợp, phân chia hoặc khi được kết luận là loại bỏ theo hướng dẫn của Đơn vị quản lý dự án và sự đồng ý của Đơn vị thẩm định.

5.3.2.14  Khi chấp thuận mọi chu trình hoặc cấu trúc ghi chép thay thế, phải thể hiện được là đáp ứng tất cả các mục tiêu và yêu cầu của tiêu chuẩn này.

Hình 3 - Minh họa vòng đời phát triển 1

Hình 4 - Minh họa vòng đời phát triển 2

6  Đảm bảo phần mềm

6.1  Kiểm thử phần mềm

6.1.1  Mục tiêu

6.1.1.1  Mục tiêu kiểm thử phần mềm (được thực hiện bởi Đơn vị kiểm thử và/hoặc Đơn vị tích hợp) là để xác nhận tính năng hoạt động của phần mềm theo chỉ dẫn kỹ thuật kiểm thử tương ứng theo phạm vi kiểm thử lựa chọn có thể đạt được.

6.1.2  Tài liệu đầu vào

1) Tất cả các tài liệu về hệ thống, phần cứng và phần mềm cần thiết như được quy định trong Kế hoạch thẩm tra phần mềm.

6.1.3  Tài liệu đầu ra

1) Chỉ dẫn kiểm thử tổng thể phần mềm

2) Báo cáo kiểm thử tổng thể phần mềm

3) Chỉ dẫn kiểm thử tích hợp phần mềm

4) Báo cáo kiểm thử tích hợp phần mềm

5) Chỉ dẫn kiểm thử tích hợp phần mềm / phần cứng

6) Báo cáo kiểm thử tích hợp phần mềm / phần cứng

7) Chỉ dẫn kiểm thử thành phần phần mềm

8) Báo cáo kiểm thử thành phần phần mềm

6.1.4  Các yêu cầu

6.1.4.1  Đơn vị thẩm tra có thể chấp nhận các kiểm thử được các đơn vị khác tiến hành, như Đơn vị quản lý các yêu cầu, Đơn vị thiết kế hoặc Đơn vị thực hiện, nếu được ghi lại đầy đủ và phù hợp với các yêu cầu dưới đây.

6.1.4.2  Thiết bị đo đạc sử dụng để kiểm thử phải được hiệu chỉnh phù hợp. Mọi chương trình, phần cứng hoặc phần mềm được sử dụng để kiểm thử phải được thể hiện là phù hợp với mục đích.

6.1.4.3  Kiểm thử phần mềm phải được ghi lại trong Chỉ dẫn kiểm thử và Báo cáo kiểm thử, như được quy định trong các tài liệu dưới đây.

6.1.4.4  Từng Chỉ dẫn kiểm thử phải ghi lại những vấn đề sau:

a) Các mục tiêu kiểm thử.

b) Các trường hợp kiểm thử, dữ liệu kiểm thử, và các kết quả mong muốn.

c) Loại kiểm thử được tiến hành.

d) Môi trường kiểm thử, công cụ, cấu hình và chương trình.

e) Chỉ tiêu kiểm thử sẽ được kết luận khi hoàn thành kiểm thử.

f) Chỉ tiêu và mức độ kiểm thử đạt được.

g) Vai trò và trách nhiệm của các cá nhân liên quan trong quá trình kiểm thử.

h) Các yêu cầu được đề cập trong chỉ dẫn kiểm thử.

i) Lựa chọn và sử dụng thiết bị kiểm thử phần mềm.

6.1.4.5  Báo cáo kiểm thử phải được lập như sau:

a) Báo cáo kiểm thử phải đề cập tới tên của Đơn vị kiểm thử, nêu rõ các kết quả kiểm thử và xác định các mục tiêu kiểm thử và chỉ tiêu kiểm thử trong Chỉ dẫn kiểm thử có được đáp ứng. Các thất bại phải được lưu lại và tổng kết.

b) Các trường hợp kiểm thử và các kết quả phải được ghi lại, nên theo dạng để máy có thể đọc được cho các phân tích sau này.

c) Các kiểm thử phải có thể thực hiện lại và được thực hiện bằng phương pháp tự động nếu khả thi.

d) Các mã mô tả kiểm thử để chạy kiểm thử tự động phải được thẩm tra.

e) Nhận dạng và cấu hình của tất cả các hạng mục liên quan (phần cứng được sử dụng, phần mềm được sử dụng, thiết bị được sử dụng, thiết bị hiệu chuẩn, cũng như các dạng thông tin của chỉ dẫn kiểm thử) phải được lưu lại.

f) Việc đánh giá mức độ kiểm thử và việc hoàn thành kiểm thử phải được nêu ra và mọi sai lệch phải được ghi lại.

6.2  Thẩm tra phần mềm

6.2.1  Mục tiêu

6.2.1.1  Mục tiêu của việc thẩm tra phần mềm là để kiểm tra và đi đến kết luận dựa trên bằng chứng mà các đối tượng đầu ra (quá trình, tài liệu, phần mềm hoặc ứng dụng) của một giai đoạn phát triển cụ thể đáp ứng được các yêu cầu và các kế hoạch một cách hoàn thiện, chính xác và nhất quán. Các hoạt động này sẽ được Đơn vị thẩm tra quản lý

6.2.2  Các tài liệu đầu vào

1) Tất cả các tài liệu về hệ thống, phần mềm và phần cứng cần thiết.

6.2.3  Các tài liệu đầu ra

1) Kế hoạch thẩm tra phần mềm

2) Báo cáo thẩm tra phần mềm

3) Báo cáo thẩm tra đảm bảo chất lượng phần mềm

6.2.4  Các yêu cầu

6.2.4.1  Tối thiểu việc thẩm tra phải được ghi lại trong Kế hoạch thẩm tra phần mềm và trong một hoặc nhiều Báo cáo thẩm tra (liên quan đến quá trình).

6.2.4.2  Kế hoạch thẩm tra phần mềm phải được lập thành văn bản, do trách nhiệm của đơn vị thẩm tra, trên cơ sở các tài liệu cần thiết.

Các yêu cầu từ mục 6.2.4.3 đến 6.2.4.9 tham chiếu theo Kế hoạch thẩm tra phần mềm.

6.2.4.3  Kế hoạch thẩm tra phần mềm phải mô tả các hoạt động được tiến hành để đảm bảo cho việc thẩm tra được chính xác và các thiết kế cụ thể hoặc các yêu cầu thẩm tra khác được đưa ra một cách phù hợp.

6.2.4.4  Trong quá trình phát triển (và dựa vào quy mô của hệ thống), kế hoạch có thể được chia nhỏ thành một số tài liệu con và có thể được bổ sung thêm khi các yêu cầu chi tiết của việc thẩm tra trở nên rõ ràng hơn.

6.2.4.5  Kế hoạch thẩm tra phần mềm phải ghi lại tất cả các chỉ tiêu, kỹ thuật và chương trình được sử dụng trong quá trình thẩm tra. Kế hoạch thẩm tra phần mềm phải bao gồm các kỹ thuật và các biện pháp được lựa chọn trong các bảng A.5, A.6, A.7 và A.8. Việc kết hợp được lựa chọn phải được kết luận là thỏa mãn các yêu cầu 4.8, 4.9, 4.10.

6.2.4.6  Kế hoạch thẩm tra phần mềm phải mô tả các hoạt động được tiến hành để đảm bảo sự chính xác và thống nhất tương ứng với đầu vào cho giai đoạn đó. Những hoạt động này bao gồm cả việc rà soát, kiểm thử và tích hợp.

6.2.4.7  Trong từng giai đoạn phát triển, phải thể hiện được các yêu cầu về chức năng, hoạt động và an toàn đã được đáp ứng.

6.2.4.8  Các kết quả của từng việc thẩm tra phải được lưu lại theo dạng xác định hoặc được tham chiếu trong Kế hoạch thẩm tra phần mềm.

6.2.4.9  Kế hoạch thẩm tra phần mềm phải đề cập đến các vấn đề sau:

a) Việc lựa chọn chiến lược thẩm tra và các kỹ thuật (để tránh sự phức tạp vô lý trong quá trình đánh giá việc thẩm tra và kiểm thử, phải đưa ra lựa chọn để chọn lọc các kỹ thuật có thể sẵn sàng phân tích).

b) Lựa chọn các kỹ thuật từ các Bảng A.5, A.6, A.7 và A.8.

c) Lựa chọn và ghi lại các hoạt động thẩm tra.

d) Đánh giá các kết quả thẩm tra thu được.

e) Đánh giá các yêu cầu về an toàn và độ chắc chắn.

f) Vai trò và các trách nhiệm của các cá nhân liên quan đến quá trình thẩm tra.

g) Mức độ phạm vi kiểm thử dựa trên chức năng được yêu cầu đạt được.

h) Kết cấu và nội dung của từng bước thẩm tra, đặc biệt đối với Thẩm tra yêu cầu phần mềm (7.2.4.22), Thẩm tra cấu trúc và thiết kế phần mềm (7.3.4.41, 7.3.4.42), Thẩm tra thành phần phần mềm (7.4.4.13), Thẩm tra mã nguồn phần mềm (7.5.4.10) và Thẩm tra tích hợp (7.6.4.13) sao cho tạo điều kiện thuận lợi cho việc xem xét theo Kế hoạch thẩm tra phần mềm.

6.2.4.10  Báo cáo thẩm tra đảm bảo chất lượng phần mềm phải được lập thành văn bản, do trách nhiệm của đơn vị thẩm tra, trên cơ sở các tài liệu đầu vào từ mục 6.2.2.

Yêu cầu trong mục 6.2.4.11 tham chiếu đến Báo cáo thẩm tra đảm bảo chất lượng phần mềm.

6.2.4.11  Khi đã lập được kế hoạch thẩm tra phần mềm, việc thẩm tra phải đề cập tới

a) Kế hoạch thẩm tra phần mềm đáp ứng các yêu cầu chung về khả năng sẵn sàng và khả năng theo dõi theo vết trong các mục 5.3.2.7 đến 5.3.2.10 và trong mục 6.5.4.14 đến 6.5.4.17 cũng như các yêu cầu cụ thể trong 6.2.4.3 đến 6.2.4.9.

b) Sự thống nhất nội bộ của Kế hoạch thẩm tra phần mềm.

Các kết quả phải được ghi lại trong Báo cáo thẩm tra đảm bảo chất lượng phần mềm.

6.2.4.12  Mọi Báo cáo thẩm tra phần mềm phải được viết thành văn bản, do trách nhiệm của đơn vị thẩm tra, trên cơ sở các tài liệu đầu vào. Các báo cáo này có thể được phân vùng để cho rõ ràng, thuận tiện và phải tuân theo Kế hoạch thẩm tra phần mềm. Yêu cầu trong mục 6.2.4.13 tham chiếu tới Báo cáo thẩm tra phần mềm.

6.2.4.13  Mỗi báo cáo thẩm tra phần mềm phải ghi lại các vấn đề sau:

a) Nhận dạng và cấu hình của các hạng mục được thẩm tra, cũng như tên đơn vị thẩm tra.

b) Các hạng mục không thỏa mãn các chỉ dẫn kỹ thuật.

c) Các thành phần, dữ liệu, cấu trúc và thuật toán được thay đổi kém linh hoạt theo vấn đề.

d) Các lỗi được phát hiện hoặc các sai lệch.

e) Việc đáp ứng hoặc sai lệch so với Kế hoạch thẩm tra phần mềm (trong tình huống sai lệch Báo cáo thẩm tra phải giải tích sự sai lệch là quan trọng hay không quan trọng).

f) Các giả thiết nếu có.

g) Tổng hợp các kết quả thẩm tra.

6.3  Thẩm định phần mềm

6.3.1  Mục tiêu

6.3.1.1  Mục tiêu của việc thẩm định phần mềm là để chứng minh các quá trình và các kết quả thuộc mức toàn vẹn về an toàn phần mềm được xác định, đáp ứng các yêu cầu phần mềm và phù hợp với ứng dụng dự định. Hoạt động này được Đơn vị thẩm định thực hiện.

6.3.1.2  Các hoạt động thẩm định chính là để chứng minh bằng phân tích và/hoặc kiểm thử xem tất cả các yêu cầu phần mềm được quy định, thực hiện, kiểm thử và đáp ứng theo yêu cầu của SIL có thể áp dụng, và để đánh giá mức độ quan trọng về an toàn của tất cả các vấn đề không bình thường và sự không phù hợp dựa trên các kết quả của việc rà soát, phân tích và kiểm thử.

6.3.2  Các tài liệu đầu vào

Tất cả các tài liệu về hệ thống, phần mềm và phần cứng như được quy định trong tiêu chuẩn này.

6.3.3  Các tài liệu đầu ra

1) Kế hoạch thẩm định phần mềm

2) Báo cáo thẩm định phần mềm

3) Báo cáo thẩm tra thẩm định phần mềm

6.3.4  Các yêu cầu

6.3.4.1  Các hoạt động thẩm định phần mềm phải được xây dựng và thực hiện, với các kết quả được đánh giá, bởi một đơn vị thẩm định ở mức độ độc lập phù hợp như được quy định trong mục 5.1.

6.3.4.2  Tối thiểu việc thẩm định phải được ghi lại trong Kế hoạch thẩm định phần mềm và Báo cáo thẩm định phần mềm, như được quy định dưới đây.

6.3.4.3  Kế hoạch thẩm định phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thẩm định, trên cơ sở của các tài liệu đầu ra.

Các yêu cầu từ mục 6.3.4.4 đến 6.3.4.6 tham chiếu Kế hoạch thẩm định phần mềm.

6.3.4.4  Kế hoạch thẩm định phần mềm phải bao gồm cả việc tổng hợp kết luận về chiến lược thẩm định được lựa chọn. Theo mức toàn vẹn về an toàn phần mềm được yêu cầu, việc kết luận phải bao gồm việc xem xét:

a) Các kỹ thuật thủ công hoặc tự động, hoặc cả hai.

b) Các kỹ thuật tĩnh hoặc động, hoặc cả hai.

c) Các kỹ thuật phân tích hoặc thống kê, hoặc cả hai.

d) Kiểm thử trong môi trường thực hoặc mô phỏng, hoặc cả hai.

6.3.4.5  Kế hoạch thẩm định phần mềm phải xác định rõ các bước cần thiết để chứng minh sự đáp ứng đầy đủ các yêu cầu về an toàn được đưa ra trong Chỉ dẫn các yêu cầu an toàn hệ thống của Chỉ dẫn kỹ thuật phần mềm.

6.3.4.6  Kế hoạch thẩm định phần mềm phải xác định rõ các bước cần thiết để chứng minh sự phù hợp của Chỉ dẫn thử nghiệm phần mềm tổng thể như là một kiểm thử dựa trên Chỉ dẫn các yêu cầu phần mềm.

6.3.4.7  Báo cáo thẩm định phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thẩm định, trên cơ sở các tài liệu đầu vào.

Các yêu cầu từ mục 6.3.4.8 đến 6.3.4.11 tham chiếu đến Báo cáo thẩm định phần mềm.

6.3.4.8  Các kết quả của việc thẩm định phải được ghi lại trong Báo cáo thẩm định phần mềm.

6.3.4.9  Đơn vị thẩm định phải kiểm tra quá trình thẩm tra có được hoàn thành không.

6.3.4.10  Báo cáo thẩm định phần mềm phải nêu rõ đầy đủ cơ sở phần mềm mà đã được thẩm định.

6.3.4.11  Báo cáo thẩm định phải xác định rõ mọi sai khác được biết trong phần mềm và các tác động có thể có đối với việc sử dụng phần mềm.

6.3.4.12  Báo cáo thẩm tra thẩm định phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thẩm tra, trên cơ sở các tài liệu đầu vào từ mục 6.3.2.

Các yêu cầu từ mục 6.3.4.13 đến 6.3.4.14 tham chiếu đến Báo cáo thẩm tra thẩm định phần mềm.

6.3.4.13  Khi đã thiết lập được Kế hoạch thẩm định phần mềm, việc thẩm tra phải đề cập tới:

a) Kế hoạch thẩm định phần mềm đáp ứng các yêu cầu chung về khả năng có thể đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.17 cũng như các yêu cầu cụ thể từ mực 6.3.4.4 đến 6.3.4.6.

b) Sự thống nhất nội bộ của Kế hoạch thẩm định phần mềm.

6.3.4.14  Khi đã thiết lập được Báo cáo thẩm định phần mềm, việc thẩm tra phải đề cập tới:

a) Báo cáo thẩm định phần mềm đáp ứng các yêu cầu chung về khả năng có thể đọc được và khả năng theo dõi theo vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.17 cũng như các yêu cầu cụ thể từ mục 7.7.4.7 đến 7.7.4.11.

b) Sự thống nhất nội bộ của Báo cáo thẩm định phần mềm.

Các kết quả phải được ghi lại trong Báo cáo thẩm tra thẩm định phần mềm

6.3.4.15  Đơn vị thẩm định phải được giao quyền để yêu cầu hoặc thực hiện các hoạt động rà soát, phân tích và kiểm thử bổ sung.

6.3.4.16  Phần mềm chỉ có thể được đưa ra chạy sau khi có sự chấp thuận của Đơn vị thẩm định.

6.3.4.17  Việc mô phỏng và lập mô hình có thể được sử dụng để hỗ trợ cho quá trình thẩm định.

6.4  Đánh giá phần mềm

6.4.1  Mục tiêu

6.4.1.1  Để đánh giá các quá trình vòng đời và các kết quả đầu ra sao cho phần mềm có mức toàn vẹn về an toàn xác định 1-4 và phù hợp với ứng dụng dự định.

6.4.1.2  Đối với phần mềm có mức SIL 0, các yêu cầu của tiêu chuẩn này phải được đáp ứng, nhưng nếu có chứng chỉ tuyên bố phù hợp với tiêu chuẩn TCVN ISO 9001, thì sẽ không cần phải đánh giá.

6.4.2  Tài liệu đầu vào

1) Chỉ dẫn các yêu cầu an toàn hệ thống

2) Chỉ dẫn các yêu cầu phần mềm

3) Tất cả các tài liệu khác cần thiết để tiến hành quá trình đánh giá

6.4.3  Tài liệu đầu ra

1) Kế hoạch đánh giá phần mềm

2) Báo cáo đánh giá phần mềm

3) Báo cáo thẩm tra đánh giá phần mềm

6.4.4  Các yêu cầu

6.4.4.1  Việc đánh giá phần mềm phải được Đơn vị đánh giá tiến hành, với mức độ độc lập như trong mục 5.1.2.6 và 5.1.2.7.

6.4.4.2  Phần mềm có Báo cáo đánh giá phần mềm của một đơn vị đánh giá khác sẽ không cần phải đánh giá lại. Đơn vị đánh giá phải kiểm tra xem phần mềm có phù hợp với việc sử dụng dự định trong môi trường dự định, và việc đánh giá trước đó tuyên bố phần mềm đã đạt được mức toàn vẹn về an toàn ít nhất bằng với mức được yêu cầu.

6.4.4.3  Đơn vị đánh giá phải xem xét tất cả các tài liệu liên quan tới dự án trong suốt quá trình phát triển.

6.4.4.4  Kế hoạch đánh giá phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị đánh giá, trên cơ sở các tài liệu đầu vào ở mục 6.4.2. Nếu phù hợp, có thể sử dụng Kế hoạch đánh giá phần mềm chung hoặc quy trình được ghi lại trước đó. Yêu cầu trong mục 6.4.4.5 tham chiếu tới Kế hoạch đánh giá phần mềm.

6.4.4.5  Kế hoạch đánh giá phần mềm phải bao gồm các nội dung sau:

a) Các nội dung cần đánh giá.

b) Các hoạt động trong quá trình đánh giá và các mối liên quan sau đó đối với các hoạt động kỹ thuật.

c) Các tài liệu cần được xem xét.

d) Các kết luận về chỉ tiêu Đạt/Không đạt và cách xử lý các trường hợp không phù hợp.

e) Các yêu về nội dung và hình thức của Báo cáo đánh giá phần mềm.

6.4.4.6  Báo cáo thẩm tra đánh giá phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thẩm tra, trên cơ sở các tài liệu đầu vào trong mục 6.4.2.

Các yêu cầu trong mục 6.4.4.7 tham chiếu tới Báo cáo thẩm tra đánh giá phần mềm.

6.4.4.7  Khi đã thiết lập được Kế hoạch đánh giá phần mềm, việc thẩm tra phải đề cập tới:

a) Kế hoạch đánh giá phần mềm đáp ứng các yêu cầu chung về khả năng sẵn sàng và khả năng truy vết từ mục 5.3.2 7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.17 cũng như các yêu cầu cụ thể trong mục 6.4.4.5.

b) Sự thống nhất nội bộ của Kế hoạch đánh giá phần mềm.

Các kết quả phải được ghi lại trong Báo cáo thẩm tra đánh giá phần mềm.

6.4.4.8  Đơn vị đánh giá phải đánh giá xem phần mềm của hệ thống có phù hợp với mục đích sử dụng và phản hồi đúng theo các vấn đề về an toàn phát sinh từ Chỉ dẫn các yêu cầu an toàn hệ thống.

6.4.4.9  Đơn vị đánh giá phải đánh giá nếu lựa chọn và áp dụng nhóm các kỹ thuật trong Phụ lục A, phù hợp với quá trình phát triển dự định theo mức toàn vẹn về an toàn được yêu cầu.

Ngoài ra Đơn vị đánh giá phải xem xét mức độ áp dụng của từng kỹ thuật trong Phụ lục A, ví dụ: liệu nó có được áp dụng cho tất cả hoặc chỉ một phần của phần mềm, và phải tìm kiếm các bằng chứng về việc nó đã được áp dụng đúng.

6.4.4.10  Đơn vị đánh giá phải đánh giá về hệ thống quản lý cấu hình, sự thay đổi, bằng chứng về việc sử dụng và áp dụng nó.

6.4.4.11  Đơn vị đánh giá phải xem xét bằng chứng về năng lực của nhân viên dự án theo Phụ lục B và phải đánh giá tổ chức phát triển phần mềm theo mục 5.1.

6.4.4.12  Với mọi phần mềm có các điều kiện áp dụng liên quan tới an toàn, Đơn vị đánh giá phải kiểm tra các sai lệch được ghi lại, sự không phù hợp với các yêu cầu và các vấn đề không phù hợp được ghi lại nếu có tác động đến an toàn, và đưa ra kết luận liệu việc giải thích trong dự án có thể chấp nhận được. Kết quả phải được nêu rõ trong báo cáo đánh giá.

6.4.4.13  Đơn vị đánh giá phải đánh giá các hoạt động thẩm tra và thẩm định và bằng chứng hỗ trợ.

6.4.4.14  Đơn vị đánh giá phải đồng ý về phạm vi và nội dung của kế hoạch kiểm thử phần mềm. Việc đồng ý này phải khẳng định việc có mặt Đơn vị đánh giá trong quá trình kiểm thử.

6.4.4.15  Đơn vị đánh giá có thể tiến hành các hoạt động kiểm toán và kiểm tra (ví dụ: chứng kiến các kiểm thử) trong suốt quá trình phát triển. Đơn vị đánh giá có thể yêu cầu các công việc thẩm tra và thẩm định bổ sung.

Chú thích: đó là cơ hội để Đơn vị đánh giá sớm tham gia vào dự án.

6.4.4.16  Báo cáo đánh giá phần mềm phải được lập thành văn bản do trách nhiệm của Đơn vị đánh giá. Các yêu cầu từ mục 6.4.4.17 đến 6.4.4.19 tham chiếu đến Báo cáo đánh giá phần mềm.

6.4.4.17  Báo cáo đánh giá phần mềm phải đáp ứng các yêu cầu của Kế hoạch đánh giá phần mềm và đưa ra kết luận và các khuyến nghị.

6.4.4.18  Đơn vị đánh giá phải ghi lại các hoạt động của mình trên cơ sở thống nhất với Báo cáo đánh giá phần mềm. Các hoạt động này phải được tổng hợp lại trong Báo cáo đánh giá phần mềm.

6.4.4.19  Đơn vị đánh giá phải xác định rõ và đánh giá mọi sự không phù hợp với các yêu cầu của tiêu chuẩn này và kết luận về tác động của nó đến kết quả cuối cùng. Mọi vấn đề không phù hợp và các lý do không phù hợp phải được liệt kê trong Báo cáo đánh giá phần mềm.

6.5  Đảm bảo chất lượng phần mềm

6.5.1  Mục tiêu

6.5.1.1  Để xác định, giám sát và kiểm soát tất cả các hoạt động trên, thì cần thiết phải có cả biện pháp kỹ thuật và quản lý để đảm bảo phần mềm đạt được chất lượng yêu cầu. Việc này là cần thiết để tạo ra biện pháp phòng vệ chất lượng để phòng các lỗi mang tính hệ thống và để đảm bảo có thể thiết lập được phương thức đánh giá cho phép các hoạt động thẩm tra và thẩm định được tiến hành có hiệu quả.

6.5.1.2  Để đưa ra các bằng chứng về việc tất cả các hoạt động trên đã được tiến hành.

6.5.2  Tài liệu đầu vào

Tất cả các tài liệu sẵn có trong từng giai đoạn của vòng đời.

6.5.2  Tài liệu đầu ra

1) Kế hoạch đảm bảo chất lượng phần mềm

2) Kế hoạch quản lý cấu hình phần mềm, nếu không sẵn có ở mức độ hệ thống

3) Báo cáo thẩm tra đảm bảo chất lượng phần mềm

6.5.4  Các yêu cầu

6.5.4.1  Tất cả các kế hoạch phải được đưa ra ngay khi bắt đầu dự án và được cập nhật trong suốt vòng đời.

6.5.4.2  Tất cả các đơn vị tham gia vào việc phát triển phần mềm phải thực hiện và sử dụng Hệ thống đảm bảo chất lượng phù hợp với tiêu chuẩn TCVN ISO 9000, để hỗ trợ cho các yêu cầu trong tiêu chuẩn này. Chứng nhận phù hợp TCVN ISO 9001 được khuyến nghị cao.

6.5.4.3  Kế hoạch đảm bảo chất lượng phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thẩm tra, trên cơ sở các tài liệu đầu vào của mục 6.5.2.

Các yêu cầu từ mục 6.5.4.4 đến 6.5.4.6 tham chiếu Kế hoạch đảm bảo chất lượng phần mềm.

6.5.4.4  Kế hoạch đảm bảo chất lượng phần mềm phải được lập thành văn bản và phải cụ thể theo dự án. Phải thực hiện các yêu cầu của mục 6.5.4.5.;

6.5.4.5  Tối thiểu, phải cụ thể hoặc tham chiếu các hạng mục sau trong Kế hoạch đảm bảo chất lượng phần mềm.

a) Xác định mô hình vòng đời, bao gồm:

1) Các hoạt động và các nhiệm vụ cơ bản thống nhất với các kế hoạch đặt ra, ví dụ: Kế hoạch an toàn được thiết lập ở cấp Hệ thống;

2) Chỉ tiêu đầu vào và đầu ra của từng hoạt động;

3) Các đầu vào và đầu ra của từng hoạt động;

4) Các hoạt động đảm bảo chất lượng chính;

5) Các đơn vị chịu trách nhiệm cho từng hoạt động.

b) Cấu trúc tài liệu.

c) Kiểm soát tài liệu:

1) Các vai trò liên quan đến việc lập văn bản, kiểm tra và phê duyệt;

2) Phạm vi phân phối;

3) Đạt được.

d) Theo dõi và truy vết các sai lệch;

e) Phương pháp, biện pháp và các chương trình để đảm bảo chất lượng theo mức toàn vẹn về an toàn đã được phân bổ (xem Phụ lục A).

f) Các căn cứ của từng sự kết hợp các kỹ thuật hoặc biện pháp được lựa chọn theo Phụ lục A phù hợp với mức toàn vẹn về an toàn phần mềm được xác định, theo mục 4.7 đến 4.9.

Một số Kế hoạch đảm bảo chất lượng phần mềm cần thông tin có thể có trong các tài liệu khác, như Kế hoạch Quản lý cấu hình phần mềm, Kế hoạch bảo trì, Kế hoạch thẩm tra phần mềm, và Kế hoạch thẩm định phần mềm. Các mục trong Kế hoạch đảm bảo chất lượng phần mềm phải tham chiếu các tài liệu chứa thông tin liên quan. Trong mọi trường hợp nội dung của từng mục trong Kế hoạch đảm bảo chất lượng phần mềm phải được quy định trực tiếp hoặc được tham chiếu tới tài liệu khác.

Các tài liệu được tham chiếu phải được rà soát để đảm bảo chúng đưa ra được tất cả các thông tin cần thiết và đề cập đến đầy đủ các yêu cầu của tiêu chuẩn này.

6.5.4.6  Các hoạt động, tài liệu đảm bảo chất lượng theo yêu cầu của tất cả các mục quy định trong tiêu chuẩn này phải được quy định hoặc tham chiếu trong Kế hoạch đảm bảo chất lượng phần mềm và được cụ thể theo dự án cụ thể.

6.5.4.7  Báo cáo thẩm tra đảm bảo chất lượng phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thẩm tra, trên cơ sở các tài liệu đầu vào của mục 6.5.2.

Các yêu cầu trong mục 6.5.4.8 tham chiếu tới Báo cáo thẩm tra đảm bảo chất lượng phần mềm.

6.5.4.8  Khi đã thiết lập được Kế hoạch đảm bảo chất lượng phần mềm, việc thẩm tra phải đề cập đến:

a) Kế hoạch đảm bảo chất lượng phần mềm đáp ứng các yêu cầu chung về khả năng sẵn sàng và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.17 cũng như các yêu cầu cụ thể từ mục 6.5.4.4 đến 6.5.4.6.

b) Sự thống nhất nội bộ của Kế hoạch đảm bảo chất lượng phần mềm.

Các kết quả phải được ghi lại trong Báo cáo thẩm tra đảm bảo chất lượng phần mềm.

6.5.4.9  Từng tài liệu được lập kế hoạch phải có nội dung quy định chi tiết về việc cập nhật trong toàn bộ dự án: tần suất, trách nhiệm, phương pháp.

6.5.4.10  Từng tài liệu phần mềm và sản phẩm chuyển giao phải được đặt dưới sự kiểm soát cấu hình tại thời điểm phát hành lần đầu.

6.5.4.11  Các thay đổi đối với tất cả các hạng mục trong Kiểm soát quản lý cấu hình phải được phê duyệt và ghi lại.

6.5.4.12  Để bổ sung cho việc phát triển phần mềm, Hệ thống quản lý cấu hình cũng phải đề cập đến môi trường phát triển phần mềm được sử dụng trong vòng đời đầy đủ.

Việc bổ sung này (cần thiết để tái lập việc phát triển và các hoạt động bảo trì) phải bao gồm tất cả các chương trình, các chương trình chuyển đổi, dữ liệu và các tệp kiểm thử, các tệp thông số hóa, và các nền tảng phần cứng hỗ trợ.

6.5.4.13  Nhà cung cấp phải thiết lập các quy trình lưu trữ và duy trì để kiểm soát các nhà cung cấp bên ngoài, bao gồm:

- Các biện pháp và các biên bản liên quan để đảm bảo phần mềm được các đơn vị bên ngoài cung cấp tuân thủ chặt chẽ các yêu cầu được thiết lập. Phần mềm được phát triển trước đó phải được đảm bảo phù hợp với mức toàn vẹn về an toàn và độ tin cậy được yêu cầu. Phần mềm mới phải được phát triển và bảo trì phù hợp với Kế hoạch đảm bảo chất lượng phần mềm của nhà cung cấp hoặc Kế hoạch đảm bảo chất lượng phần mềm được nhà cung cấp bên ngoài chuẩn bị phù hợp với Kế hoạch đảm bảo chất lượng phần mềm của nhà cung cấp:

- Các biện pháp và các biên bản liên quan để đảm bảo các yêu cầu được đưa ra cho Nhà cung cấp bên ngoài là phù hợp và hoàn chỉnh.

6.5.4.14  Phải xem xét cẩn thận khả năng theo dõi theo vết theo các yêu cầu trong việc thẩm định hệ thống liên quan tới an toàn và phải đưa ra cách thức để chứng minh trong tất cả các giai đoạn của vòng đời.

6.5.4.15  Trong nội dung của tiêu chuẩn này, và theo mức độ phù hợp với mức toàn vẹn về an toàn phần mềm được quy định, khả năng truy vết phải đề cập cụ thể tới:

a) Khả năng truy vết các yêu cầu theo thiết kế hoặc các đối tượng khác đáp ứng chúng.

b) Khả năng truy vết các đối tượng thiết kế theo các đối tượng thực hiện chúng.

c) Khả năng truy vết các yêu cầu và các đối tượng thiết kế theo các kiểm thử (thành phần, sự tích hợp, các kiểm thử toàn bộ) và các phân tích để xác nhận chúng.

Khả năng truy vết phải phụ thuộc vào việc quản lý cấu hình.

6.5.4.16  Trong các trường hợp đặc biệt, ví dụ: phần mềm đã có trước đó hoặc phần mềm mẫu, khả năng theo dõi theo vết có thể được thiết lập sau khi chạy và/hoặc ghi lại mã, nhưng trước khi thẩm tra/thẩm định. Trong trường hợp này, phải thể hiện được việc thẩm tra/thẩm định là hiệu quả, đúng với khả năng theo dõi theo vết trong tất cả các giai đoạn.

6.5.4.17  Các đối tượng của các yêu cầu, thiết kế hoặc sự hoạt động mà không thể truy vết đầy đủ thì phải được chứng minh là không phụ thuộc vào mức toàn vẹn về an toàn của hệ thống.

6.6  Cải tiến và kiểm soát sự thay đổi

6.6.1  Mục tiêu

6.6.1 1  Để đảm bảo phần mềm hoạt động như được yêu cầu, duy trì mức toàn vẹn về an toàn và độ tin cậy khi cải tiến phần mềm.

6.6.1.2  Các đối tượng này được quản lý bởi Đơn vị quản lý cấu hình.

6.6.2  Các tài liệu đầu vào

1) Kế hoạch đảm bảo chất lượng phần mềm

2) Kế hoạch quản lý cấu hình phần mềm

3) Tất cả các tài liệu thiết kế, phát triển và phân tích

4) Các yêu cầu thay đổi

5) Phân tích tác động của thay đổi và quá trình phê duyệt.

6.6.3  Các tài liệu đầu ra

1) Tất cả các tài liệu đầu vào bị thay đổi

2) Các biên bản thay đổi phần mềm (xem 9.2.4.11)

3) Các biên bản cấu hình mới

6.6.4  Các yêu cầu

6.6.4.1  Quá trình quản lý sự thay đổi phải xác định tối thiểu các vấn đề sau:

a) Các tài liệu cần thiết của các hoạt động báo cáo vấn đề và/hoặc sửa chữa, với mục đích đưa ra phản hồi cho đơn vị quản lý có trách nhiệm.

b) Phân tích thông tin thu thập được trong báo cáo vấn đề để xác định các nguyên nhân.

c) Các hoạt động sau đó để báo cáo, theo dõi và xử lý các vấn đề được xác định trong giai đoạn phát triển và trong quá trình bảo trì phần mềm.

d) Các trách nhiệm về tổ chức cụ thể liên quan đến việc phát triển và bảo trì phần mềm.

e) Cách thức áp dụng các kiểm soát để đảm bảo các hoạt động sửa chữa đã được thực hiện và có hiệu quả.

f) Phân tích tác động của thay đổi đối với thành phần phần mềm trong quá trình phát triển hoặc đã được chuyển giao.

g) Phân tích tác động phải nêu rõ các hoạt động thẩm tra lại, thẩm định lại, đánh giá lại cần thiết cho sự thay đổi.

h) Khi áp dụng nhiều thay đổi, phân tích tác động phải xem xét tác động tích lũy.

i) Chú thích: Một số thay đổi có thể yêu cầu tích lũy việc kiểm thử lại toàn bộ.

j) Quá trình phê duyệt trước khi thực hiện.

6.6.4.2  Tất cả các thay đổi phải bắt đầu từ việc quay lại một giai đoạn phù hợp ở trong vòng đời. Tất cả các giai đoạn sau đó phải được tiến hành phù hợp với các quy trình được quy định cho các giai đoạn cụ thể phù hợp với các yêu cầu trong tiêu chuẩn này.

6.7  Các ngôn ngữ và chương trình hỗ trợ

6.7.1  Mục tiêu

6.7.1.1  Mục tiêu là đưa ra bằng chứng cho thấy các hư hỏng tiềm ẩn của các chương trình không tác động xấu tới thông số đầu ra của bộ chương trình được tích hợp theo một phương thức liên quan đến an toàn mà không được phát hiện bằng các biện pháp tổ chức và / hoặc kỹ thuật bên ngoài chương trình đó. Để thực hiện được việc này, các chương trình phần mềm được phân thành ba loại là T1, T2 và T3 tương ứng (xem định nghĩa ở mục 3.1).

6.7.2  Các tài liệu đầu vào

Chỉ dẫn hoặc hướng dẫn sử dụng các chương trình.

6.7.3  Các tài liệu đầu ra

Báo cáo thẩm định các chương trình (khi cần thiết, xem 6.7.4.4 hoặc 6.7.4.6).

6.7.4  Các yêu cầu

6.7.4.1  Các chương trình phần mềm phải được lựa chọn như một phần không thể tách rời trong các hoạt động phát triển phần mềm.

Chú thích: Các chương trình phù hợp hỗ trợ cho việc phát triển phần mềm nên được sử dụng để làm tăng mức toàn vẹn của phần mềm bằng cách giảm khả năng phát sinh hoặc khả năng không phát hiện các sự cố trong quá trình phát triển. Ví dụ về các chương trình liên quan tới các giai đoạn của vòng đời phát triển phần mềm bao gồm:

a) Các chương trình chuyển đổi hoặc chuyển dịch phần mềm hoặc dạng thiết kế (ví dụ: nội dung hoặc sơ đồ) từ một cấp cơ bản sang một cấp khác: các chương trình cải tiến thiết kế, các chương trình biên dịch, các chương trình hợp ngữ, các chương trình kết nối, các chương trình chạy và các chương trình tạo mã.

b) Các chương trình thẩm tra và thẩm định như chương trình phân tích mã tĩnh, màn hình giám sát kiểm thử, các chương trình hỗ trợ chứng minh nguyên lý, các chương trình mô phỏng và các chương trình kiểm tra mô hình.

c) Các chương trình chuẩn đoán được sử dụng để duy trì và giám sát phần mềm dưới các điều kiện hoạt động.

d) Các chương trình về hạ tầng như các hệ thống hỗ trợ quá trình xây dựng.

e) Các chương trình kiểm soát cấu hình như các chương trình kiểm soát định dạng.

f) Các chương trình dữ liệu ứng dụng tạo ra hoặc duy trì các dữ liệu cần thiết để xác định các thông số và thực hiện các chức năng hệ thống, ví dụ: các thông số về chức năng, các dải biên độ, các mức cảnh báo và đóng ngắt các tình trạng đầu ra được chấp nhận khi có hư hỏng, các bố trí địa lý.

Các chương trình được lựa chọn nên có khả năng kết hợp lại được với nhau. Trong tiêu chuẩn này, các chương trình sẽ kết hợp với nhau nếu các kết quả từ một chương trình có nội dung và định dạng phù hợp để tự động nhập vào chương trình sau đó, từ đó giảm thiểu tối đa khả năng phát sinh lỗi của con người trong quá trình tái lập hoạt động ở các kết quả trung gian.

Phải lựa chọn các chương trình và chứng minh nó tương thích với các yêu cầu của việc ứng dụng.

Phải xem xét tính sẵn sàng của các chương trình phù hợp để đưa ra các dịch vụ cần thiết trong toàn bộ vòng đời của phần mềm.

6.7.4.2  Việc lựa chọn các chương trình loại T2 và T3 phải được nêu rõ lý do (xem 7.3.4.12). Việc giải thích phải bao gồm xác định các hư hỏng tiềm ẩn có thể có trong các đầu ra của chương trình và các biện pháp để tránh hoặc xử lý các hư hỏng này.

6.7.4.3  Tất cả các chương trình loại T2 và T3 phải có chỉ dẫn kỹ thuật hoặc hướng dẫn sử dụng xác định rõ ràng sự hoạt động của chương trình và mọi hướng dẫn hoặc ràng buộc liên quan đến việc sử dụng.

6.7.4.4  Đối tới từng chương trình loại T3, phải có sẵn các bằng chứng cho thấy đầu ra của chương trình phù hợp với chỉ dẫn kỹ thuật của đầu ra hoặc các hư hỏng trong đầu ra là được phát hiện. Bằng chứng có thể dựa trên cùng các bước cần thiết để xử lý thủ công giống như khi thay thế chương trình và căn cứ được đưa ra, nếu những bước này bị thay thế bằng các bước xử lý khác (ví dụ: thẩm định chương trình). Bằng chứng có thể dựa trên:

a) Sự kết hợp phù hợp về lịch sử quá trình sử dụng tốt trong cùng các môi trường và cho cùng các ứng dụng giống nhau (trong tổ chức hoặc các tổ chức khác).

b) Việc thẩm định chương trình như quy định trong mục 6.7.4.5.

c) Việc mã hóa ràng buộc khác nhau cho phép phát hiện và kiểm soát các hư hỏng gây ra các sự cố của chương trình.

d) Sự phù hợp về mức toàn vẹn về an toàn trong việc phân tích rủi ro các quá trình và các quy trình có sử dụng chương trình.

e) Các biện pháp phù hợp khác để tránh hoặc xử lý các hư hỏng của chương trình.

Chú thích 1: Lịch sử về định dạng có thể đảm bảo độ chắc chắn của chương trình và biên bản về các lỗi / các vấn đề không rõ ràng liên quan đến quá trình sử dụng của công cụ trong môi trường đó.

Chú thích 2: Bằng chứng được liệt kê cho loại T3 cũng có thể sử dụng cho các chương trình loại T2 khi kết luận về độ chính xác của kết quả.

6.7.4.5  Phải lưu lại các kết quả của việc thẩm định chương trình, bao gồm các kết quả sau:

a) Biên bản về các hoạt động thẩm định;

b) Phiên bản hướng dẫn sử dụng chương trình đang được sử dụng;

c) Các chức năng của chương trình đang được thẩm định;

d) Các chương trình và thiết bị được sử dụng;

e) Các kết quả của hoạt động thẩm định; các kết quả thẩm định được ghi lại phải nêu rõ hoặc phần mềm đã được thẩm định đạt hoặc các lý do không đạt;

f) Các trường hợp kiểm thử và các kết quả sử dụng cho các phân tích sau đó;

g) Sự không thống nhất giữa các kết quả mong muốn và các kết quả thực tế.

6.7.4.6  Khi không có bằng chứng về sự phù hợp với mục 6.7.4.4, phải có các biện pháp hiệu quả để kiểm soát các hư hỏng của phần mềm liên quan đến an toàn có thể được hoạt động do các lỗi thuộc về chương trình.

Chú thích 1: Ví dụ: sự phát sinh các mã ràng buộc khác nhau cho phép phát hiện và kiểm soát các hư hỏng gây ra các sự cố của chương trình chuyển đổi.

Chú thích 2: Ví dụ: Sự phù hợp về mục đích của các chương trình biên dịch không đáng tin có thể được giải thích như sau.

Mã đối tượng của chương trình biên dịch phụ thuộc vào sự kết hợp các kiểm thử, kiểm tra và phân tích, có thể đảm bảo độ chính xác của đoạn mã theo mức thống nhất với Mức toàn vẹn về an toàn mục tiêu. Cụ thể, áp dụng các nội dung sau cho tất cả các kiểm thử, kiểm tra và phân tích:

- Việc kiểm thử phải cho thấy chương trình thực hiện đã xử lý ở mức độ cao đầy đủ của đoạn mã chạy. Nếu có đoạn mã nào đó không đạt được bằng kiểm thử, phải thể hiện bằng kiểm tra hoặc phân tích cho thấy chức năng liên quan hoạt động chính xác khi đoạn mã được truy cập đến đối tượng.

- Các kiểm tra và phân tích được áp dụng cho đoạn mã đối tượng và phải thể hiện là có khả năng phát hiện ra các dạng lỗi có thể phát sinh từ một sai sót trong chương trình biên dịch.

- Sau khi kiểm thử, kiểm tra và phân tích, chương trình biên dịch sẽ không thực hiện thêm các chuyển đổi.

- Nếu có thêm quá trình biên dịch hoặc chuyển đổi được tiến hành thì tất cả các kiểm thử, kiểm tra và phân tích sẽ được lặp lại.

6.7.4.7  Việc thể hiện phần mềm hoặc thiết kế (gồm có ngôn ngữ lập trình) được lựa chọn phải:

a) Có một chương trình chuyển đổi được đánh giá về mức độ phù hợp với mục đích, bao gồm cả việc đánh giá theo các tiêu chuẩn quốc tế hoặc quốc gia, nếu phù hợp.

b) Phù hợp với các đặc tính của việc ứng dụng.

c) Chứa các tính năng tạo điều kiện thuận lợi để phát hiện các lỗi về thiết kế hoặc lập trình,

d) Hỗ trợ các tính năng phù hợp với biện pháp thiết kế.

Ngôn ngữ lập trình là một trong các loại thể hiện phần mềm hoặc thiết kế. Chương trình chuyển đổi sẽ chuyển dạng thể hiện phần mềm hoặc thiết kế (ví dụ: nội dung hoặc sơ đồ) từ mức độ nền tảng sang mức độ khác. Ví dụ về chương trình chuyển đổi bao gồm: các chương trình cải tiến thiết kế, các chương trình chạy, chương trình hợp ngữ, các chương trình liên kết, các chương trình tải và các chương trình tạo mã.

Việc đánh giá Chương trình chuyển đổi có thể được thực hiện cho một dự án ứng dụng cụ thể, hoặc cho một loại ứng dụng. Ở trường hợp loại ứng dụng, người sử dụng chương trình phải có sẵn tất cả các thông tin cần thiết về chương trình liên quan đến việc sử dụng dự định và phù hợp với việc sử dụng chương trình. Việc đánh giá chương trình đối với một dự án cụ thể có thể được giảm bớt sau đó để kiểm tra khả năng phù hợp tổng thể của chương trình cho dự án và sự phù hợp với “chỉ dẫn kỹ thuật hoặc hướng dẫn sử dụng” (ví dụ: sử dụng đúng chương trình). Việc sử dụng đúng chương trình có thể bao gồm các hoạt động thẩm tra bổ sung có trong dự án cụ thể.

Có thể sử dụng các hỗ trợ trong quá trình thẩm định để đánh giá mức độ phù hợp với mục đích của chương trình chuyển đổi theo chỉ tiêu xác định, chỉ tiêu này phải có các yêu cầu về chức năng và phi chắc năng. Đối với các yêu cầu chức năng của chương trình chuyển đổi, việc kiểm thử động có thể là một kỹ thuật thẩm định chính. Nếu có thể thì phải sử dụng các hỗ trợ kiểm thử tự động.

6.7.4.8  Khi không thể đáp ứng đầy đủ 6.7.4.7, phải đánh giá và làm rõ mức độ phù hợp với mục đích của ngôn ngữ lập trình và các biện pháp bổ sung đề cập đến tất cả các thiếu sót đã được xác định của ngôn ngữ lập trình.

Chú thích: Xem chú thích 2 trong mục 6.7.4.6.

6.7.4.9  Khi thực hiện việc tạo mã tự động hoặc chuyển đổi tự động tương đương, khả năng phù hợp của chương trình chuyển đổi tự động trong quá trình phát triển phần mềm liên quan tới an toàn phải được đánh giá tại thời điểm trong vòng đời phát triển khi lựa chọn được các chương trình hỗ trợ phát triển.

6.7.4.10  Quản lý cấu hình phải đảm bảo rằng đối với các chương trình loại T2 và T3, chỉ sử dụng các phiên bản đã được làm rõ.

6.7.4.11  Mỗi phiên bản mới của chương trình được sử dụng phải được làm rõ căn cứ (xem Bảng 1). Việc làm rõ này có thể dựa trên bằng chứng được đưa ra cho phiên bản trước đó nếu có bằng chứng đầy đủ về việc:

a) Các sai lệch về chức năng (nếu có) sẽ không ảnh hưởng đến khả năng tương thích của chương trình với phần còn lại của bộ chương trình.

b) Phiên bản mới không có khả năng có các sự cố mới đáng kể và chưa được nhận biết.

Chú thích: Bằng chứng về phiên bản mới không có khả năng có các lỗi mới chưa được nhận biết có thể dựa trên việc xác định tin cậy các thay đổi và dựa trên các phân tích về các hoạt động thẩm tra và thẩm định được tiến hành.

6.7.4.12  Mối quan hệ giữa các loại chương trình và các điều khoản áp dụng quy định trong Bảng 1.

Bảng 1. Mối quan hệ giữa các loại chương trình và các điều khoản áp dụng

7  Phát triển phần mềm chung

7.1  Vòng đời và tài liệu ghi lại đối với phần mềm chung

7.1.1  Mục tiêu

7.1.1.1  Để đưa ra sự mô tả về chính phần mềm, từ các mức độ trừu tượng cao hơn xuống các cải tiến chi tiết, để tạo ra cơ sở chứng minh độ an toàn đạt được cũng như cho các hoạt động bảo trì trong tương lai.

7.1.2  Các yêu cầu

7.1.2.1  Phải lập ra các tài liệu được liệt kê trong Bảng A.1 cho phần mềm chung theo mức toàn vẹn về an toàn phần mềm được yêu cầu.

7.1.2.2  Chuỗi các tài liệu chuyển giao như được mô tả trong Bảng A.1 thể hiện mô hình thác nước tuyến tính lý tưởng. Tuy nhiên mô hình này không dự định để tham chiếu cho các hoạt động chiến lược và liên kết, do thường khó khăn trong quá trình đạt được sự phù hợp cao trong hoạt động thực tế. Các giai đoạn có thể chồng lên nhau nhưng các hoạt động thẩm tra và thẩm định phải chứng minh sự thống nhất của các đầu vào và đầu ra (các tài liệu và phần mềm) ở giữa và trong các giai đoạn.

Tuy nhiên, mục đích chính của việc dự kiến tài liệu lưu trữ là để đưa ra sự mô tả về chính phần mềm, từ mức độ trừu tượng cao hơn xuống các cải tiến chi tiết, để tạo ra cơ sở cho việc chứng minh độ an toàn đạt được cũng như các hoạt động bảo trì trong tương lai.

7.2  Các yêu cầu phần mềm

7.2.1  Mục tiêu

7.2.1.1  Để mô tả tập hợp hoàn chỉnh các yêu cầu đối với phần mềm đáp ứng tất cả các yêu cầu hệ thống an toàn và đưa ra tập hợp hoàn chỉnh các loại tài liệu cho từng giai đoạn tiếp theo.

7.2.1.2  Để mô tả Chỉ dẫn kỹ thuật kiểm thử tổng thể phần mềm.

7.2.2  Các tài liệu đầu vào

1) Chỉ dẫn các yêu cầu hệ thống

2) Chỉ dẫn các yêu cầu về an toàn hệ thống

3) Mô tả cấu trúc hệ thống

4) Chỉ dẫn kỹ thuật giao diện với bên ngoài (ví dụ: Chỉ dẫn kỹ thuật giao diện phần mềm / phần mềm, chỉ dẫn kỹ thuật giao diện phần mềm / phần cứng)

5) Kế hoạch đảm bảo chất lượng phần mềm

6) Kế hoạch thẩm định phần mềm

7.2.3  Các tài liệu đầu ra

1) Chỉ dẫn các yêu cầu phần mềm

2) Chỉ dẫn kiểm thử tổng thể phần mềm

3) Báo cáo thẩm tra các yêu cầu phần mềm

7.2.4  Các yêu cầu

7.2.4.1  Chỉ dẫn các yêu cầu phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị quản lý các yêu cầu, trên cơ sở các tài liệu đầu vào từ mục 7.2.2.

Các yêu cầu từ mục 7.2.4.2 đến 7.2.4.15 tham chiếu đến Chỉ dẫn các yêu cầu phần mềm.

7.2.4.2  Chỉ dẫn các yêu cầu phần mềm phải thể hiện các đặc tính cần thiết của phần mềm đang được phát triển. Những đặc tính này (tất cả đều đã được xác định trong ISO/IEC 9126 (ngoại trừ các đặc tính an toàn)), phải bao gồm:

a) Chức năng (bao gồm khả năng và sự hiệu năng theo thời gian phản hồi).

b) Độ chắc chắn và khả năng bảo trì.

c) Độ an toàn (bao gồm các chức năng về an toàn và các mức độ toàn vẹn về an toàn phần mềm liên quan).

d) Tính hiệu quả.

e) Khả năng sử dụng.

f) Khả năng thay đổi.

7.2.4.3  Mức toàn vẹn về an toàn phần mềm phải được đưa ra như được quy định trong Điều 4 và được ghi lại trong Chỉ dẫn các yêu cầu phần mềm.

7.2.4.4  Theo mức toàn vẹn về an toàn phần mềm được yêu cầu, Chỉ dẫn các yêu cầu phần mềm phải được thể hiện và được cấu trúc sao cho:

a) Hoàn chỉnh, chính xác rõ ràng, không mập mờ, có thể thẩm tra, có thể kiểm thử, có thể duy tu bảo dưỡng và khả thi.

b) Có thể theo dõi theo vết theo tất cả các tài liệu đầu vào.

7.2.4.5  Chỉ dẫn các yêu cầu phần mềm phải bao gồm các dạng thể hiện và mô tả để các cá nhân chịu trách nhiệm liên quan trong toàn bộ vòng đời hệ thống có thể hiểu được.

7.2.4.6  Chỉ dẫn các yêu cầu phần mềm phải xác định và ghi lại tất cả các giao diện với các hệ thống khác bên trong hoặc bên ngoài thiết bị được điều khiển, bao gồm người vận hành, bất kì khi nào có sự tồn tại liên kết trực tiếp hoặc được lập kế hoạch.

7.2.4.7  Tất cả các chế độ hoạt động liên quan phải được đưa ra chi tiết trong Chỉ dẫn các yêu cầu phần mềm.

7.2.4.8  Tất cả các chế độ hoạt động liên quan của các thiết bị điện tử lập trình, đặc biệt ở chế độ vận hành hư hỏng, phải được nêu chi tiết trong Chỉ dẫn các yêu cầu phần mềm.

7.2.4.9  Mọi ràng buộc giữa phần cứng và phần mềm phải được xác định và được ghi lại trong Chỉ dẫn các yêu cầu phần mềm.

7.2.4.10  Chỉ dẫn các yêu cầu phần mềm phải xem xét việc tự kiểm tra phần mềm và kiểm tra phần cứng bằng phần mềm theo mức độ mô tả được yêu cầu của việc ghi chép hệ thống. Việc tự kiểm tra phần mềm bao gồm cả việc phát hiện và báo lỗi hư hỏng và lỗi của chính phần mềm.

7.2.4.11  Chỉ dẫn các yêu cầu phần mềm phải bao gồm các yêu cầu đối với việc kiểm thử định kỳ các chức năng theo mức độ do Chỉ dẫn các yêu cầu an toàn hệ thống yêu cầu.

7.2.4.12  Chỉ dẫn các yêu cầu phần mềm phải bao gồm các yêu cầu cho phép kiểm thử được tất cả các chức năng về an toàn trong suốt quá trình vận hành tổng thể hệ thống, theo mức độ do Chỉ dẫn các yêu cầu an toàn hệ thống yêu cầu.

7.2.4.13  Tất cả các chức năng được phần mềm thực hiện, đặc biệt là các chức năng liên quan tới việc đạt được mức toàn vẹn về an toàn hệ thống yêu cầu, thì những chức năng này phải được xác định rõ ràng trong Chỉ dẫn các yêu cầu phần mềm.

7.2.4.14  Khi phần mềm được yêu cầu thực hiện các chức năng không liên quan tới an toàn thì những chức năng này phải được xác định rõ ràng trong Chỉ dẫn các yêu cầu phần mềm.

7.2.4.15  Chỉ dẫn các yêu cầu phần mềm phải được hỗ trợ bằng các kỹ thuật và các biện pháp trong Bảng A.2. Phải làm rõ các kết hợp được lựa chọn thỏa mãn mục 4.8 và 4.9.

7.2.4.16  Chỉ dẫn kiểm thử tổng thể phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị kiểm thử, trên cơ sở Chỉ dẫn các yêu cầu phần mềm.

Các yêu cầu từ mục 7.2.4.17 đến 7.2.4.19 tham chiếu đến Chỉ dẫn kỹ thuật kiểm thử tổng thể phần mềm.

7.2.4.17  Chỉ dẫn kỹ thuật kiểm thử tổng thể phần mềm phải mô tả các kiểm thử được tiến hành trên phần mềm hoàn chỉnh.

7.2.4.18  Chỉ dẫn kỹ thuật kiểm thử tổng thể phần mềm phải được hỗ trợ bằng các kỹ thuật và các biện pháp trong Bảng A.7. Phải làm rõ các kết hợp được lựa chọn thỏa mãn mục 4.8 và 4.9.

7.2.4.19  Chỉ dẫn kiểm thử tổng thể phần mềm phải xác định rõ các trường hợp kiểm thử cho từng chức năng được yêu cầu, bao gồm:

a) Các tín hiệu đầu vào được yêu cầu với các dải trị số và các giá trị của chúng.

b) Các tín hiệu đầu ra được dự báo với các dải trị số và các giá trị của chúng.

c) Các chỉ tiêu kiểm thử thành công, bao gồm hai mặt hiệu năng và chất lượng.

7.2.4.20  Báo cáo thẩm tra các yêu cầu phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thẩm tra, trên cơ sở của Chỉ dẫn các yêu cầu an toàn hệ thống, Chỉ dẫn các yêu cầu phần mềm, Chỉ dẫn kiểm thử tổng thể phần mềm và Kế hoạch đảm bảo chất lượng phần mềm.

Các yêu cầu từ mục 7.2.4.21 đến 7.2.4.22 tham chiếu đến Báo cáo thẩm tra các yêu cầu phần mềm.

7.2.4.21  Báo cáo thẩm tra các yêu cầu phần mềm phải được lập thành văn bản phù hợp với các yêu cầu chung được thiết lập cho tất cả các Báo cáo thẩm tra (xem 6.2.4.13).

7.2.4.22  Khi đã thiết lập được Chỉ dẫn các yêu cầu phần mềm, việc thẩm tra phải đề cập tới:

a) Chỉ dẫn các yêu cầu phần mềm đáp ứng đầy đủ của các yêu cầu được đưa ra trong Chỉ dẫn các yêu cầu hệ thống, Chỉ dẫn các yêu cầu an toàn hệ thống và Kế hoạch đảm bảo chất lượng phần mềm.

b) Chỉ dẫn các yêu cầu phần mềm đáp ứng được các yêu cầu chung về khả năng sẵn sàng và khả năng theo dõi theo vết trong các mục từ 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.17 cũng như các yêu cầu cụ thể từ mục 7.2.4.2 đến 7.2.4.15.

c) Sự đầy đủ của Chỉ dẫn kỹ thuật kiểm thử tổng thể phần mềm như là Chỉ dẫn các yêu cầu phần mềm.

d) Xác định mọi hoạt động bổ sung để chứng minh phạm vi chính xác của các yêu cầu không thể kiểm thử được.

e) Sự thống nhất nội bộ trong Chỉ dẫn các yêu cầu phần mềm.

f) Chỉ dẫn các yêu cầu phần mềm đáp ứng đầy đủ hoặc tính tới các ràng buộc giữa phần cứng và phần mềm.

Các kết quả phải được ghi lại trong Báo cáo thẩm tra các yêu cầu phần mềm.

7.3  Cấu trúc và thiết kế

7.3.1  Mục tiêu

7.3.1.1  Để xây dựng cấu trúc phần mềm đạt được các yêu cầu của phần mềm.

7.3.1.2  Để xác định và đánh giá mức độ tương tác phần cứng / phần mềm đối với an toàn.

7.3.1.3  Để lựa chọn phương pháp thiết kế nếu trước đó chưa xác định được.

7.3.1.4  Để thiết kế phần mềm có mức toàn vẹn về an toàn phần mềm xác định từ các tài liệu đầu vào.

7.3.1.5  Để đảm bảo hệ thống tạo ra và phần mềm của nó có thể sẵn sàng kiểm thử từ ban đầu. Khi việc thẩm tra và kiểm thử là công việc chính trong quá trình thẩm định, phải xem xét cụ thể các yêu cầu thẩm tra và kiểm thử trong quá trình hoạt động.

7.3.2  Tài liệu đầu vào

1) Chỉ dẫn các yêu cầu phần mềm.

7.3.3  Tài liệu đầu ra

1) Chỉ dẫn cấu trúc phần mềm.

2) Chỉ dẫn thiết kế phần mềm

3) Chỉ dẫn giao diện phần mềm

4) Chỉ dẫn kiểm thử tích hợp phần mềm

5) Chỉ dẫn kiểm thử tích hợp phần mềm / phần cứng

6) Báo cáo thẩm tra cấu trúc và thiết kế phần mềm

7.3.4  Các yêu cầu

7.3.4.1  Chỉ dẫn cấu trúc phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thiết kế, trên cơ sở của Chỉ dẫn các yêu cầu phần mềm.

Các yêu cầu từ mục 7.3.4.2 đến 7.3.4.14 tham chiếu Chỉ dẫn cấu trúc phần mềm.

7.3.4.2  Phải thiết lập và nêu chi tiết Cấu trúc phần mềm được đề xuất trong Chỉ dẫn cấu trúc phần mềm.

7.3.4.3  Chỉ dẫn cấu trúc phần mềm phải xem xét tính khả thi của việc đạt được Chỉ dẫn các yêu cầu phần mềm theo mức toàn vẹn về an toàn phần mềm yêu cầu.

Chú thích: Cấu trúc phần mềm phải giảm thiểu tối đa mức độ và tính phức tạp của phần ứng dụng về an toàn.

7.3.4.4  Chỉ dẫn cấu trúc phần mềm phải xác định, phân tích và nêu chi tiết mức độ của tất cả các tương tác phần cứng/phần mềm.

7.3.4.5  Chỉ dẫn cấu trúc phần mềm phải xác định rõ tất cả các thành phần của phần mềm và đối với những thành phần này phải chỉ rõ:

a) Liệu những thành phần này là mới hay là cũ.

b) Liệu những thành phần này đã được thẩm định trước đó chưa và các điều kiện thẩm định.

c) Mức toàn vẹn về an toàn phần mềm của thành phần.

7.3.4.6  Các thành phần của phần mềm phải

a) Bao trùm một tập hợp xác định các yêu cầu phần mềm.

b) Được xác định rõ ràng và có các định dạng độc lập bên trong hệ thống quản lý cấu hình.

7.3.4.7  Việc sử dụng phần mềm thương mại phổ biến phải xem xét đến những hạn chế dưới đây:

a) Đối với tất cả các mức toàn vẹn về an toàn phần mềm, phải xác định và ghi lại rõ ràng các thông tin dưới đây:

- Các yêu cầu mà phần mềm hiện có trước đó dự định đáp ứng;

- Các giả thiết về môi trường hoạt động của phần mềm trước đó;

- Các giao diện với các bộ phận khác trong phần mềm.

b) Đối với tất cả các mức toàn vẹn về an toàn phần mềm, quá trình thẩm định toàn bộ phần mềm đã thực hiện thẩm định phần mềm đã có trước đó.

c) Đối với các mức toàn vẹn an toàn phần mềm SIL 3 hoặc SIL 4, phải chú ý những vấn đề sau:

- Phải tiến hành phân tích các sự cố hư hỏng có thể của phần mềm hiện có trước đó và các hậu quả của những hư hỏng này;

- Phải xác định chiến lược phát hiện các hư hỏng của phần mềm hiện có trước đó và bảo vệ hệ thống không bị những hư hỏng này;

- Quá trình thẩm tra và thẩm định phải đảm bảo:

1) Phần mềm hiện có trước đó đáp ứng được các yêu cầu đã được phân bổ.

2) Các hư hỏng của phần mềm hiện có trước đó phải được phát hiện và hệ thống tích hợp phần mềm hiện có trước đó được bảo vệ không bị những hư hỏng này.

3) Đáp ứng được các giả thiết về môi trường hoạt động của phần mềm hiện có trước đó.

d) Phần mềm hiện có trước đó phải đính kèm bản mô tả chính xác đầy đủ (ví dụ: bị giới hạn theo các chức năng được sử dụng) và hoàn chỉnh (ví dụ: các chức năng, các ràng buộc và bằng chứng). Bản mô tả phải có các ràng buộc đối với phần cứng và/hoặc phần mềm để Đơn vị tích hợp nhận thức được và xem xét trong quá trình ứng dụng. Cụ thể bản mô tả này sẽ thiết lập phương tiện để đưa thông tin cho Đơn vị tích hợp về phần mềm được xây dựng, các đặc tính, sự hoạt động kỹ thuật của nó.

Chú thích: Có thể sử dụng bằng chứng mang tính thống kê trong Kế hoạch thẩm định phần mềm hiện có trước đó.

7.3.4.8  Ưu tiên sử dụng các thành phần phần mềm đã được thẩm tra hiện có được xây dựng theo tiêu chuẩn này trong quá trình thiết kế bất cứ khi nào có thể.

7.3.4.9  Nếu phần mềm bao gồm các thành phần có các mức toàn vẹn về an toàn phần mềm khác nhau thì tất cả các thành phần phần mềm phải được xử lý như đối với các mức cao nhất, trừ khi có bằng chứng về sự độc lập giữa các thành phần có mức toàn vẹn về an toàn phần mềm cao hơn và các thành phần có mức toàn vẹn về an toàn phần mềm thấp hơn. Phải ghi lại bằng chứng trong Chỉ dẫn cấu trúc phần mềm.

7.3.4.10  Chỉ dẫn cấu trúc phần mềm phải xác định rõ chiến lược phát triển phần mềm theo mức độ toàn vẹn về an toàn được yêu cầu. Chỉ dẫn cấu trúc phần mềm phải được thể hiện và cấu trúc theo cách:

a) Hoàn chỉnh, chính xác, rõ ràng, không mập mờ, có thể thẩm tra, có thể kiểm thử, có thể duy trì và khả thi.

b) Có thể truy vết theo Chỉ dẫn các yêu cầu phần mềm.

7.3.4.11  Các biện pháp xử lý các sự cố phải có trong Chỉ dẫn cấu trúc phần mềm để đạt được sự cân bằng giữa việc các chiến lược tránh sự cố và các chiến lược xử lý sự cố.

7.3.4.12  Chỉ dẫn cấu trúc phần mềm phải kết luận rằng các kỹ thuật, biện pháp và các chương trình được lựa chọn tạo thành một nhóm thỏa mãn Chỉ dẫn các yêu cầu phần mềm theo mức toàn vẹn về an toàn phần mềm yêu cầu.

7.3.4.13  Chỉ dẫn cấu trúc phần mềm phải tính tới các yêu cầu từ mục 8.4.8 khi phần mềm được cấu hình bằng dữ liệu hoặc các thuật toán ứng dụng.

7.3.4.14  Chỉ dẫn cấu trúc phần mềm phải lựa chọn các kỹ thuật và các biện pháp ở Bảng A.3, Phải kết luận sự kết hợp được lựa chọn thỏa mãn mục 4.8 và 4.9.

7.3.4.15  Phải cân bằng giữa quy mô và mức độ phức tạp của cấu trúc phần mềm được phát triển.

7.3.4.16  Có thể sử dụng cách lập mẫu trong mọi giai đoạn để tìm ra các yêu cầu hoặc có được cái nhìn chi tiết hơn về các yêu cầu và các hệ quả của nó.

7.3.4.17  Chỉ có thể sử dụng các đoạn mã trong mẫu ở hệ thống mục tiêu nếu chứng minh được việc mã hóa và quá trình phát triển và ghi chép của nó đáp ứng tiêu chuẩn này.

7.3.4.18  Chỉ dẫn giao diện phần mềm đối với tất cả các giao diện giữa các thành phần của phần mềm và giới hạn của phần mềm tổng thể phải được lập thành văn bản, do trách nhiệm của Đơn vị thiết kế, trên cơ sở của Chỉ dẫn các yêu cầu phần mềm và Chỉ dẫn cấu trúc phần mềm.

Các yêu cầu trong mục 7.3.4.19 tham chiếu tới Chỉ dẫn giao diện phần mềm.

7.3.4.19  Việc mô tả các giao diện phải đề cập tới:

a) Các điều kiện trước / sau.

b) Xác định và mô tả tất cả các giá trị giới hạn biên cho tất cả các dữ liệu được quy định.

c) Sự hoạt động khi vượt quá giá trị giới hạn biên.

d) Sự hoạt động khi đạt giá trị giới hạn biên.

e) Đối với các dữ liệu đầu vào và đầu ra chủ chốt theo thời gian:

1) Các ràng buộc về thời gian và các yêu cầu để hoạt động chính xác.

2) Quản lý các tình huống bất thường.

f) Bộ nhớ được phân bổ cho các vùng đệm giao diện và các cơ chế để phát hiện bộ nhớ không thể được phân bổ thêm hoặc tất cả các vùng đệm đã bị đầy, nếu có thể áp dụng.

g) Sự tồn tại các cơ chế đồng bộ hóa giữa các chức năng (xem mục e).

Phải xác định tất cả các dữ liệu đến và đi ra khỏi các giao diện cho toàn bộ dải giá trị được xác định bằng loại dữ liệu, bao gồm các dải không được sử dụng khi các chức năng xử lý:

a) Các bản xác định và mô tả tất cả các cấp độ tương đương đối với tất cả các dữ liệu được quy định và từng chức năng sử dụng các bản này.

b) Việc xác định các cấp độ tương đương không được sử dụng hoặc bị cấm.

Chú thích: Loại dữ liệu bao gồm:

1) Các thông số đầu vào và các kết quả đầu ra của các chức năng và/hoặc các quy trình.

2) Dữ liệu được quy định ở dạng sóng vô tuyến hoặc các nhóm liên lạc.

3) Dữ liệu của phần cứng.

7.3.4.20  Chỉ dẫn thiết kế phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thiết kế, trên cơ sở của Chỉ dẫn các yêu cầu phần mềm, Chỉ dẫn cấu trúc phần mềm và Chỉ dẫn giao diện phần mềm.

Các yêu cầu từ mục 7.3.4.21 đến 7.3.4.24 tham chiếu Chỉ dẫn thiết kế phần mềm.

7.3.4.21  Phải có sẵn các tài liệu đầu vào trước khi bắt đầu quá trình thiết kế, mặc dù không cần thiết phải tổng kết lại.

7.3.4.22  Chỉ dẫn thiết kế phần mềm phải mô tả thiết kế phần mềm dựa trên việc phân chia thành các thành phần, mỗi thành phần có Chỉ dẫn thiết kế thành phần phần mềm và Chỉ dẫn kiểm thử thành phần phần mềm riêng.

7.3.4.23  Chỉ dẫn thiết kế phần mềm phải đề cập tới:

a) Các thành phần phần mềm được theo dõi theo vết ngược lại cấu trúc phần mềm và mức toàn vẹn về an toàn của chúng.

b) Các giao diện của các thành phần phần mềm với môi trường.

c) Các giao diện giữa các thành phần phần mềm.

d) Các cấu trúc dữ liệu.

e) Việc phân bổ và truy vết các yêu cầu của các thành phần,

f) Các thuật toán chính và quá trình lập chuỗi,

g) Các cơ chế báo cáo lỗi.

7.3.4.24  Chỉ dẫn thiết kế phần mềm phải lựa chọn các kỹ thuật và các biện pháp từ Bảng A.4. Phải chứng minh sự kết hợp được lựa chọn thỏa mãn mục 4.8 và 4.9.

7.3.4.25  Các tiêu chuẩn mã hóa phải được phát triển và quy định:

a) Việc ứng dụng lập trình tốt, như được quy định trong Bảng A.12,

b) Các biện pháp để tránh hoặc phát hiện các lỗi có thể phát sinh trong quá trình ứng dụng ngôn ngữ và không thể phát hiện được trong quá trình thẩm tra (xem 7.5 và 7.6). Các hư hỏng này sẽ được tìm ra bằng việc phân tích tất cả các đặc tính của ngôn ngữ.

c) Các quy trình để ghi lại mã nguồn.

7.3.4.26  Việc lựa chọn tiêu chuẩn mã hóa phải được làm rõ theo mức độ của mức toàn vẹn về an toàn phần mềm.

7.3.4.27  Phải sử dụng các tiêu chuẩn mã hóa để phát triển tất cả các phần mềm và tham chiếu các tiêu chuẩn này trong Kế hoạch đảm bảo chất lượng phần mềm.

7.3.4.28  Để phù hợp với mức toàn vẹn về an toàn phần mềm yêu cầu, phương pháp thiết kế được lựa chọn phải có các đặc tính hỗ trợ:

a) Nền tảng, tính modul hóa và các đặc tính khác kiểm soát mức độ phức tạp.

b) Sự thể hiện rõ ràng và chính xác của:

1) Chức năng.

2) Luồng thông tin giữa các thành phần.

3) Quá trình tạo chuỗi và thông tin liên quan theo thời gian.

4) Các quá trình hoạt động đồng thời.

5) Cấu trúc dữ liệu và các tính năng.

c) Sự nhận thức của con người.

d) Quá trình thẩm tra và thẩm định.

e) Quá trình bảo trì phần mềm.

7.3.4.29  Chỉ dẫn kiểm thử tích hợp phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị tích hợp, trên cơ sở của Chỉ dẫn các yêu cầu phần mềm, Chỉ dẫn cấu trúc phần mềm, Chỉ dẫn thiết kế phần mềm và Chỉ dẫn giao diện phần mềm.

Các yêu cầu từ mục 7.3.4.30 đến 7.3.4.32 tham chiếu Chỉ dẫn kiểm thử tích hợp phần mềm.

7.3.4.30  Chỉ dẫn kiểm thử tích hợp phần mềm phải được lập thành văn bản phù hợp với các yêu cầu chung được thiết lập trong Chỉ dẫn kỹ thuật kiểm thử (xem 6.1.4.4).

7.3.4.31  Chỉ dẫn kiểm thử tích hợp phần mềm phải đề cập tới các vấn đề sau:

a) Phải thể hiện cho thấy từng thành phần phần mềm đưa ra các giao diện được quy định cho các thành phần khác bằng cách chạy các thành phần cùng với nhau.

b) Phải thể hiện cho thấy phần mềm hoạt động theo một cách thức phù hợp khi các giao diện bị phụ thuộc vào các đầu vào không nằm trong chỉ dẫn kỹ thuật.

c) Dữ liệu đầu vào cần thiết của chuỗi và các giá trị của nó phải là cơ sở của các trường hợp kiểm thử.

d) Dữ liệu đầu ra được dự báo cùng với các kết quả và các giá trị của chúng phải là căn cứ của các trường hợp kiểm thử.

e) Phải thể hiện cho thấy các kết quả của việc kiểm thử tổng thành (xem 7.5.4.5 và 7.5.4.7) sẽ được sử dụng lại để kiểm thử tích hợp phần mềm.

7.3.4.32  Chỉ dẫn kiểm thử tích hợp phần mềm phải lựa chọn các kỹ thuật và các biện pháp trong Bảng A.5. Phải chứng minh sự kết hợp được lựa chọn thỏa mãn mục 4.8 và 4.9.

7.3.4.33  Chỉ dẫn kiểm thử tích hợp phần mềm / phần cứng phải được lập thành văn bản, do trách nhiệm của Đơn vị tích hợp, trên cơ sở Bản mô tả thiết kế hệ thống, Chỉ dẫn các yêu cầu phần mềm, Chỉ dẫn cấu trúc phần mềm và Chỉ dẫn thiết kế phần mềm.

Các yêu cầu từ mục 7.3.4.34 đến 7.3.4.39 tham chiếu Chỉ dẫn kiểm thử tích hợp phần mềm/phần cứng.

7.3.4.34  Chỉ dẫn kiểm thử tích hợp phần mềm / phần cứng nên sớm được lập ra trong vòng đời phát triển, để việc kiểm thử tích hợp có thể được hướng dẫn đúng và để việc thiết kế chi tiết hoặc các yêu cầu tích hợp khác có thể được đưa ra phù hợp. Phụ thuộc vào quy mô hệ thống, chỉ dẫn kiểm thử tích hợp phần mềm / phần cứng có thể được phân chia nhỏ trong quá trình phát triển ra một số loại tài liệu con và được bổ sung lẫn nhau, khi các thiết kế phần cứng và phần mềm được phát triển và các yêu cầu tích hợp chi tiết trở nên rõ ràng hơn.

7.3.4.35  Chỉ dẫn kiểm thử tích hợp phần mềm / phần cứng phải phân biệt rõ giữa các hoạt động có thể được nhà cung cấp thực hiện theo đề nghị của họ và các hoạt động đó yêu cầu có sự tiếp cận đến lĩnh vực của người sử dụng.

7.3.4.36  Chỉ dẫn kiểm thử tích hợp phần mềm / phần cứng phải đề cập tới các vấn đề sau:

a) Phải thể hiện cho thấy phần mềm hoạt động đúng trên phần cứng, sử dụng phần cứng theo các giao diện phần cứng được quy định.

b) Phải thể hiện cho thấy phần mềm có thể xử lý các sự cố phần cứng theo yêu cầu.

c) Phải chứng minh được thời gian và hiệu năng cần thiết.

d) Dữ liệu đầu vào cần thiết cùng với các kết quả và các giá trị phải là cơ sở của các trường hợp kiểm thử.

e) Dữ liệu đầu ra được dự báo với các kết quả và các giá trị phải là cơ sở của các trường hợp kiểm thử.

f) Phải thể hiện cho thấy các kết quả của việc kiểm thử thành phần (xem 7.5.4.5) và kiểm thử tích hợp phần mềm (xem 7.6.4.3) sẽ được sử dụng lại trong kiểm thử tích hợp phần mềm / phần cứng.

7.3.4.37  Chỉ dẫn kiểm thử tích hợp phần mềm / phần cứng phải ghi lại các vấn đề sau:

a) Các trường hợp kiểm thử và dữ liệu kiểm thử.

b) Các loại hình kiểm thử được tiến hành.

c) Môi trường kiểm thử, bao gồm các chương trình, phần mềm hỗ trợ và bản mô tả cấu hình.

d) Chỉ tiêu hoàn thành kiểm thử.

7.3.4.38  Chỉ dẫn kiểm thử tích hợp phần mềm / phần cứng phải được lập thành văn bản phù hợp với các yêu cầu chung được thiết lập trong Chỉ dẫn kỹ thuật kiểm thử (xem 6.1.4.4)..

7.3.4.39  Chỉ dẫn kỹ thuật kiểm thử tích hợp phần mềm / phần cứng phải lựa chọn các kỹ thuật và các biện pháp trong Bảng A.5. Việc lựa chọn kết hợp phải được chứng minh thỏa mãn mục 4.8 và 4.9.

7.3.4.40  Báo cáo thẩm tra cấu trúc và thiết kế phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thẩm tra, trên cơ sở Chỉ dẫn các yêu cầu phần mềm, Chỉ dẫn cấu trúc phần mềm, Chỉ dẫn thiết kế phần mềm, Chỉ dẫn kiểm thử tích hợp phần mềm và Chỉ dần kiểm thử tích hợp phần mềm / phần cứng.

Các yêu cầu từ mục 7.3.4.41 đến 7.3.4.43 tham chiếu tới Báo cáo thẩm tra cấu trúc và thiết kế phần mềm.

7.3.4.41  Chỉ dẫn thẩm tra thiết kế và cấu trúc phần mềm phải được lập thành văn bản phù hợp với các yêu cầu chung được thiết lập trong Báo cáo thẩm tra (xem 6.2.4.13).

7.3.4.42  Sau khi lập xong Chỉ dẫn thiết kế, giao diện và cấu trúc phần mềm, việc thẩm tra phải đề cập đến:

a) Sự thống nhất nội bộ của Chỉ dẫn thiết kế, giao diện và cấu trúc phần mềm.

b) Sự đáp ứng đầy đủ Chỉ dẫn kỹ thuật các yêu cầu phần mềm về mặt thống nhất và hoàn chỉnh của Chỉ dẫn thiết kế, giao diện và cấu trúc phần mềm.

c) Chỉ dẫn cấu trúc phần mềm đáp ứng các yêu cầu chung về khả năng có thể đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.16 cũng như các yêu cầu cụ thể từ mục 7.3.4.1 đến 7.3.4.14.

d) Chỉ dẫn giao diện phần mềm đáp ứng các yêu cầu chung về khả năng có thể đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.16 cũng như các yêu cầu cụ thể từ mục 7.3.4.18 đến 7.3.4.19.

e) Chỉ dẫn cấu trúc phần mềm đáp ứng các yêu cầu chung về khả năng có thể đọc được và khả năng truy vết từ mục 5.3.27 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.16 cũng như các yêu cầu cụ thể từ mục 7.3.4.20 đến 7.3.4.24.

f) Sự xem xét đầy đủ các ràng buộc của Chỉ dẫn cấu trúc phần mềm và Chỉ dẫn thiết kế phần mềm.

Các kết quả phải được ghi lại trong Báo cáo thẩm tra cấu trúc và thiết kế phần mềm.

7.3.4.43  Sau khi lập xong Chỉ dẫn thiết kế, giao diện và cấu trúc phần mềm, việc thẩm tra phải đề cập đến:

a) Chỉ dẫn kiểm thử tích hợp phần mềm đáp ứng các yêu cầu chung về khả năng có thể đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.16 cũng như các yêu cầu cụ thể từ mục 7.3.4.29 đến 7.3.4.32.

b) Chỉ dẫn kiểm thử tích hợp phần mềm / phần cứng đáp ứng các yêu cầu chung về khả năng có thể đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.16 cũng như các yêu cầu cụ thể từ mục 7.3.4.33 đến 7.3.4.39.

Các kết quả phải được ghi lại trong Báo cáo thẩm tra cấu trúc và thiết kế phần mềm.

7.4  Thiết kế thành phần

7.4.1  Mục tiêu

7.4.1.1  Để xây dựng thiết kế thành phần phần mềm đạt được các yêu cầu của Chỉ dẫn thiết kế phần mềm theo mức toàn vẹn về an toàn phần mềm được yêu cầu.

7.4.1.2  Để xây dựng chỉ dẫn kiểm thử thành phần phần mềm đạt được các yêu cầu của Chỉ dẫn thiết kế thành phần phần mềm theo mức toàn vẹn về an toàn phần mềm được yêu cầu.

7.4.2  Các tài liệu đầu vào

1) Chỉ dẫn thiết kế phần mềm.

7.4.3  Các tài liệu đầu ra

1) Chỉ dẫn thiết kế thành phần phần mềm

2) Chỉ dẫn kiểm thử thành phần phần mềm

3) Báo cáo thẩm tra thiết kế thành phần phần mềm

7.4.4  Các yêu cầu.

7.4.4.1  Đối với từng tổng thành, Chỉ dẫn thiết kế thành phần phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thiết kế, trên cơ sở của Chỉ dẫn thiết kế phần mềm.

Các yêu cầu từ mục 7.4.4.2 đến 7.4.4.6 tham chiếu Chỉ dẫn thiết kế thành phần phần mềm.

7.4.4.2  Đối với từng thành phần phần mềm, phải có các thông tin dưới đây:

- Tác giả;

- Lịch sử cấu hình;

- Bản mô tả ngắn gọn.

Lịch sử cấu hình phải bao gồm việc nhận dạng chính xác các định dạng phiên bản hiện tại và tất cả các định dạng trước đó của thành phần phần mềm, quy định về phiên bản, ngày, tác giả và bản mô tả về các thay đổi được thực hiện so với phiên bản trước đó.

7.4.4.3  Chỉ dẫn thiết kế thành phần phần mềm phải đề cập tới:

a) Việc xác định tất cả các đơn vị thành phần phần mềm cấp thấp nhất (ví dụ: các đường dẫn, biện pháp, quy trình) được truy vết ngược về cấp độ cao hơn.

b) Các giao diện chi tiết của chúng với môi trường và các thành phần khác với các đầu vào và đầu ra chi tiết.

c) Mức toàn vẹn về an toàn của thành phần mà không được phân bổ thêm nữa trong nội bộ thành phần.

d) Thuật toán chi tiết và cấu trúc dữ liệu.

Từng Chỉ dẫn cấu trúc thành phần phần mềm phải tự thống nhất và cho phép chuyển đổi thành đoạn mã của thành phần phần mềm tương ứng.

7.4.4.4  Mỗi chỉ dẫn kỹ thuật thiết kế thành phần phần mềm phải có thể đọc được, hiểu được và có thể kiểm thử.

7.4.4.5  Quy mô và mức độ phức tạp của từng thành phần phần mềm được phát triển phải cân bằng với nhau.

7.4.4.6  Chỉ dẫn thiết kế thành phần phần mềm phải lựa chọn các kỹ thuật và các biện pháp trong Bảng A.4. Phải chứng minh sự kết hợp được lựa chọn là thỏa mãn mục 4.8 và 4.9.

7.4.4.7  Đối với từng thành phần, Chỉ dẫn kiểm thử thành phần phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị kiểm thử, trên cơ sở Chỉ dẫn thiết kế thành phần phần mềm.

Các yêu cầu từ mục 7.4.4.8 đến 7.4.4.10 tham chiếu tới Chỉ dẫn kiểm thử thành phần phần mềm.

7.4.4.8  Chỉ dẫn kiểm thử thành phần phần mềm phải được lập thành văn bản phù hợp với các yêu cầu chung được thiết lập trong Chỉ dẫn kiểm thử (xem 6.1.4.4).

7.4.4.9  Phải kiểm thử thành phần theo chỉ dẫn kiểm thử thành phần phần mềm được lập ra. Những kiểm thử này phải thể hiện được từng thành phần thực hiện chức năng của nó. Chỉ dẫn kiểm thử thành phần phần mềm phải xác định và chứng minh chỉ tiêu cần thiết và mức độ kiểm thử được thực hiện theo mức toàn vẹn về an toàn được yêu cầu. Các kiểm thử này phải được thiết kế sao cho đáp ứng ba mục tiêu:

a) Để xác nhận thành phần thực hiện các chức năng dự định của nó (kiểm thử hộp đen).

b) Để kiểm tra cách thức tương tác của các bộ phận bên trong của thành phần để thực hiện các chức năng dự định của nó (kiểm thử hộp đen/trắng).

c) Để xác nhận tất cả các yếu tố của thành phần được kiểm thử (kiểm thử hộp trắng).

7.4.4.10  Chỉ dẫn kiểm thử thành phần phần mềm phải lựa chọn các kỹ thuật và các biện pháp trong Bảng A.5. Phải chứng minh kết hợp được lựa chọn là thỏa mãn mục 4.8 và 4.9.

7.4.4.11  Báo cáo thẩm tra thiết kế thành phần phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thẩm tra, trên cơ sở Chỉ dẫn thiết kế phần mềm, Chỉ dẫn thiết kế thành phần phần mềm, Chỉ dẫn kiểm thử thành phần phần mềm.

Các yêu cầu từ mục 7.4.4.12 đến 7.4.4.13 tham chiếu tới Báo cáo thẩm tra thiết kế thành phần phần mềm.

7.4.4.12  Báo cáo thẩm tra thiết kế phần mềm phải được lập thành văn bản phù hợp với các yêu cầu chung được thiết lập trong Báo cáo thẩm tra (xem 6.2.4.13).

7.4.4.13  Sau khi lập xong Chỉ dẫn thiết kế thành phần phần mềm, việc thẩm tra phải xem xét:

a) Sự đáp ứng đầy đủ của Chỉ dẫn thiết kế thành phần phần mềm với Chỉ dẫn thiết kế phần mềm.

b) Chỉ dẫn thiết kế thành phần phần mềm đáp ứng các yêu cầu chung về khả năng có thể đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.16 cũng như các yêu cầu cụ thể từ mục 7.4.4.1 đến 7.4.4.6.

c) Sự đáp ứng đầy đủ Chỉ dẫn thiết kế thành phần phần mềm của Chỉ dẫn kiểm thử thành phần phần mềm.

d) Chỉ dẫn kiểm thử thành phần phần mềm đáp ứng các yêu cầu chung về khả năng có thể đọc được và khả năng theo dõi theo vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.17 cũng như các yêu cầu cụ thể từ mục 7.4.4.7 đến 7.4.4.10.

e) Việc phân chia Chỉ dẫn thiết kế phần mềm thành các thành phần phần mềm và Chỉ dẫn thiết kế phần mềm có xem xét tới:

1) Tính khả thi của hiệu năng yêu cầu.

2) Khả năng kiểm thử của các thẩm tra khác.

3) Khả năng bảo trì để cho phép các phát triển sau thêm.

Các kết quả phải được ghi lại trong Báo cáo thẩm tra thiết kế thành phần phần mềm.

7.5  Chạy và kiểm thử thành phần

7.5.1  Mục tiêu

7.5.1.1  Để tạo ra được phần mềm có thể phân tích, có thể kiểm thử, có thể thẩm tra và có thể bảo trì. Việc kiểm thử tổng thành cũng sẽ nằm trong giai đoạn này.

7.5.2  Các tài liệu đầu vào

1) Chỉ dẫn thiết kế thành phần phần mềm

2) Chỉ dẫn kiểm thử thành phần phần mềm

7.5.3  Các tài liệu đầu ra

1) Mã nguồn phần mềm và tài liệu hỗ trợ

2) Báo cáo kiểm thử thành phần phần mềm

3) Báo cáo thẩm tra mã nguồn phần mềm

7.5.4  Các yêu cầu

7.5.4.1  Mã nguồn phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thực hiện trên cơ sở của Chỉ dẫn thiết kế thành phần phần mềm. Các yêu cầu của từ mục 7.5.4.2 đến mục 7.5.4.4 tham chiếu tới mã nguồn phần mềm.

7.5.4.2  Phải cân bằng quy mô và độ phức tạp của mã nguồn được xây dựng.

7.5.4.3  Mã nguồn phần mềm phải có thể đọc được, có thể hiểu được và có thể kiểm thử được.

7.5.4.4  Mã nguồn phần mềm phải được kiểm soát cấu hình trước khi bắt đầu ghi lại quá trình kiểm thử.

7.5.4.5  Báo cáo kiểm thử thành phần phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị kiểm thử, trên cơ sở của Chỉ dẫn kiểm thử thành phần phần mềm và Mã nguồn phần mềm.

Các yêu cầu từ 7.5.4.6 tham chiếu tới Báo cáo kiểm thử thành phần phần mềm.

7.5.4.6  Báo cáo kiểm thử thành phần phần mềm phải được lập thành văn bản phù hợp với các yêu cầu chung được thiết lập trong Báo cáo kiểm thử (xem 6.1.4.5).

7.5.4.7  Báo cáo kiểm thử thành phần phần mềm phải có các đặc điểm sau:

a) Kết luận về các kết quả kiểm thử và liệu mỗi thành phần có đáp ứng được các yêu cầu của Chỉ dẫn thiết kế thành phần phần mềm.

b) Kết luận về mức độ kiểm thử đưa ra cho từng thành phần, thể hiện được mức độ kiểm thử cần thiết đã đạt được cho tất cả các chỉ tiêu yêu cầu.

7.5.4.8  Báo cáo thẩm tra mã nguồn phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thẩm tra, trên cơ sở của Chỉ dẫn thiết kế thành phần phần mềm, Chỉ dẫn kiểm thử thành phần phần mềm và Mã nguồn phần mềm.

Các yêu cầu từ mục 7.5.4.9 đến 7.5.4.10 tham chiếu tới Báo cáo thẩm tra mã nguồn phần mềm.

7.5.4.9  Báo cáo thẩm tra mã nguồn phần mềm phải được lập thành văn bản phù hợp với các yêu cầu chung được thiết lập trong Báo cáo thẩm tra (xem 6.2 4.13).

7.5.4.10  Sau khi lập xong Báo cáo kiểm thử mã nguồn phần mềm và thành phần mềm, việc thẩm tra phải xem xét:

a) Sự hoạt động đầy đủ của Mã nguồn phần mềm theo Chỉ dẫn thiết kế thành phần phần mềm.

b) Việc sử dụng đúng các kỹ thuật và biện pháp được lựa chọn trong Bing A.4 thỏa mãn mục 4.8 và 4.9.

c) Việc xác định quá trình ứng dụng đúng các tiêu chuẩn mã hóa.

d) Mã nguồn phần mềm đáp ứng các yêu cầu chung về khả năng có thể đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.16 cũng như các yêu cầu cụ thể từ mục 7.5.4.1 đến 7.5.4.4.

e) Sự đầy đủ của Báo cáo kiểm thử thành phần phần mềm, ghi lại các kiểm thử được tiến hành phù hợp với Chỉ dẫn kiểm thử thành phần phần mềm.

Các kết quả phải được ghi lại trong Báo cáo thẩm tra mã nguồn phần mềm.

7.6  Tích hợp

7.6.1  Mục tiêu

7.6.1.1  Để thực hiện việc tích hợp phần mềm và tích hợp phần mềm/phần cứng.

7.6.1.2  Để chứng minh phần mềm và phần cứng tương tác đúng với nhau để thực hiện các chức năng dự định.

7.6.2  Các tài liệu đầu vào

1) Chỉ dẫn kiểm thử tích hợp phần mềm / phần cứng

2) Chỉ dẫn kiểm thử tích hợp phần mềm

7.6.3  Các tài liệu đầu ra

1) Báo cáo kiểm thử tích hợp phần mềm

2) Báo cáo kiểm thử tích hợp phần mềm / phần cứng

3) Báo cáo thẩm tra tích hợp phần mềm.

7.6.4  Các yêu cầu

7.6.4.1  Việc tích hợp các thành phần phần mềm phải là quá trình kết hợp liên tục các thành phần độc lập và đã được kiểm thử trước đó thành một tập hợp sao cho các giao diện giữa các thành phần và phần mềm được kết hợp lại có thể được chứng minh đầy đủ trước khi tích hợp hệ thống và kiểm thử hệ thống.

7.6.4.2  Trong quá trình tích hợp phần mềm / phần cứng, mọi sự cải tiến hoặc thay đổi hệ thống được tích hợp phải được nghiên cứu tác động xác định rõ tất cả các thành phần bị tác động và các hoạt động thẩm tra lại cần thiết.

7.6.4.3  Báo cáo kiểm thử tích hợp phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị tích hợp, trên cơ sở của Chỉ dẫn kiểm thử tích hợp phần mềm.

Các yêu cầu từ mục 7.6.4.4 đến 7.6.4.6 tham chiếu Báo cáo kiểm thử tích hợp phần mềm.

7.6.4.4  Báo cáo kiểm thử tích hợp phần mềm phải được lập thành văn bản phù hợp với các yêu cầu chung được quy định trong Báo cáo kiểm thử (xem 6.1.4.5).

7.6.4.5  Báo cáo kiểm thử tích hợp phải được lập như sau:

a) Báo cáo kiểm thử tích hợp phần mềm được lập phải nêu rõ các kết quả kiểm thử và liệu các mục tiêu và chỉ tiêu của Chỉ dẫn kiểm thử tích hợp phần mềm có được đáp ứng Nếu có hư hỏng, phải ghi lại các trường hợp hư hỏng đó.

b) Phải ghi lại các trường hợp kiểm thử và các kết quả, ưu tiên theo dạng máy có thể đọc được để phân tích sau này.

c) Các kiểm thử phải có thể được lặp lại và có thể thực hiện bằng các phương pháp tự động nếu có thể thực hiện được.

d) Báo cáo kiểm thử tích hợp phần mềm phải ghi lại định dạng và cấu hình của tất cả các hạng mục có liên quan.

7.6.4.6  Báo cáo kiểm thử tích hợp phần mềm phải chứng minh việc sử dụng đúng các kỹ thuật và biện pháp được lựa chọn trong Bảng A.6 là thỏa mãn mục 4.8 và 4.9.

7.6.4.7  Báo cáo kiểm thử tích hợp phần mềm / phần cứng phải được lập thành văn bản, dưới trách nhiệm của Đơn vị tích hợp, trên cơ sở của Chỉ dẫn kiểm thử tích hợp phần mềm / phần cứng.

Các yêu cầu từ mục 7.6.4.8 đến 7.6.4.10 tham chiếu Báo cáo kiểm thử tích hợp phần mềm / phần cứng.

7.6.4.8  Báo cáo kiểm thử tích hợp phần mềm/phần cứng phải được lập thành văn bản phù hợp với các yêu cầu chung được quy định trong Báo cáo kiểm thử (xem 6.1 4.5).

7.6.4.9  Báo cáo kiểm thử tích hợp phải được lập như sau:

a) Báo cáo kiểm thử tích hợp phần mềm/phần cứng phải nêu rõ các kết quả kiểm thử và liệu các mục tiêu và chỉ tiêu của Chỉ dẫn kiểm thử tích hợp phần mềm/phần cứng có được đáp ứng. Nếu có hư hỏng, phải ghi lại các trường hợp hư hỏng đó.

b) Phải ghi lại các trường hợp kiểm thử và các kết quả, ưu tiên theo dạng máy có thể đọc được để phân tích sau này.

c) Các kiểm thử có thể lặp lại được và có thể thực hiện bằng các phương pháp tự động nếu khả thi.

d) Báo cáo kiểm thử tích hợp phần mềm/phần cứng phải ghi lại định dạng và cấu hình của tất cả các hạng mục có liên quan.

7.6.4.10  Báo cáo kiểm thử tích hợp phần mềm/phần cứng phải chứng minh việc sử dụng đúng các kỹ thuật và biện pháp được lựa chọn trong Bảng A.6 là thỏa mãn mục 4.8 và 4.9.

7.6.4.11  Báo cáo thẩm tra tích hợp phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thẩm tra, trên cơ sở của Chỉ dẫn kiểm thử tích hợp phần mềm và phần mềm / phần cứng và các báo cáo kiểm thử tương ứng.

Các yêu cầu từ mục 7.6.4.12 đến 7.6.4.13 tham chiếu Báo cáo thẩm tra tích hợp phần mềm.

7.6.4.12  Báo cáo thẩm tra tích hợp phần mềm phải được lập thành văn bản phù hợp với các yêu cầu chung được thiết lập trong Báo cáo thẩm tra (xem 6.2.4.13).

7.6.4.13  Sau khi lập xong Báo cáo kiểm thử tích hợp phần mềm và Báo cáo kiểm thử tích hợp phần mềm/phần cứng, việc thẩm tra phải xem xét:

a) Sự đầy đủ của Báo cáo kiểm thử tích hợp phần mềm, ghi lại các kiểm thử được tiến hành phù hợp với Chỉ dẫn kiểm thử tích hợp phần mềm.

b) Liệu Báo cáo kiểm thử tích hợp phần mềm có đáp ứng các yêu cầu về khả năng có thể đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.16 cũng như các yêu cầu cụ thể từ mục 7.6.4.3 đến 7.6.4.6.

c) Sự đầy đủ của Báo cáo kiểm thử tích hợp phần mềm/phần cứng, ghi lại các kiểm thử được tiến hành phù hợp với Chỉ dẫn kiểm thử tích hợp phần mềm/phần cứng.

d) Liệu Báo cáo kiểm thử tích hợp phần mềm có đáp ứng các yêu cầu chung khả năng có thể đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.16 cũng như các yêu cầu cụ thể từ mục 7.6.4.7 đến 7.6.4.10.

7.7  Kiểm thử tổng thể phần mềm / Thẩm định lần cuối

7.7.1  Mục tiêu

7.7.1.1  Để phân tích và kiểm thử phần mềm và phần cứng được tích hợp đảm bảo thỏa mãn Chỉ dẫn các yêu cầu phần mềm, nhấn mạnh cụ thể vào các vấn đề chức năng và an toàn theo mức toàn vẹn về an toàn phần mềm và để kiểm tra xem liệu phần mềm có phù hợp với ứng dụng.

7.7.2  Tài liệu đầu vào

1) Chỉ dẫn các yêu cầu phần mềm

2) Chỉ dẫn kiểm thử tổng thể phần mềm

3) Kế hoạch thẩm tra phần mềm

4) Kế hoạch thẩm định phần mềm

5) Tất cả các tài liệu phần mềm và phần cứng, bao gồm các kết quả thẩm tra trung gian.

6) Chỉ dẫn các yêu cầu an toàn hệ thống

7.7.3  Tài liệu đầu ra

1) Báo cáo kiểm thử tổng thể phần mềm

2) Báo cáo thẩm định phần mềm

3) Thông tin lưu ý về phiên bản phần mềm sử dụng

7.7.4  Các yêu cầu

7.7.4.1  Báo cáo kiểm thử tổng thể phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị kiểm thử, trên cơ sở của Chỉ dẫn kiểm thử tổng thể phần mềm.

Các yêu cầu từ mục 7.7.4.2 đến 7.7.4.4 tham chiếu Báo cáo kiểm thử tổng thể phần mềm.

7.7.4.2  Báo cáo kiểm thử tổng thể phần mềm phải được lập thành văn bản phù hợp với các yêu cầu chung được thiết lập trong Báo cáo kiểm thử (xem 6.1.4.5).

7.7.4.3  Đơn vị thẩm định phải quy định và tiến hành các kiểm thử bổ sung theo sự hướng dẫn của mình hoặc yêu cầu Đơn vị kiểm thử tiến hành. Các kiểm thử tổng thể phần mềm sẽ chủ yếu dựa trên cấu trúc của Chỉ dẫn các yêu cầu phần mềm, giá trị được bổ sung mà Đơn vị thẩm định đưa ra là các kiểm thử tạo áp lực lên hệ thống trong các trường hợp phức tạp thể hiện yêu cầu thực tế của người sử dụng.

7.7.4.4  Các kết quả của tất cả các kiểm thử và phân tích phải ghi lại trong Báo cáo kiểm thử tổng thể phần mềm.

7.7.4.5  Phần mềm phải được trải nghiệm bằng cách kết nối các đối tượng phần cứng thực tế hoặc hệ thống thực sẽ tương tác trong hoạt động, hoặc bằng mô phỏng các tín hiệu đầu vào và các đối tượng theo đầu ra. Phần mềm phải được kiểm tra dưới các điều kiện hiện có trong quá trình hoạt động bình thường, các tình huống xuất hiện đã được dự đoán trước và các điều kiện không mong muốn yêu cầu có các hoạt động phòng vệ của hệ thống. Khi sử dụng các đầu vào hoặc tải được mô phỏng, phải thể hiện cho thấy những đầu vào và tải này không khác đáng kể so với các đầu vào và tải gặp phải trong hoạt động thực tế.

7.7.4.6  Báo cáo thẩm định phần mềm phải được lập thành văn bản, do trách nhiệm của đơn vị thẩm định, trên cơ sở của Kế hoạch thẩm định phần mềm.

Các yêu cầu từ mục 7.7.4.7 đến 7.7.4.11 tham chiếu Báo cáo thẩm định phần mềm.

7.7.4.7  Báo cáo thẩm định tổng thể phần mềm phải được lập thành văn bản phù hợp với các yêu cầu chung được thiết lập trong Báo cáo thẩm định (xem 6.3.4.7 đến 6.3.4.11).

7.7.4.8  Khi hoàn thiện việc tích hợp và hoàn thiện việc kiểm thử và phân tích tổng thể phần mềm, phải lập Báo cáo thẩm định phần mềm như sau:

a) Phải tuyên bố liệu các mục tiêu và chỉ tiêu của Kế hoạch thẩm định phần mềm có được đáp ứng. Phải ghi lại và làm rõ các sai lệch.

b) Phải đưa ra được kết luận tổng kết về các kết quả kiểm thử và liệu toàn bộ phần mềm trên máy mục tiêu có đáp ứng được các yêu cầu đưa ra trong Chỉ dẫn các yêu cầu phần mềm.

c) Phải đưa ra đánh giá về mức độ kiểm thử theo các yêu cầu của Chỉ dẫn các yêu cầu phần mềm.

d) Phải thực hiện đánh giá các hoạt động thẩm tra khác phù hợp với Kế hoạch và Báo cáo thẩm tra phần mềm cùng với kiểm tra việc truy vết các yêu cầu có được thực hiện và đáp ứng đầy đủ.

e) Nếu Đơn vị thẩm định đưa ra các tình huống kiểm thử của mình, không thông báo cho Đơn vị kiểm thử thì trong Báo cáo thẩm định phần mềm phải ghi lại các tình huống này phù hợp với mục 6.3.4.7 đến 6.3.4.11.

7.7.4.9  Báo cáo thẩm định phần mềm phải có sự xác nhận về sự phù hợp theo mức toàn, vẹn về an toàn phần mềm xác định của từng hoạt động kết hợp các kỹ thuật hoặc các biện pháp được lựa chọn theo Phụ lục A. Phải có đánh giá về hiệu quả tổng thể của việc kết hợp các kỹ thuật và biện pháp được thông qua, tính tới quy mô và mức độ phức tạp của phần mềm tạo ra và tính tới các kết quả hoạt động kiểm thử, thẩm tra và thẩm định thực tế.

7.7.4.10  Báo cáo thẩm định phần mềm phải đề cập đến các vấn đề sau:

a) Ghi lại nhận dạng và cấu hình của phần mềm.

b) Kết luận về việc xác định thiết bị và phần mềm hỗ trợ kỹ thuật phù hợp.

c) Kết luận về việc xác định các mô hình mô phỏng được sử dụng phù hợp.

d) Kết luận về sự phù hợp của Chỉ dẫn kiểm thử tổng thể phần mềm.

e) Thu thập và duy trì việc truy vết mọi sai lệch được phát hiện.

f) Rà soát và đánh giá mọi sai lệch về mặt rủi ro (tác động).

g) Kết luận dự án có được tiến hành phù hợp, xử lý các hoạt động sửa chữa phù hợp với quá trình và các quy trình quản lý các thay đổi và xác định rõ ràng mọi vấn đề khác biệt được phát hiện.

h) Kết luận về từng hạn chế được đưa ra do sự sai lệch theo cách có thể truy vết.

i) Kết luận liệu phần mềm có phù hợp với ứng dụng, tính tới các điều kiện và ràng buộc ứng dụng.

7.7.4.11  Phải xác định rõ ràng mọi sai lệch được phát hiện, bao gồm các lỗi tìm thấy và các vấn đề không phù hợp với tiêu chuẩn này hoặc với các yêu cầu phần mềm hoặc kế hoạch, cũng như các ràng buộc và giới hạn trong các mục con của Báo cáo thẩm định phần mềm, được đánh giá theo mức toàn vẹn về an toàn và có trong Thông tin lưu ý về phiên bản phần mềm sử dụng đi kèm với phần mềm được chuyển giao.

7.7.4.12  Thông tin lưu ý về phiên bản phần mềm sử dụng đi kèm với phần mềm được chuyển giao phải có tất cả các hạn chế khi sử dụng phần mềm. Những hạn chế này được rút ra từ

a) Các lỗi tìm thấy.

b) Các vấn đề không phù hợp với tiêu chuẩn này.

c) Mức độ đáp ứng các yêu cầu.

d) Mức độ đáp ứng mọi kế hoạch.

8  Phát triển các thuật toán hoặc dữ liệu ứng dụng: các hệ thống được cấu hình bằng các thuật toán hoặc dữ liệu ứng dụng

8.1  Mục tiêu

8.1.1  Đặc điểm kỹ thuật của các hệ thống đường sắt là cần phải thiết kế từng hạng mục lắp đặt đáp ứng các yêu cầu riêng biệt cho một điều kiện khai thác cụ thể. Một hệ thống được cấu hình bằng các dữ liệu ứng dụng và/hoặc các thuật toán ứng dụng sẽ cho phép phần mềm chung đã được chứng nhận được thay đổi theo các yêu cầu độc lập cho từng ứng dụng cụ thể.

Mục tiêu của việc phát triển dữ liệu ứng dụng là tìm ra dữ liệu chuẩn từ các lắp đặt trước đó và kiểm tra sự hoạt động dự định bằng cách đánh giá quá trình phát triển được sử dụng cho dữ liệu ứng dụng.

Các yêu cầu phát triển thuật toán ứng dụng cũng sẽ giống như các yêu cầu khi phát triển phần mềm chung được mô tả trong các mục 1-7 và 9.

Một ví dụ điển hình là hệ thống có phần chung được cấu hình trước đó cho một ứng dụng đường sắt chung bằng một nhóm các thuật toán ứng dụng, sau đó được cấu hình bổ sung cho một lắp đặt cụ thể bằng cách cài đặt và kết nối các thuật toán ứng dụng và bằng một nhóm dữ liệu cấu hình. Ví dụ: các nguyên lý phát tín hiệu của hệ thống khóa lẫn (ví dụ: quản lý tín hiệu, quản lý điểm) có thể được thực hiện bằng một nhóm các thuật toán ứng dụng.

Dữ liệu ứng dụng chủ yếu sẽ lấy dưới dạng các giá trị thông số hoặc các mô tả (nhận dạng, kiểu loại, vị trí,...) của các đối tượng từ bên ngoài. Các thuật toán ứng dụng có thể lấy dưới dạng các sơ đồ khối chức năng, các sơ đồ trạng thái và các sơ đồ chuyển tiếp bậc thang, xác định sự phản hồi mong muốn của hệ thống theo các đầu vào, trạng thái hiện tại và các giá trị thông số cụ thể. Các thuật toán ứng dụng bao gồm các liên kết logic và các phép tính được thực hiện.

Các thuật toán/dữ liệu ứng dụng thường được tạo ra bằng cách sử dụng các chương trình chuyên dụng. Dữ liệu này có thể được thể hiện theo dạng bảng hoặc dạng sơ đồ (có thể được diễn giải hoặc biên dịch thành các mã chạy chương trình sau khi đã được chuyển đổi thành mã nguồn được xử lý thông qua các ngôn ngữ lập trình chuyên dụng (với cú pháp và ngữ nghĩa)).

Việc thay đổi các hệ thống thông qua khả năng cấu hình sẽ giúp cho đơn vị thiết kế có được các mức độ kiểm soát khác nhau trên toàn bộ chức năng phần mềm chi tiết.

8.1.2  Các quy trình và các chương trình được sử dụng để phát triển phải phù hợp với mức toàn vẹn về an toàn hệ thống được xác định bằng chức năng được phát triển.

8.1.3  Các điều khoản dưới đây sẽ mô tả các yêu cầu để phát triển bước đầu các hệ thống có thể cấu hình và để phát triển từng nhóm các thuật toán / dữ liệu ứng dụng cụ thể sau này.

8.2  Tài liệu đầu vào

1) Chỉ dẫn các yêu cầu phần mềm của phần mềm chung

2) Chỉ dẫn cấu trúc phần mềm của phần mềm chung

3) Các điều kiện áp dụng của phần mềm chung và các chương trình ứng dụng

4) Hướng dẫn sử dụng của phần mềm chung và các chương trình ứng dụng

8.3  Tài liệu đầu ra

1) Kế hoạch chuẩn bị ứng dụng

2) Chỉ dẫn các yêu cầu ứng dụng

3) Cấu trúc và thiết kế ứng dụng

4) Chỉ dẫn kiểm thử ứng dụng

5) Báo cáo kiểm thử ứng dụng

6) Báo cáo thẩm tra chuẩn bị ứng dụng

7) Mã nguồn của các thuật toán / dữ liệu ứng dụng

8) Báo cáo thẩm tra các thuật toán / dữ liệu ứng dụng

8.4  Các yêu cầu

8.4.1  Quá trình phát triển ứng dụng

8.4.1.1  Kế hoạch chuẩn bị ứng dụng phải được lập thành văn bản, do trách nhiệm của Đơn vị quản lý các yêu cầu hoặc Đơn vị thiết kế, trên cơ sở các tài liệu đầu vào trong mục 8.2.

Các yêu cầu từ mục 8.4.1.2 đến 8.4.1.11 tham chiếu tới Kế hoạch chuẩn bị ứng dụng.

8.4.1.2  Kế hoạch chuẩn bị ứng dụng phải được lập để xác định và nêu chi tiết quá trình phát triển ứng dụng, bao gồm tất cả các hoạt động, các sản phẩm chuyển giao và các vai trò thực hiện. Kế hoạch có thể được lập cho từng ứng dụng cụ thể hoặc cho một loại ứng dụng cụ thể, ví dụ: cho một ứng dụng chung.

8.4.1.3  Kế hoạch chuẩn bị ứng dụng phải xác định cấu trúc tài liệu của quá trình chuẩn bị ứng dụng.

8.4.1.4  Kế hoạch chuẩn bị ứng dụng phải lựa chọn các kỹ thuật và các biện pháp trong Bảng A.11. Phải chứng minh các kết hợp được lựa chọn là thỏa mãn mục 4.8 và 4.9.

8.4.1.5  Kế hoạch chuẩn bị ứng dụng phải quy định các quy trình và các chương trình ứng dụng (theo loại dựa trên mục 6.7) được sử dụng trong quá trình phát triển ứng dụng.

8.4.1.6  Kế hoạch chuẩn bị ứng dụng phải có các hoạt động thẩm tra và thẩm định để đảm bảo các thuật toán / dữ liệu ứng dụng là hoàn thiện, đúng và tương thích với các hoạt động khác và với ứng dụng chung, và để đưa ra bằng chứng về việc đáp ứng các điều kiện ứng dụng của ứng dụng chung. Các hoạt động thẩm tra, thẩm định và bằng chứng có thể được thay thế bằng việc thẩm tra và thẩm định được thực hiện trên các chương trình lập ra các thuật toán / dữ liệu ứng dụng. Các kết quả được thu thập lại với nhau trong Báo cáo thẩm tra chuẩn bị ứng dụng và Báo cáo kiểm thử ứng dụng.

8.4.1.7  Kế hoạch chuẩn bị ứng dụng phải có các hoạt động thẩm tra và thẩm định để đảm bảo các chương trình ứng dụng và phần mềm chung là tương thích với nhau và tương thích với ứng dụng cụ thể và để đưa ra bằng chứng về việc đáp ứng các điều kiện ứng dụng.

8.4.1.8  Phải tiến hành phân tích rủi ro trong quá trình phát triển ứng dụng, bao gồm các chương trình ứng dụng và các quy trình, để thẩm định kế hoạch chuẩn bị ứng dụng và để đáp ứng mức toàn vẹn về an toàn phần mềm yêu cầu. Kế hoạch chuẩn bị ứng dụng phải bao gồm cả việc phân tích rủi ro.

8.4.1.9  Kế hoạch chuẩn bị ứng dụng phải quy định các yêu cầu về sự độc lập giữa nhân viên tiến hành các nhiệm vụ thẩm tra, thẩm định và chuẩn bị theo 5.1.

Chú thích: Các hoạt động chuẩn bị dữ liệu được tiến hành bởi các đơn vị thiết kế ứng dụng.

8.4.1.10  Kế hoạch chuẩn bị ứng dụng phải xác định loại chương trình cho tất cả các chương trình phần cứng hoặc phần mềm được sử dụng trong vòng đời chuẩn bị ứng dụng.

8.4.1.11  Nếu có thể, Kế hoạch chuẩn bị ứng dụng phải đặt ra các ký hiệu để quy định các yêu cầu và thiết kế mà quen thuộc với các kỹ sư ứng dụng. Nếu đưa ra các ký hiệu mới, phải đưa ra các tài liệu cần thiết cho người sử dụng, cũng như các quá trình đào tạo phù hợp.

8.4.1.12  Báo cáo thẩm tra các thuật toán / dữ liệu ứng dụng phải được lập thành văn bản, do trách nhiệm của Đơn vị thẩm tra, trên cơ sở các tài liệu đầu vào ở mục 8.2.

Các yêu cầu trong mục 8.4.1.13 tham chiếu Báo cáo thẩm tra các thuật toán / dữ liệu ứng dụng.

8.4.1.13  Khi đã lập xong Kế hoạch chuẩn bị ứng dụng, việc thẩm tra phải xem xét các vấn đề sau:

a) Kế hoạch chuẩn bị ứng dụng có đáp ứng các yêu cầu chung về khả năng đọc được và khả năng truy vét từ mục 5.3.2.7 đến mục 5.3.2.10 và từ mục 6.5.4.14 đến mục 6.5.4.17 cũng như các yêu cầu cụ thể từ mục 8.4.1.2 đến mục 8.4.1.11.

b) Sự thống nhất nội bộ của Kế hoạch chuẩn bị ứng dụng.

Các kết quả phải được ghi lại trong Báo cáo thẩm tra các thuật toán / dữ liệu ứng dụng.

8.4.1.14  Phải thẩm tra và thẩm định việc thực hiện Kế hoạch chuẩn bị ứng dụng cho từng ứng dụng cụ thể.

8.4.2  Chỉ dẫn các yêu cầu ứng dụng

8.4.2.1  Chỉ dẫn các yêu cầu ứng dụng phải được lập thành văn bản, do trách nhiệm của Đơn vị quản lý các yêu cầu, trên cơ sở các tài liệu đầu vào trong mục 8.2.

Các yêu cầu từ mục 8.4.2.2 đến 8.4.2.3 tham chiếu tới Chỉ dẫn các yêu cầu ứng dụng.

8.4.2.2  Trong các yêu cầu đối với ứng dụng cụ thể phải có các yêu cầu cụ thể cho từng lắp đặt (ví dụ: bố trí đường ray, các cột tín hiệu, các giới hạn tốc độ của hệ thống tín hiệu), cũng như tóm tắt lại hoặc xem xét các điều kiện ứng dụng của phần mềm chung và các chương trình ứng dụng, và các tiêu chuẩn phải tuân thủ của ứng dụng (ví dụ: các nguyên tắc phát tín hiệu của hệ thống tín hiệu).

8.4.2.3  Phải quy định các yêu cầu liên quan tới các thuật toán và dữ liệu ứng dụng được xử lý bởi phần mềm chung của hệ thống tại giai đoạn này.

8.4.2.4  Báo cáo thẩm tra các thuật toán / dữ liệu ứng dụng phải được lập thành văn bản, do trách nhiệm của Đơn vị quản lý các yêu cầu, trên cơ sở các tài liệu đầu vào trong mục 8.2.

Các yêu cầu từ mục 8.4.2.5 tham chiếu tới Báo cáo thẩm tra các thuật toán / dữ liệu ứng dụng.

8.4.2.5  Khi đã lập xong Chỉ dẫn các yêu cầu ứng dụng, việc thẩm tra phải xem xét các vấn đề sau:

a) Chỉ dẫn các yêu cầu ứng dụng có đáp ứng các yêu cầu chung về khả năng đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.17 cũng như các yêu cầu cụ thể từ mục 8.4.2.2 đến 8.4.2.3.

b) Sự thống nhất nội bộ của Chỉ dẫn các yêu cầu ứng dụng

Các kết quả phải được ghi lại trong Báo cáo thẩm tra các thuật toán / dữ liệu ứng dụng.

8.4.3  Cấu trúc và thiết kế

8.4.3.1  Phải quy định số lượng và kiểu loại các thành phần phần cứng và phần mềm chung được sử dụng trong ứng dụng cụ thể. Vị trí của các thành phần, các thuật toán và dữ liệu ứng dụng trong cấu trúc ứng dụng cụ thể phải được xác định. Các thuật toán và dữ liệu ứng dụng được xử lý bởi phần mềm chung phải được thiết kế tại giai đoạn này.

8.4.4  Phát triển các thuật toán / dữ liệu ứng dụng

8.4.4.1  Quá trình phát triển ứng dụng phải bao gồm việc lập và biên dịch mã nguồn của các thuật toán / dữ liệu ứng dụng cụ thể và chung, cũng như các hoạt động thẩm tra và kiểm thử liên quan đến quá trình lập này. Khuyến nghị sử dụng các ngôn ngữ có dạng sơ đồ để tạo mã nguồn cho các thuật toán ứng dụng. Tham chiếu Bảng A.16.

8.4.4.2  Báo cáo kiểm thử ứng dụng phải được lập thành văn bản, do trách nhiệm của Đơn vị kiểm thử, trên cơ sở các tài liệu đầu vào trong mục 8.2.

Các yêu cầu từ mục 8.4.4.3 tham chiếu tới Báo cáo kiểm thử ứng dụng.

8.4.4.3  Báo cáo kiểm thử ứng dụng phải ghi lại các lần chạy chính xác và hoàn chỉnh của các kiểm thử được quy định trong Chỉ dẫn kiểm thử ứng dụng.

8.4.4.4  Báo cáo thẩm tra chuẩn bị ứng dụng phải:

a) Ghi lại mọi hoạt động được thực hiện để đảm bảo sự chính xác và hoàn chỉnh của dữ liệu / thuật toán và sự gắn kết với các nguyên lý ứng dụng và cấu trúc ứng dụng cụ thể.

b) Đánh giá mức độ tương thích của dữ liệu / thuật toán với ứng dụng chung.

8.4.4.5  Chỉ dẫn kiểm thử ứng dụng phải được lập thành văn bản, do trách nhiệm của Đơn vị kiểm thử, trên cơ sở các tài liệu đầu vào trong mục 8.2.

Các yêu cầu từ mục 8.4.4.6 tham chiếu tới Chỉ dẫn kiểm thử ứng dụng.

8.4.4.6  Chỉ dẫn kiểm thử ứng dụng phải quy định các kiểm thử được tiến hành ở giai đoạn trung gian hoặc giai đoạn cuối cùng của quá trình chuẩn bị dữ liệu / thuật toán, để đảm bảo:

a) Sự gắn kết và hoàn chỉnh của dữ liệu/ thuật toán với các nguyên lý ứng dụng.

b) Sự gắn kết và hoàn chỉnh của dữ liệu/ thuật toán với cấu trúc ứng dụng cụ thể.

8.4.4.7  Báo cáo thẩm tra ứng dụng / thuật toán phải được lập thành văn bản, dưới trách nhiệm của Đơn vị thẩm tra, trên cơ sở các tài liệu đầu vào trong mục 8.2.

Các yêu cầu từ mục 8.4.4.8 tham chiếu tới Báo cáo thẩm tra các thuật toán / dữ liệu ứng dụng.

8.4.4.8  Khi đã lập xong Chỉ dẫn kiểm thử ứng dụng, việc thẩm tra phải xem xét các vấn đề sau:

a) Chỉ dẫn các yêu cầu ứng dụng có đáp ứng các yêu cầu chung về khả năng đọc được và khả năng truy vết từ mục 5.3.27 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.17 cũng như các yêu cầu cụ thể trong mục 8.4.4.6.

b) Sự thống nhất nội bộ của Chỉ dẫn kiểm thử ứng dụng.

Các kết quả phải được ghi lại trong Báo cáo thẩm tra các thuật toán / dữ liệu ứng dụng.

8.4.5  Tích hợp ứng dụng và chấp nhận kiểm thử

8.4.5.1  Đối với một số hệ thống, các thuật toán / dữ liệu ứng dụng có thể được tích hợp cùng với phần cứng và phần mềm chung trong kiểm thử xuất xưởng trước khi lắp đặt vào hệ thống mục tiêu. Điều này có thể không cần thiết nếu có thể đạt được đủ mức độ tin cậy bằng các phương pháp khác. Ứng dụng sau đó phải được lắp đặt vào hệ thống mục tiêu, và phải thực hiện các kiểm thử tích hợp trong các lắp đặt hoàn chỉnh. Hệ thống mục tiêu cuối cùng phải được chạy thử như một hệ thống hoạt động đầy đủ và thực hiện quá trình chấp nhận cuối cùng hệ thống mục tiêu khi lắp đặt hoàn chỉnh. Báo cáo kiểm thử ứng dụng phải ghi lại quá trình chạy chương trình đúng và hoàn chỉnh của các kiểm thử được quy định trong Chỉ dẫn kiểm thử ứng dụng. Báo cáo thẩm tra chuẩn bị ứng dụng phải kiểm tra sự hoàn chỉnh và sự chính xác của các kiểm thử được tiến hành khi lắp đặt hoàn chỉnh.

8.4.5.2  Chỉ dẫn kiểm thử ứng dụng phải được lập thành văn bản, do trách nhiệm của Đơn vị kiểm thử, trên cơ sở các tài liệu đầu vào trong mục 8.2.

Các yêu cầu từ mục 8.4.4.8 tham chiếu tới Chỉ dẫn kiểm thử ứng dụng.

8.4.5.3  Chỉ dẫn kiểm thử ứng dụng phải quy định các kiểm thử được tiến để đảm bảo:

a) Sự tích hợp chính xác dữ liệu / thuật toán trên phần mềm và phần cứng chung, nếu cần thiết.

b) Sự tích hợp chính xác dữ liệu / thuật toán khi lắp đặt hoàn chỉnh.

8.4.5.4  Báo cáo thẩm tra các thuật toán / dữ liệu ứng dụng phải được lập thành văn bản, do trách nhiệm của Đơn vị thẩm tra, trên cơ sở các tài liệu đầu vào trong mục 8.2.

Các yêu cầu từ mục 8.4.5.5 tham chiếu tới Báo cáo thẩm tra các thuật toán / dữ liệu ứng dụng.

8.4.5.5  Khi đã lập xong Chỉ dẫn kiểm thử ứng dụng, việc thẩm tra phải xem xét xem Chỉ dẫn kiểm thử ứng dụng có đáp ứng được các yêu cầu cụ thể trong mục 8.4.5.3.

8.4.6  Thẩm định và đánh giá ứng dụng

Các hoạt động thẩm định và đánh giá phải đánh giá hiệu năng của từng giai đoạn vòng đời.

8.4.7  Các chương trình và các quy trình chuẩn bị ứng dụng

8.4.7.1  Đối với từng loại hệ thống mới được cấu hình bằng các thuật toán / dữ liệu ứng dụng, các chương trình và quy trình cụ thể phải được xây dựng để cho phép áp dụng quá trình phát triển ứng dụng quy định trong mục 8.4.1 cho các lắp đặt hệ thống mới. Việc phát triển những chương trình này phải được thực hiện phù hợp với tiêu chuẩn này, cũng như phù hợp với phần mềm và phần cứng chung trong hệ thống. Các hoạt động thẩm tra, thẩm định và đánh giá phải đảm bảo các chương trình chuẩn bị dữ liệu và phần mềm chung là tương thích.

8.4.7.2  Mọi quá trình phát triển phải được thẩm định và đánh giá. Phải chú ý là sẽ thường cần các chương trình biên dịch chuyên dụng để chuyển đổi dữ liệu và thuật toán.

8.4.7.3  Tất cả các thuật toán / dữ liệu ứng dụng và tài liệu liên quan đến từng ứng dụng cụ thể phải theo các yêu cầu triển khai phần mềm như được quy định trong mục 9.1.

8.4.7.4  Tất cả các thuật toán / dữ liệu ứng dụng và tài liệu liên quan đến từng ứng dụng cụ thể phải theo các yêu cầu bảo trì phần mềm như được quy định trong mục 9.2.

8.4.7.5  Tất cả các thuật toán / dữ liệu ứng dụng và tài liệu liên quan đến từng ứng dụng cụ thể phải được quản lý cấu hình theo các yêu cầu quy định trong mục 6.5 và 6.7. Việc quản lý cấu hình các thuật toán / dữ liệu ứng dụng có thể độc lập với việc quản lý phần mềm chung.

8.4.7.6  Báo cáo thẩm tra ứng dụng chứng minh mức độ và sự bắt buộc các điều kiện ứng dụng của phần mềm chung và các chương trình ứng dụng.

8.4.8  Phát triển phần mềm chung

8.4.8.1  Việc phát triển phần mềm chung mà hỗ trợ cho việc chạy các thuật toán / dữ liệu ứng dụng phải phù hợp với các yêu cầu từ mục 7.1 đến 7.7 của tiêu chuẩn này. Các yêu cầu bổ sung dưới đây cũng phải được giám sát.

8.4.8.2  Phải xác định rõ các loại hoặc các cấp độ chức năng có thể được cấu hình bằng các thuật toán / dữ liệu ứng dụng trong từng hệ thống và hệ thống con trong các tài liệu Chỉ dẫn các yêu cầu phần mềm của phần mềm chung. Mức toàn vẹn về an toàn được chỉ định cho các chức năng sẽ xác định các tiêu chuẩn được áp dụng cho quá trình phát triển sau này của các thuật toán / dữ liệu ứng dụng cho tất cả các lắp đặt trong hệ thống.

8.4.8.3  Trong quá trình thiết kế phần mềm chung, phải quy định các giao diện chi tiết giữa phần mềm chung và các thuật toán / dữ liệu ứng dụng, trừ khi các giao diện này đã được quy định ở giai đoạn vòng đời trước đó, ví dụ: theo yêu cầu về sử dụng một ngôn ngữ ứng dụng cụ thể hiện có.

8.4.8.4  Phải tăng cường sự phân tách rõ ràng giữa phần mềm chung và các thuật toán / dữ liệu ứng dụng, ví dụ: phải có khả năng biên dịch lại và cập nhật phần mềm chung hoặc các thuật toán / dữ liệu ứng dụng mà không cần phải cập nhật những hạng mục khác, trừ khi có sự thay đổi về giao diện xác định giữa phần mềm chung và các thuật toán / dữ liệu ứng dụng. Mặt khác, phải tách biệt các thuật toán / dữ liệu cụ thể theo các ứng dụng với các thuật toán / dữ liệu ứng dụng chung.

8.4.8.5  Các quy trình kiểm soát sự thay đổi phải đảm bảo mọi thay đổi của phần mềm chung chỉ có thể được lắp đặt sau khi đã xây dựng được phần mềm đã được sửa đổi là tương thích với các thuật toán / dữ liệu ứng dụng gốc hoặc các thuật toán / dữ liệu ứng dụng đã được sửa đổi.

8.4.8.6  Phải chú ý trong quá trình thẩm tra và giai đoạn kiểm thử thẩm định của phần mềm chung để đảm bảo tất cả các kết hợp dữ liệu và thuật toán liên quan đã được xem xét.

Nếu chưa xem xét tất cả các kết hợp dữ liệu và thuật toán liên quan trong quá trình thẩm tra, kiểm thử và thẩm định của phần mềm chung, phải xác định rõ các kết hợp này như là hạn chế sử dụng của phần mềm chung. Phải thực hiện hoàn chỉnh quá trình thẩm tra, kiểm thử về thẩm định phần mềm chung khi một số dữ liệu hoặc thuật toán được xác định là vượt quá hạn chế này.

8.4.8.7  Phần mềm chung phải được thiết kế để phát hiện các thuật toán / dữ liệu ứng dụng bị lỗi nếu việc thực hiện này khả thi.

8.4.8.8  Các Đơn vị thiết kế phải đưa ra các Thông tin lưu ý về phiên bản phần mềm chung và các chương trình ứng dụng trong giai đoạn Kiểm thử tổng thể phần mềm/thẩm định lần cuối của phần mềm chung và các chương trình ứng dụng. Nội dung của những tài liệu này phải theo các hoạt động thẩm tra và thẩm định.

Các nội dung dưới đây phải được đề cập đến trong tài liệu “Các điều kiện áp dụng của phần mềm chung và các chương trình ứng dụng”:

1) Các tham chiếu tới hướng dẫn sử dụng phần mềm chung và các chương trình ứng dụng.

2) Mọi ràng buộc của các thuật toán / dữ liệu ứng dụng, ví dụ: cấu trúc hoặc các quy tắc mã hóa bắt buộc để đáp ứng các mức toàn vẹn về an toàn.

9  Triển khai và bảo trì phần mềm

9.1  Triển khai phần mềm

9.1.1  Mục tiêu

9.1.1.1  Để đảm bảo phần mềm hoạt động như được yêu cầu, duy trì mức toàn vẹn về an toàn yêu cầu và độ tin cậy khi triển khai phần mềm trong môi trường ứng dụng cuối cùng.

9.1.2  Tài liệu đầu vào

Tất cả các tài liệu thiết kế, phát triển và phân tích liên quan đến quá trình triển khai.

9.1.3  Tài liệu đầu ra

1) Kế hoạch phát hành và triển khai phần mềm

2) Hướng dẫn triển khai phần mềm

3) Thông tin lưu ý về phiên bản phần mềm sử dụng

4) Các biên bản triển khai

5) Báo cáo thẩm tra quá trình triển khai

9.1.4  Các yêu cầu

9.1.4.1  Phải thực hiện việc triển khai do trách nhiệm của đơn vị quản lý dự án.

9.1.4.2  Trước khi chuyển giao phát hành phần mềm, cơ sở của phần mềm phải được ghi lại và duy trì việc truy vết theo quá trình kiểm soát quản lý cấu hình. Phải bao gồm cả phần mềm đã có trước đó và phần mềm được phát triển theo phiên bản trước đây của tiêu chuẩn này.

9.1.4.3  Việc phát hành phần mềm phải được tái lập lại trong suốt vòng đời cơ sở.

9.1.4.4  Thông tin lưu ý về phiên bản phần mềm phải được lập thành văn bản, do trách nhiệm của Đơn vị thiết kế, trên cơ sở các tài liệu của mục 9.1.2.

Các yêu cầu trong mục 9.1.4.5 tham chiếu tới Thông tin lưu ý về phiên bản phần mềm sử dụng.

9.1.4.5  Thông tin lưu ý về phiên bản phần mềm sử dụng phải đưa ra:

a) Các điều kiện áp dụng phải được tuân thủ.

b) Thông tin về khả năng tương thích giữa các thành phần phần mềm và giữa phần mềm với phần cứng.

c) Tất cả các hạn chế trong quá trình sử dụng phần mềm (xem 7.7.4.12).

9.1.4.6  Hướng dẫn triển khai phần mềm phải được lập thành văn bản trên cơ sở các tài liệu đầu vào trong mục 9.1.2.

Các yêu cầu trong mục 9.1.4.7 tham chiếu Hướng dẫn triển khai phần mềm.

9.1.4.7  Hướng dẫn triển khai phần mềm phải xác định các quy trình để xác định rõ và thực hiện chính xác quá trình phát hành phần mềm.

9.1.4.8  Trong trường hợp triển khai mang tính bổ sung tăng cường (ví dụ: triển khai các thành phần đơn lẻ), khuyến nghị cao đối với SIL 3 và SIL 4, khuyến nghị với SIL 1 và SIL 2 việc phần mềm được thiết kế có các bộ phận đảm bảo kích hoạt loại trừ các phiên bản không tương thích của các thành phần trong phần mềm.

9.1.4.9  Quá trình quản lý cấu hình phải đảm bảo việc có mặt đồng thời các phiên bản khác nhau của các thành phần phần mềm giống nhau không phát sinh ra sự gây hại nếu việc này không thể tránh được.

9.1.4.10  Phải có quy trình quay vòng (ví dụ: khả năng quay về các phiên bản trước đây) khi triển khai lắp đặt một phần mềm mới.

9.1.4.11  Phần mềm phải có các cơ chế tự xác định phiên bản được tích hợp, cho phép tự xác định trong quá trình hoạt động và sau khi nạp vào đối tượng. Cơ chế tự xác định nên chỉ rõ thông tin về phiên bản của phần mềm đối với phần mềm và mọi dữ liệu cấu hình cũng như định dạng sản phẩm.

Chú thích: Khuyến nghị bảo vệ các dữ liệu có trong các đoạn mã có chứa các thông tin về phát hành phần mềm trong suốt quá trình mã hóa (xem Bảng A.3 “Các mã phát hiện lỗi”).

9.1.4.12  Biên bản triển khai phải được lập thành văn bản trên cơ sở các tài liệu đầu vào trong mục 9.1.2.

Yêu cầu trong mục 9.1.4.13 tham chiếu tới Biên bản triển khai phần mềm.

9.1.4.13  Biên bản triển khai phải đưa ra bằng chứng về việc phần mềm đã được tải lên, bằng cách kiểm tra các cơ chế tự xác định đã được tích hợp sẵn (xem 9.1.4.11). Biên bản này phải được lưu trữ trong các tài liệu liên quan đến hệ thống được chuyển giao giống như các lần thẩm tra khác và là một phần trong quá trình thử hoạt động và chấp nhận.

9.1.4.14  Phần mềm được triển khai phải có khả năng truy vết theo các lắp đặt được chuyển giao.

Chú thích: Việc này đặc biệt quan trọng khi phát hiện ra các sự cố nghiêm trọng và cần phải được hiệu chỉnh trong nhiều hơn một lần cài đặt.

9.1.4.15  Phần mềm phải đưa ra được các thông tin chuẩn đoán, và là một phần của hoạt động giám sát sự cố.

9.1.4.16  Biên bản thẩm tra triển khai phải được lập thành văn bản, do trách nhiệm của Đơn vị thẩm tra, trên cơ sở các tài liệu đầu vào của mục 9.1.2.

Các yêu cầu của mục 9.1.4.17 đến 9.1.4.19 tham chiếu Báo cáo thẩm tra triển khai.

9.1.4.17  Khi đã lập xong Hướng dẫn triển khai phần mềm, việc thẩm tra phải xem xét các vấn đề sau:

a) Hướng dẫn triển khai phần mềm có đáp ứng các yêu cầu chung về khả năng đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.17 cũng như các yêu cầu cụ thể trong mục 9.1.4.7.

b) Sự thống nhất nội bộ của Hướng dẫn triển khai phần mềm.

9.1.4.18  Khi đã lập xong Biên bản triển khai, việc thẩm tra phải xem xét các vấn đề sau:

a) Biên bản triển khai có đáp ứng các yêu cầu chung về khả năng đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.17 cũng như các yêu cầu cụ thể trong mục 9.1.4.13.

b) Sự thống nhất nội bộ của Biên bản triển khai.

9.1.4.19  Khi đã lập xong Hướng dẫn đi kèm, việc thẩm tra phải xem xét các vấn đề sau:

a) Hướng dẫn đi kèm có đáp ứng các yêu cầu chung về khả năng đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.17 cũng như các yêu cầu cụ thể trong mục 9.1.4.5.

b) Sự thống nhất nội bộ của Hướng dẫn đi kèm.

9.1.4.20  Phải có các biện pháp trong gói phần mềm để ngăn chặn hoặc phát hiện ra các lỗi phát sinh trong quá trình lưu trữ, chuyển đổi, chạy hoặc lặp lại các đoạn mã hoặc dữ liệu thực hiện. Khuyến nghị mã hóa các đoạn mã chạy trong quá trình nạp.

9.2  Bảo trì phần mềm

9.2.1  Mục tiêu

9.2.1.1  Để đảm bảo phần mềm hoạt động như yêu cầu, duy trì mức toàn vẹn về an toàn phần mềm yêu cầu và độ tin cậy khi tiến hành sửa chữa, cải tiến hoặc thay đổi phù hợp với chính phần mềm. Xem thêm mục 6.6 “Kiểm soát sự thay đổi và cải tiến” trong tiêu chuẩn này và giai đoạn 13 “Cải tiến và thay đổi” trong TCVN 10935-1.

9.2.2  Tài liệu đầu vào

Tất cả các tài liệu thiết kế, phát triển và phân tích liên quan.

9.2.3  Tài liệu đầu ra

1) Kế hoạch bảo trì phần mềm.

2) Các biên bản thay đổi phần mềm.

3) Các biên bản bảo trì phần mềm.

4) Báo cáo thẩm tra bảo trì phần mềm

9.2.4  Các yêu cầu

9.2.4.1  Mặc dù tiêu chuẩn này không nhằm áp dụng cho các phần mềm cũ mà chỉ áp dụng cho các phần mềm xây dựng mới và chỉ áp dụng cho toàn bộ phần mềm hiện có nếu nó có các thay đổi lớn, quá trình bảo trì phần mềm liên quan trong mục 9.2 này sẽ áp dụng cho tất cả các thay đổi, kể cả các thay đổi nhỏ. Tuy nhiên, khuyến nghị cao áp dụng toàn bộ tiêu chuẩn này trong quá trình nâng cấp và bảo trì các phần mềm hiện có.

9.2.4.2  Đối với mọi mức toàn vẹn về an toàn phần mềm, nhà cung cấp trước khi bắt đầu công việc thay đổi phải quyết định liệu các hoạt động bảo trì được xem là lớn hay nhỏ hoặc các phương pháp bảo trì hệ thống có phù hợp. Nhà cung cấp phải chứng minh và ghi lại quyết định này và đệ trình lên Đơn vị đánh giá để đánh giá.

9.2.4.3  Phải thực hiện việc bảo trì phù hợp với các hướng dẫn có trong tiêu chuẩn ISO/IEC 9000-3.

9.2.4.4  Phải thiết kế khả năng bảo trì như một đặc tính vốn có của phần mềm, đặc biệt theo các yêu cầu của mục 7.3, 7.4 và 7.5. Phải sử dụng bộ tiêu chuẩn ISO/IEC 9126 để thực hiện và thẩm tra mức độ khả năng bảo trì nhỏ nhất.

9.2.4.5  Kế hoạch bảo trì phần mềm phải được lập thành văn bản trên cơ sở các tài liệu đầu vào của mục 9.2.2.

Các yêu cầu trong mục 9.2.4.6 tham chiếu tới Kế hoạch bảo trì phần mềm.

9.2.4.6  Phải thiết lập và ghi lại các quy trình bảo trì phần mềm trong Kế hoạch bảo trì phần mềm. Các quy trình này cũng phải đề cập tới các vấn đề sau

a) Kiểm soát việc báo cáo lỗi, ghi lại lỗi, các biên bản bảo trì, các xác nhận thay đổi và cấu hình phần mềm/hệ thống và các kỹ thuật, biện pháp có trong Bảng A.10.

b) Việc thẩm tra, thẩm định và đánh giá mọi sự thay đổi.

c) Các xác nhận đối với việc thay đổi.

9.2.4.7  Biên bản bảo trì phần mềm phải được lập thành văn bản trên cơ sở các tài liệu đầu vào trong mục 9.2.2.

Yêu cầu trong mục 9.2.4.8 tham chiếu Biên bản bảo trì phần mềm.

9.2.4.8  Phải lập Biên bản bảo trì phần mềm cho từng hạng mục của phần mềm trước khi phát hành lần đầu tiên và phải duy trì việc này. Để bổ sung cho các yêu cầu trong ISO/IEC 90003:2004 về “Các biên bản và báo cáo bảo trì” (xen ISO/IEC 90003:2004, mục “Bảo trì”), biên bản này phải có:

a) Các tham chiếu đến tất cả các Biên bản thay đổi phần mềm cho hạng mục phần mềm đó.

b) Việc đánh giá tác động của thay đổi.

c) Các trường hợp kiểm thử các thành phần, bao gồm dữ liệu về việc thẩm định lại và kiểm thử hồi quy.

d) Lịch sử cấu hình phần mềm.

9.2.4.9  Biên bản thay đổi phần mềm phải được lập thành văn bản trên cơ sở các tài liệu đầu vào trong mục 9.2.2.

Yêu cầu trong mục 9.2.4.10 tham chiếu Biên bản thay đổi phần mềm.

9.2.4.10  Phải lập Biên bản thay đổi phần mềm cho từng hoạt động bảo trì. Biên bản này phải có:

a) Yêu cầu thay đổi hoặc cải tiến, phiên bản, bản chất của sự cố, thay đổi cần thiết và nguồn lực để thay đổi.

b) Phân tích tác động của hoạt động bảo trì đối với tổng thể hệ thống, bao gồm tương tác phần cứng, phần mềm, con người và môi trường và các tương tác có thể.

c) Chỉ dẫn kỹ thuật chi tiết việc thay đổi hoặc cải tiến được tiến hành.

d) Quá trình thẩm định lại, kiểm thử hồi quy và đánh giá lại việc thay đổi hoặc cải tiến theo mức toàn vẹn về an toàn phần mềm yêu cầu. Trách nhiệm đối với việc thẩm định lại có thể thay đổi theo dự án, tùy thuộc vào mức toàn vẹn về an toàn phần mềm. Đồng thời, tác động của việc thay đổi hoặc cải tiến đối với quá trình thẩm định lại có thể bị hạn chế theo các mức độ hệ thống khác nhau (chỉ có các tổng thành bị thay đổi, tất cả các tổng thành được xác định là bị tác động, toàn bộ hệ thống). Do đó Kế hoạch thẩm định phần mềm phải đề cập tới các vấn đề này theo mức toàn vẹn về an toàn phần mềm. Mức độ độc lập của quá trình thẩm định lại phải giống với mức độ như khi thẩm định mới.

9.2.4.11  Phải lập Báo cáo thẩm tra bảo trì phần mềm, do trách nhiệm của đơn vị thẩm tra, trên cơ sở các tài liệu đầu vào trong mục 9.2.2.

Các yêu cầu từ mục 9.2.4.12 đến 9.2.4.14 tham chiếu tới Báo cáo thẩm tra bảo trì phần mềm.

9.2.4.12  Khi đã lập xong Kế hoạch bảo trì phần mềm, việc thẩm tra phải xem xét các vấn đề sau:

a) Kế hoạch bảo trì phần mềm có đáp ứng các yêu cầu chung về khả năng đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.17 cũng như các yêu cầu cụ thể trong mục 9.2.4.6.

b) Sự thống nhất nội bộ của Kế hoạch bảo trì phần mềm.

9.2.4.13  Khi đã lập xong Biên bản bảo trì phần mềm, việc thẩm tra phải xem xét các vấn đề sau:

a) Biên bản bảo trì phần mềm có đáp ứng các yêu cầu chung về khả năng đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.17 cũng như các yêu cầu cụ thể trong mục 9.2.4.8.

b) Sự thống nhất nội bộ của Biên bản bảo trì phần mềm.

9.2.4.14  Khi đã lập xong Biên bản thay đổi phần mềm, việc thẩm tra phải xem xét các vấn đề sau:

a) Biên bản thay đổi phần mềm có đáp ứng các yêu cầu chung về khả năng đọc được và khả năng truy vết từ mục 5.3.2.7 đến 5.3.2.10 và từ mục 6.5.4.14 đến 6.5.4.17 cũng như các yêu cầu cụ thể trong mục 9.2.4.10.

b) Sự thống nhất nội bộ của Biên bản thay đổi phần mềm.

9.2.4.15  Phải tiến hành các hoạt động bảo trì theo Kế hoạch bảo trì phần mềm.

9.2.4.16  Phải lựa chọn các kỹ thuật và các biện pháp trong Bảng A.10. Phải chứng minh việc kết hợp lựa chọn là thỏa mãn mục 4.8 và 4.9.

9.2.4.17  Phải thực hiện việc bảo trì tối thiểu với mức độ về kinh nghiệm, chương trình, ghi chép lưu trữ, lập kế hoạch và quản lý giống với mức độ khi phát triển phần mềm lúc đầu. Việc này cũng phải áp dụng cho việc quản lý cấu hình, kiểm soát thay đổi, kiểm soát tài liệu và mức độ độc lập của các bên liên quan.

9.2.4.18  Phải quản lý các hoạt động kiểm soát nhà cung cấp từ bên ngoài, các hoạt động báo cáo sự cố và hoạt động khắc phục với chỉ tiêu được quy định trong các nội dung liên quan trong mục Đảm bảo chất lượng phần mềm (6.5) giống như khi phát triển phần mềm mới.

9.2.4.19  Đối với từng sự cố hoặc thay đổi được báo cáo, phải thực hiện phân tích tác động đến an toàn.

9.2.4.20  Đối với phần mềm được bảo trì, phải tiến hành các hoạt động giảm thiểu được cân đối theo rủi ro đã xác định để đảm bảo tính toàn vẹn tổng thể của hệ thống, khi mà các vấn đề báo cáo được điều tra và khắc phục.

Phụ lục A

(Quy định)

Tiêu chí lựa chọn các kỹ thuật và biện pháp

Các điều khoản trong tiêu chuẩn được kết hợp trong phụ lục này thông qua các bảng (xem mục A.1, từ Bảng A.1 đến Bảng A.11) để minh họa các biện pháp đạt được sự phù hợp. Có những bảng ở mức độ thấp hơn, có bảng được nêu chi tiết (xem A.2, từ Bảng A.12 đến Bảng A.23), mở rộng dựa trên các chủ đề nhất định trong các bảng. Ví dụ, “Lập mô hình” trong Bảng A.2 và được nêu chi tiết trong Bảng A.17. Phụ lục tham khảo D tham chiếu từ các bảng này.