소프트웨어 산업의 규제

몇 년마다 누군가 소프트웨어 산업에 대한 엄격한 규제를 제안합니다.

이 IEEE 기사 는 최근에이 주제에 대해 주목을 받고 있습니다.

대중을 물리적 또는 재정적 위험에 노출시키는 시스템 용 프로그램을 작성하는 소프트웨어 엔지니어가 자신의 역량에 대해 테스트를 받는다는 것을 알고 있다면, 사고는 계속 될 것이며, 코드의 결함과 실패를 줄일 수 있으며, 거래의 일부 생명을 구할 수도 있습니다.

나는 이것의 가치와 장점에 대해 회의적이다. 내 생각에 그것은 그것을 제안한 사람들에 의한 토지 횡령처럼 보인다.

나를 위해 그것을 인용하는 인용문은 다음과 같습니다.

시험은 주제의 숙달이 아닌 기본 지식을 테스트합니다.

큰 실패 (예 : THERAC-25 )는 복잡하고 "기본 지식"으로는 결코 예방할 수없는 미묘한 문제인 것 같습니다.

현지 문제 (예 : 일부 관할 구역에서 타이틀 엔지니어의 기존 보호)를 무시합니다.

목표는 고귀합니다-cks / lat ^1을 피하고 소프트웨어를 구입하는 사람들에게 그 구별을 더 분명하게하십시오. 소프트웨어 산업의 엄격한 규제가 원래 목표를 달성 할 수 있습니까?

¹ 의료직의 규제가 의도 한대로.

소프트웨어 엔지니어가 의료 전문가 나 회계사와 같은 분류로 비둘기를 can 수 있다는 견해는 그들이 해결하려는 "문제"에 대한 무지한 견해입니다. 이에 대한 의견을 제시하기 전에이 법안을 제안하는 규제 기관의 부의장 인 손튼 씨의 주장에 대해 살펴 보겠습니다.

Thornton은“의사, 회계사 및 간호사와 같은 실무 전문가는 라이센스를 취득한 것처럼 소프트웨어 엔지니어도 라이센스를 취득해야합니다. " 소프트웨어를 작성할 계약자 를 선택할 때 대중은 일종의 자격 증명에 의존 할 수 있어야 합니다."

-Mitch Thornton, IEEE 라이센스 및 등록 부사장

이것은 표면에서 매우 합리적으로 들립니다. 결국, "성공적으로 규제 된"것으로 간주 될 수있는 다른 산업들이 있습니다. 성공적으로 규제되었다는 것은 옐로우 페이지에서 의사를 찾아 보면 공인 대학에서 철저한 교육을 받았으며 여러 시험을 통과하여 거주지를 완료 한 것을 합리적으로 확신 할 수 있음을 의미합니다. 다음은 일부 "성공적으로 규제 된"산업 (전문 인력 측면)입니다.

• 변호사
• 의사들
• 회계사
• 원자력 엔지니어
• 이발소 ( 농담하지 않음 )

결국, 췌장에서 종양을 제거하거나 도시 외곽의 원자력 발전소 원심 분리기에서 작업하는 사람은 원하지 않습니다. 소프트웨어 엔지니어에게 유사한 제한이없는 이유는 무엇입니까?

“공공 건강 또는 안전, 보안, 재산 또는 경제에 위험을 초래할 수있는 프로그램을 가진 사람들 만 테스트해야합니다.”

이것은 모호한 진술이며 자유주의적인 해석과 적용에 열려 있습니다. Apple Inc. 또는 Facebook이 미국 경제에 없어서는 안될 부분이라고 주장 할 수 있습니다. 무능력으로 사이트를 중단하면 미국에 피해를 입힐 수 있으므로 정부에서 특별 코드를 작성해야합니다. 경제? 마지막 직장에서 실수로 크론 작업이 잘못되어 곡물 공급을 중단하여 식품 공급을 위험에 빠뜨릴 수 있습니다.

이 제안의 실제 의도를 피하고 있음을 알고 있습니다. 새로운 Jetta에서 잠금 방지 제동 시스템 용 코드를 작성하는 사람이 잠금 방지 제동 시스템 용 코드를 작성할 수있는 유능하고 적절한 라이센스를 갖도록하는 것이 기본 개념입니다. 당신의 제타에서.

