IT 산업이 다른 산업과 마찬가지로 결함없는 대규모 프로젝트를 신속하게 제공 할 수없는 이유는 무엇입니까?

내셔널 지오그래픽의 MegaStructures 시리즈를 본 후 , 대규모 프로젝트가 얼마나 빨리 완료되는지 놀랐습니다. 일단 예비 작업 (디자인, 사양 등)이 종이에 완성되면, 거대한 프로젝트를 실현하는 데 몇 년 또는 몇 달이 걸립니다 .

예를 들어, Airbus A380은 "공식적으로 2000 년 12 월 19 일에 발사되었습니다"및 "2005 년 3 월 초에" 항공기는 이미 테스트되었습니다. 거대한 유조선, 고층 빌딩 등도 마찬가지입니다.

이것을 소프트웨어 산업의 지연과 비교할 때, 대부분의 IT 프로젝트가 왜 그렇게 느리거나 더 정확하게, 왜 충분한 규모의 사람들에게 같은 규모로 빠르고 완벽하게 실패 할 수 없는지 궁금하지 않습니다.

Airbus A380과 같은 프로젝트는 다음을 모두 제공합니다.

• 예상치 못한 주요 위험 :이 항공기는 최초의 항공기는 아니지만 기술의 한계를 뛰어 넘고 있으며 소규모 항공사에게는 잘 작동하는 것이 물리적 제약으로 인해 큰 항공기에는 적합하지 않을 수 있습니다. 같은 방식으로 아직 사용되지 않은 새로운 기술이 사용됩니다. 예를 들어 Boeing 747이 완료된 1969 년에는 사용할 수 없었기 때문입니다.

• 일반적으로 인적 자원 및 관리와 관련된 위험 : 프로젝트 중간에 사람들이 휴가, 휴가 중이기 때문에 사람에게 접근 할 수 없음, 일반적인 인적 오류 등

이러한 위험으로 인해 사람들은 여전히 ​​짧은 기간에 대형 여객기와 같은 프로젝트를 달성 하고 있으며 배송 지연에도 불구하고 이러한 프로젝트는 여전히 큰 성공을 거두었습니다.

소프트웨어 개발과 관련하여 프로젝트는 기술적으로나 관리 측면에서 여객기만큼 크거나 복잡하지 않으며 실제 세계에서 예측할 수없는 위험이 약간 줄어 듭니다.

그럼에도 불구하고 대부분의 IT 프로젝트는 느리고 늦 으며, 더 많은 개발자를 프로젝트에 추가하는 것은 해결책이 아닙니다 (10 명의 개발자 팀에서 2 천명으로 이동하면 때로는 프로젝트를 더 빨리, 때로는 제공하지 않을 수 있으며 때로는 완료하지 않을 위험이 있습니다).

여전히 제공되는 버그는 많은 버그를 포함 할 수 있으며 연속적인 서비스 팩과 정기적 인 업데이트가 필요합니다 (원래 제품의 버그를 패치하고 항공기 충돌을 방지하기 위해 매주 두 번 모든 Airbus A380에 "업데이트 설치"를 상상하십시오).

그러한 차이점을 어떻게 설명 할 수 있습니까? 소프트웨어 개발 산업이 너무 젊어서 단일 프로젝트에서 수천 명의 사람들을 관리 할 수 ​​없어서 규모가 크고 결함이없는 제품을 매우 빠르게 제공 할 수 없기 때문입니까?

Ed Yourdon의 죽음 3 월 은 이러한 메타 유형의 질문들 중 몇 가지를 다루었습니다 .

일반적으로 소프트웨어 산업에는 다음과 같은 것들이 부족하여 대규모 프로젝트를 방해합니다.

• 표준화 및 작업 항목 분석

  • 이것은 확실히 나아졌지 만 디자인 구조는 여전히 큰 시스템을 깰 수는 없습니다. 어떤면에서 소프트웨어는 주어진 프로젝트에 필요한 것에 동의하지 않고 구성 요소로 분류 할 수있는 능력이 훨씬 떨어집니다.
  • 항공 우주, 건물 건설, 자동차 등은 모두 완전히 평행 한 개발이 가능하도록 인터페이스가 촘촘한 구성 요소 중심 아키텍처입니다. 소프트웨어는 여전히 해당 영역에서 너무 많은 출혈을 허용합니다.

• 성공적이고 유사한 프로젝트로 구성되어 있습니다. A380 은 에어 버스가 만든 최초의 대형 비행기 가 아니 었 습니다 . 큰 소프트웨어 응용 프로그램이 많이 있지만, 그 중 일부는 어떤면에서나 다른면에서 극적으로 어려움을 겪어 왔으며 "성공"이라고 부르지 않았습니다.

• 다수의 유사하고 성공적인 프로젝트를 수행 한 대규모 디자이너 및 제작자. 인적 재능이없는 성공적인 프로젝트 문제와 관련하여 반복성 관점에서 일을 매우 어렵게 만듭니다.

• "절대로"같은 것을 두 번 만들지 마십시오. 여러면에서 비행기는 다른 비행기와 같습니다. 날개, 엔진, 좌석 등이 있습니다. 대규모 소프트웨어 프로젝트는 거의 반복되지 않습니다. 각 OS 커널은 크게 다릅니다. 파일 시스템의 차이를 살펴보십시오. 그리고 그 문제에 대해 얼마나 많은 고유 한 OS가 있습니까? 큰 것은 어느 시점에서 기본 항목의 복제품이됩니다. AIX , Solaris , HP-UX 등은 AT & T System V로 돌아 왔습니다 . Windows는 각 반복을 통해 엄청난 양의 드래그를 진행했습니다. Linux 변형은 일반적으로 Linus가 시작한 것과 동일한 코어로 돌아갑니다. 변형이 진정한 독창적 인 독점 OS보다 더 빨리 전파되는 경향이 있기 때문에 나는 그것을 가져옵니다.

• 정말 나쁜 프로젝트 추정. 반복성 계수가 너무 낮기 때문에 얼마나 큰지, 어떤 것이 만들어지는 데 걸리는지를 예상하기가 어렵습니다. 프로젝트 관리자와 경영진이 코드에 손을 대지 않고 실제로 수행중인 작업을 볼 수 없기 때문에 타임 라인에 대한 비현실적인 기대치가 생성됩니다.

• QA / QC는 대규모 프로젝트를위한 것만 큼 강조되지 않습니다. 이것은 컴포넌트들 사이의 인터페이스가 느슨해지고 컴포넌트 작동 방식에 대한 엄격한 사양이없는 것으로 되돌아갑니다. 이러한 느슨 함은 의도하지 않은 결과를 초래하고 버그가 발생하도록합니다.

• 지속적으로 측정 가능한 자격. 일반적으로 사람들은 X 언어 또는 프로그래밍 분야에서 일한 기간을 말합니다. 시간은 칼리버 또는 기술의 대체물로 사용됩니다. 여러 번 언급 한 것처럼 좋은 프로그래밍 인재를 인터뷰하고 찾는 것은 어렵습니다. 문제의 일부는 "좋은"의 정의가 매우 주관적으로 남아 있다는 것입니다.

