Bài học kinh nghiệm về quản lý yêu cầu: Chuyến bay 501 của Ariane 5

Thảm họa chuyến bay 501 của Ariane 5 cho thấy vì sao chúng ta luôn պետք suy nghĩ kỹ trước khi tái sử dụng nguyên trạng các yêu cầu, thiết kế kỹ thuật và bài kiểm thử từ những dự án trước. 

Trong quá trình phát triển sản phẩm phần cứng, việc tái sử dụng yêu cầu, đoạn mã phần mềm, ca kiểm thử hoặc quyết định thiết kế từ các dự án trước là điều rất phổ biến. Cách làm này có thể tiết kiệm thời gian, nhưng chỉ khi các điều kiện từng khiến những lựa chọn đó là phù hợp vẫn còn áp dụng.

Ariane 5 Flight 501 là chuyến bay đầu tiên của tên lửa Ariane 5 của châu Âu vào ngày 4 tháng 6 năm 1996. Tên lửa này đã tái sử dụng một phần phần mềm tham chiếu quán tính từ Ariane 4, một tên lửa châu Âu đời trước mà phần mềm đó đã hoạt động thành công. Nhưng Ariane 5 có quỹ đạo bay khác, một giá trị đã vượt quá phạm vi mà phần mềm dự kiến, và tên lửa bị phá hủy chưa đầy một phút sau khi phóng.

Bài học rất đơn giản nhưng dễ bị quên mất: trước khi tái sử dụng công việc từ các dự án trước, hãy kiểm tra xem các giả định và điều kiện vận hành cũ còn đúng trong dự án mới hay không.

Những điểm chính cần ghi nhớ

• Việc tái sử dụng các yêu cầu, phần mềm, bài kiểm thử hoặc quyết định thiết kế đã được chứng minh giúp tiết kiệm thời gian, nhưng bối cảnh cũ cần được xem xét lại.
• Hãy rà soát các ca kiểm thử được tái sử dụng trước khi dùng chúng để chứng minh cùng một yêu cầu trong một sản phẩm khác.
• Giảm rủi ro bằng cách giữ cho yêu cầu, quy trình kiểm thử, bằng chứng và trạng thái được liên kết với nhau.

Điều gì đã xảy ra trong vụ phóng Ariane 5

Ngày 4 tháng 6 năm 1996, Ariane 5 thực hiện chuyến bay đầu tiên từ Kourou, Guiana thuộc Pháp, mang theo bốn vệ tinh nghiên cứu Cluster cho Cơ quan Vũ trụ châu Âu. Nhiệm vụ kéo dài chưa đầy một phút. Khoảng ba mươi bảy giây sau khi cất cánh, tên lửa lệch khỏi quỹ đạo dự kiến và bị phá hủy.

Vấn đề bắt nguồn từ hệ thống tham chiếu quán tính, hệ thống này gửi dữ liệu tư thế và vận tốc đến máy tính trên khoang của tên lửa. Ariane 5 đã tái sử dụng phần mềm từ Ariane 4, bao gồm một quy trình căn chỉnh vẫn tiếp tục hoạt động trong khoảng 40 giây sau khi phóng. Quy trình đó đã hoạt động tốt trên Ariane 4, nhưng Ariane 5 có quỹ đạo bay khác.

Do sự khác biệt về quỹ đạo này, một số việc đã xảy ra liên tiếp trong thời gian rất ngắn:

• Một giá trị vận tốc theo phương ngang trở nên lớn hơn mức phần mềm dự kiến.
• Phần mềm cố chuyển đổi giá trị đó từ số dấu phẩy động 64 bit sang số nguyên có dấu 16 bit, nhưng giá trị này không còn nằm vừa trong phạm vi đó nữa.
• Phép chuyển đổi bị tràn, và hệ thống tham chiếu quán tính coi đây là lỗi rồi tự tắt.
• Hệ thống dự phòng chạy cùng phần mềm đó và cũng tắt vì cùng lý do.
• Không còn dữ liệu bay hợp lệ, máy tính trên khoang đã dùng dữ liệu chẩn đoán thay thế, đưa ra các lệnh bay sai và tên lửa bị phá hủy.