문제는 다음과 같습니다. 오늘날과 시대의 소프트웨어 엔지니어링은 모든 것을 포함하며 모든 분야를 테스트 할 수는 없습니다. 비즈니스 규칙이 너무 구체적이며, 규칙에 따라 너무 다양합니다. Jetta에서 ABS 시스템 용 코드를 작성하는 가상의 엔지니어는 Elantra에서 ABS 시스템 용으로 완전히 다른 것을 작성할 수 있습니다. 그는 재 인증을 받아야합니까?

이러한 파생 분야를 모두 테스트하면 어떻게됩니까? 전자 상거래 웹 사이트에서 작업하는 모든 프로그래머가 전자 상거래 가능 프로그래머로 인증 받았다고 가정하십시오. 그래서? 이것이 갑자기 프로그래머와 회사가 실제로 필요한 검증을 수행 하고 PCI 준수를 구축 한다는 의미 입니까? 그들이하더라도-결함은 여전히 ​​발생합니다.

IEEE Licensure and Registration Committee의 부사장 인 Mitch Thornton에 따르면이 시험은 주제에 대한 지식이 아닌 기본 지식을 테스트 할 것이라고한다.

키커입니다. 기본 지식의 부족은 결코 문제가되지 않습니다. 척이 제어 구조 개념으로 어려움을 겪고 있었기 때문에 잠금 방지 브레이크가 작동을 멈추지 않았습니다. 테일 라이트의 전기 단락으로 인해 ABS가 꺼졌고 전원이 올바르게 다시 라우팅되지 않았기 때문에 고장이 발생했습니다. 또는 뭔가.

필자가 작성한 인슐린 펌프 소프트웨어는 기본 기술이 부족하여 작동을 멈추지 않았습니다. 유럽 ​​팀원이 미터법을 사용했을 때 인슐린 분배를 측정하는 방법에 버그가 있었기 때문에 중단되었습니다.

이는 개발 과정에서 설명 할 수 있지만 인증으로 테스트 할 수는 없습니다 .

이 "인증"이 적용되면 어떻게됩니까? 인시던트 수는 정확히 동일하게 유지됩니다. 왜? ABS 또는 인슐린 펌프 고장 의 실제 문제 를 제거하기 위해 아무것도하지 않기 때문 입니다.

의료 규제로 인해 아무도 죽지 않고, 금융 규제로 인해 사기로 상처받지 않으며, 주택 규제로 인해 집을 압류하지 않으며, 이발사 규제로 인해 머리가 잘리지 않으며 비행기가 추락하지 않는 사람 항공기 규제 덕분입니다.

분명히, 규제의 존재가 결함이나 실패가 없음을 의미하지는 않습니다. 반대로, 결함이나 결함이 존재한다고해서 규제가 그러한 결함이나 결함을 방지한다는 것을 의미하지는 않습니다. 소프트웨어 엔지니어는 이미 각 안전 필수 산업의 구성원으로 엄격하게 규제되고 있으며 해당 산업 외부에서는 거의 필요하지 않습니다.

역사는 훌륭한 장인과 평범한 사람의 차이는 어떤 형태의 객관적인 수단으로도 테스트 할 수 없다는 것을 적절하게 믿습니다. 기본 지식은 기본 지식을 적용하는 방법에 대한 훌륭한 프로그래머, 지혜 및 경험을 제공하지 않습니다.

또한 이러한 테스트는 일반적으로 몇 가지 유행어와 구체적인 절차로 끝나고 시작하기에 실질적인 것을 측정하지 못합니다.

소프트웨어 산업이 길드를 개발하고자한다면이 문제에 접근하는 것이 훨씬 더 좋은 방법 일 것입니다. 그러나 중앙 집중화는 탁월성을 파괴 할 수있는 힘만 가지고 있습니다.

또한이 방법으로 방지하려는 문제는 테스트에 의해 포착되지 않을 수 있습니다. 어쨌든, 나는 또한 @ThomasOwens가 이것에 대답하는 것을보고 싶습니다.

최소한 미국 이데올로기에서 정부의 역할은 소프트웨어 회사가 결함이 있거나 안전하지 않은 소프트웨어로 인한 재산 피해에 대해 책임을 지도록하는 것입니다. 이를 통해 회사는 자체 표준을 시행하고 문제에 대한 개인적인 책임을 져야합니다. 이것은 항상 더 나은 솔루션이며, 중앙 정부가 한계를 넘어서는 것은 아닙니다.

최신 정보

나는 지난 밤에 맥주 또는 10 이상에 대해 생각하고있었습니다.