나는 모두 부정적인 것을 의미하지는 않으며, 소프트웨어 산업은 우리가 있었던 곳에서 큰 진전을 이루었다 고 생각합니다. 이와 같은 포럼과 다른 포럼은 디자인 원칙에 대한 대화와 토론을 촉진하는 데 실제로 도움이되었습니다. 소프트웨어 엔지니어를위한 "기본"지식을 표준화하기 위해 노력하는 조직이 있습니다. 확실히 개선의 여지가 있지만, 나는 산업이 상당히 짧은 기간 내에 먼 길을 왔다고 생각합니다.

대답은 놀라 울 정도로 간단합니다. '다른 산업' 은 실패율이 높습니다. 우리는 단지 잘못된 것을 비교하고 있습니다. 소프트웨어 작성은 종종 '빌드'라고 불리므로 다른 산업의 제조 또는 건설 단계와 비교합니다. 그러나 당신이 그것을 보면, 그것은 전혀 건설이 아닙니다 : 그것은 디자인 입니다. 소프트웨어 디자인은 코드로 작성되며, 소프트웨어를 컴파일하거나 직접 해석하여 컴퓨터로 구축합니다.

다른 산업의 많은 설계는 원래 예상보다 시간이 오래 걸리거나 비용이 많이 들거나 단순히 완성을 보지 못합니다. 익숙한 소리?

그렇다면 소프트웨어를 계획 할 때 무엇을하고 있습니까? 글쎄, 우리는 여전히 디자인하고 있지만 초기 단계입니다.

소프트웨어에는 제조 라인이 없습니다. 최종 구성 요소를 구축하는 것은 (비교적으로) 저렴하며 최종 제품의 복제는 완벽하고 효과적으로 무료입니다. 빌드 아티팩트를 복사하십시오.

일부 수치를 지적하려면 다음을 수행하십시오.

1. 요구 사항 구현이 시작된 이후의 변경 ; 예를 들어, 최초의 Airbus A380이 공장에서 생산되기 시작했을 때 누군가가 200 석을 더 원한다면 그 좌석이있을 것이라고 믿을 수 없습니다. 그러나 대규모 소프트웨어 프로젝트에서는 프로그래머가 개발을 시작한 후에도 5 가지 유형의 사용자를 추가 할 수 있습니다.
2. 복잡성 -대규모 소프트웨어 프로젝트는 매우 복잡합니다. 아마도 인간이 설계하고 개발 한 가장 복잡한 프로젝트 일 것입니다.
3. 아키텍처 및 디자인 단계 에서 충분한 리소스가 소비되지 않습니다 .
4. 현장 미숙함 -소프트웨어 엔지니어링은 다른 엔지니어링 자매에 비해 비교적 젊은 분야입니다. 여기에는 두 가지 의미가 있습니다. a) 휴리스틱과 모범 사례가 많지 않습니다. b) 경험이 많은 전문가는 그리 많지 않다.
5. 수학적 증거 부족 -대부분의 경우 수학적 공식 방법은 소프트웨어가 필요에 따라 작동 함을 증명하는 데 사용되지 않습니다. 대신 테스트가 사용됩니다. 이것은 수학에 더 크게 의존하는 다른 공학 분야에서도 마찬가지입니다. 그 이유는 복잡성 때문입니다.
6. 러쉬 -많은 관리자는 달성 할 수없는 마감일이 있습니다. 마감 시간 때문에 코드 품질이 두 번째로 높아집니다.

질문에 엄격히 대답-나는 다른 사람들이 프로그래머로부터 매우 높은 기대 (특히 배달 시간)를 가지고 있으며 큰 소프트웨어를 프로그래밍하는 것이 얼마나 어려운지를 정확하게 이해하지 못하는 경향이 있습니다.

질문의 전제는 약간 결함이 있습니다. A380과 Boeing 787은 모두 늦게 배송되었습니다.

A380의 경우 지연이 대부분 CATIA 설계 소프트웨어 버전이 서로 다르고 약간 호환되지 않는 에어 버스의 프랑스 및 독일 단위로 인해 발생했습니다 . 이 비공식적으로 비행기에 맞지 않는 배선 하니스로 나타났습니다.

가장 널리 사용되는 항공기 설계 소프트웨어 인 CATIA에는 문제가 없었지만 누군가 어딘가에서 소프트웨어 구성 공을 떨어 뜨 렸습니다.

Boeing 787은 소프트웨어 관련 지연으로 인해 어려움을 겪었지만 문제의 대부분은 무게 제어 및 공급 업체의 비표준 부품 배송과 같은 기존의 새로운 비행기 문제였습니다.

초기 항공기에 구조적 문제가 발생한 후 A380과 B787 모두 날개 디자인을 수정해야했습니다.

모든 분야에서 인간에게는 대규모의 복잡한 프로젝트가 어렵다.

스카이 스크래퍼 녀석 귀하의 질문에 대답 할 수 있는지 확실하지 않지만 스레드의 다양한 항목에 약간의 빛을 비출 수 있습니다. 건물은 실제로 매우 빠르게 발생합니다. 주요 제약 조건은 로캘 (규제)입니다. 그러나 일반적으로 고층 빌딩은 처음부터 끝까지 3-10 년이 걸립니다.

새 건물을 새 소프트웨어 프로젝트와 비교하는 것은 그리 정확하지 않다고 생각합니다. 새로운 건물은 새로운 버전의 커널 또는 OS에 더 가깝습니다. 이와 관련하여 소프트웨어 개발이 훨씬 빠릅니다. 우리는 클라이언트가 절대로 가입하지 않을 위험이 높은 작업이므로 0부터 빌드하지 않습니다. 건물의 대부분의 설계 및 개발은 입증 된 프로젝트의 파생물입니다.

개인적인 경험으로 10 개 프로젝트 중 하나만 건설되었습니다. 공정은 설계 중심이 아니라 개발 중심이되므로 철강 가격과 같은 것이 전체 프로젝트를 시작하는 순간은 창 밖이거나 설계가 공정의 저렴한 구성 요소이기 때문에 설계되었습니다.

설계팀은 설계도, 설계도 개발까지 2 ~ 6 개월, 설계자, 기획 컨설턴트, 구조 엔지니어, 풍력 엔지니어, 서비스 엔지니어, 수량 및 비용 컨설턴트, 측량사에 의한 세부 사항 및 시공 문서 작성까지 6 개월이 소요됩니다. 접근성 엔지니어와 목록은 계속됩니다 ...

가상 대 물리적의 주장은 그리 정확하지 않습니다. 또한 가상 도구를 주로 사용하며 최종 제품에서 시간과 규모를 모두 원격으로 처리합니다. 대부분의 경우 우리는 모형 규모로 건물의 측면을 테스트조차 할 수 없으며 시뮬레이션을 사용하여 발생할 수있는 일을 예측합니다.

복잡성 측면에서 차이점이 있지만 전체적으로는 거의 같습니다. 우리는 서로 관련이있는 유닛과 여러 레벨의 계층화 된 추상화 및 인터페이스를 가지고있을뿐만 아니라 프로세스의 작은 부분을 매우 전문화하여 의사 소통을 매우 어렵게 만듭니다.

디자인과 개발의 논쟁에 관해서는 두 프로세스가 모두 디자인되었다고 생각합니다. 이러한 것들을 분리하여 유지하는 것은 학문적으로 좋게 들리지만 일이 어떻게 작동하는지 모른다면 디자인 할 수 없습니다. 당신은 단지 실패의 위험을 증가시킵니다.

