프로젝트 종료시 버그를 수정하는 것이 비용이 많이 듭니까?

에서 앤드류 헤이에 의해 블로그 포스트 , 다음과 같은 공리는 단정했다 :

프로젝트가 끝날 때 버그를 수정하는 것보다 프로젝트 초기에 같은 버그를 수정하는 데 비용이 훨씬 많이 듭니다.

그러나 특히 Less Wrong에 대한 블로그 게시물을 읽은 후에는 확실하지 않으며 백업 한 데이터는 매우 오래되었습니다.

이것이 오늘날에도 여전히 공리입니까?

내가 본 유일한 하드 데이터는 Boehm 및 Papaccio, 소프트웨어 비용 이해 및 제어 입니다.

이것은 1988 년으로 거슬러 올라가며 약 80 개의 소프트웨어 프로젝트에 대한 연구였습니다. 그들은 조기에 결정을 내리고 늦게 수정하면 조기에 수정했을 때보 다 50-200 배의 비용이들 수 있다고 결론지었습니다. 그러나 그들이 말하는 매우 초기의 결정은 어떤 OS를 실행할 것인지, 어떤 언어와 데이터베이스를 사용할 것인지입니다.

따라서 이러한 수치는 오늘날의 소프트웨어 개발과 관련하여 과장 될 수 있습니다. 그러나 지금 우리는 현장에서 많은 경험을 가지고 있으며 본능적으로 그것이 여전히 일관된 사실임을 알고 있습니다.

극단적으로, 우리는 생산 직전에 요구 사항의 실패가 잡히면 많은 재 작업을 유발하고 프로젝트가 지연되거나 실제로 취소 될 수 있다는 것을 알고 있습니다. 어떤 작업이 완료되기 전에 잡히면 괜찮 았어요.

편집 : Doc Brown은 그의 의견에서 좋은 지적을합니다.

Boehm의 연구는 컴파일 및 실행 시간이 엄청나게 느린 시간에 COBOL 및 FORTRAN 프로젝트에 대해 수행되었습니다. 나는 90 년대 초에 COBOL에서 경력을 쌓기 시작했으며 컴파일 및 테스트주기는 너무 오래 걸렸기 때문에주기를 거치기 전에 코드를 건조 테스트 (또는 최소한 빌드 단계 동안)했습니다. 무언가를 잡아서 일찍 취소하여 한 시간 정도 절약 할 수 있습니다).

그 전에 우리 상사는 우리의 불만에 대해 비웃었습니다. 오래 전부터 손에 든 펀치 카드 상자를 서버 실에 가지고 가서 하루 동안 방치해야했기 때문입니다.

그래서 지금보다 훨씬 더 사실 이었습니다 .

그러나 최근에는 블로그가 Steve McConnell의 시각화를 재사용 하는 그래프를 보았습니다 ( ref , 날짜 1996)는 그래프가 실제로 하드 숫자를 기반으로 하는 것처럼 보입니다 . 그렇지 않습니다. 그의 요점을 간단히 설명하는 것은 시각화입니다.

OP가 인용 한 기사에서 Morendil의 전제는 좋은 것이라고 생각합니다. 우리가이 주제에 대해 가지고있는 과학은 가난하고 구식이지만 여전히 정경으로 취급됩니다. 그러나 나는 또한 우리가 쓴 경험에서 적어도 어느 정도는 사실이라는 것을 알고 있기 때문에 그것이 잘 견디고 사실이라고 생각합니다. 그리고 그의 극적인 "병에 걸린 징계"문구는 그에게 호의를 베풀지 않는다고 생각합니다.

이 주장을 뒷받침 할 수있는 하드 데이터 나 다른 증거는 알지 못하지만 최소한 상식이라고 생각합니다.

상호 의존적 인 서브 시스템이있는 복잡한 시스템을 사용하는 경우 (대부분의 중요하지 않은 응용 프로그램과 마찬가지로) 시스템 중 하나의 변경으로 인해 발생할 수있는 녹아웃 (knock-on) 문제에 대해 생각하십시오. 서브 시스템이 (단위 테스트 등을 통해) 정확하고 일찍 수정 된 것으로 판명되면, 노크 만으로 인해 발생할 수있는 버그의 수는 간단히 수정함으로써 간단히 완화됩니다.