의료 분야를 규제하는 것은 패러다임을 없애는 것이 었습니다. 그들의 목표가 동종 요법 및 자연 요법 의사를 퇴치하는 것이었을 때, 동종 요법 의사가 친절하게 "척수"라고 불렀다면, 그러한 규제는 성공적이었다. 그러나, 나는 그러한 일이 입법을 쓰는 사람들을 제외한 모든 사람에게 이익이된다는 것에 동의하지 않습니다. 이것이 무엇을했는지 생각해보십시오. 의료 비용을 지속 불가능한 수준으로 높이고 MD의 책임 수준을 크게 높였으며 시장에서 소비자의 선택 권한과 자체 결정력을 모두 제거했습니다. 의료계에는 더 이상 아이디어를 얻을 수있는 시장이 없으며, 의학에 대한 새로운 치료법과 사고 방식이 억제되었습니다. 또한, 현장 진입 장벽이 매우 높아 결과적으로 우수한 MD가 부족합니다. 에스. 또한 규제 기관은 의사의 공급을 통제 할 수있는 권한을 가지므로 의사가 지불하는 가격을 통제 할 수 있습니다.

우리가 의료 규제로부터 얻은 몇 가지 이득이 있지만 비용은 전적으로 너무 높습니다.

이러한 규정이 통과되면 소프트웨어 엔지니어에게도 동일한 일이 발생합니다. 이제는 규제 기관이 객체 지향 프로그래밍이 유일한 설계 표준이며 기능 및 절차 적 프로그래머는 실습 할 수 없다고 판단 할 것입니다. 그런 다음 안전하지 않기 때문에 자신의 메모리를 관리 할 수 ​​없다고 알려주기 시작합니다. 그런 다음 JAVA와 C #을 모두 사용하여 Oracle과 Microsoft가 더 뚱뚱하고 행복해 지도록 사용해야합니다. 혁신은 질식되고 창의성은 금지 될 것입니다. Microsoft와 Google은 법률을 작성하므로 시장 규칙은 자체 수익성과 사회 복지에 구애받습니다.

또한 컴퓨터가 취미와 학문적 노력으로 시작되었다는 것을 모두에게 상기시켜 드리겠습니다. 80 년대와 90 년대 초의 유닉스 전쟁 이외에도 우리는 무료 운영 체제, 무료 컴파일러, 무료 프로그램 등을 가졌습니다 ... 이것은 빨리 끝날 것입니다. Richard Stallman, Linus Torvalds 및 Dennis Richtie가 우리에게 물려받은 세상은 점차 사라질 것입니다.

요약하자면, "시간당 25 달러에 워드 프레스 CMS 사이트를 설계 할 것입니다"또는 "500 달러에 모든 아이폰 앱"과 경쟁하는 데 지쳐 있습니까? 왜 그렇지 않습니까? 나는 내가하는 일과 내가 원하는 고객에게 능숙하기 때문에 기꺼이 돈을 지불하려고합니다. 독립적으로 또는 직장에서 프로젝트를 수행 할 때 본인의 머리와 명성에 f * & ^ 업의 위험이 있습니다. 내가가는 곳마다 저를 따라갈 것입니다. 또한 대부분의 사람들은 그들이 지불하는 것을 얻는다는 것을 알고 있습니다. 자신의 잔디밭 사람에게 지불하는 가격 만 나에게 기꺼이 지불하려는 고객은 어쨌든 다루는 악몽이 될 것입니다. 정부가 서비스 제공 업체가 손해를 보상하도록 법적 구조를 고쳤다면 여전히 현장에 고용되어있는 나쁜 프로그래머는 거의 없을 것입니다.

그건 그렇고, 우리는 여전히 나쁜 의사가 있지만 유일한 차이점은 시장에서 의사를 제거 할 힘이 거의 없다는 것입니다. 그들이 자신의 행동에 책임을 져야한다면, 고객에게 무능한 혼란을 일으킬 또 다른 기회를 갖기 전에는 사업을 중단했을 것입니다.

실리콘 밸리 뉴스-2015 년 6 월 31 일

공포 : 인증되지 않은 프로그래머가 프로그램 중단

"난 절대 다시는 달릴 수 없어"피해자를 출력합니다. 경찰이 수사 중입니다

범죄자 : Dr. H. Acker Jr.의 라이센스가 포인터를 잘못 사용하여 취소되고 시스템 파일에서 읽으려고 시도 함