OP의 질문에 따른 전반적인 (잠재적으로 잘못된) 추정은 프로그래밍이 엔지니어링보다 예술이라는 것입니다. 사람들은 왜 즐거움을 느끼고 심지어 무료로 표현하고 우아함을 표현합니까? 컴퓨터 과학은 또한 공학보다 과학에 가깝습니다. 기존 부품을 함께 패치하는 대신 알고리즘을 증명하려고 노력하고 제대로 작동하도록하는 이유는 무엇입니까? 이것이 의미가 있는지 확실하지 않습니다. 저는 소프트웨어 전문가가 아닙니다.

소프트웨어 디자인 및 개발에있어 한 가지 측면은 매체 자체에 관한 것입니다. 컴퓨터는 인간 중심의 작업을 매우 부 자연스럽게 만듭니다. 모든 것이 매우 명시 적이며 공차가 거의 없습니다. 이 문제를 해결하기 위해 정신적으로 노력하기는 어렵고, 일부는 복잡성을 버림으로써 해결하지 못합니다. 다른 것이 없다면 이것과 관련이 있습니까?

그렇다면 그 디자인은 얼마나 걸립니까? 년? 두? 십 년? 디자인은 무언가를 만드는 가장 복잡한 부분이며, 구성 자체는 쉽습니다.

이 기사를 바탕으로 소프트웨어 개발은 ​​대부분 디자인 문서가 소스 코드 자체 인 디자인 프로세스라는 점을 천천히 이해하고 있습니다. 그리고 디자인 프로세스는 생산 프로세스와 완전히 다릅니다. 경험이 많은 사람이 필요하고 계획을 세우는 것은 불가능합니다. 작은 요구 사항 만 변경해도 프로젝트의 전체 아키텍처가 크게 변경 될 수 있기 때문입니다. 이러한 이해는 풍동에서 비행기 모델을 테스트하는 것처럼 최종 디자인 문서로 코드 품질을 개선하고 디자인 프로세스의 일부로 테스트 및 디버깅을 수행하는 민첩한 방법론 의 기초입니다 .

구성 자체는 컴파일러에 의해 자동으로 처리됩니다. 덕분에 몇 분 만에 전체 제품을 만들 수 있습니다.

소프트웨어 프로젝트가 막대한 지연과 비용으로 완료된 이유는 관리자가 여전히 이러한 설계 프로세스를 예측, 예측 및 계획 할 수 있다고 생각하기 때문입니다. 이것은 실제로 유효한 것보다 더 자주 발생합니다. 그들은 여전히 ​​최종 결과가 비용 증가와 마감 기한과 반대되는 경우에도 사람들을 엄격한 건설 프로세스에 연결함으로써 품질을 향상시킬 수 있다고 생각합니다.

에어 버스 A380을 설계하는 도중에 누군가가 회의에 뛰어 들어 "응급 비행기로 건설 할 수 있을까?"라고 상상해보십시오. 다른 사람들은 "그렇습니다. 예. 비행기. 더 많은 날개가 더 좋습니다." 다음 몇 년 동안 A380 디자인을 트라이 플레인으로 전환하는 데 소비됩니다. 또 다른 회의에서 누군가가 말합니다. "비행기는 늙었습니다. 복엽 비행기를 원합니다. 날개 하나만 제거하십시오."

또는 다리 건설 프로젝트 중간에 누군가가“우리는 해운 회사와 계약을 맺었습니다. 배가 훨씬 더 길기 때문에 다리가 40 피트 더 높아야합니다. 고치십시오. "

크고 작은 소프트웨어 프로젝트가 놀라운 속도로 실패하는 몇 가지 이유가 있습니다.

IT에서 기계 공학을 전공 한 사람으로서 IT 성공률이 낮은 이유에 대해 자주 궁금해했습니다.

이 스레드의 다른 사람들과 마찬가지로, 나는 종종 IT의 미숙함, 세부 표준의 부족 (예, 심각합니다. 간단한 볼트의 표준 시트를 확인한 적이 있습니까?) 및 표준화의 부족으로 인해 실패로 인한 경우가 종종 있습니다. 구성 요소 및 모듈.

건물 건설 또는 조선과 같은 다른 산업들도 훨씬 더 "길을 잃은 경로"를 가지고 있습니다. 특정 솔루션 프로토 타입에 대한 지식과 경험은 맞춤형 형태로 반복해서 재사용됩니다. 크기와 목적이 다른 건물, 선박 또는 비행기가 왜 그렇게 비슷해 보이는지 궁금한 적이 있습니까? (물론 규칙에는 예외가 있습니다 ...)

그 프로토 타입은 잘 연구되고 이해되고 일반적으로 사용되고 입증 된 실적을 가지고 있기 때문입니다. 다른 방법으로는 할 수 없었기 때문이 아닙니다. IT 표준화의 경우는 드물다. (대규모) 프로젝트는 구성 요소를 재발 명하여 연구와 전달을 동시에 같은 사람들 과 함께하는 경향이있다 !

이로 인해 개발 및 서비스 비용이 많이 드는 일회성 제품이 필연적으로 오류가 발생하기 쉽고 불확실한 조건에서 예측할 수없는 방식으로 실패합니다. 그리고 이것 때문에, 물론,이 제품들은 훨씬 더 빨리 쓸모없고, 적어졌으며, 똑같은 비용으로 약간 더 좋은 제품으로 대체되었습니다. IT가 필요로하는 것은 중년 장인을 효율적인 공장으로 바꾸는 산업 혁명과 같습니다.

그러나 IT를 진정으로 독특하게 만드는 요소가 있습니다. 언급 된 다른 산업과 달리 IT는 실제로 어디에나 있습니다. 현대의 모든 측면 에서 사용됩니다 . 따라서 IT 부서가 이처럼 많은 발전을 이뤘으며 그 결과를 달성 할 수 있다는 것은 작은 기적입니다.

나는 당신의 진술에 동의하지 않는 것을 두려워합니다.

에어 버스와 보잉은 비행기를 만드는 회사의 두 가지 예입니다. 비행기를 만드는 회사는 몇 개입니까? 소프트웨어를 구축하는 회사 수와 비교할 경우 매우 적습니다.

소프트웨어 프로젝트를 조이는 것처럼 비행기 프로젝트를 조이는 것도 마찬가지로 쉽습니다. 항공기 산업에서 진입 장벽이 소프트웨어 산업 에서처럼 낮은 경우, 많은 실패한 항공기 프로젝트를 보게 될 것입니다.

차를보십시오; 내구성이 뛰어나고 고급 인 자동차를 생산하는 고품질 제조업체 (Land Rover, Mercedes를 생각)가 있으며 수리하지 않고 1 년 동안 지속되지 않는 자동차를 생산하는 제조업체가 있습니다 (Kia 또는 Cherry). 이것은 진입 장벽이 약간 낮은 업계의 완벽한 예입니다. 더 약한 플레이어를 갖기 시작했습니다.

소프트웨어도 다르지 않습니다. 다른 버그가 많은 제품이있는 반면, Windows, Office, Linux, Chrome 또는 Google 검색은 적시에 제공되어 항공기와 비슷한 품질 수준을 가진 매우 높은 품질의 프로젝트입니다.

많은 사람들이 그리워하는 또 다른 요점은 우리가 삶의 사실로 취하는 자동차, 유조선 또는 항공기를 유지 관리하는 데 얼마나 많은 유지 보수가 필요한지입니다. 모든 비행기는 이륙 전에 기술 점검을 받아야합니다. 몇 k 마일마다 차량을 점검하고 오일 교환, 타이어 교환과 같은 정기적 인 작업을 수행해야합니다.

