내 질문에 대한 일반적인 추세를 Building an Aircraft using Agile에 대해 살펴보면 비용 이외의 가장 큰 문제는 안전합니다.애자 일을 사용하여 생명이 중요한 시스템 구축
민첩성을 사용하여 안전한 시스템을 구축하거나 (안전하다고 증명할 수 없다고 생각하는 사람들이 있습니까? 모든 반복 테스트가이를 완화하지는 않습니까? 민첩성을 사용하여 개발 된 소프트웨어는 폭포와 같은 상대방만큼 신뢰할 수 없을 것입니까?
이 문제를 설명하는 여러 가지 중요한 소프트웨어 오류가 있습니다. 특히, Ariane 5 Flight 501 및 Therac-25은이 문제를 심각한 문제로 만드는 소프트웨어 오류의 예입니다. Ariane 5 로켓은 유도 소프트웨어의 정수 오버 플로우로 인해 발사 후 37 초 이내에 비행 경로에서 벗어났습니다. 사고로 인해 장비 분실로 3 억 7000 만 달러가 들었지만 생명이 손실되지는 않았습니다. 치명적인 선량으로 여러 사람을 죽인 의료 기계 Therac-25도 마찬가지입니다.
더 나은 소프트웨어 방법론으로 이러한 문제가 방지 될 수 있습니까? 난 그렇게까지 확신은 못해. Ariane 5의 실패에 기여한 경영 의사 결정은 소프트웨어가 구축되는 방식과 관련이 거의 없었으며 Therac-25 조사는 시스템이 실패 할 수 없다는 믿음으로 인해 방해 받았습니다.
더 나은 테스트 방법이 도움이되었을 수 있습니다. 정적으로 형식화 된 좋은 컴파일러가 정수 오버플로를 찾지 못했을 것이라고 생각하기는 어렵습니다. 새로운 테스팅 방법 (예 : Pex)은 정리 해설기가 내장되어있어 코너 케이스를 검색 할 수 있으며 Therac-25에 있던 센서 이상을 식별 할 수있었습니다.
하지만 최고 수준의 관리에서 제품을 상자에 담아 배송하는 사람들에 이르기까지 안전에 대한 철저한 약속이없는 한 신뢰할 수있는 기술은 없습니다.
대부분의 안전에 중요한 또는 중요한 시스템은 폭포수 모델 및 공식 코드 리뷰와 같은 표준 개발 구조의 이점을 얻을 수 있습니다. 이러한 방법은보다 구조화 된 코드 기반을 유지하는 데 도움이됩니다. Code Complete 2 ed.
애자일의 리팩터링과 결합 된 우수 사례가 코드 구조를 잘 유지하지 못한다고 생각합니까? –
애자일 프로세스는 애자일 애플리케이션, 즉 업무용 애플리케이션을위한 것입니다. 중요 시스템은 잠재적으로 폭포와 같은보다 견고한 프로세스의 이점을 누릴 수 있습니다. OTOH, 폭포 모델로 작성된 비즈니스 응용 프로그램 제품군은 자체 무게로 인해 붕괴되는 경향이 있습니다. –
애자일은 동적 개발 모델입니다. 응용 프로그램의 요구 사항이 신속하고 예기치 않게 변경 될 때 사용합니다. 또한 개발자 수를 여전히 계산할 수있는 경우. 모던/인/고/차가움 때문에 사용하지 마십시오.
물론 단위 테스트에서 오류를 발견 할 수는 있지만 그 결석을 결코 증명할 수는 없습니다. 개발 중 응용 프로그램의 요구 사항 변경/추가에는 숨겨진 오류를 추가하는 것이 포함됩니다.
안전이 중요한 응용 프로그램의 일반적인 계획된 응용 프로그램의 경우 폭포 또는 v 모델과 같은 정적 개발 모델을 사용하려고합니다.
애자일은 프로젝트를 관리하는 방법이지 완성 된 프로젝트의 안전을 테스트하거나 확인하는 방법이 아닙니다.
안전에 중대한 시스템은 실제로 작업이 실제로 완료되었음을 확신하기 위해 (기능적으로) 완료된 후에도 광범위한 테스트가 필요합니다. 이러한 종류의 작업은 특별히 테스트에 중점을 둔 테스터 팀에 맡겨질 것으로 기대됩니다.
애자 일은 전통적인 제품 수명주기가 비즈니스 목표를 변경하는 데 충분한 시간이 필요한 부드러운 요구 사항에 잘 맞지만 안전이 중요한 환경에서는 빠르게 변화하는 요구 사항이나 특정 요구 사항이 매우 낮을 것이라고 생각합니다. 나쁜 것.
폭포를 사용하는 것이 코드에 어떤 내재적 인 순서 또는 안정성을 부여한다는 생각을하지 않습니다. 개별 스프린트가 잘 관리되고 코드가 테스트 및 검토되면 짧은 주기로 동일한 코드가 생성됩니다. 품질, 그냥 청크.
스크럼을 사용하면 문제가 발생하는 프로젝트 타임 라인에서 일찍부터 헤드 업을 할 수 있습니다. 아무 것도하지는 않지만 실적이 저조한 관리자/개발자/누구든 숨어있는 장소를 제거 할 수 있습니다.
즉, 애자일 방법을 사용하여 모든 종류의 시스템을 구축 할 수 있습니다. 사용자가 구축 한 시스템을 테스트하지 않을 경우에만 가능합니다. 테스터들을위한 것.
모두가 여기에서 빠져 나가고있는 것처럼 보이는 안전에 중대한 시스템에 대한 전체적인 관점은 삶의 손실을 (때로는 대규모로) 잃을 가능성이 있기 때문에 올바른 것으로 입증되어야한다는 것입니다. 시스템의 요구 사항이 정확하게 지정되어 있고 (종종 Z 및 VDM과 같은 공식적인 방법을 사용하는) 라이센스 권한이 없거나 설계가 그러한 요구 사항을 반영한 경우 (그리고 그러한 것으로 입증 될 수있는 경우가 아니면) 운영 인증서가 필요하기도합니다.) 그리고 코드는 디자인에 대한 정확한 반영이라고 할 수 있습니다 (다시 그렇게 입증되었습니다).
종종 그러한 증거를 제공하기 위해 제품을 테스트하는 옵션은 존재하지 않습니다. (OK 사람들은 원자로, Boeing 777, Therac 25로 무엇이든간에 버그가 어디 있는지 확인해보십시오.) 안전에 중대한 시스템 (특히 S.I.L 3 이상으로 분류 된 시스템)은 철저하고 포괄적 인 문서를 필요로하는데 이는 내가 알 수있는 한 모든 측면에서 민첩한 선언문과 완전히 상충됩니다. 안전에 중대한 시스템을 사용하는 프로그래머는 라이센스 기관으로부터 소프트웨어의 새로운 재평가를 요청하지 않고도 relesed 소프트웨어를 변경할 수 없으며 첫 번째 버전의 정확성과 catestrophic 함의를 증명하는 엄격함을 감안할 때 망쳐 버려.
컴파일러가 정수 오버플로를 찾지 못했습니다. 여러 줄의 독립적 인 계산에 따르면 로켓이 오버플로 상태에 빠지게되는 것은 물리적으로나 구조적으로 불가능하다는 것을 증명했기 때문에 그 코드 행에 대한 오버플로 검사는 의도적으로 사용할 수 없었습니다. . 그렇다면 오버플로가 어떻게 발생 했습니까? 불가능할 경우 어떻게됩니까? 잠깐, 나는 아리안 4보다 작고 강력하지 않은 계산에 대해 언급하는 것을 잊었을 까? 그러한 계산을 한 엔지니어들도 그렇습니다. –
IOW는 아리안 4의 비행 제어 소프트웨어가 아리안 5 (원칙적으로 좋은 아이디어로 재사용 됨)가 안정적이고 검증 된 테스트 조각을 재사용한다는 것이 었습니다. 소프트웨어), 그러나 만든 모든 가정이 새로운 사양 하에서 여전히 유효한지 확인하는 것을 잊었습니다. –
그러나 아리안 5와 Therac-25는 애자일 프로젝트가 아니 었습니다. 나는 생각하지 않습니다. 그래서 이것이 어떻게 관련되어 있는지 혼란 스럽습니다. –