대변인은 대법원에 항소 할 것이라고 말했습니다.

발표 : 1975 년에 인증 된 코볼 프로그래머는 2025 년까지 재 인증해야합니다.

IEEE 확인 인증은 이후 변경되지 않았습니다.

광고 : Magic Knowledge Stuffers, Inc로 인증 보장

21 일 만에 프로그래밍을 가르칩니다.

잘 정의 된 지식 체계, 윤리 강령, 교육 프로그램 인증, 인증 및 라이센스 부여, 전문 개발을 지원하는 전문 사회 및 직업. 소프트웨어 엔지니어링에는 직업의 특성이 대부분 있습니다.

저는 소프트웨어 기술 지식 (SWEBOK) 과 소프트웨어 공학 윤리 및 전문가 실무 규범 으로 시작하는 것으로 생각하고 싶습니다 . 이것들에 대한 일반적인 수용은 여전히 ​​상당히 제한적이지만 소프트웨어 엔지니어로 자신을 식별하는 사람이 지식을 가지고 있어야하는 유형과 전문적인 능력으로 어떻게 행동해야하는지 파악하기위한 좋은 기반이된다고 생각합니다. 그렇다고해서 이것이 엄격한 규칙이 아니라 전문 소프트웨어 엔지니어에게 요구되는 작업과 관련하여 일반적으로 무엇을하는지 안내하는 문서입니다. SWEBOK은 관련성을 유지하기 위해 수시로 개정됩니다.

다음 특징은 교육 프로그램의 인증입니다. 미국에서는 소프트웨어 엔지니어링 프로그램의 인증이 ABET에 의해 처리됩니다 . 또한 컴퓨터 과학, 정보 기술, 컴퓨터 공학 및 기타 컴퓨팅 관련 직업을 인정합니다. ABET 은 인증 된 프로그램 에 대한 요구 사항을 웹 사이트에 게시합니다. 소프트웨어 엔지니어링은 엔지니어링 프로그램으로 간주됩니다. 인증의 목적은 적어도 교실에서 가르치는 주제의 관점에서 다른 공학 프로그램 졸업생들 사이의 일관성을 보장하는 것입니다. 교육의 질에 대해서는 아무 것도 말하지 않습니다.

졸업 후에는 인증 및 라이센스를 사용하여 표준 지식 기관에 대해 교실 (및 경우에 따라 직장에서)에서 배운 지식을 평가합니다. 공인 된 학교에는 정의 된 학습 자료가 있지만,이 자료를 얼마나 잘 배우고 프로그램을 마칠 때 얼마나 많은 학생들이 배우는 지에 대한 척도는 없습니다. 인증 및 라이센스는이를 수행하는 방법을 제공합니다. 모든 사람이 동일한 시험을 치르고 해당 직종에 기반을 둔 다양한 지식 기관에 대한 지식을 보여줍니다. 소프트웨어 엔지니어링에서 IEEE는 SWEBOK에 기반을 둔 인증을 제공합니다- 공인 소프트웨어 개발 노인 및 최근 졸업생 및 Certified Software Development Professional의 어소시에이트업계 경험이있는 사람들을 위해. 이를 위해 가치를 높이려면 소프트웨어 엔지니어링이 무엇인지에 대한 올바른 정의로 ​​SWEBOK를 수용해야합니다.

마지막으로, 전문 사회는 직업에 대한 안내 문서를 유지 관리하고, 지식과 아이디어의 교환을위한 회의 및 출판을 촉진하고, 학계와 산업 사이의 다리 간격 등을 촉진합니다. 두 개의 주요 사회는 IEEE Computer Society 와 ACM 이지만 전세계에는 다른 사회가 있습니다. 이것들은 모든 것을 멋진 작은 묶음으로 묶고 올바른 사람들에게 정보를 전달하는 데 도움이됩니다.

여기에서 다른 질문이 있습니다. 소프트웨어 개발은 ​​엔지니어링 분야입니까? 인증 또는 라이센스는 소프트웨어 엔지니어에게 가치를 추가합니까? 인증이 유용한가요?