소프트웨어도 필요합니다. 기계 / 물리적 제품과 마찬가지로 진단, 예방 또는 감사 소프트웨어의 상태 및 품질에 많은 시간을 투자 한 사람이라면 이와 같은 내용은 줄어 듭니다. 시작할 때마다 응용 프로그램의 로그를 읽습니까? 글쎄 .. 비행기라면 ;-)

디지털 빌딩 블록은 1 또는 0 일 수 있습니다. 그 사이에는 없습니다.

기계 설계에는 허용 수준이 있습니다. 완벽한 리벳 하나를 브리지에 넣을 수는 있지만 코드에서 1을 0으로 두는 경우 한 번만 전체 프로그램이 실패 할 수 있습니다.

컴퓨팅의 논리적이고 상호적인 특성으로 인해 아주 작은 변화라도 중대한 실패로 이어질 수 있습니다.

나는 종종 같은 것을 궁금해했다. 그것은 확실히 느낌이 우리가 무슨 일을하는지 어떤 생각이없는 아마추어의 무리 것처럼 (이따금). 관리자 나 다른 외부 요인에 대한 책임을지는 설명을 싫어합니다. 개발자는 우리가 만든 것에 대해 책임을 져야합니다.

나는 우리가 오류가 싼 사업에 있다고 생각 합니다. 패치 소프트웨어는 초고층 건물을 재건하거나 판매 된 모든 휴대폰을 리콜하는 것과 비교하여 저렴합니다.

이것은 버그가 일상 생활의 일부인 문화를 만들어 냈습니다 . 그들은 어깨를 으 with합니다. 일부 버그는 피할 수 없지만 일상적인 작업 을 지배 해야 합니까? QA가 문제가 될만한 가치가 있다고 생각하지 않는 관리자는 정확하게 버그를 예상하기 때문에 완전히 이해합니다. 버그를 수정하는 것이 지루하기 때문에 오류없는 코드를 만들기 위해 모든 노력을 기울이지 않는 프로그래머는 이해할 수 없습니다.

본질적으로 나는 그것이 문화적 문제라고 믿고 그것이 변화하기를 희망한다.

엔지니어링 표준과 실무는 IT 분야 (독립 산업로서)와 항공 우주 분야 에서 매우 다릅니다 . 이것은 항공 우주 분야의 IT 표준 문서를 접할 때 IT 전문가가 어떻게 반응하는지 고려함으로써 가장 쉽게 이해할 수 있습니다 . 예를 들어, 최근 인터넷에 등장한 Joint Strike Fighter C ++ 표준 .

많은 사람들은 격언이나 불쾌한 사직을 표현한다 (우리가 그렇게 할 수 있으면 좋겠다). 많은 사람들이 이런 식으로 소비자 제품을 제공하는 실질적인 방법이 없다고 주장하면서 조롱으로 반응합니다. 소비자가 아니라 경영진의 기대를 감안할 때 이것은 옳을 수도 있습니다. 아무 것도 데모하지 않고 몇 주 동안 코딩하고 코딩하는 코더에게는 많은 불신이 있습니다. 신은 단지 2 주 동안 무언가를 디자인 하는 코더를 도와줍니다 비행기에서는 그렇지 않습니다.

소프트웨어에서 사람들은 실제로 무언가를 기대합니다. 물론, 추론은 실제로 견고하기까지 약간의 시간이 걸릴 것입니다. 그러나 일주일 안에 간단한 용어 로 설명 할 수 있는 복잡한 것을 가질 수 없습니까? 또한 정직하고 복잡한 용어로 묘사 된 복잡한 것들이 상상력을 자극하는 경우는 거의 없다는 것을 배웁니다. 그리하여 많은 엔지니어들이 상상할 수없는 단순한 일들이 창조적 인 방법으로 모여진 상상의 세계에 연루됩니다.

나에게서 몇 가지 물건 :

1 표준 및 부품 : 개발자가 아닌 비행기 제조업체 입니다. 완전히 확신 할 수는 없지만 많은 부분이 아웃소싱되는 것 같습니다. 그들은 자신의 전자 / 악기를 만들지 않고 일부 회사에서 자리를 얻거나 엔진이 다른 곳에서 개발되었을 수 있습니다.

반면에 소프트웨어 프로젝트는 거의 항상 작은 프레임 워크 / 헬퍼만으로 시작합니다.

2-시장 출시 시간 : 비행기에있어 시간은 중요한 문제가 아닙니다. 나는 에어 버스의 디자인이 완성되기 몇 년 전에 마무리되었고, 그 당시에 일어날 수있는 중대한 돌파구를 무시하기로 결정했다. (예를 들어, 현재 개발중인 최첨단 기술은 자동차 제조업체와 동일하게 5-10 년 후에 거리를 칠 것입니다.)

소프트웨어의 경우 지금 매우 큰 프로젝트가 필요하고 지금 큰 프로젝트를 시작하고 아무런 변화없이 개발하는 데 3 년이 걸리면 더 이상 사용할 수없는 기술에 의존하거나 제품이 완전히 구식 일 가능성이 높습니다. 이것은 차례로 많은 문제를 제공합니다.

3- 릴리스주기 및 버전. -비행기는 "해제"되면 완전히 마무리해야합니다. 안정적인 베타 버전, 야간 빌드 또는 이와 유사한 것은 없습니다. 또한 완료되면 작은 방식으로 만 수정할 수 있습니다. 기존 보잉에 100 석의 추가 레벨을 추가 할 수는 없지만 불가능합니다.

반면에 소프트웨어는 종종 "작동하는 빌드"이지만 점진적인 제품 일 필요는없는 점진적인 변경이 있습니다. 또한 IT에서는 "이봐, 비행기에 50 톤을 더 수용 할 수있는 또 다른 수하물 칸을 추가하자"고 말하는 것은 드문 일이 아닙니다.

나는 대답이 매우 간단하다고 생각합니다.

1) 물리적 구성 및 구현은 사람들이있는 한 오랫동안 지속되어 왔으며 물리적 프로젝트를 구현하는 방법과 기술을 개발하는 데 수천 년이 걸렸습니다. 완전히 새로운 기술을 필요로하는 소프트웨어 '구축'은 50 년이 넘지 않았습니다. 아직까지 시간을 충분히 파악하지 못했습니다.

2) 가상 구성이 더 어렵습니다. 물리적 현실이 전혀없는 것을 마음 속으로 '보아야'합니다. 제품의 모양과 제품을 만드는 단계를 알기 전에 많은 정보를 분석하고 추상화해야합니다. 다리나 건물을 지을 때는 그렇지 않습니다.

3) 실제 엔지니어링을 수행 할 때보 다 소프트웨어 오류 또는 버그의 원인을 찾는 것이 훨씬 더 어려운 경우가 많습니다. 대들보가 버클 링되는 경우, 버클 링 위치와 버팀목을 잡고지지하는 지지대 등을 볼 수 있습니다. 소프트웨어 결함을 찾기 위해서는 많은 코드를 검사하고 프로세스를 상호 작용하는 것이 어렵고 시간이 많이 걸리며 물리적 구조와 같은 방식으로 물리와 수학의 법칙.

Jack Ganssle의 내장 된 뮤즈의 기사를 그대로 사용하여 답변을 드리겠습니다. 이것은 어디에서나 펌웨어라고 말하지만 소프트웨어로 정신적으로 교체하십시오.