또한 버그를 조기에 수정하는 경우에도 개발자의 마음에 새 구현이 적용됩니다. 주어진 프로젝트의 길이에 따라, 마지막에 버그를 수정하는 경우 개발자는 작성한 내용과 코드가 의존하는 하위 시스템의 작동 방식을 파악하는 데 시간을 소비해야합니다. 이것을 다시 배우는 데 걸린 시간 = $.

과학적으로 엄격한 방법으로 이것을 측정하는 것이 가능하다는 것은 의심의 여지가 있습니다. 너무 많은 다른 요소가 관련되어 있으며 사례 연구보다 더 많은 프로젝트를 수행할만한 두 프로젝트는 없습니다. 논리적 사고는 먼 길을 가야합니다. 몇 가지 주장 :

• 프로젝트의 총 코드 양은 끝날수록 커지는 경향이 있습니다. 버그 수정을 오래 기다릴수록 터치해야 할 코드베이스가 더 커집니다.
• 프로젝트에 추가 된 새 코드의 품질은 최소한 압력이 가해지면 (종종 주어진 경우) 끝까지 줄어 듭니다. 마감 기한이 다가 오면 사람들이 정시에 배를 타기 위해 모범 사례를 배제 할 수 있습니다. 이것은 나중에 버그를 고칠수록 더 나쁜 코드를 찾아 내야한다는 것을 의미합니다.
• 코드 복제는 일반적으로 찌그러짐에도 불구하고 항상 발생하며, 복사하여 붙여 넣기는 쉽지만 중복 된 코드 섹션을 다시 병합하기는 어렵 기 때문에 한 번 복사하여 붙여 넣은 코드의 양은 일반적으로 계획. 복사하여 붙여 넣은 코드가 많을수록 버그가 복제 될 가능성이 높고 여러 번 찾아서 수정해야 할 가능성이 높습니다 (따라서 일부 발생이 눈에 띄지 않을 가능성이 높음).
• 버그 수정은 코드베이스에 대한 변경입니다. 상황을 개선하기를 희망하지만 변화는 항상 위험을 수반합니다. 수개월이 걸리는 프로젝트에서 심각한 문제를 일으키는 변경은 손상 관리를위한 충분한 여유 공간을 남겨 두어야하지만 배송 이틀 전에 심각한 문제가 발생합니다.
• 버그 자체가 오래 존재할수록 응용 프로그램의 다른 부분이 오작동에 의존하기 시작합니다. 그런 다음 수정하면 함수에서 실제로 문서화 된 올바른 결과를 제공하지 않을 것으로 예상되는 코드에 2 차 버그가 갑자기 발생합니다.

이것은 시스템 엔지니어링에서 기본적으로 받아 들여진 것들이며 모든 형태의 기술 개발 (교량, 미사일, 전함 또는 소프트웨어 구축)에 적용됩니다.

기본적으로 개발 단계를 진행할 때 비용은 약 1 배 증가합니다.

아이디어를 구상 할 때 고치기 위해 10 달러의 비용이 드는 것 ...

사양을 업데이트해야 할 경우 약 $ 100가 소요됩니다 ....

또는 무언가가 구현되어 있고 그 시점에서 변경해야하고 사양을 업데이트하고 승인을받는 등의 작업을 수행해야하는 경우 1000 달러 정도의 비용이 들지만 공식적인 승인 / 판매 테스트를 거치지 않은 경우

또는 무언가가 구현되고 고객이 수락 한 경우 약 $ 10000의 비용이 들며, 그 시점에서 변경해야합니다 (사양을 업데이트하고 승인을 받고 고객 승인 및 자격 등을 다시 테스트하고 다시 실행해야 함).

그리고 배치 / 롤아웃 / 서비스 도입 후의 비용은 훨씬 더 많습니다.

예가 풍부하고 이해하기 쉽다. 25,000 명의 직원을 사용한 후 변경된 범위가 변경되는 뱅킹 시스템은 재교육 시간에 패킷 비용이 들며, 스코핑, 코딩, 테스트, 회귀, 등

분명히 마일리지는 다를 수 있습니다. Fred Nurke의 전자 양말 온난화 전자 상거래 웹 사이트 변경의 비용과 영향은 항공기 비행 제어 컴퓨터의 소프트웨어 변경 비용과 약간 다릅니다.

나는 하드 데이터 나 사실에 접근 할 수 없기 때문에 지난 20 년간 IT에서 얻은 일화적인 관찰 만 제공 할 수 있습니다.