모든 소프트웨어 개발에는 엄격한 엔지니어링 원칙이 필요하다고 생각하지 않습니다. 소프트웨어 개발의 과학 및 공학에 대한 경험적이고 과학적인 연구가 모든 사람에게 도움이되는 것은 아닙니다. 그러나 최신 비디오 게임 개발, 심박 조율 기용 임베디드 소프트웨어 개발 또는 다음 우주선 제작에는 큰 차이가 있습니다. 그 중점은 모두 다릅니다. 세 개 중 두 개는 숙련 된 엔지니어의주의를 기울여야합니다. 다른 하나는 엔지니어링 사례를 통해 배울 수 있지만 프로젝트를 성공적으로 완료하기 위해이를 사용할 필요는 없습니다.

인증 및 라이센스에는 충분한 지식이 필요합니다. SWEBOK는 탄탄한 토대를 제공하는 훌륭한 문서이지만 널리 인정되지는 않습니다. 실무자들이 받아 들일 수있는 구체적인 프로그램을 기반으로 학업 프로그램 및 인증 / 라이센스 시험을 기초로하지 않는 한 실제로는 아무 의미가 없습니다. SWEBOK 또는 대체 문서가 (적어도 엄격한 엔지니어링이 필요한 분야에서) 널리 받아 들여지면 인증 또는 라이센스 시험을 사용하여 필요한 지식의 이해를 측정 할 수 있습니다.

그러나 인증에는 눈에 띄는 문제가 있습니다. 그것은 책에 대한 테스트입니다. 어떤 사람들은 읽기, 학습, 암기 및 시험에 능숙합니다. 그러나 이것이 훌륭한 엔지니어라는 의미는 아닙니다. 사람들은 항상 균열을 통해 미끄러 져 들어갑니다. 인증 또는 라이센스는 한 단계 일뿐입니다. 다른 숙련 된 엔지니어의 직업 훈련 및 멘토링은 훌륭한 실무자를 손질해야합니다. 또한 사람들이 중요한 환경에서 연습하지 못하게하는 능력은 사회와 기업에 대한 위험을 완화하는 데 도움이 될 수 있습니다.

이에 대해 상당히 심도있게 논의한 좋은 책은 Steve McConnell의 전문 소프트웨어 개발 : 짧은 일정, 고품질 제품,보다 성공적인 프로젝트 및 강화 된 경력 입니다.

정부 규정이 통과되면 미국의 소프트웨어 산업은 계약을 체결하는 데 소요되는 비용이 신생 기업 및 소기업이 감당할 수있는 비용보다 높기 때문에 크게 계약을 체결합니다.

법학 학위 또는 의학 박사와 관련된 희소성과 비용은 우리 산업에서 다소 눈에 띄게 될 것입니다. 대안이 모든 조가 잠재적으로 다음 페이스 북을 구축 할 수 있다는 점에서 좋지 않습니다.

사람들은 실수를 저지르기 때문에 많은 양의 규제로 재난이 발생하지 않습니다. 사람에게 알려진 소프트웨어 개발에 대한 가장 엄격한 요구 사항이있는 NASA를 고려하십시오. 그들은 여전히 ​​소프트웨어 버그가 있습니까? (예, 여러 번 예!)

시장은 이러한 문제를 규정보다 훨씬 잘 정리합니다. 문제를 일으키는 소프트웨어를 만드는 회사는 부상당한 사람들이 책임을집니다. 우리의 나머지 사람들은 그들의 실수에 대해 지불 할 필요가 없습니다.

1999 년 ACM 은 IEEE SWEBOK 작업을 크게 철회 할 때 라이센스에 관한 성명서 를 발표했습니다 . 공개적으로 사용 가능한 SWEBOK 문서와 ACM 진술을 검토 한 후 ACM의 의견을지지합니다.

이 기사를 살펴보면 4-6 년의 경험이있는 사람이 기본 지식을 테스트하는 시험을 치러야합니다. 그건 말도 안되는 일이며 문 밖에서 웃어야합니다.

장치의 소프트웨어 구성 요소는 구현 세부 사항입니다. 예를 들어, 제어 시스템 산업에서 모든 안전 장치는 하드 와이어였으며 사람들은 소프트웨어를 신뢰하지 않았습니다. 그러나 현재 안전 릴레이 및 안전 PLC와 같은 소프트웨어 기반 안전 장치를보고 있습니다. 안전 장치에 대한 산업 규정 (안전 범주에 따라 다름)을 준수해야하므로 허용됩니다. 따라서 경우에 따라 장치에는 중복 프로세서와 두 개의 서로 다른 팀이 작성한 중복 코드 등이 필요합니다.