무엇에 비해?

펌웨어는 우주에서 가장 비싼 것입니다. Lockheed Martin의 전 CEO 인 Norman Augustine은 그의 훌륭한 저서 "Augustine 's Laws"에서 국방 사회가 직면 한 문제에 대한 공개 이야기를 들려줍니다. 고성능 전투기는 연료 범위와 성능 간의 상충되는 요구의 미묘한 균형입니다. 속도 대 무게. 70 년대 후반 전투기는 그 어느 때보 다 무거웠습니다. 항상 더 큰 이윤을 추구하는 계약자들은 그 비용을 많이 추가 할 수있는 어떤 것도 헛되이 보였지만 무게는 아무 것도 없었습니다.

답은 펌웨어입니다. 무한 비용, 제로 질량. 항공 전자는 이제 전투기 비용의 절반 이상을 차지합니다. 최신 미국 전투기 인 F-22의 가격이 팝의 10 억 분의 3에 불과하다는 점을 고려하면 엄청난 변화입니다. 어거스틴은이 이야기와 관련하여 실질적으로 기쁨을 안겨줍니다.

그러나 소프트웨어가 왜 그렇게 비쌉니까? Tom DeMarco는이 질문에 대해 다음 세 단어로 대답했습니다. 그는 상대적으로 지루한 비즈니스 사례에 대해 계속 논의했지만 그 해답은 수년간 내 마음에 울려 퍼졌습니다. 무엇에 비해? 소프트웨어를 사용하여 전례없는 복잡한 제품 동작을 일상적으로 생성합니다. 물론 코드는 비싸다. 그러나 문명의 역사에서 아무도 복잡한 것을 만들어 본 적이 없습니다.

Wikipedia에서 뻔뻔스럽게 들어 올렸고 정확성을 확인하지 않은 다음 거품 정렬을 고려하십시오.

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

공백이 아닌 110 자에 불과하며 한두 시간 안에 던져 질 수 있습니다. 소프트웨어가없고 다른 전략을 사용하여 정렬을 구현해야한다고 가정합니다. 비용은 얼마입니까?

