No Silver Bullet, 미국 1999 년 튜링상 수상자, 세계 소프트웨어 공학계의 개척자, 권위, 원로-페레데릭 브룩스 박사, 교수, 어떻게 실제로 지난 2 년 동안' 인월 신화' 중국어판, 복사판이 잇달아 국내에 도입, 번역, 출판, 그에 따른 기세와 소음이 이어지면서, 현재' 은탄 없음' 이라는 트렌디한 수입품은 거의 온통 날아다니는 침어가 되어 IT 계의 일부 사람들이 매일 입에 매달리고 있다. "이것은 은탄이 아니다. 부씨의 은탄설 (NSB) 은 사람들의 눈에는 휴대할 수 있는 만유, 만능유액, 장소를 찾을 수 있을 뿐, 준보용 한 제를 붙이는 것 같다고 말했다.
그런데 사실은 정말 그렇습니까? 부씨은탄이 도대체 무엇이냐, 지금 사람들이 보편적으로 생각하는 것처럼 은탄이 없는 것이 아니라, 왜 은탄이 있다고 말하는가, 왜 부씨은탄이 실제적인 의미가 없다고 말하는가, 늙은 천의 진짜 의도는 무엇인가? 아래 분해를 보십시오. < P > 동기 < P > 는 최근 한담에서 한 서클 친구에게 국내 소프트웨어 공사 현황과 미래 발전에 대한 그의 견해를 물었다. 그는 이 방면의 활동가로, 그의 망설임 가득한 표현을 들을 줄 알았는데, 그가 고개를 저을 줄은 생각지도 못했다. 나는 그에게 무슨 일이 있었는지 물었다. 그는 "소프트웨어 공사가 국내에서 이미 악취를 당했다" 고 말했다. 그래서 지금 그는 밖에서 활동도 하고, 소리도 내지 못하고, 소프트웨어 공사와 관련을 맺지 못하고 있다. (윌리엄 셰익스피어, 윈스턴, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어) 그의 이 말은 완전히 나의 예상을 벗어난 것이어서, 정말 나를 놀라게 했다! 네, 소프트웨어 공학 무용론과 허황은 중국에서 유래가 오래되었다고 할 수 있습니다. 하지만 매일 소프트웨어를 다루는 우리 사람들의 눈에는 소프트웨어 엔지니어링이 일상적인 일과 생활 방식이며, 소프트웨어 엔지니어링이 없는 소프트웨어 개발이 어떤 모습일지 상상하기 어렵다. (윌리엄 셰익스피어, 윈스턴, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어) < P > 한동안 관찰한 결과, 이런 혹독한 현실을 차츰 발견했는데, 현재 국내에 이렇게 많은 사람들이 (적어도 가장 전문적인 웹사이트, 미디어, 포럼에 반영됨) 어렴풋이 소프트웨어 공사의 중요성과 필요성을 의심하고,' 소프트웨어 공사가 도대체 무엇이냐' 에 대한 이해도 마음대로, 가지각색이다. 나는 이 현상의 배후에 있는 모든 방면의 원인을 반복해서 생각했다. 불행히도, 많은 사람들이' 인월 신화' 을 보고 나서 (아마도 전혀 자세히 보지 않았을 수도 있음), 브롱스가 보유하고 있는 것은 비관적인 논조로 여겨져 은탄론에서' 소프트웨어공학은 은탄이 아니다' 를 유도하고, 소프트웨어공학은 기본적으로 쓸모없는 신화, 소프트웨어공학을 선전하는 것 같다. < P > 또 한 차례 꼼꼼한 조사 연구를 통해 부씨의 NSB 는 틀리지 않았고, 우리 대부분은 은탄이 없다고 외치는 사람들이 틀릴 가능성이 높다는 사실을 알게 되었습니다. 우리는 부교수를 제대로 이해하지 못했습니다! < P > 부씨은탄은 만령약 < P > 이 아니다. 우선 은탄이 만령약의 동의어가 아니라는 것을 분명히 해야 한다. 즉, 우리는 문장에서' 은탄' 이라는 단어를' 만령약' 으로 마음대로 사용할 수 없다는 것이다.
증명: 반증법을 채택하다.
' 은탄' 이' 만령약' 이라고 가정하면' OOAD 는 은탄이 아니고 UML 은 은탄이 아니다. 용례는 은탄이 아니다. RUP 은 은탄이 아니다. MDA 는 은탄이 아니다. 소프트웨어 공학도 은탄이 아니다' 는 것은 모두 옳다 < P > 는' 세상에 만령약이 없다' 는 명제는 공리여야 한다. 원래 다시 증명할 필요가 없다. 천 교수가 전후 9 년 사이에 두 편의 중요한 문장 두 편을 썼는데, 이렇게 큰 정력을 들인 것은' 소프트웨어공사에 만령약이 없다' 는 것을 증명하기 위해서인가? 황당하지 않나요? 분명히 여기에 모순이 있기 때문에 앞의 가설은 성립될 수 없다. 이는 부씨 은탄이 또 다른 의미를 가지고 있다는 것을 설명한다. < P >' 은탄 없음' 이라고 말하는 대부분의 사람들은 은탄의 의미를 제대로 이해하지 못하며, 낡은 천의 정신을 이해하지 못하는 것으로 추정된다. 그들은 실수를 저질렀을 가능성이 높다. 첫 번째는 쓸데없는 말을 하는 것일 수도 있고, 두 번째는 무심코 간과하고, 진정으로 가치 있는 기술과 방법을 배척하는 것일 수도 있다. NSB 오용 (은탄, 만령약을 혼동) 의 예를 들어 "수년 동안 기술계는 개발 과정의 모든 문제를 해결하는' 은탄' 을 꾸준히 찾고 있다. 이러한 노력은 존경할 만하다. 하지만 결과는 탄식했다. 사실 이런 은탄은 존재하지 않는다. 6 년대 말부터 등장한 소프트웨어 공사는 만병통치의 만병통치약으로 쓰였다. " 작가는 분명히 은탄이 무엇인지 이해하지 못했기 때문에 이 말은 지루한 쓸데없는 말이 되어' 소프트웨어 엔지니어링의 위기' 를 후속 논증하기 위한 허상과 착오의 전제가 되었다. (윌리엄 셰익스피어, 윈스턴, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어)
그럼 도대체 은탄이 뭘까요?
도대체' 은탄' 이란 무엇인가? 유명한 부씨 예언에 대해 한 번 탐구합시다. 은탄 유무에 관한 문제에서, 만약 반드시 진실해야 한다면, 원문을 떠나 도처에서' 은탄 없음' 을 외치는 것은 과학적인 방법이 아닐 것이다. 내 번역은 < P > "엔지니어링 기술이든 관리 기술이든 1 년 이내에 소프트웨어의 생산성, 신뢰성 또는 단순성을 독립적으로 약속할 수 있는 단일 진전은 없다" 는 것이다. < P > 은탄기술에 필요한 연평균 성장률을 계산해 보세요. < P > 정의에 따르면 (1+x )^1 = 1, 그래서 X .26 < P > 는 부브은탄이 실제로 우리의 소프트웨어 개발 생산성을 매년 평균 26% 정도 유지해야 한다는 것을 알 수 있습니다. 우리가 은탄 유무를 토론할 때, 당연히 이 기본 판단 기준을 떠날 수 없다. < P > 부씨 은탄의 지루성 < P > 사실 부씨 은탄을 추구하는 것은 현실적인 소프트웨어 개발에 실질적인 의미가 없다. 왜요 적어도 세 가지 이유가 있습니다:
1) 특정 소프트웨어 제품 또는 엔지니어링 프로젝트에 대해 다른 무분별한 생산성 향상의 의미는 무엇입니까? 일방적으로 생산성 (또는 신뢰성, 간결성) 을 높이는 것은 우리의 진정한 목적이 아닙니다. 기업은 품질을 보장하고, 고객의 요구를 진정으로 만족시키며, 이윤을 얻을 수 있는 경우에만 높은 생산성 및/또는 높은 신뢰성, 높은 단순성을 추구하는 것이 의미가 있습니다. 따라서 기술이나 도구가 은탄이 아니라면 1 배의 개선을 보장할 수 없다면, 우리는 그것을 경시하거나 거부하거나 버릴 수 없습니다.
2) 왜 단일 기술만 채택할 수 있다고 규정해야 합니까? 특정 소프트웨어 제품 또는 엔지니어링 프로젝트의 경우, 우리 조직에 결함이 있는 한, 개선 효과가 과거보다 낫다고 예상하는 한, 전반적인 성공, 품질 및 비즈니스 목표를 보장할 수 있는 다양한 엔지니어링 기술 및 관리 방법, 우리는 용감하고 과감하게 시도하고, 종합적이고 유연하게 운용해야 하며, 게다가 단일 기술 진전을 어떻게 정의하느냐는 매우 어렵다. 우리는 종종 종합적인 전반적인 성장을 요구하고, 단일 은탄을 추구하는 것은 현실적인 가치가 없다.
3) 왜 1 년 1 배를 요구합니까? 기술을 평가할 때, 우리는 일반적으로 올해 프로젝트, 제품에 실질적인 도움이 될 수 있는지 여부를 고려합니다. 세계 최고의 소프트웨어 기업 수석 과학자들은 일반적으로 전략 기술에도 3 ~ 5 년을 많이 고려하며, 1 년 1 배에 대해 이야기하는 것은 실제 엔지니어링의 의미가 없습니다. 더욱이, 어떤 공사 기술, 관리 방법은 효과가 있지만, 만약 그것이 프로젝트에 가져온 개선이 26% 에 이르지 못한다면, 예를 들어 지구의 2%, 1% 만 있다면 좋지 않을 것이다. 버려야 한다. 무시해야 하는가? < P > 노포가 NSB 라는 논단을 내릴 때 확실히 약간의 요령을 취하여 적어도 1 년 안에 효력을 잃지 않을 것으로 기대한다는 것을 알 수 있다. (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), 성공명언) 그러나 NSB 가 우리의 실제 업무에 어떤 영향과 의미가 있을까요? 적어도 우리는' 은탄' 을 실천을 지도하고, 어떤 기술이나 도구를 선택, 채택하는 기준으로 삼을 수는 없다. (알버트 아인슈타인, 과학명언)
그렇다면 부씨는 왜 NSB 를 제안합니까? 공혈이 아니어야 한다. 내 이해와 분석에 따르면, 그 이유는 1986 년 당시 학술 교수였던 그가 당시 CASE 도구 개발업자들이 지나치게 허위 선전에 불만을 품었기 때문에 NSB 를 통해 그들의 도구에 큰 한계가 있다는 것을 밝혀냈기 때문에 소프트웨어 공학의 근본 문제를 해결할 수 없었고, 또 우리에게 명확한 길 ("There ISno") 을 지적해 주었다. But there is a road. "[1], 그가 생각하는 은탄은 실제로 미래에 근본적인 문제를 해결할 수 있는 기술을 말한다. 부씨은탄은 원래 외국의 일부 CASE 도구 개발업자들이 지나치게 선전하는 농담을 조롱하는 데 사용되었지만, 결국 우리 국내의 지루한 매니아 무리에 의해 소프트웨어 공사를 무턱대고 공격하는 데 쓰였다. (윌리엄 셰익스피어, 윈스턴, 독서명언) (윌리엄 셰익스피어, 윈스턴, 과학명언) < P > 진실 공개-은탄 < P > 는 혁명적인 핵심 기술로 각 업종의 은탄이 광범위하게 존재한다. 보험을 위해, 노천은 소프트웨어 엔지니어링 NSB 에 대해 1 년 동안 예견했다. 그러나 당시에는 없었는데, 장차 없는 것은 아니다. 소프트웨어 엔지니어링의 은탄은 정말 영원히 존재하지 않습니까? < P > 부씨 은탄이 요구하는 연간 26% 증가가 정말 어렵습니까? 국내 많은 IT 기관에서는 한 프로젝트의 효율이나 품질이 3% 향상되는 것은 어려운 일이 아니라고 생각합니다. 왜냐하면 우리 업무에는 아직 비효율적이고 잘못된 부분이 많기 때문입니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언) 관리든 기술적으로든 우리의 소프트웨어 엔지니어링 수준은 세계 선진국과 동등한 수준까지 높아져 3% 의 재성장 공간조차 없었다는 것을 믿지 않는다. (알버트 아인슈타인, 소프트웨어 엔지니어링, 소프트웨어 엔지니어링, 소프트웨어 엔지니어링, 소프트웨어 엔지니어링, 소프트웨어 엔지니어링, 소프트웨어 엔지니어링, 소프트웨어 엔지니어링, 소프트웨어 엔지니어링, 소프트웨어 엔지니어링) < P > 사실 늙은 천은 마음속에 은탄이 있거나 은탄이 나타나기를 기대하고 있다. 그는 은탄이 존재할 가능성을 분석하는 데 많은 지면을 썼다. 특히, 비즈니스 분석, 요구 사항 분석 및 소프트웨어 설계를 중시하며, 인식 문제와 문제 해결의 본질에 가까울수록 좋습니다. 그는 IT 업계에 근본적인 문제와 부차적인 문제를 해결하는 기술을 구별하고 전자의 R&D 를 더욱 중시하고 적극적으로 추진해야 한다고 경고했다. 이것이 그의 진정한 본의라고 생각하지만, 국내 많은 사람들이 여러 가지 이유로 영문도 모른 채 후반절을 잊어버리거나 못 본 척하며 NSB 로 소프트웨어 공사를 잘못 부정하기도 한다. < P > 그의 분석에 따르면 당시 일부 기술, 도구 및 방법 (예: 고급 프로그래밍 언어, 시분할 기술, 통합 프로그래밍 환경) 은 1 배 은탄이 될 수 없었다 외국 소프트웨어 엔지니어링의 2 년 동안의 발전 경로를 자세히 살펴보면 은탄이나 준은탄 (1% 를 추구하는 은탄) 이 의미가 있다는 것을 알 수 있습니까? ) 이미 나타나거나 곧 나타나려고 하는데, 심지어 이미 한동안 존재해 왔다. 예를 들어, 소프트웨어 재사용은 은탄의 증거입니다. 모토로라는 컴파일러 프로젝트에서 85% 의 재사용을 통해 1:1 생산성 향상 [4] 을 얻었습니다. 제너럴모터스 회사의 재고 계획 및 유지 관리 시스템, Smalltalk 8 으로 기존 PL/1 시스템을 대체하여 전반적인 생산성 향상은 14:1[3]! 객체 지향 기술은 확실히 은탄이거나 적어도 은탄의 핵심 레시피라는 것을 알 수 있다. < P > 노보가 말한 소프트웨어 엔지니어링의' 근본적인 문제' 는 근본적으로 해결할 수 없기 때문에 은탄이 존재할 수 없다는 것이 잘못된 논리라는 의견도 있다. "풀 수 있다" 와 "해결의 효율성" 은 별개의 일이다. 부 교수가 말한' 근본적인 문제' 는 NP 의 완전한 문제와 비슷한 것인가요? 물론 아닙니다. 부 교수의 NSB 는 솔루션의 효율성과 효능에 대해 이야기하고 있습니다. 소프트웨어 공학은 이론 과학과는 달리, 실제 업무 관행과 과학 응용이며, 소프트웨어 엔지니어링이 해결해야 할 문제는 대개 해결 가능해야 한다 (프로젝트의 실현가능성 분석에 의해 보장됨). 그렇지 않으면 공사를 부를 수 없다. 그렇게 많은 고난도의 소프트웨어 프로젝트, 전 세계를 돌아다니는 수억 대의 휴대폰 (중국은 이미 세계 최대 이동통신 시장임), 하늘을 나는 777, 38, 중국인들을 기우뚱거리고, 세계를 놀라게 하는 선저우 5 호 (우리 우주영웅들이 손에 은탄을 쥐고 있음), 화성에 오르는 용기 번호를 생각해 보자. 이들은 모두 사람들이 아니다 친구들, 실천이야말로 진리를 검증하는 유일한 기준이니, 더 이상 책에 얽매이지 말고, 우리의 지혜의 눈으로 주변 세상을 잘 보아라. 소프트웨어 엔지니어링에서 도대체 하드웨어 기술처럼 n*1 배율의 기술 및/또는 관리 은탄이 있는지, 단순한 과학연산과 이론추론으로 증명하는 것은 상당히 어렵다. 천 교수조차도 할 수 없을 것 같다. 모든 것은 결국 사실과 데이터로만 말할 수 있다. < P > 솔직히 말해서, 우리는 세계 소프트웨어 업계의 지도자들과 은탄에 대해 이야기할 자격이 없을 것이다. 3 여 년 동안 이미 방대한 학과로 발전한 소프트웨어 공학의 모든 방면, 민간용 소프트웨어 분야에서 우리가 얼마나 많은 오리지널 물건을 가지고 있는지, 몇 가지 손에 들고 세계 학술계와 공업계에 갈채를 보내는 성과를 거뒀는가? 지금까지 중국에는 아직 자신의 대상 기술 전문가가 없는 것 같습니다. 지금 보기에, 21 세기로 접어들면서 우리는 여전히 더 넓은 범위에서 어려운 소프트웨어 공학의 계몽을 계속해야 할 필요가 있다. (윌리엄 셰익스피어, 윈스턴, 과학명언) 그러므로 사람을 그르치는 은탄론에 속지 마십시오! 만약 우리가 3721 을 신경쓰지 않는다면, 우리가 익숙하지 않고, 익히지 못한' 새로운' 기술,' 새로운' 방법을 모두 가짜 탄환으로 여기고,