Đây là lý do khiến trường hợp này hữu ích cho quản lý yêu cầu. Phần mềm được tái sử dụng trước đó đã hoạt động, nhưng nó mang theo một giả định từ tên lửa trước: rằng giá trị này sẽ luôn nằm trong phạm vi an toàn. Ariane 5 đã thay đổi bối cảnh của giả định đó, vì vậy giả định này cần được làm rõ và kiểm tra lại trong hệ thống mới.

Minh họa này nhắc nhở rằng công việc kỹ thuật được tái sử dụng vẫn cần một bước kiểm tra đơn giản: các giả định đứng sau nó có còn đúng trong hệ thống mới không?

Các nhóm phần cứng có thể học gì từ trường hợp Ariane 5

Hầu hết các nhóm phần cứng không chế tạo tên lửa, nhưng họ luôn tái sử dụng những gì đã được chứng minh. Một khối PCB từ một sản phẩm trước đó có thể được sao chép sang một thiết kế mới. Một đoạn firmware có thể được chuyển sang một phiên bản phần cứng mới. Một quy trình kiểm thử có thể vẫn được giữ nguyên sau khi kiến trúc nguồn đã thay đổi. 

Đó là công việc kỹ thuật bình thường. Tái sử dụng giúp các nhóm tiến nhanh hơn. Bước quan trọng là bảo đảm rằng yêu cầu, giả định và phép kiểm chứng vẫn còn phù hợp với hệ thống mới.

Rà soát các yêu cầu được tái sử dụng

Một yêu cầu đã hiệu quả trong một sản phẩm không nên mặc nhiên được xem là còn đúng trong sản phẩm tiếp theo. Cùng một câu chữ có thể vẫn trông chính xác, nhưng các điều kiện vận hành xung quanh nó có thể đã thay đổi. Ví dụ, giới hạn dòng điện, dải nhiệt hoặc ràng buộc giao tiếp có thể an toàn trong một thiết kế nhưng cần được xem xét lại trong thiết kế khác. Trước khi tái sử dụng một yêu cầu, nhóm nên kiểm tra xem sản phẩm mới có còn hoạt động trong cùng các giả định đó hay không.

Liên kết các giả định với quy trình kiểm chứng

Một số giả định kỹ thuật quan trọng nhất lại không bao giờ được viết thành yêu cầu chính thức. Chúng nằm trong ghi chú thiết kế, kế hoạch kiểm thử cũ hoặc trong trí nhớ của ai đó. Điều này có thể trở nên rủi ro khi công việc được tái sử dụng. Nếu một giả định ảnh hưởng đến quyết định thiết kế, nhóm cần có cách để liên kết nó với một bước kiểm chứng. Nếu không, rất dễ tái sử dụng quyết định đó mà không nhìn thấy lý do từng khiến nó an toàn ngay từ đầu.

Rà soát bài kiểm thử khi yêu cầu thay đổi

Một ca kiểm thử đã đạt ở dự án trước không phải lúc nào cũng chứng minh được điều tương tự trong dự án tiếp theo. Nếu yêu cầu thay đổi, hoặc nếu hệ thống xung quanh yêu cầu thay đổi, thì quy trình kiểm thử liên quan cũng có thể cần thay đổi. Điều này đặc biệt quan trọng khi các nhóm tái sử dụng ca kiểm thử, tiêu chí chấp nhận hoặc bằng chứng tuân thủ.

Quy trình làm việc yêu cầu được kết nối giúp ích như thế nào

Một quy trình làm việc về yêu cầu tốt hơn sẽ không coi yêu cầu như một dòng văn bản đứng riêng lẻ. Nó giữ yêu cầu được liên kết với lý do đằng sau nó, công việc thiết kế mà nó ảnh hưởng đến và công việc kiểm chứng cho thấy liệu nó còn hợp lệ hay không. 

