Có phải lập trình Agile quá ... ad hoc cho các hệ thống an toàn quan trọng?

Question

Ví dụ, nó sẽ vô cùng nguy hiểm để làm điều đó cho phần mềm điện tử?

Lưu ý, tôi không hoàn toàn hiểu Agile.

Answer 1

tôi đã làm việc trên các hệ thống máy Traffic Control sử dụng một quá trình chủ yếu thác, và các dự án chắc chắn có thể được hưởng lợi từ các hoạt động nhanh nhẹn. Tôi không thích suy nghĩ về số lượng mã đó đã hoạt động "do nhầm lẫn", mà không có bất kỳ loại thử nghiệm hồi quy tự động cấp đơn vị nào. Và yêu cầu-up-front điều là một cái gì đó của một cá trích đỏ. Mặc dù các hệ thống hàng không vũ trụ có thể gần như bạn có thể yêu cầu đặt trước ở phía trước, nhưng vẫn là có các đối số về ý nghĩa của các yêu cầu không rõ ràng mà chỉ bật lên khi hệ thống được chấp nhận thử nghiệm. Hoặc bạn có các vấn đề về thông lượng mà không ai có thể coi là hiển thị trễ trong trò chơi vì tích hợp lớn. Thử nghiệm đầu tiên, các giải pháp tăng đột biến, tích hợp liên tục, lập trình theo cặp - Tôi nghĩ tất cả những điều này sẽ cải thiện các dự án tôi đã làm.

UPDATE: Chưa kể tần suất "tài liệu thiết kế" là một gói dối trá vào cuối của dự án, bởi vì thiết kế nhất thiết phát triển khi đối mặt với thực tế. Agile nhận ra thực tế thiết kế nổi lên, cũng giống như thực tế trong các dự án Thác nước như trong bất kỳ dự án nào khác, thay vì cố gắng giả vờ bạn có thể thiết kế ngay trước khi bắt đầu viết mã.

Answer 2

Tôi không có đủ kinh nghiệm trong lĩnh vực đó (ngoài người dùng hệ thống hàng không) để tạo thành ý kiến ​​thực sự độc lập của riêng tôi. Tuy nhiên, tất cả những điều mà tôi tiếp tục đọc về các hệ thống quan trọng có hồ sơ theo dõi tốt nhất khiến tôi tin rằng thác nước thực sự là cách tốt nhất. Có thể bởi vì mọi người sẵn sàng cho phép lãng phí thêm các yêu cầu đóng băng để thúc đẩy an toàn. Thương mại-off là một chút khác nhau trong trường hợp đó tôi đoán.

Answer 3

Bạn có thể sử dụng cách tiếp cận nhanh, nhưng lần đầu tiên sẽ phải bao gồm các khía cạnh an toàn và bảo mật của bạn, hoặc ít nhất là cung cấp cho chúng, để bạn không tự bắn mình vào chân và kết thúc viết lại toàn bộ . Nhưng tôi đồng ý với Brian, có lẽ bạn nên sử dụng cách tiếp cận Thác cho các dự án như vậy.

Answer 4

Determining the Applicability of Agile Practices to Mission and Life-Critical Systems

Agile Suitability Filters

Nói tóm lại, không có "Agile" lập trình. Có một tập hợp các thực hành. Một số cho vay tốt hơn so với những người khác, nhưng nói chung, bất kỳ dự án sẽ được hưởng lợi từ một số thực hành.

Những người có diện tích lớn nhất thường quan tâm là Lập mô hình và Kiến trúc. Có rất nhiều đội ngoài đó sử dụng thực hành nhanh - ví dụ, tôi biết các thành viên của Fun3d team với NASA - họ sử dụng các thực hành nhanh và đối phó với những thứ như hỗ trợ Space Shuttle.

Có một số nhóm dành cho loại công việc này - vì vậy có thể. Bạn chỉ cần phải nhận thức được những rủi ro của bạn - giống như bất kỳ phương pháp khác.

Answer 5

Nhanh nhẹn phải là quy trình xử lý kỷ luật. Dù quá trình của bạn, vấn đề an toàn trong trường hợp này nên được giải quyết lên phía trước. Tôi không thấy cách phân phối lặp lại, sử dụng hệ thống xây dựng liên tục, tính toán tỷ lệ ghi chương trình, có cuộc họp đứng lên, khiến khách hàng tham gia tích cực, vv sẽ tác động tiêu cực đến an toàn.

Answer 6

Tôi làm việc trong hàng không vũ trụ (vệ tinh đặc biệt), và chúng tôi sử dụng một cách tiếp cận lai bởi vì chúng tôi phải đối mặt với hai vấn đề khác nhau: yêu cầu thực tế và yêu cầu quy trình kinh doanh.

Chúng tôi sử dụng phương pháp thác nước-ish cho các yêu cầu tàu vũ trụ và các phần quan trọng vì thay đổi vệ tinh chậm và hiếm, và vặn vẹo lên đó là xấu.

Nhưng đối với các quy trình kinh doanh luôn thay đổi, chúng tôi sử dụng phương pháp nhanh nhẹn vì cách chúng bay tàu vũ trụ liên tục thay đổi do nhu cầu của khách hàng. Screwing up có nghĩa là trong trường hợp xấu nhất người dùng nhận được kết quả không tốt đẹp.