20 년 전과 비교해 오늘날 대부분의 개발자가 소프트웨어를 만드는 방식에는 큰 차이가 있다고 생각합니다. 민첩한 운동이 특히 지난 5-6 년 동안 많은 운동량을 얻음에 따라 직장에서의 태도가 실제로 바뀌는 것을 보았습니다. 우리가하는 일의 질이 매년 도약과 경계에서, 그리고 프로젝트마다 배운 교훈을 적용 할 때마다 모든 프로젝트에서 성장하는 것처럼 보입니다. 테스트 우선 개발에 중점을 둔 Leaner 프로세스는 논란의 여지가 많지 않고 일반화되었습니다. 오늘날 많은 회사에 진출 할 수 있도록 Agile에 익숙하지 않으면 문을 보여주지 않으면 운이 좋을 것입니다.

이것이 어떤 영향을 미쳤습니까? 우선, 문제가 종종 훨씬 빨리 식별되는 것을 알았습니다. 문제가 너무 크지 않은 경우 때때로 무기한으로 보류 될 수 있습니다. 드문 경우이지만, 당시에는 고려되지 않은 근본적인 문제가 명백 해짐에 따라 나중에 해결 될 때 사소한 것으로 생각되는 버그가 심각한 문제가되는 것을 보았습니다. 때때로 이로 인해 수정주기가 단축 될 수 있으며 어느 정도 비용이들 수 있지만, 비용은 종종 자원 조달 측면에서 덜 측정되며,보다 자주 고객과 개발자 간의 관계에 미치는 영향 측면에서 측정됩니다. 고객은이 민첩한 사고 방식에 익숙해 져서 예전보다 훨씬 빠르게 결과를 반환합니다. 매우 반복적 인 개발 스프린트와 요청과 구현 사이의 빠른 처리 시간으로 인해 우리는 많은 것을 기대하게되었습니다. 실제 버그에 관한 한, 버그를 수정하는 데 걸리는 시간은 변경 사항을 지원하는 견고한 테스트 모음과 통찰력과 솔루션을 제공하는 새로운 테스트를 만들 수있는 능력으로 인해 더 자주 줄어 듭니다. 보고 된 문제에.

전체적으로, 강력한 일련의 테스트가 존재하는 경우 버그를 수정하기위한 전체적인 노력이 줄어든 것으로 보이며, 테스트는 개발자가하는 일에 초점을 유지하기위한 절차이지만 실제 비용 어떤면에서는 초점이 순수한 공급과 수요에서 관계 관리로 옮겨 가기 때문에 어떤면에서는 적어도 일부는 구현에서 비즈니스의 다른 영역으로 이동했다.

명백한 또 다른 사실은 몇 년 전 우리의 직감에 따라 민첩한 것이 유지 관리주기를 단축시킬 수 있다는 것이 옳고 그른 것으로 입증되었다는 것입니다. 확실한 테스트 덕분에 코드를 디버깅하고 수정하기가 훨씬 쉬워졌으며, 프로덕션 코드에 공개 된 버그의 수를 줄였으며, 현재 우리가 필요로하는 것을 피하기 위해 더 열심히 노력하고 있다는 점에서 잘못되었습니다. 지속적으로 코드를 리팩토링하고 아키텍처를 개선하여 레거시 코드를 유지함으로써 새로운 제품을 처음부터 완전히 개발해야하는 경우가 점점 더 줄어들고 있습니다.

결국 OP의 질문과 관련하여 이것이 무엇을 의미합니까? 글쎄, 그것은 우리가 한 번 생각했던 것만 큼 답이 건조하고 건조하지 않다는 것을 의미합니다. 15 년 전, 아마 그 질문에 예 라고 대답했을 것입니다하지만 지금은 경험적으로 측정하기가 너무 어렵다고 말하는 것이 더 현실적이라고 생각합니다. 소프트웨어를 개발하기 위해 우리가하는 일의 성격은 당시 OP의 질문을 처음 시작했을 때부터 크게 바뀌었기 때문입니다. 어떤면에서, 기술과 기술을 산업으로 발전시킬수록 문제는 결정적인 예에서 단 몇 년 만에 중요하지 않다고 말할 수있는 시점으로 갈수록 커집니다. 버그를 수정하면 테스트와 프로세스가 훨씬 강력 해져 예산을 절약하려는 노력과 고객의 요구를 충족시키기위한 우선 순위 및 상대적 비용에 따라 버그 수정시기가 단축됩니다. 문맥 상 사실상 무의미 해집니다.