일반인에게 판매 및 소비되는 경우 안전 지침을 충족해야하는 제품입니다. 제품에 소프트웨어가 포함되어 있기 때문에 이러한 규칙은 변경되지 않습니다. 제품이 모든 규제 기준을 충족하는지 확인하고 소프트웨어가 포함 된 경우 소프트웨어를 검토하고 해당 분야에서 경쟁력 을 갖추어야 합니다 . 그렇지 않은 경우 설계를 승인하고 결함이있는 것으로 판명되면 회사 (또는 회사)가 책임을집니다.

일부 제품은보다 엄격한 요구 사항을 충족해야하기 때문에 모든 프로그래머를 규제 할 필요는 없습니다. 이러한 제품에 소프트웨어가 포함 된 경우 소프트웨어 구성 요소가 요구 사항을 충족하는지 확실하게 결정할 수있는 잘 개발 된 엔지니어링 원칙이 필요합니다. IEEE의 의미는 다음과 같습니다. 상대적으로 젊은 소프트웨어 엔지니어링 분야는 다른 엔지니어링 분야의 신뢰성과 신뢰 수준으로 개발되어야합니다.

"프로그래밍"과는 아무런 관련이 없으며 "엔지니어링"과는 관련이 있습니다.

물론 이것은 개발자와 엔지니어의 차이점에 대한 논쟁적인 문제로 되돌아갑니다. 이들은 일반적으로 겹치는 두 가지 역할입니다. 개발자 부분은 소프트웨어를 만드는 것을 의미합니다. 역할의 엔지니어링 부분은 공공 안전을 책임지는 디자인에 도장을 찍는 경우를 의미합니다. 당신 은 다른없이 하나 가 될 수 있습니다 .

항공기 산업에서는 소프트웨어가 이미 엄격하게 규제되고 있습니다. DO-178B를 참조하십시오 .

업계의 다른 하위 집합에는 규범이 있다고 확신합니다.

"소프트웨어"는 요즘 많은 것을 포괄합니다. 의무적으로 모든 것을 포괄하는 규제를하는 것은 터무니없는 것이라고 생각합니다.

소프트웨어 산업의 규제는 Quality Assurance 프로세스의 규제를 통해 가장 잘 이루어집니다.

대규모 소프트웨어 회사에는 수많은 테스터, QA 관리자, 자동화 된 테스트 스위트, 코드 검토 프로세스, 테스트 프로세스 등이 있습니다. 다른 회사에서 소프트웨어 품질 감사를 수행하는 것이 전적으로 목적인 회사가 있습니다. 표준 조직에는 QA 및 QA 감사에 대한 지침이 있습니다.

회사 내부에서 소프트웨어 엔지니어는 업무의 품질을 책임집니다. 그러나 그들의 점검과 균형은 회사의 품질 과정에 있습니다.

"소프트웨어 관련 문제"를 해결하는 것과 같은 가장 현대적인 시도와 동일합니다. 입법을 시도하는 사람들은 문제의 근본 과정에 대한 지식이 거의 없습니다. 안전에 중요한 소프트웨어를 개발할 때 규정 된 프로세스 (및 물론 의도)를 따르는 경우 항공기, 의료 장비의 원자력 발전소의 경우 단일 버그만으로도 고장을 일으킬 수 없습니다. 어떤 알고리즘도 손상시키지 않고 전체 알고리즘을 잘못 구현할 수 있습니다.

FDA와 FTA는 모두 위험 분석을 필요로하며이를 완화 전략에 기초합니다. 후자는 일반적으로 완화에 결함이 있음을 인정하는 스위스 치즈 전략입니다. 따라서 동일한 위험에 대한 여러 완화가 적용됩니다 (하나의 완화는 여러 위험에 적용될 수 있음). 각 완화는 살펴볼 수있는 스위스 치즈의 조각과 같습니다 하나, 아마도 두 개의 슬라이스가 합쳐 지지만 충분한 슬라이스를 합치면 더 이상 불가능합니다. 완화가 완벽하게 구현 되어도 100 % 안전한 장비가되지는 않습니다. 위험 분석이 정확하지 않으면 아무도 (Y2K) 생각하지 않을 위험이 있습니다.

당신은 당신이 원하는 주제에 대해 테스트하고 극히 높은 수준을 요구하기를 원하는 모든 엔지니어를 테스트 할 수 있습니다. 가장 중요한 안전 오류는 통합 오류입니다. 그것들은 한 사람의 코드에서 오류가 아니지만 두 소프트웨어 시스템의 소프트웨어와 하드웨어 사이의 정렬 불량으로 인해 또는 알파 입자가 프로그램 카운터를 올바른 위치에서 떨어 뜨 렸기 때문에 발생합니다.