Answer 7

Tôi nghĩ điều đó phụ thuộc vào cách các yêu cầu bảo mật được tích hợp trong quy trình. Nếu chúng là một bộ thử nghiệm bổ sung, thì đó không phải là điều mâu thuẫn với lập trình nhanh. Tôi nghĩ rằng các phương thức nhanh có thể giúp bạn tạo ra phần mềm an toàn hơn, bởi vì các dự án nhanh có xu hướng có chất lượng cao hơn các dự án thác nước. Quan trọng là, đảm bảo chất lượng bổ sung mà bạn đã cài đặt cũng được sử dụng cho các phương thức nhanh.

Nhưng nếu yêu cầu bảo mật được áp dụng cho quá trình xây dựng, điều đó có thể mâu thuẫn với các phương thức nhanh.

Answer 8

Thực tế, có một biến thể của mô hình thác nước được gọi là mô hình V, được ưu tiên bởi IEC61508 chẳng hạn. Đó là loại thác nước, nhưng với các quy định cho việc lặp lại (s) của chu trình dự án cơ bản. Mục đích chính của việc tái lặp lại trong trường hợp này là xử lý các vấn đề được phát hiện trong các giai đoạn khác nhau trong quy trình. Ý tưởng cơ bản là sau đó xuống con đường bạn gặp phải một vấn đề, tiếp tục trở lại trong quá trình của bạn, bạn phải đi để chăm sóc và xem xét tác động của những thay đổi của bạn.

Vì vậy, nó không thực sự nhanh nhẹn, nhưng ... :-)

Answer 9

Có rất nhiều cân nhắc. Đầu tiên là mức độ an toàn của bạn là gì. Nếu câu trả lời của bạn là "A" hoặc "B" (và thực sự "A") thì tuyệt đối KHÔNG. Bạn sẽ không nhận được ngay với việc làm Agile trong bất cứ hình dạng hoặc hình thức nào. Có các tiêu chuẩn mã hóa rất nghiêm ngặt, tiêu chuẩn tài liệu và các tiêu chuẩn quy trình được yêu cầu từ phần mềm Cấp A (nền tảng của tôi khoảng 15 năm). Điều này bao gồm:

• Truy xuất đầy đủ/lên đầy đủ.
• Phạm vi phủ sóng toàn bộ chi nhánh.
• Phạm vi phủ sóng đa điều kiện đầy đủ.
• tài liệu cơ bản được nêu ra bởi DO-178B bao gồm: SRD, SDD, SCI, SCMP, SDP, TQP, SCI ...

Vì vậy, không chỉ làm bạn phải xác nhận mã, thiết kế và yêu cầu của bạn nhưng bạn cũng phải xác nhận bộ công cụ, trình biên dịch, thiết bị kiểm tra tự động và vv.

Tóm lại, nó thực sự không phải là một kỳ công nhỏ và nó sẽ không được thực hiện với một nhóm nhỏ. Tương tự như vậy, các giao diện thực sự vững chắc và rất cụ thể cũng như tĩnh. Thay đổi giao diện thường đòi hỏi sự phối hợp với hơn 3 công ty (sản xuất khung máy bay, Vender 1 nói chuyện với Vender 2).

Trong tất cả sự trung thực, thay đổi mã 12 dòng có thể có giá lên tới $ 170.000. Tất nhiên, thay đổi mã 500 dòng sẽ là 190.000 đô la. Trong ngắn hạn, có một quá trình lớn trên không kết hợp với mã Cấp A (ít hơn nhiều so với Cấp B, thậm chí ít hơn với C và rất ít với Cấp D) làm cho các lần lặp nhỏ rất tốn kém; I E. nó tốn rất nhiều tiền để có được 777 nhiên liệu và bay 777 để kiểm tra một sự thay đổi nhỏ. Ngay cả các phòng thí nghiệm kiểm tra hệ thống của máy bay thương mại lớn cũng sẽ có tỷ lệ cháy là 10.000 USD/ngày.

Ví dụ: Cấp A: HUD, Máy đảo chiều đẩy, Hệ thống nguồn, FADEC (Điều khiển động cơ) Cấp B: Hệ thống chuyển mạch phụ, Hệ thống thông tin thanh âm. Cấp C: Trong các liên kết dữ liệu chuyến bay. Cấp D: Trong hệ thống giải trí trên chuyến bay.

Cấp D và, có thể Cấp C, có thể là ứng cử viên cho Agile.

Answer 10

Trên hội nghị EuroStar 2009 Gittie Ottosen đã nói về cách họ làm nhanh nhẹn tại công ty của họ. Điều ấn tượng là công ty này Systematic đang tạo ra phần mềm cho hàng thủ công, quân sự, vv. Họ làm điều đó phù hợp với CMMI 5, ISO 9001 và AQAP 150 & 2110. Vì vậy, tôi đoán nhanh có thể áp dụng cho các hệ thống có quy định cao. Có thể cố gắng tìm kiếm bản trình bày đó và cố gắng tìm thêm thông tin từ anh ấy.