그러나 내가 말했듯이, 이것은 어려운 데이터 지원 증거가 아니며, 지난 몇 년 동안의 관찰 결과이며, 우리의 행동 방식을 개선시킬 더 획기적인 지혜가 올 것이라고 내 직감은 나에게 말합니다.

초기 버그는 시스템의 다른 부분으로 전파되므로 버그를 수정하면 버그 자체에 의존하는 시스템의 일부를 다시 작성해야 할 수 있습니다.

시간이 지남에 따라 프로그램의 일부가 어떻게 구성되는지에 대해 생각하게되고 스스로를 상기시켜야합니다. 기술적 부채의 형태입니다 (프로젝트를 초기 단계로 서두르면 지름길로 인해 완료하는 데 문제가 있습니다).

그것은 그렇게 간단하며 증명할 것이 없습니다.

직원에게 효과적인 솔루션을 제시하기 위해 가능한 한 빨리 프로젝트를 서두르려고한다고 생각합니다. 좋은 소식은 당신이 그것을 매우 빨리 가질 것이라는 것입니다. 나쁜 소식은 가능한 한 빨리 쓰레기를 작성하고 몇 달 안에 모든 것을 고칠 계획이라면 완전히 다시 쓰지 않고는 그것을 끝내지 않을 것입니다. 아마 이것을 리팩토링조차 할 수 없을 것입니다.

글쎄, 아마 당신에게 당신이 요구하는 결정적인 증거를 줄 수는 없지만, 나는 최근의 사건과 관련이 있습니다.

우리는 제품에 워크 플로우 관리 기능을 제공하는 기능을 추가했습니다. 전형적인 BDUF 물건, 고객이 서명하고 승인 한 사양. 사양에 구현되었습니다. 배포 1 일차부터 불만.

우리는 고객과의 실제 사용성 연습을 수행하지 않았으며 원하는 것을 그들의 말로 받아 들였습니다. 결과 : 수백 시간의 재 작업 – 분석, 설계, 구현 및 QA를 다시 수행해야했습니다. 사양에서 특정 사용 사례를 놓 쳤기 때문입니다. 당신이 원한다면 사양의 버그.

체인의 누군가가 최종 사용자 가정과 다른 가정을 할 때 이전 작업에서 비슷한 것을 보았습니다. 일직선 코딩 버그는 발생할 때 가까이 잡히면 다루기가 비교적 쉽지만 디자인 버그는 전체 시스템을 죽일 수 있습니다.

릴리스 후 버그를 수정하면 버그를 찾아서 수정하는 데 비용이 듭니다. 이로 인해 릴리스 후 시간이 오래 걸리거나 그렇지 않을 수 있습니다. 그러나 통합 테스트, 회귀 테스트, UA 테스트, 릴리스 활동 등을 고려해야합니다. 버그 수정이 여러 가지 다른 수정 또는 버전 업데이트와 함께 제공되지 않는 한 초기 릴리스에 수정 사항을 포함하면 피할 수있는 테스트 및 릴리스 활동에 대한 추가 비용이 발생합니다. 수정 / 업데이트 / 기능.

또한 버그가 사용 중에 야기 할 비용을 고려하십시오. 단지 외관상으로는 문제가되지 않지만 기능이나 성능 버그로 인해 지원 활동이나 생산성 저하 또는 잘못된 계산으로 비용이 발생할 수 있습니다.

Intel에게 Pentium Bug의 가격이 얼마인지 물어보십시오. Ariane 5 Rocket이 또 다른 좋은 예입니다. 이 버그는 프로젝트가 끝날 때 수정되었습니다. 소프트웨어 릴리스에서 "시도"의 예산이 6 자리 인 시스템에서 작업했습니다. 이러한 극단적 인 경우 비용을 쉽게 확인할 수 있습니다. 다른 (대부분의 경우), 비용은 소음에 의해 숨겨 지지만 여전히 존재합니다.

버그가 존재하는 동안 비용이 든다는 것은 의심 할 여지가 없습니다. 결함 보고서에 따르면, 하나의 항목 인 Dup을 컴파일하고 심사하고 닫는 데 시간이 걸리므로 시간이 돈이기 때문에 오픈 버그로 인해 지속적인 비용이 발생합니다. 따라서 버그 수정을 연기하면 수정하는 것보다 비용이 더 많이 듭니다.

버그가 야생으로 빠져 나가면 비용이 현명하게 증가합니다 ... 소프트웨어 출시 전후에 "프로젝트의 끝"입니까?

