실패한 소프트웨어 개발 아이디어 나 기술의 좋은 예는 무엇입니까?

구체적으로 대중의 아이디어가 틀린 곳의 예는 무엇입니까? 사람들이 왜 처음부터 아이디어를 고수 했습니까? 그리고 왜 아이디어가 기각 되었습니까? 아니면 아이디어가 여전히 살아 있고 잘된다면 왜 그런가?

예를 들어 CORBA (및 기타 유사한 기술)를 소프트웨어 구성 요소 간의 통신 문제를 해결하려고 시도한 것으로 설명 할 수 있습니다 . 많은 사람들이 다양한 구성 요소 사이에 계약을 정의해야한다고 생각했습니다. 궁극적으로 HTTP + JSON은 대중의 문제를 해결했으며 Thrift 및 Proto-bufs와 같은 다른 다양한 RPC 메커니즘이 나타났습니다.

기본적으로 컴퓨터 외부의 세계에서와 마찬가지로 아이디어와 기술은주의를 끌기 위해 경쟁하고 레버리지 등을 사용합니다. 그리고 일부는 한동안 우승자 인 것처럼 보일 수 있으며, 다음 큰 것 (The Next Big Thing)의 출현과 함께 모호해집니다. 실제로 더 나은 것과 관련이 있거나 없을 수도 있습니다. VHS 대 Betamax 또는 다양한 DVD 형식 간의 최근 전쟁을 목격하십시오.

CORBA는 거대하고 어색하고 사용하기 어려웠지만 일부 사람들은 당시에 발명 할 수있는 최고였습니다 (WWW (World Wide Web) 및 HTTP, Java, XML 등이 널리 알려지기 전에 설계되었습니다). 또한 위원회 가 디자인 의 고전적인 예이기도했으며 , 모든 아이디어를 만족시켜 모든 사람들을 만족시킬 수있게되었으며, 결국은 (적어도 오늘의 시각으로는 볼 수없는) 부풀어 오릅니다. FOSS의 출현과 함께 곧 가격이 올라가는 가격은 말할 것도 없습니다.

궁극적으로 HTTP + JSON은 대중의 문제를 해결했습니다.

적어도 유사한 "최종 솔루션"이 두 번 나오지 않고 결국에는 떨어지지 않은 사람에게는 ... CORBA에 대해 비슷한 감정이 있었음을 명심하는 것이 좋습니다. ;-)

CORBA의 Rise and Fall 에서 인용하기 쉽다고 생각합니다 .

CORBA의 역사는 컴퓨팅 산업이 여러 번 본 역사이며 현재 미들웨어 노력, 특히 웹 서비스가 비슷한 역사를 재현 할 것으로 보입니다. [...]

전반적으로 OMG의 기술 채택 프로세스는 CORBA의 쇠퇴의 핵심 이유로 여겨 져야합니다. 이 과정은 기술 탁월성을 달성하기는 어렵지만 기술 평범함을 달성하기 어려운 시점까지위원회와 정치 운동에 의한 디자인을 장려합니다. 또한, 분리 된 피처를 추가하면 건축 비전이 점차 침식됩니다. [...]

OMG와 같은 민주적 인 프로세스는 좋은 소프트웨어를 만드는 데 적합하지 않습니다. 그러나 알려진 절차상의 문제에도 불구하고 업계는 기술을 생산하기 위해 대규모 컨소시엄에 의존하는 것을 선호합니다. 현재 미들웨어의 은색 총알 인 웹 서비스는 OMG와 매우 유사한 프로세스를 사용하며 많은 계정에 의해 투쟁, 단편화, 아키텍처 일관성 부족,위원회 별 디자인 및 기능 부풀림으로 어려움을 겪고 있습니다. 웹 서비스가 CORBA와 매우 유사한 역사를 제정하는 것은 불가피합니다.

이제 다른 각도에서 : "대중의 아이디어"라는 용어를 읽었을 때 나는 CORBA 나 다른 표준과는 매우 다른 것들에 대해 생각했습니다. 이들은 일반적으로 한 사람 또는 소규모 그룹의 아이디어입니다. 나는 "카우보이 코딩", "코드와기도", "내 기계에서 작동한다"등과 같은 악명 높은 관행 / 관점에 대해 생각했다. 이것들은 거의 모든 초보자이기 때문에 IMHO의 실제 "대중의 아이디어"이다 개발자는 본능적으로 코드 작성을 시작합니다. 또한 공간이나 시간에 맞게 확장 할 수 없기 때문에 잘못되었습니다. 이러한 방식으로 유지 관리 가능하고 확장 가능한 큰 프로그램을 만들 수 없습니다. 그러나 불행히도 사람들이 전 세계의 전문 상점에서 이런 식으로 일하는 것은 예외가 아니라 여전히 표준이라고 생각합니다.

이것의 또 다른 극단은 SW 개발에 대한 "올바른 접근법"에 대한 많은 관리자 및 이론가들의 아이디어이며, CMM, RUP, Waterfall 등과 같은 큰 M 방법론에 나타나 있습니다. 올바른 프로세스를 통해 개발자가 실제로 누구인지에 관계없이 결정적인 방식으로 양질의 소프트웨어를 자동으로 생산하기 시작합니다. 애자일 방법을 사용하여 같은 게임을 플레이 할 수 있습니다. 라벨 변경 일뿐입니다. 자신의 개발 팀에 적합한 멤버를 선택 (및 유지)하는 것이 개발 프로세스보다 덜 중요하다고 생각하는 모든 관리자는 실패 할 것입니다. 그러나 프로세스에 대한 이러한 믿음은 여전히 ​​널리 퍼져있는 것 같습니다. 어쩌면 그것은 여전히 ​​경영 학교에서 가르쳐지고 있습니까?