Đó là điều quan trọng nhất khi có điều gì đó thay đổi. Một yêu cầu được tái sử dụng có thể vẫn trông đúng, nhưng giả định đằng sau nó có thể აღარ phù hợp với sản phẩm mới. Một bài kiểm thử có thể vẫn còn đó, nhưng có thể không còn kiểm tra đúng điều kiện cần kiểm tra nữa.

Trong một quy trình làm việc được kết nối, các nhóm có thể giữ những thành phần quan trọng ở gần nhau: yêu cầu, bối cảnh đằng sau nó, phương pháp kiểm chứng, quy trình, kết quả, bằng chứng và trạng thái hiện tại. Thay vì phải lục tìm trong các tài liệu cũ hoặc báo cáo kiểm thử, kỹ sư có thể thấy điều gì đang được liên kết và điều gì có thể cần được rà soát lại.

Altium Requirements Portal hỗ trợ kiểu quy trình làm việc này bằng cách giữ yêu cầu, khả năng truy vết, quyền sở hữu và công việc kiểm chứng trong một môi trường dùng chung. Điều này giúp các nhóm tái sử dụng những gì đã được chứng minh một cách tự tin hơn vì yêu cầu và các bước kiểm tra xung quanh nó luôn được liên kết.

Các giả định cũ trong dự án của bạn còn đúng không?

Mọi nhóm phần cứng đều tái sử dụng những gì đã được chứng minh. Đây không phải là một lối tắt cần tránh, mà là một cách thực tế để phát triển nhanh hơn và tiếp nối các quyết định kỹ thuật tốt. 

Câu hỏi hữu ích là điều gì đã thay đổi xung quanh phần công việc được tái sử dụng đó:

• Dải vận hành có thay đổi không? 
• Bài kiểm thử có cần được sửa đổi không? 
• Các giả định đằng sau quyết định ban đầu còn áp dụng không?

Khi các nhóm có thể trả lời những câu hỏi đó, việc tái sử dụng sẽ trở nên đáng tin cậy hơn. Yêu cầu không đứng một mình. Lý do đằng sau nó, bước kiểm chứng và bằng chứng vẫn đủ gần nhau để nhóm có thể rà soát khi bối cảnh sản phẩm thay đổi. 

Đó là bài học mà Ariane 5 đến nay vẫn mang lại cho các nhóm phần cứng: tái sử dụng đạt hiệu quả tốt nhất khi bối cảnh đằng sau nó vẫn được giữ liên kết.

Hãy làm cho các quyết định tái sử dụng dễ kiểm tra và đáng tin cậy hơn với một công cụ quản lý yêu cầu mà toàn bộ nhóm của bạn đều có thể truy cập.

Bắt đầu với Requirements Portal →

Câu hỏi thường gặp

Việc tái sử dụng công việc kỹ thuật có thể trở nên rủi ro không?

Việc tái sử dụng công việc kỹ thuật có thể trở nên rủi ro khi bối cảnh sản phẩm thay đổi nhưng các giả định ban đầu, giới hạn vận hành hoặc bước kiểm chứng không được rà soát lại. Công việc đó có thể vẫn trông đúng, nhưng các điều kiện từng khiến nó hợp lệ trong dự án trước có thể không còn áp dụng nữa.

Kỹ sư nên kiểm tra điều gì trước khi tái sử dụng một yêu cầu, bài kiểm thử hoặc quyết định thiết kế?

Các nhóm nên kiểm tra xem sản phẩm mới có sử dụng cùng điều kiện vận hành, giao diện, giới hạn và tiêu chí chấp nhận như dự án gốc hay không. Họ cũng nên xác nhận rằng phương pháp kiểm chứng liên quan vẫn chứng minh đúng điều cần chứng minh trong hệ thống mới.

Khả năng truy vết giúp ích như thế nào khi các yêu cầu được tái sử dụng?

Khả năng truy vết giúp các nhóm thấy được cách một yêu cầu kết nối với các quyết định thiết kế, giả định, quy trình kiểm thử, bằng chứng và trạng thái. Khi công việc được tái sử dụng chuyển sang một dự án mới, các liên kết đó giúp dễ dàng nhìn ra phần nào vẫn còn hợp lệ và phần nào có thể cần được rà soát.