나는 한 번 흥미로운 두 가지 요점을 가진 기사를 읽었습니다 (불행히도 내가 가진 참고 문헌은 오랫동안 사라 졌으므로 여기서는 가정해야합니다). 그들이 한 첫 번째 요점은 모든 오류의 약 50 %가 요구 사항 사양에 도입되었고 UAT 또는 시스템 테스트 중에 발견 된 모든 오류의 약 90 %라는 것이 었습니다.

두 번째 요점은 V 모델의 각 단계마다 비용이 10 배 증가했다는 것입니다. 요인이 올바른지 아닌지 나는 관련성이 없지만 가장 비용이 많이 드는 오류는 설계가 잘못된 가정을 기반으로 할 때 발생합니다. 이로 인해 엄청난 양의 다시 쓰기가 발생합니다. 해당 가정 때문에 작동하지만 올바른 가정이 적용될 때 실패하는 모든 코드를 다시 작성해야합니다.

요구 사항 사양에서 하나의 잘못된 가정으로 인해 전체 도메인 모델을 다시 작성해야했습니다. 이러한 버그가 조기에 발견되면 요구 사양을 검토 할 때 비용이 매우 낮습니다. 이 특별한 경우에는 10 줄의 텍스트가 필요했을 것입니다. UAT 중에 발견 된 경우 (이와 같이) 비용은 상당합니다 (주어진 예에서 프로젝트 비용이 50 % 증가했습니다)

통계 자료는 없지만 개인적인 경험 :

내가 작업했던 로켓 모터 제어 코드는 powerCutoff = someCondition && debugOptions.cutoffIsAllowed; . 기본 옵션은 컷오프가 허용되지 않았습니다. 'final'빌드는 모든 디버그 옵션을 제거해야하므로 행이로 수정되었습니다 powerCutoff = someCondition;.

코드 검토 중에 버그를 발견 했습니까? 우리는하지 않았다. 테스트에서 트리거 조건이 처음 발생한 것은 예상치 못한 컷오프를 초래 한 첫 비행 몇 달 전이었습니다.

이 버그는 검토하는 동안 발견되면 1 시간 미만의 비용이 듭니다. 통합 중에 발견 된 경우 하루나 이틀이 소요되어 단일 테스트 반복이 발생합니다. 공식 인증 과정에서 문제가 발생하면 새로운 빌드로 전체 테스트 시리즈를 다시 시작하여 일주일 또는 2 주가 소요될 수 있습니다.

그대로 비용이 줄었다. 먼저 비행 장치가 조건을 트리거 할 수 있는지 확인하기위한 테스트를 설계하고 실행했습니다. 실제 가능성으로 판단 된 후, 최상의 수정에 대한 엔지니어링, 관리 및 고객 분석, 새로운 빌드 출시, 새로운 회귀 테스트 계획 생성 및 실행, 여러 장치 및 시뮬레이터의 시스템 테스트 비용이 발생했습니다. 전체적으로 수만 시간이 아니라도 수천 달러가 소요됩니다. 실제로 올바른 코드를 변경하려면 원래 15 분이 소요됩니다.

슬프게도, 많은 것들처럼, 그것은 달려 있습니다.

대화 상자 메시지의 철자가 틀리면 수정하기가 쉽지 않습니다 (문자열 업데이트, 재 구축 / 패키지, 재배치). 또는 레이아웃을 업데이트해야하는 경우 .css 파일을 수정하면 충분합니다.

버그가 100 개 이상의 페이지 사양과 증거를 가진 중요한 방법의 출력이 잘못된 경우 조사 자체에 몇 시간 또는 며칠이 걸릴 수 있습니다. 이것은 오래된 'axiom'이 말하는 것이며, 무엇보다도 TDD와 애자일이 피하려고 시도하는 것입니다 (초기 명확하게 실패하고 안전한 점진적 진보를 이루십시오).

단일 프로젝트에서 다중 스크럼 팀에 대한 최근의 경험에서 '버그'는 일반적으로 기능 분기가 안정적으로 승격 될 때 릴리스가 끝날 때만 나타나는 병합 / 통합 문제입니다. 충돌은 종종 팀 간 지원이 필요하기 때문에 팀이 자신의 목표를 완수하기 위해 혼란에 빠지지만 다른 버그보다 비싸다는 것을 알지 못합니다. 릴리스, 그러나 가장 빠른 시간에 그들은 할 수 있습니다. 그것이 최악의 이유입니다.