공식적인 방법의 광범위한 채택을 방해하는 장벽은 무엇입니까? [닫은]

공식적인 메소드를 사용하여 애플리케이션의 코드를 지정, 증명 및 생성 할 수 있습니다. 이것은 오류 발생이 적기 때문에 대부분 안전 / 핵심 프로그램에서 사용됩니다.

일상적인 프로그래밍이나 웹 애플리케이션 등에서 더 자주 사용하지 않는 이유는 무엇입니까?

참고 문헌 :

• 공식적인 방법
• B 방법
• 호 아레 로직

엔지니어는 모든 바보가 10으로 할 수있는 일을 달러로 할 수있는 사람입니다.

자원 제약, 예산 제약, 시간 제약, 모두 중요합니다.

공식적인 방법을 사용하여 소프트웨어를 개발하는 것은 일반적으로 비용이 훨씬 많이 들며 그렇지 않은 것보다 훨씬 오래 걸립니다. 또한 많은 프로젝트에서 가장 어려운 부분은 비즈니스 요구 사항을 이해하는 것입니다. 이 경우 공식적인 방법을 사용하면 코드가 비즈니스 요구 사항에 대한 불완전하고 부정확 한 이해에 100 % 부합한다는 증거입니다.

이러한 이유로, 공식적인 방법, 증명, 프로그램 검증 및 유사한 기술의 사용은 일반적으로 "중요한 것", 즉 항공 전자 공학 소프트웨어, 의료 기기 제어 시스템, 발전소 등으로 제한됩니다.

프로그래밍하거나 프로그래밍하지 않습니까?

소프트웨어 제품에 문제를 해결하기 위해, 요구 사항에 대한 이해를 가진 후, 당신은 할 수 있습니다 이든 프로그래밍 언어를 사용하여 프로그램을 작성 또는 공식 언어로 사용 코드 생성 도구를 사용하여 프로그램을 지정합니다. 후자는 단지 추상화 수준을 추가합니다.

올바른 일을하거나 올바른 일을 하는가?

공식적인 접근 방식은 소프트웨어가 사양에 따라 작동한다는 증거를 제공합니다. 따라서 귀하의 제품은 올바르게 작동합니다. 그러나 올바른 일을합니까?

작업중인 요구 사항이 불완전하거나 모호 할 수 있습니다. 그들은 심지어 버그가있을 수 있습니다. 최악의 경우 실제 요구 사항도 표현되지 않습니다. 그러나 그림은 천 단어의 가치가 있습니다. 예를 들어이 기사 에서 "고객이 원하는 것"에 대한 Google 이미지 만 있습니다 .

형식 비용

완벽한 세상에서는 처음부터 완전히 상세하고 완벽한 요구 사항을 갖게 될 것입니다. 그런 다음 소프트웨어를 완전히 지정할 수 있습니다. 공식적으로 갈 계획이라면 생산성이 향상되도록 코드가 자동으로 생성됩니다. 생산성 향상은 공식 도구의 비용을 상쇄합니다. 그리고 모든 사람들은 이제 공식적인 방법을 사용했습니다. 왜 그렇지 않습니까?

실제로, 이것은 거의 현실이 아닙니다! 이것이 많은 폭포 프로젝트가 실패한 이유와 반복 개발 방법 (애자일, RAD 등)이 주도한 이유입니다 . 불완전하고 불완전한 요구 사항, 설계 및 구현을 처리하고 문제가 없을 때까지 개선 할 수 있습니다.

그리고 여기에 요점이 있습니다. 공식적인 방법을 사용하면 각 반복마다 완전히 일관된 공식 사양이 필요합니다. 공식적인 논리는 용서하지 않고 불완전한 생각을 좋아하지 않기 때문에 신중한 사고와 추가 작업이 필요합니다. 이 제약 조건 하에서 간단한 폐기 실험이 비싸집니다. 또한 역 추적으로 이어질 각 반복 (예 : 작동하지 않는 아이디어 또는 오해 된 요구 사항)도 마찬가지입니다.

실제로