기계 엔지니어는 자신의 직업이 컴퓨터보다 오래 전에 분류기를 구축했다고 자랑 할 것입니다. 코드 스 니펫이 4MHz에서도 관리 할 수있는 것보다 분당 650 개의 카드 처리량을 가진 IBM의 1949 년 모델 82 카드 분류기 ( http://www.columbia.edu/acis/history/sorter.html )를 고려하십시오. Z80. 물론, 모델 (82)은 한 번에 하나의 카드 열만 정렬했다; 데크를 완전히 분류하려면 수십 번의 패스가 필요합니다.

이 짐승을 디자인하고 만드는 데 얼마나 걸렸습니까? 몇 년은 의심의 여지가 없습니다. 그리고 그 기능은 우리 코드와 비교할 때 훨씬 빠르며 거대한 데이터 세트를 처리 할 수 ​​있습니다. 그러나 그것은 1949 년이었습니다. FPGA와 VHDL 또는 CPU가없는 전자 부품으로 버블을 만드는 데 얼마나 걸립니까?

한 시간 동안 칩 레벨 위의 거친 블록 다이어그램을 관리했습니다 (블록의 이름은 "adder", "16 비트 래치"등). 그러나 시퀀싱 논리는 분명히 매우 지저분하므로 적절한 방정식을 작성하기가 너무 어려울 것이라고 가정하고 PLD를 던졌습니다. 그리고 아마도 그것은 프로그래밍 할 수없는 논리 규칙을 어기는 것입니다. 그러나 합리적인 시간에 게이트를 사용하는 모든 논리를 설계하고 디버깅하는 것은 갤런 가스처럼 거의 불가능합니다.

16 비트 워드 및 어드레스를 가정하면, 회로는 약 12 ​​비트 래치, 가산기 등을 필요로한다. 플러스 메모리. 그리고 정렬되지 않은 데이터가 RAM에 어떻게 도착하는지 또는 결과를 내보내는 방법을 모릅니다. 이는 지정되지 않은 설계 요구 사항입니다. 소프트웨어 전용 솔루션은 함수 프로토 타입을 작성하는 것만으로 이러한 요구 사항을 자연스럽게 해결합니다.

대략적인 블록 다이어그램을 회로도로 변환하는 데 하루가 걸릴 수 있습니다. 그런 다음 PCB를 설계 및 생산하고 부품을 주문 및로드하고 예상치 못한 불가피한 수명 문제를 처리하도록 설계를 변경 한 다음 회로를 작동시킬 시간이 있습니다. 우리는 몇 주 동안의 노력과 보드, 부품 및 적절한 테스트 장비를 위해 많은 돈을 이야기 할 수 있습니다.

이 모든 것이 7 줄의 코드를 대체합니다. 실제 임베디드 프로그램이 10,000 개 미만인 경우는 거의 없습니다. 많은 사람들이 백만을 초과합니다. 실제 초대형 컴퓨터 프로그램을 대체하기 위해 얼마나 많은 하드웨어와 엔지니어링이 필요합니까?

스프레드 시트와 같은 실제 프로그램을 고려하십시오. 프로세서없이 회로를 만드는 데 얼마나 많은 회로가 필요합니까? 도시의 크기 일 수 있습니다.

펌웨어는 우주에서 가장 비싸지 만, 해결해야 할 문제의 상상할 수없는 복잡성 때문입니다. 그러나 그것은 다른 대안보다 훨씬 저렴합니다. 따라서 상사가 소프트웨어가 왜 그렇게 오래 걸리는지 물어 보면 무엇을 말해야하는지 알게됩니다. 무엇에 비해?

그래서! 소프트웨어 / 펌웨어는 비교할 수없는 복잡성을 가지고 있습니다.

소프트웨어 엔지니어링 및 관리는 다른 많은 엔지니어링 영역과 근본적으로 다릅니다. 결과물은 물리적이지 않으며 생산 프로세스 는 설계 및 개발 프로세스입니다. 소프트웨어의 다른 사본을 작성하면 한계 비용이 거의 없습니다. 모든 비용은 첫 번째 사본을 개발할 때 발견됩니다.

소프트웨어 엔지니어링 및 관리 분야가 상대적으로 젊기 때문에 소프트웨어 개발 및 엔지니어링을 전체적으로 방해하는 사실로 간주되는 잘못된 정보와 허위 사실이 있습니다 ( 이 참조 참조 ).

모든 개발자가 똑같이 만들어지는 것은 아닙니다. 어떤 사람들은 좋고 다른 사람들은 그렇지 않습니다.

내가 말하는 것을 느끼기 위해 항상 다른 사람들의 코드를 읽으십시오. 너무 많은 추가 논리 문이 위험을 추가 할 수 있습니다. 이러한 위험은 잘못된 행동이나 버그로 이어질 수 있습니다. 논리 문이 충분하지 않으며 이제 널 참조가 있습니다. 좋은 프로그래머는 이것을 이해하고 언제 어디서 무엇을해야하는지 알고 있습니다. 그러나 아무도 완벽하지 않습니다. 상황이 복잡합니다. 잘못 생각한 사람들의 작업을 추가하면 프로젝트가 어떻게 운영되는지 쉽게 알 수 있습니다.

성당은 건축하는 데 최대 100 년이 걸렸습니다.

일부 에어 버스 비행기는 작동하기 위해 백만 줄의 코드가 필요합니다.

무언가를 개선 한 시간이 길수록 더 많은 개선이 이루어 지므로 소프트웨어 업계에 몇 세기에 걸친 시행 착오를 주어 더 나은 결과를 얻을 수 있으며, 버그없이 탄탄한 거대한 프로젝트를 개발하는 데 얼마나 많은 시간이 필요한지 알게 될 것입니다 또는 결함.

대규모 프로젝트는 종종 대규모 조직에서 발생합니다. 대규모 조직에서 일한 적이 없다면 관료주의라는 성과와 생산성을 떨어 뜨릴 수있는 것이 한 가지 있습니다.

놀랍게도 많은 사람들은 관료주의가 무엇인지 (종종 정치와 혼동되는 경우), 심지어 관료주의 문제가있을 때조차도 모릅니다.

우리는 최근 스마트 카드 인증을 구현하는 프로젝트를 마무리했습니다. 원래 3 개월로 추정되었습니다. 15 개월이 걸렸습니다. 지연에 대한 비용, 예산, 범위 또는 기술적 이유가 없었습니다. 범위는 실제로 상당히 좁았습니다. 권한이 높은 계정 (관리자 계정), 총 계정 수는 약 1,200 개입니다.

또 다른 중요한 요소는 비즈니스 파트너입니다. 여기에는 공급 업체가 포함됩니다. 파트너에게 프로젝트 지연을 유발하는 문제가있는 경우 실제로 지연 문제를 해결하는 옵션이 많지 않습니다. 그들은 당신을 위해 직접 작동하지 않으며, 원인 일 수있는 파트너에서 한 사람을 해고하지 못할 수도 있습니다. 파트너가 해고되거나 재정적 처벌이나 불이익을받을 수는 있지만 프로젝트가 지연되었다는 사실은 변하지 않습니다. Boeing이 Boeing 787 Dreamliner 와 함께 맘모스 소싱 전략을 수행했을 때 이런 일이 발생했습니다 .

나는 당신을 위해 더 짧은 버전을 가지고 있습니다 :

쉬운 일이나 능률적 인 일이 무엇이든간에 우리 대신 그것을하는 프로그램을 작성합니다.

그런 다음 대신 메타 프로세스와 싸우십시오.

그 자체로는 그다지 사실은 아니지만 매일 블로그 엔진을 작성하는 대신 수천 개의 블로그가 설정됩니다. 매일 특수하게 설계된 데이터베이스 응용 프로그램을 작성하는 대신 수천 개의 Excel 매크로가 작성됩니다.

여기에 언급 된 몇 가지 다른 요소가 있지만이 점을 토론에 추가하고 싶었습니다.

책임 부족 ... 비행기가 추락하면 사람들이 고소를 당합니다. 소프트웨어 산업은 소프트웨어 결함에 대한 책임을지지 않으므로 강력하고 안전한 제품을 만들려는 인센티브가 부족합니다.

대부분의 대규모 프로젝트는 소수의 디자인 제약 조건을 정의 할 수있는 하위 프로젝트의 분리 가능성이 높습니다. 하위 프로젝트가 각각 완료되면 전체 프로젝트가 작동합니다. 하위 프로젝트에서 문제가 발생하면 모든 노력에 문제가 없습니다. 하위 프로젝트를 완료하는 다른 방법을 찾으십시오 (예 : 다른 엔진 사용).

이것은 소프트웨어 프로젝트에서 가능하지만 실질적으로나 인간 본성의 문제로 어렵습니다.

부분적으로, 다른 산업계에서는 이러한 종류의 분리 성이 좋은 것이라는 어려운 방법을 배웠습니다. 예를 들어 Rolls Royce 항공기 엔진을 사용하려는 경우 특정 디자인의 날개에서만 작동하는 특수 Rolls Royce 볼트 및 부착 점을 사용할 필요가 없으며 Pratt 및 Whitney로 전환하려는 경우, 날개 전체를 처음부터 다시 디자인해야합니다 (동체를 완전히 다시 디자인해야하며, 다른 좌석을 구입해야하며, 다른 기내 엔터테인먼트 시스템을 구입해야합니다. 어느...). 주의를 기울이지 않고 엔진을 교체 할 수는 없지만 몇 가지 연계가있을 수 있지만 큰 프로젝트는 일반적으로 그러한 일이 최소화 될 때 더 잘 작동합니다.

나는 큰 프로젝트가 실제로 작은 프로젝트의 클러스터에 의해 해결되는 한, 서로간에 깨끗한 인터페이스를 가진 작은 소프트웨어 프로젝트의 클러스터로 설계된 큰 소프트웨어 프로젝트는 특히 자주 실패 하지 않을 것이라고 가정 합니다. (이 점에서 실수를 할 수 있습니다.)

소프트웨어 시스템을 구축하는 것은 물리적 구조를 구축하는 것과는 매우 다릅니다. 즉, 구현 이 매우 다릅니다. 예를 들어 거대한 유조선을 만드는 동안 로봇이나 손으로 부품을 용접하고 모든 볼트와 너트를 조이고 페인팅하고 장식을하는 등 비교적 간단한 작업은 쉽지 않습니다. 장비 및 가구 등. 이 모든 것은 정말 간단한 일입니다.

그러나 소프트웨어의 경우 훨씬 더 복잡해 집니다. 예를 들어, 제품의 보안 로그인 및 사용자 신임 정보 저장 부분을 정확히 어떻게 구현합니까? 어떤 라이브러리와 도구를 사용할 수 있습니까? 어떤 라이브러리와 도구에 익숙하십니까? 해싱 + 솔팅 기능을 정확히 작성하는 방법 과 보안을 어떻게 보장합니까? 이렇게 여러 가지 방법으로이 작업을 수행 할 수 있으므로 이러한 종류의 작업에 실제적인 실제 디자인 패턴 을 설정하는 것은 불가능합니다 . 그렇습니다. 위에서 언급 한 디자인 패턴 은 "모범 사례"로서 더 작은 규모로 존재하지만 모든 단일 소프트웨어 시스템은 다른 시스템 시스템과 매우 다르며 현장은 매우 빠른 속도로 발전하고 변경되어 본질적으로 유지하기가 불가능합니다.

집을 지을 때 실제로 주요지지 벽이 부적절하고 교체해야한다는 것을 깨닫는 그런 문제가 발생하지 않으므로 지금까지 진행 상황을 철거하고지지 벽을 다시 시작하여 기지에서 시작해야합니다. . 설계 단계 에서 이러한 문제를 해결 하는 것은 건물에 어떤 종류의지지 벽이 필요한지를 예측하는 것이 상대적으로 간단하기 때문입니다.

그러나 소프트웨어의 경우에는 그렇지 않습니다. 실제로 전체 제품을 단일 엔터티로 디자인 한 다음 구현할 수 없습니다. 소프트웨어 설계 프로세스는 일반적으로 반복되며 제품을 구현하고 테스트함에 따라 목표와 요구 사항이 변경됩니다. 전체적으로 소프트웨어 개발은 반복적으로 진행되는 프로세스 로, 예상치 못한 상황에서 일반적으로 변경되는 경우가 많으며, 이러한 변경으로 인해 더 많은 작업, 복잡성, 불행히도 궁극적으로 더 많은 돈, 시간 및 노력이 요구되는 과제가 발생합니다.

본질적으로, 큰 프로젝트를 전달하고 프로젝트 타임 라인 및 로드맵을 예측하기 어려운 이유는 소프트웨어 개발 및 특히 작업 설계가 매우 복잡한 분야 이기 때문 입니다. 복잡성은 근본 문제입니다.

"큰 프로젝트"의 정의가 왜곡되었습니다.

기술적으로 큰 프로젝트는 정시에 제공 될 수 있으며, 수년에 걸쳐 여러 번 건축 된 것이기 때문에 완벽합니다.

• 팩맨 클론.
• 계산기
• 텍스트 편집기

나는 당신이 생각하고 있다고 확신합니다 ... "그건 작은 프로젝트입니다! 텍스트 편집기는 간단 합니다." 나는 당신과 동의하지 않을 것입니다. 컴퓨터는 엄청나게 복잡합니다. 그냥 설치하고 시간에 어려울 수있는 운영 체제에서 사용자를 설정하고, 당신도하지 않았다 쓰기 OS를, 또는 하드웨어를 구축 할 수 있습니다.

당신이 말하는 프로젝트 는 우주 탐험과 비슷한 거대한 프로젝트입니다. 은하 간 여행을 개발하는 데 걸리는 시간을 어떻게 알 수 있습니까? 우리는 어떤 모델을 기반으로합니까? 알려진 개발, 알려진 미지, 알려지지 않은 미지, 마지막으로 알려지지 않은 미지가 있으며, 이는 소프트웨어 개발에서 많이 발생합니다.

문제는 기대 중 하나라고 생각합니다. 기술이 있다고해서 사용하는 것이 한동안 성공 (또는 현명한 사용)이라는 의미는 아닙니다. 다른 산업이 소프트웨어 산업처럼 행동한다면, 우리는 10 년 말까지 블랙홀 구동 진공 청소기를 판매 할 것입니다. 또는 일부 "비주얼"은 달 기반을 구축 할 수있는 자원을 가지고 있으며 스타 벅스가 방문객들의 경험을 실제로 "반올림"하기로 결정했습니다. 나는 문제가 소프트웨어 산업이라고 생각하지 않는다, 그러나 기대는 위치 에 그것.

언급 할 수 있는 유일한 것은 아니지만 , 하나의 기본 것은 지적 할 가치가 있다고 생각합니다. 대부분의 제품은 기존 동작에 적합합니다. 자동차와 같은 획기적인 돌파구 인 제품조차도 일반적으로 기존의 행동에 적합하도록 만들어졌으며 단순히 간단하고 쉽게 / 저렴하게 / 무엇을하도록 만들었습니다. 네, 자주의 일부 기존의 행동에 부작용 (말에 대한 자동차 대신 음식에 대한 연료를 받고, 예를 들어)뿐만 아니라,하지만 후자의 대부분은 상당히 작은 부작용 경향이있다.

대조적으로, 사용자의 행동을 바꾸지 않는 거의 모든 소프트웨어 (예를 들어, 사용자가 훨씬 쉽게 업무를 수행하도록 함)는 기본적으로 1 일째부터 완전히 실패한 것으로 보장됩니다. 더 큰 소프트웨어 프로젝트는 개별 수준에서 사용자의 행동을 포함하지만 조직 전체에서 큰 그룹의 행동을 포함합니다.

간단히 말해서 소프트웨어 자체를 디자인하는 것이 종종 작업의 가장 쉬운 부분입니다. 어려운 부분은 그들을 위해 사람들의 직업을 재 설계하는 것입니다. 시작하기가 어렵습니다. 작동 할뿐만 아니라 수용 될 수있는 방식으로하는 것도 여전히 훨씬 더 어렵다.

Airbus A380 은 언급 한 바와 같이 성공적인 프로젝트가 아닙니다. 저는 CAD / CAM 회사에서 일을했는데, 회사마다 다른 버전의 소프트웨어를 사용하고 있었기 때문에 몇 년이 지연되었다고 들었습니다. 즉, 세계의 다른 부분에서 다른 부분이 설계되었습니다. 그리고 통합하는 동안 모든 설계가 통합되어 있음을 알게 되었기 때문에 하나의 버전으로 다시 설계해야합니다. 그래서 그것을 보면 나는 그것이 성공했다고 생각하지 않습니다. 2 ~ 3 년 전에 온다면 에어 버스의 게임 체인저 였을 것입니다.

또한 강력한 소프트웨어와 관련하여 비행기, 자동차 (ABS, EPS, 기후 제어 등) 또는 우주 왕복선을 보면 50 % 이상의 소프트웨어가 실행되고 있으며 매우 강력합니다. 단지 우리가 소프트웨어에 더 가깝고 더 많은 소프트웨어 프로그램이 있기 때문에 더 많은 오류가 나타납니다.

http://www.globalprojectstrategy.com/lessons/case.php?id=23을 방문 하여 Airbus A380이 얼마나 성공적인지 확인하십시오.

공학적 배경을 가진 소프트웨어 엔지니어와 건축 분야에서 일하는 아내. 우리는 직업의 차이점에 대해 오랫동안 토론하고 논쟁했습니다.

소프트웨어 엔지니어링은 새로운 것을 디자인하는 것 입니다. 거의 모든 기본 사항은 오픈 소스 라이브러리에서 수행되었습니다. 소프트웨어 엔지니어를 고용하는 거의 모든 직업에서 존재하지 않는 것을 설계해야합니다.

구성 및 대부분의 엔지니어링 형태와 같이 소프트웨어의 '라이브러리'에있는 것은 이미 완전히 설계되었습니다. 타워를 만들고 싶습니까? 몇 가지 수정으로 기존 구조에서 계획을 복사하여 붙여 넣기 만하면됩니다.

사실, 내가 엔지니어가되지 않기로 결정한 주요 이유 중 하나는 기존의 발명품에 대해 10 % 개선을 설계하는 데 대부분의 시간을 소비한다는 것입니다. .

엔지니어링에는 새로운 디자인이 많지 않습니다. 숙련 된 엔지니어는 기존 디자인을 새로운 것으로 조작하거나 개선 할 수있는 사람입니다. 그러나 거의 모든 프로그래머는 디자인을 수정하거나 해킹하거나 새로운 것을 만들어야합니다.

어셈블리 에서 C, C ++, Java, JavaScript, C #, PHP 등 표준이 완전히 얼마나 바뀌 었는지 다시 살펴보십시오 . 10 년에서 20 년 전에 재활용 할 수있는 코드는 많지 않습니다. 이것은 수십 년 전부터 디자인을 계속 개선 할 수있는 자동차 또는 항공 산업과는 매우 다릅니다.

소프트웨어에서 프로젝트 관리는 매우 어렵다 . 시간 추정은 작업을 수행 하는 사람들 이 가장 잘 수행 할 수 있지만, 견적을 작성 하는 데 바쁠 때는 코드를 작성하지 않습니다 . 이것은 사람들이 프로젝트 관리를 전혀 피하도록 유혹합니다.

종종 많은 코드가 특정 사람에 따라 다르며, 이러한 사람들이 늦거나 수행 할 수없는 경우 코드가 진행되지 않습니다. 반대로 자동차를 만들고 싶다면 다른 사람들을 고용하여 타이어, 섀시, 배터리, 엔진 등을 조립할 수 있습니다. 객체 지향 및 기존 프레임 워크가이를 가능하게하지만 모든 것을 처음부터 디자인 할 때는 실용적이지 않을 수 있습니다.

소프트웨어에서 장애가 발생할 수 있습니다 . 테스트 비용이 많이들 수 있습니다. 소프트웨어에서는 충돌을 해결할 수있을 때 모든 테스트를 건너 뛰는 것이 매우 유혹적입니다. 대부분의 엔지니어링 형태에서 '충돌'은 치명적일 수 있습니다.

극단적 인 프로그래밍 (실제로 소프트웨어 메가 프로젝트에서 사용) 과 같은 광범위한 테스트를 사용하는 프로그래밍 방법이 있습니다 . 그러나 마감 시간이 촉박하므로 (의도적으로 더 엄격해질 수 있음) 모든 프로그래밍을 건너 뛰고 버그로 시작하려는 유혹이 있습니다. "항상 모든 버그 수정" 의 Joel Spolsky 스타일은 장기적으로 더 많은 시간을 절약 할 수 있지만, 규율이없는 사람은 이것을 건너 뛰고 실패합니다.

소규모 프로젝트가 더 좋습니다 . 아내는 한때 큰 회사에서 일자리를 구해달라고 요청했습니다. 그것은 대기업이 나쁜 회사라는 주장으로 끝났습니다. 대기업에는 많은 자원, 경험, 기능적 프로젝트 관리 및 올바른 절차가 있습니다. 나에게 큰 회사는 공룡이며, 대부분의 시간은 코드 수정, 테스트 및 문서화에 소비됩니다.

저는 10 명 미만이 백만 달러 규모의 IT 프로젝트를 수행하는 것을 보았습니다. 더 많은 사람들이 프로젝트 속도를 늦추고 불필요한 관료주의를 추가했을 것입니다. WhatsApp 은 수십억 달러에 달하는 '소규모'프로젝트의 예입니다. 큰 프로젝트가 가능하지는 않지만 소프트웨어로 수십억 달러의 가치를 창출하기 위해 수천 명의 사람들이 필요하지 않습니다.

다른 질문에서 실제로 다루지 않은 한 가지 이유는 소프트웨어 분야가 재료 기반 세계에서는 거의 발생하지 않는 속도로 혁신하기 때문입니다.

그 이유 중 하나는 소프트웨어 (프로그래밍 언어, 빌드 도구, IDE)가 소프트웨어 빌드에 사용되기 때문에 소프트웨어 진화가 긍정적 인 피드백주기이기 때문입니다. Ray Kurzweil의 수익 가속화 법칙에 대한 가장 확실한 예 는 기하 급수적으로 증가하는 속도로 진행됩니다. 당신은 하나의 프레임 워크, 프로그래밍 언어, 통신 프로토콜을 마스터하면 그건 이동하는 시간 다음에.

비행기가 소프트웨어처럼 제작 된 경우 다른 모든 모델로 재료를 변경하고 18 개월마다 용량과 속도를 두 배로 늘리고 새로운 모델의 엔진 기술을 방금 발명 한 것으로 교체하고 수영 및 외계인 검색 기능을 추가합니다. 생명.

아, 이상적으로는 음성 명령을 듣고 직장 여행이 끝나면 어두운 방이있는 몰입 형 영화관, 페인트 볼 경기장 및 나이트 클럽으로 두 배가됩니다. 똑같은 것! (영화관, 페인트 볼 및 나이트 클럽 기능을 갖춘 회사가 나온 후 1 년 만에 A에서 B까지 안정적으로 비행기를 만든 회사가 배를 belly 다.)

저에게 소프트웨어 엔지니어링의 주요 문제점은 사용 사례, 사용자 및 교차 플랫폼입니다.

사용 사례

비행기에는 몇 개의 사용 사례가 있습니까? 그것의 대부분은 단지 한 곳에서 다른 곳으로 날아가는 것입니다. 레이더, 교통 통제 등이 더 많을 수도 있지만 사용 사례는 명확하지 않습니다. 소프트웨어 엔지니어링에서는 분명하지 않은 요구 사항과 원하는 것을 모르는 사용자가 직면하고 있습니다. 다른 사용자는 다른 구성 / 흐름이 필요하며 사용자가 원하는대로 비행기를 사용자 정의 할 수 있습니까 (TV와 냉장고를 갖고 싶습니다!)?

사용자

누가 비행기를 운항합니까? 조종사, 부조종사, 일부 청지기 (계산 된 경우) 및 탑 운영자. 그들은 모두 전문가이며 직업 설명이 명확합니다. 소프트웨어는 악의적 인 해커와 크래커는 말할 것도없이 멍청한 놈과 인형이 사용하지만 여전히 다른 모듈 (예 : OpenID 또는 Google 애드 센스 ) 과 통합 할 수 있어야합니다 . 비행기가 미사일이나 닌자 강도로부터 살아남은 상태에서 인형에 의해 운영 될 수 있다면, 비행기는 소프트웨어와 동일한 품질을 가지고 있다고 말할 수 있습니다.

크로스 플랫폼

비행기는 지구의 하늘에서만 비행합니다. 안개 나 바람, 덥고 춥고 습한 기후를 어떻게 처리하는지 잘 모르겠지만 비행기는 다른 중력 수준에서 비행하도록 설계되지 않았습니다 ( 화성으로 비행 할 수 있다면 놀라게됩니다 ). 때때로, 응용 프로그램은 인터넷 익스플로러와 같은 다른 플랫폼, 살아남 아야 구글 크롬 , 파이어 폭스 와 사파리 브라우저 (죄송 오페라 OS 레벨), 또는 Windows XP / 7 / 8, 리눅스. 모바일 장치와 다른 해상도 및 방향은 말할 것도 없습니다.

다른 산업이 사고없이 프로젝트를 완료했다고 생각한다면 1977 년에 지어진 Citigroup Center 건물에 관한 이야기를 읽어야합니다. 거의 7 년의 계획 및 건설 후에도 건물은 심각한 설계 결함으로 완성되어 폭풍 사건은 16 년마다 예상됩니다.

다시 말해서, Citicorp Center가 매년 서서 약 16 분의 1의 확률로 그것이 붕괴 될 가능성이있었습니다.

오리지널 디자이너들은이 문제를 알지 못했지만 운 좋게도 건물을 연구하는 학생에게 붙잡 혔습니다.

LeMessurier가 알려줄 때까지 전화가 도착했습니다. LeMessurier에 따르면, 1978 년에 학부 건축 학생이 LeMessurier의 건물에 대한 대담한 주장을 제기했습니다. Citicorp Center는 바람에 날려 버릴 수 있습니다.

디자인 결함의 비밀을 유지하기 위해 가장 적은 수의 사람들을 포함하여 밤새 문자 그대로 수리했습니다.

건물 주변 10 블록 반경에 대한 비상 대피 계획을 마련했습니다.

그들은 밤새 용접을했고 새벽에 건물 입주자들이 다시 일하는 것처럼 종료했습니다.

이 이야기는 작가 Joe Morgenstern이 파티에서 들었던 이야기를 듣고 LeMessurier와 인터뷰 할 때까지 비밀로 남아있었습니다. Morgenstern은 1995 년에 New Yorker에서 그 이야기를 시작했습니다.

어느 것이 질문을 제기합니다. 프로젝트의 다른 치명적인 디자인 결함이 공개적으로 인정받지 않고 비밀리에 수리 또는 무시 된 경우

• NYC 스카이 스크래퍼 (Slate.com)를 거의 없애 버린 디자인 결함
• 씨티 그룹 센터 (wikipedia.com)