사람들이 잘못 간다는 예는 폭포 모델입니다. 이것은 전형적인 폭포 형 모델의 다이어그램이며, Winston Royce의 논문 "대형 소프트웨어 시스템 개발 관리"에도 나와 있습니다.

이 이미지 다음에이 텍스트가옵니다 :

나는이 개념을 믿지만 위에서 설명한 구현은 위험하고 실패를 불러 일으 킵니다 ... 개발주기가 끝날 때 발생하는 테스트 단계는 타이밍, 저장, 입력 / 출력, 전송 등의 첫 번째 이벤트입니다. 분석 된 것과는 다른 경험입니다. 이러한 현상은 정확하게 분석 할 수 없습니다. 예를 들어, 수학 물리학의 표준 부분 미분 방정식에 대한 솔루션은 아닙니다. 그러나 이러한 현상이 다양한 외부 제약 조건을 충족시키지 못하면 변하지 않는 큰 재 설계가 필요합니다. 간단한 8 진 패치 또는 일부 분리 된 코드의 재실행은 이러한 종류의 어려움을 해결하지 못합니다. 필요한 설계 변경은 설계의 기반이되는 모든 소프트웨어 요구 사항을 위반하는 모든 소프트웨어 요구 사항을 위반할 정도로 파괴적 일 수 있습니다. 요구 사항을 수정하거나 디자인을 크게 변경해야합니다. 실제로 개발 프로세스가 원점으로 돌아 왔으며 일정 및 / 또는 비용이 최대 100 % 초과 될 것으로 예상 할 수 있습니다.

이 논문의 뒷부분에서 Royce는 현재 단계와 이전 단계 사이의 반복과 요구 사항 분석 설계와 설계 코드 테스트 사이의 다른주기 사이의 반복을 포함하는 대체 프로세스 모델을 제시합니다. 또한 여러 문서와 해당 단계를 완료해야하는 단계를 파악하고 각 단계에서 고객 참여 및 여러 폭포를 옹호하여 관련된 모든 아티팩트의 분석, 테스트 및 사용을 포함합니다. 실제로 Royce가 논의하는 것은 민첩한 방법에 대한 초기 접근 방법으로 간주 될 수 있습니다. 그러나 여전히 계획 중심이지만 민첩한 운동의 기초입니다.

사람들이 왜 첫 번째 폭포에 걸 렸는지 모르겠습니다. 나는 그들이 위험을 감수하고 실패를 초대하는 것을 좋아합니다.

더 높은 추상화 수준에서 자동 코드 생성 또는 자동 프로그래밍 .

Wikipedia 기사에는 역사적인 정보가 다소 부족하지만 프로그래머가 컴퓨터보다 비싸게 된 이후로 관리자의 꿈이었습니다.

Fortran 및 Cobol과 같은 고급 언어가 개발 된 후 보고서 작성과 같은 특수 도메인의 언어가 개발되었습니다. Easytrieve 와 SAS 는 몇 가지 예입니다.

1980 년대 CASE 도구 는 분노였습니다. CASE는 컴퓨터 지원 소프트웨어 엔지니어링을 나타냅니다. 엔지니어링 원칙을 엄격하게 적용하면 소프트웨어 개발 속도가 빨라질 것으로 생각되었습니다. 이러한 도구가 비용을 부담하지 않은 주된 이유는 도구가 효과적으로 작동하는 데 필요한 높은 수준의 데이터 표준화 때문이었습니다.

인터넷은 1990 년대에 유명해졌습니다. 인터넷이 촉진 한 프로그래밍 유형이 폭발했습니다. 프로그래머는 잘 알려진 방법을 사용하여 일러스트레이션,지도, 사진 및 기타 이미지와 간단한 애니메이션을 이전에는 볼 수 없었던 속도로 처리해야했습니다. 이러한 객체를 생산하는 기술의 수를 곱한 것입니다. 자동 프로그래밍의 꿈은 사라졌습니다.

보다 저렴한 위치로 프로그래밍을 아웃소싱하는 것은 프로그래머 비용을 줄이기 위해 남은 몇 가지 방법 중 하나입니다. 아웃소싱 관련 문제에는 통신 문제 및 사양 문제가 포함됩니다.

공식적인 방법

옛날 옛적에, 소프트웨어가 올바른 것으로 입증 될 수 있다고 제안되었습니다. (테스트에서 오류가 없다는 것을 증명할 수는 없지만 증거는 가능합니다.) 불행히도 프로그램에 대한 증거를 고안하는 데는 몇 가지 단점이 있습니다.

• 프로그램을 작성하는 것보다 더 어렵고 시간이 많이 걸립니다.
• 전체 프로그램을 다루어야하므로 라이브러리, OS 등에 대한 증거가 필요합니다.
• 이 버그는 우연히 발생할 수 있으므로 버그가 없음을 증명하지 않습니다.

이 개념은 70 년대에 매우 인기가있었습니다.

연계 : http://en.wikipedia.org/wiki/Formal_methods http://c2.com/cgi/wiki?ProofOfCorrectness http://c2.com/cgi/wiki?PractitionersRejectFormalMethods