DO-178B và DO-178C tiêu chuẩn chứng nhận phần mềm đóng vai trò là hướng dẫn cho việc sản xuất các hệ thống bay đủ điều kiện bay. Được công bố lần đầu vào năm 1992, DO-178B (Software Considerations in Airborne Systems and Equipment Certification) là một tài liệu quan trọng được xem xét để đạt được chứng nhận cần thiết từ các cơ quan quản lý như EASA (Cơ quan An toàn Hàng không Liên minh Châu Âu) và FAA (Cục Hàng không Liên bang Hoa Kỳ) đối với các hệ thống bay dựa trên phần mềm. Tuy nhiên, Federal Aviation Regulations đã công nhận DO-178C là phương pháp chứng minh sự tuân thủ về khả năng đủ điều kiện bay vào năm 2013. Để biết thêm thông tin tổng quan về các tiêu chuẩn DO-178B và DO-178C, bạn có thể đọc bài viết này.
Các tiêu chuẩn DO-178B hoặc DO178C phải được đáp ứng thông qua các tài liệu mẫu sau đây và nhiều tài liệu khác.
- PSAC (Plan for Software Aspects of Certification)
- SDP (Software Development Plan)
- SVP (Software Verification Plan)
- SCMP (Software Configuration Management Plan)
- SQAP (Software Quality Assurance Plan)
- SAS (Software Accomplishment Summary)
Các tài liệu cần thiết để đáp ứng tiêu chuẩn DO-178B và DO-178C không chỉ giới hạn ở những tài liệu trên. Còn có nhiều tài liệu khác giúp làm phong phú thêm khả năng đủ điều kiện bay. Bạn có thể xem và mua các tài liệu này tại đây.
Tài liệu DO178
Tài liệu PSAC
Tài liệu PSAC (Plan for Software Aspects of Certification), bên cạnh việc tạo ra dữ liệu vòng đời, còn giải thích các tiêu chuẩn, quy trình, giao thức và phương pháp cần thiết phải tuân theo. Nhờ đó, các tiêu chuẩn DO-178 có thể được đáp ứng. PSAC cũng quy định tiến độ phát triển phần mềm và tình trạng tổng thể của hệ thống. Cả cơ quan phê duyệt lẫn đơn vị xin chứng nhận đều được hưởng lợi từ tài liệu này. PSAC phải được lập ra trong quá trình lập kế hoạch phần mềm ban đầu và được cơ quan chứng nhận phê duyệt. Vui lòng nhấn vào đây để xem tài liệu PSAC của chúng tôi.
Tài liệu SDP
Tài liệu SDP (Software Development Plan) nhằm kiểm tra xem các thông tin cần thiết như quy trình phát triển, giao thức, tiêu chuẩn, vòng đời và môi trường phát triển đã được xác định hay chưa. Tài liệu SDP là một phần quan trọng của quy trình lập kế hoạch phần mềm. Vui lòng nhấn vào đây để xem tài liệu SDP của chúng tôi.
Tài liệu SVP
Tài liệu SVP (Software Verification Plan) quy định các kịch bản và phạm vi thử nghiệm cần thiết, quy trình, giao thức, kiểm chứng yêu cầu và kiểm chứng mã nguồn, đồng thời cung cấp khả năng kiểm soát phiên bản phù hợp. SVP cũng là một phần quan trọng của quy trình lập kế hoạch. Vui lòng nhấn vào đây để xem tài liệu SVP của chúng tôi.
Tài liệu SCMP
Tài liệu SCMP (Software Configuration Management Plan) là một yếu tố quan trọng khác của quy trình lập kế hoạch. Kế hoạch ban đầu được chuẩn bị trong suốt quá trình phát triển phần mềm thường trải qua nhiều thay đổi. SCMP giúp chúng ta phát hiện, kiểm soát, duy trì và theo dõi những thay đổi này. Tài liệu này được áp dụng xuyên suốt quá trình phát triển phần mềm. SCMP nhằm giảm thiểu sai sót và tối đa hóa hiệu quả. Các thành viên trong nhóm phải nỗ lực báo cáo và thông báo cho nhau về các thay đổi. Vui lòng nhấn vào đây để xem tài liệu SCMP của chúng tôi.
Tài liệu SQAP
Tài liệu SQAP (Software Quality Assurance Plan) chứa các công cụ, phương pháp và kỹ thuật được sử dụng để đảm bảo rằng sản phẩm hoặc dịch vụ đáp ứng các thông số kỹ thuật được nêu trong SRS (Software Requirement specification). SQAP giải thích cách thức các Hoạt động Đảm bảo Chất lượng Phần mềm sẽ được thực hiện trong dự án. Đội ngũ SQA thiết lập các cột mốc và đánh giá chất lượng của dự án tại từng cột mốc. SQA được thực hiện xuyên suốt vòng đời phần mềm. Vui lòng nhấn vào đây để xem tài liệu SQAP của chúng tôi
Tài liệu SAS
Tài liệu SAS (Software Accomplishment Summary) tóm tắt từng bước của các thành phần phần mềm trong quá trình phát triển và kiểm chứng. SAS nên bao gồm bản tóm tắt các phát hiện từ việc đánh giá đủ điều kiện của công cụ kiểm chứng. FAA cần được thông báo về SAS. Điều này cung cấp cho cơ quan chứng nhận sự xác nhận đối với các phát hiện dữ liệu kiểm chứng và đóng vai trò làm bằng chứng cho tình trạng đủ điều kiện của công cụ. Vui lòng nhấn vào đây để xem tài liệu SAS của chúng tôi
Tiêu chuẩn ARP4754 và Tiêu chuẩn DO178
ARP4754 là viết tắt của "Aerospace Recommended Practice ARP4754A Guidelines for Development of Civil Aircraft and Systems." Tiêu chuẩn ARP4754 cung cấp hướng dẫn cho toàn bộ hệ thống máy bay, trong khi Tiêu chuẩn DO178 chỉ được sử dụng cho phần mềm bay. Cả hai tiêu chuẩn đều được các cơ quan như FAA và EASA công nhận.
ARP4754 được phát triển và công bố bởi SAE (Society of Automotive Engineers) vào năm 1996. Năm 2010, SAE công bố ARP4754A, viết tắt của Guidelines for Development of Civil Aircraft and Systems. ARP4754A làm phong phú thêm khái niệm đảm bảo thiết kế được sử dụng ở cấp độ máy bay và hệ thống, đồng thời chuẩn hóa việc sử dụng thuật ngữ đảm bảo phát triển. ARP4754 đã được FAA phê duyệt vào tháng 11 năm 2011.
ARP4754 bao trùm toàn bộ chu trình phát triển máy bay, từ việc xác định yêu cầu cho đến khi kết thúc các quy trình tích hợp và kiểm chứng. ARP4754 cung cấp mức độ trừu tượng hóa cho máy bay, hệ thống và các thành phần. Đối với thiết kế thành phần, ARP4754 tham chiếu rõ ràng đến DO-178 và DO-254. ARP4754 tập trung vào đánh giá an toàn thông qua các quy trình khác nhau như phát triển, thiết kế và kiểm chứng. Tuy nhiên, cần lưu ý rằng ARP4754 không bao gồm phạm vi cụ thể của việc phát triển phần mềm hoặc phần cứng điện tử, các hoạt động an toàn trong quá trình khai thác, và quy trình phát triển kết cấu máy bay.
Các Giai đoạn Thiết kế
Đánh giá Thiết kế Sơ bộ (Preliminary Design Review – PDR)
Thiết kế sơ bộ là một giai đoạn quan trọng của quy trình phát triển phần mềm. Trong giai đoạn thiết kế sơ bộ, các yêu cầu cấp cao và các trường hợp sử dụng (use case) được xác định để hình thành kiến trúc hệ thống. Các tài liệu về giao diện, cơ sở dữ liệu và kiến trúc, cùng sơ đồ mối quan hệ giữa các thành phần có thể được sử dụng trong thiết kế. Thiết kế sơ bộ sẽ cung cấp một hình dung trực quan về hệ thống tại thời điểm bắt đầu dự án, dựa trên các thông tin đầu vào này. Thiết kế sơ bộ cũng đặt nền móng cho các giai đoạn thiết kế chi tiết hơn tiếp theo. Nó có thể được xem như một bản phác thảo.
Preliminary Design Review (PDR) kết thúc giai đoạn thiết kế sơ bộ của dự án. PDR phải cung cấp đủ mức độ đảm bảo để có thể tiến hành thiết kế chi tiết. Mục đích của PDR là đảm bảo rằng thiết kế sơ bộ và kiến trúc hệ thống cơ bản đã hoàn chỉnh, và có đủ độ tin cậy về mặt kỹ thuật rằng các yêu cầu có thể được đáp ứng trong giới hạn ngân sách và tiến độ.
Đánh giá Thiết kế Chi tiết (Critical Design Review – CDR)
Critical Design Review (CDR) kết thúc giai đoạn thiết kế chi tiết của dự án. Các thiết kế cuối cùng được trình bày thông qua CDR bằng các phân tích toàn diện, mô phỏng, sơ đồ, mã nguồn phần mềm và dữ liệu thử nghiệm. CDR đảm bảo rằng hệ thống có thể tiến hành thử nghiệm và sản xuất. CDR cũng xác nhận rằng các yêu cầu liên quan có thể được đáp ứng trong giới hạn ngân sách và tiến độ. Các bản vẽ và thông số kỹ thuật toàn diện thu được sẽ tạo thành một đường cơ sở cuối cùng cùng với đường cơ sở sản phẩm ban đầu. CDR phải có phạm vi rộng và chi tiết.
Giai đoạn Thiết kế Cuối cùng
Giai đoạn Thiết kế Cuối cùng cung cấp các bản vẽ kiến trúc và kỹ thuật chi tiết cho từng thành phần trong dự án. Đối với một số dự án, có thể cần lập báo cáo thiết kế cuối cùng. Các vấn đề thiết kế đã được xác định phải được giải quyết trước khi hoàn tất giai đoạn thiết kế cuối cùng. Các bản vẽ và báo cáo phải cung cấp đủ chi tiết để đưa ra các ước tính theo kế hoạch. Báo cáo thiết kế cuối cùng nên bao gồm tiến độ đã cập nhật, ước tính chi phí và thông số kỹ thuật. Cũng cần xác nhận rằng dự án khả thi về mặt kinh tế. Bất kỳ thay đổi nào được thực hiện trong Giai đoạn Thiết kế Cuối cùng đều tốn kém hơn so với các giai đoạn khác. Do đó, chúng phải được thực hiện hết sức cẩn trọng.
SOI (Các Giai đoạn Tham gia)
Để đánh giá sự tuân thủ DO-178B của các dự án, SOI được thực hiện bởi cơ quan hàng không của các quốc gia liên quan tại nhiều giai đoạn khác nhau của dự án, như lập kế hoạch, phát triển và kiểm chứng. Về lý tưởng, tổng cộng bốn lần đánh giá SOI được lên kế hoạch.
Đánh giá SOI đầu tiên bao trùm giai đoạn lập kế hoạch của công tác tuân thủ chứng nhận dự án. Đánh giá SOI thứ hai tập trung vào các giai đoạn phát triển của dự án. Bắt đầu từ việc phát triển các yêu cầu phần mềm cấp cao, đánh giá này xem xét liệu thiết kế, các yêu cầu phần mềm cấp thấp và mã nguồn đã được tạo ra tuân thủ DO178B hay chưa. Đánh giá SOI thứ ba tập trung vào các giai đoạn kiểm chứng. Không chỉ các hoạt động thử nghiệm, mà tất cả các hoạt động được thực hiện cho mục đích kiểm chứng đều được xem xét. SOI thứ tư là đánh giá kết thúc được tiến hành vào cuối dự án, xem xét liệu còn tồn đọng hoạt động nào hay không và liệu có phát sinh vấn đề mới nào kể từ các đánh giá trước đó hay không.
Kỳ vọng của DO-178B đối với các sản phẩm phần mềm được tạo ra trong giai đoạn lập kế hoạch là đạt được sự thống nhất về một bộ quy tắc chung giữa cơ quan quản lý và công ty thực hiện, đồng thời tuân thủ bộ quy tắc này xuyên suốt dự án. Nói cách khác, khi soạn thảo các kế hoạch và tiêu chuẩn, công ty không chỉ xác định quy trình của riêng mình mà còn viết ra các quy tắc về cách cơ quan quản lý sẽ tự đánh giá xuyên suốt quá trình chứng nhận.
Tác giả: Can Önal ([email protected])