법적 또는 계약상의 이유로 공식적인 방법을 사용할 의무가없는 경우, 계약 기반 프로그래밍 및 기타 모범 사례 (예 : 코드 검토, TDD 등) 를 사용하여 공식 시스템 없이도 매우 높은 품질을 얻을 수 있습니다 . 소프트웨어가 작동한다는 것을 증명할 수는 없지만 사용자는 소프트웨어 작업을 더 빨리 즐길 수 있습니다.

업데이트 : 측정 된 노력

ACM 커뮤니케이션 2018 년 10 월호 에는 실제 노력에 대한 공식적인 검증 된 소프트웨어에 대한 흥미로운 기사가 있습니다.

흥미롭게도 (군용 장비의 OS 개발을 기반으로) 공식적으로 입증 된 소프트웨어를 제작하려면 기존 엔지니어링 기술보다 3.3 배 더 많은 노력 이 필요합니다 . 정말 비용이 많이 듭니다.

반면, 이러한 소프트웨어를 높은 보안 수준 (EAL 7)으로 인증하려는 노력을 추가 할 경우 기존의 소프트웨어보다 높은 보안 소프트웨어를 얻는 데 2.3 배 적은 노력 이 필요합니다 . 따라서 높은 안정성 또는 보안 요구 사항이있는 경우 공식적인 비즈니스 사례가 있습니다.

seL4 설계 및 코드 개발에는 2 년이 걸렸습니다. 수년에 걸쳐 모든 혈청 특이 적 증거를 합하면 8,700 줄의 C 코드에 대해 총 18 명의 사람이옵니다. 이에 비해, L4 제품군의 또 다른 마이크로 커널 인 L4Ka :: Pistachio는 seL4와 비슷한 크기로 6 년의 개발 기간이 소요되었으며 상당한 수준의 보증을 제공하지 않았습니다. 이는 검증 된 소프트웨어와 전통적으로 엔지니어링 된 소프트웨어 사이에 3.3 요소 만 있다는 것을 의미 합니다. Colbert와 Boehm의 평가 방법에 따르면, 8,700 줄의 C 코드에 대한 기존의 Common Criteria EAL7 인증은 45.9 명 이상의 사람이 필요합니다. 즉, 공식 이진 수준 구현 확인은 이미 2.3 이상의 요소입니다. 최고 수준의 Common Criteria보다 비용이 적게 들지만 훨씬 강력한 보증을 제공합니다.

모든 언어의 모든 프로그램은 공식적인 사양으로 간주 될 수 있습니다 (일부 터닝 머신과 동일). 공식적인 정확성을 입증하는 데 사용되는 더 높은 수준의 '공식 사양'도 다른 프로그램입니다. 그러나 그것의 (보통) 나쁜, 불완전하고, 모호하고, 불충분하게 프로그램을 통한 생각. 그리고 우연히도, 일반적으로 프로그래밍 방법을 모르는 사람들 (일반적으로 도메인 전문가)이 작성했습니다.

따라서 하나의 프로그램이 더 높은 수준의 공식 요구 사항과 호환 가능 (동일한 답변을 생성하거나 특성화 함)하는 것을 입증하면 변하지 않는 것은 상위 수준의 공식 사양에서 모호성을 해결하는 방법에 달려 있습니다. 그렇게 할 수있는 일반적인 목적은 없습니다.

높은 수준의 요구 사항을 낮은 수준의 세부 사항에 매핑하는 것은 실제 프로그래밍의 핵심입니다. 프로그래머가 사양을 읽고 해석함으로써 수행되는 핵심 작업을 손으로 흔드는 것으로 대체 할 수 없다는 것은 놀라운 일이 아닙니다. 이제이 고급 공식 사양이이 샘플 프로그램에 의해 준수되는지 확인하십시오.

이 개념이 처음에는 유망한 것처럼 보이는 논리 프로그래밍 초기에도 (높은 수준의 사양과 실제 기본 프로그램을 동일한 언어로 작성할 수 있기 때문에)이 핵심 문제는 다루기 어려웠습니다.