나는 경험이 풍부하고 유능한 개발자들과 함께 여러 분야에서 안전에 중요한 시스템을 사용했으며, 이들은 해당 분야에서 현명한 테스트를 통과했습니다. 안전에 치명적인 오류가없는 프로젝트를 본 적이 없습니다. (유감스럽게도 시스템이 다른 사람에게 해를 끼친 적이 없었습니다)

charlatans와 qua은 거의 모든 직업, 심지어 오랜 전통과 전통에도 불구하고 의료 직업에도 존재하기 때문에 완전히 제거 할 수는 없습니다.

그럼에도 불구하고 나는이 말을 통해 IT 부서가 소프트웨어 개발에 대한 자신의 통제와 규제를 악마 적으로 묘사하고있는 모든 것의 어두운 무서운 지배자가 무엇인지 확신하지 못한다. 실제로 IEEE에 대해 이야기하고 있다면 분명히 규제 측면이 있지만 IEEE 표준 준수는 총체가 아닌 의지에 달려 있습니다. 그들은 우리 모두가 같은 언어를 사용하고 전반적으로 효율성을 높이기 위해 보편적 인 산업 표준을 개발하려고 노력하고 있습니다.

또한이 표준들이 공통의 관행을 합법화하고 소프트웨어 개발을위한 토대를 마련하여 기계 공학이나 화학 공학과는 달리보다 훈련 된 공학 분야가되도록합니다. 소프트웨어가 그 목표에 가까워지고 있지만, 공학 분야로는 보편적으로 받아 들여지지 않을 것입니다.

핵심 문제는 소프트웨어 개발자가 예쁜 데스크탑 위젯 작성에서 미사일 유도 시스템 구현에 이르기까지 모든 작업을 수행 할 수 있다는 것입니다. 하나는 오류의 심각성과 결과가 다른 것보다 훨씬 높기 때문에 합리적이고 안전하며 효율적으로 접근하기 위해 엄격하게 규제 된 엔지니어링 원칙을 요구합니다. 이는 잘못 설계되어 브릿지가 붕괴되는 오류의 심각성과 매우 유사합니다. 브리지의 설계자는 품질을 보장하기 위해 엔지니어링 표준을 준수해야합니다.

나는 그것을 더 엄격한 규제라고 부르지 않고 대신 진입 장벽으로 삼을 것입니다. 그런 점에서 장점이 있다고 생각합니다. 품질을 높이려면 매우 논쟁의 여지가 있습니다.

현재 모든 John / Jane Doe는 프로그램을 작성할 수 있습니다. 진입 장벽이 없습니다. 스크립팅 및 웹 기술에 관한 몇 권의 책을 집어 들고 해킹을 시작하십시오.

우리가 집단 전체로서 진입 장벽을 높이고, 업계를보다 높은 수준으로 유지하고, 해커 / 장인에서 엔지니어로 진화하기위한 시간을 결정했을 때, 나는 그런 종류의 규제를하고 있습니다.

오늘날 자격이없는 개인 프로그래밍 프로그램이 너무 많습니다. 중요한 시스템에서 작업하든 아니든 여전히 코드를 생성하고 여전히 Big Balls of Mud를 생성 합니다.

이와 관련하여, 자기 규제 또는 진입 장벽을보다 적절하게 만드는 것이 좋습니다. 우리가 말하고 있기 때문에, 당신은 거리에서 와서 자신을 소프트웨어 엔지니어라고 부를 수는 없습니다. 당신은 실제로 어느 정도의 기술을 포기해야합니다.

방탕 기술은 단순히 시험을 치르거나 "명예의 전장"을 얻는 것 이상입니다. 테스트는 단지 검증 일뿐입니다. 실제 검증은 학교, 인턴쉽, 견습, 연장자 멘토링, 연습, 그 일부입니다.

IEEE가 달성하려고하는 것을 볼 수 있지만이 시점에서 과일없는 운동입니다. 업계는 급격히 변화하고 있으며, 제품을 출시하기위한 너무 많은 수요, "해커"사고 방식 등이 있습니다. 규제는 전혀 존재하지 않아야합니다.

나는 기사를 읽지 않았지만 소프트웨어 산업 규제가 인류에게 도움이 될 수 있는지에 대한 질문이 있다면 상황에 따라 다르다고 생각합니다.

1. 전체 산업은 다양한 영역을 포괄하며, 그 중 일부는 생명에 중요하고 (예 : 의료 기기의 방사선 량 제어) 일부는 그렇지 않습니다 ( "Muppet Are You?"Facebook 앱). 스테이크가 적은 애플리케이션에 대한 규제에 대한 논쟁은 없습니다.

2. 법적 규제로 시작 해서는 안됩니다 . 오히려 개발자를위한 인증 프로그램으로 시작해야합니다. 인증 프로그램이 측정 가능한 이점을 제공하는 경우 에만 법적 규제에 대한 의문이 있어야합니다.

3. 인증 프로그램이 측정 가능한 결과를 산출하더라도 업계에서는 엄격한 비즈니스상의 이유로이 인증을 요구하는 것으로 표준화 할 가능성이 높으며 법적 규제가 필요하지 않습니다. (이것이 MCSE 와 같은 대표단이 존재하는 이유입니다. 회사는 MCSE가 훈련 된 영역에서 MCSE를 고용하는 것을 선호합니다.)

4. 모두가 말하지만 여전히 해를 입히는 것이 사업 상 의미가있는 영역은 여전히 ​​남아 있습니다 (종종 부정적 외부 효과 , 때로는 일부 기관 의 시장력 의 결과 임 ). 예를 들어, 지역에 단일 지역 병원이있을 수 있습니다. 이 경우, 백엔드 소프트웨어의 품질은 환자가받는 치료 수준에 큰 차이를 만들 수 있지만 환자가 선택한 병원의 차이는 크지 않습니다. 병원은 반드시 고품질 개발자에게 투자 할 비즈니스 사례가 많지 않을 수도 있습니다. 이 경우 병원의 고용이 허용되는 개발자를 규제하는 공중 보건 사건이있을 수 있습니다.

이모.

나는 이것에 대답해야한다 ...

@JonathanHenson이 말한 내용과 @gnat의 입력으로 시작하면 괜찮습니다. 돈이있는 사람은 인증 된 물건에 돈을 지불 할 수 있고 돈이없는 사람 또는 국가는 라이센스에 대해 지불 할 수 없습니다 (인증 된 물건에 대한 것) ), 실용화 될 경우 여전히 쇄신이있을 것입니다. 전통적인 (아주 전통적이지 않은) 전달 방법이 닫혀 있어도 사람들은 여전히 ​​관심있는 사용자에게 소프트웨어를 전달할 수있는 방법을 찾을 것입니다. 다른 HTTP 프로토콜 또는 대체 전체 네트워크 스택을 개발하는 것을 의미하더라도 연결을 감지 할 수 없게 만드는 데에만 집중했습니다 (이를 수행 할 수있는 사람은 마지막 단락 참조).

또한, 세상이 점점 가난 해지고 있기 때문에 무언가를 지불한다는 아이디어는 위험에 처해 있습니다. 따라서 점점 더 많은 사람들이 물건을 지불 할 돈이 점점 줄어 듭니다 .FOSS 소프트웨어 만 사용하는 국가도 있습니다. 인증 (브라질과 인도가 떠오를 수 있지만 다른 국가는 확실합니다), 그리고 일부 국가는 점점 커지고 있습니다. 또한 알려지지 않은 프로그래머가 만든 인증되지 않은 소프트웨어를 사용합니다.

또한 어떤 유형의 인증이 있더라도 인증은 윤리가 아닌 지식 만 인증하며 일부 의사는 사람들로부터 무단으로 제거 된 장기를 사용한다고 생각하므로 인증 된 프로그래머도있을 것입니다 고의 또는 비 의도적으로 윤리가없고 조잡한 코드를 작성하는 행위 대부분의 FOSS 프로젝트에서 잠재적으로 숙련되지 않은 프로그래머는 다른 사람의 코드를 검토하고 페어 프로그래밍을 조금만 만드는 방식으로 오류를 찾으려고 시도합니다.

마지막으로, 해킹 그룹 (검은 모자 해커 그룹이 아니라 흰색 또는 회색 모자 그룹)에 대해서는 보안에 대해 더 많이 알고 특정 정부 부서의 가장 전문화 된 프로그래머와 만 일치하는 방식으로 보안 소프트웨어를 개발하는 것에 대해 무엇을 말합니까?