나는 내가 찾은 것의 대부분이 1970 년대와 1980 년대 초에 온다는 사실로 이것을 서두를 것이다. 이 시간 동안 순차 프로세스 모델은 반복 및 / 또는 증분 방식 (나선형 모델 또는 민첩한 방법)보다 훨씬 일반적이었습니다. 이 작업의 대부분은 이러한 순차적 모델을 기반으로합니다. 그러나 이것이 관계를 파괴한다고 생각하지는 않지만 반복적 / 증분 방식의 장점 중 하나는 기능 (응용 프로그램의 전체 수직 슬라이스)을 신속하게 릴리스하고 종속성을 주입하기 전에 문제를 해결하고 각 단계의 복잡성을 줄이는 것입니다 높다.
방금 Software Engineering Economics 사본을 꺼내고 4 장에서이 차트 뒤의 데이터에 대한 참조를 찾았습니다. 그는 ME Fagan의 "프로그램 개발 오류를 줄이기위한 설계 및 코드 검사"( IED , UMD의 PDF , EB)를 인용했습니다. Daly의 "소프트웨어 엔지니어링 관리", WE Stephenson의 " ACM (Safeguard System Software Development)에 사용되는 리소스 분석" 및 "여러 TRW 프로젝트".
... 보정 또는 변경 단계의 함수로서 소프트웨어 오류를 수정 (또는 다른 소프트웨어 변경)하는 상대 비용. 계획 및 요구 사항 단계에서 소프트웨어 요구 사항 오류가 감지되고 수정되는 경우 요구 사항 사양을 업데이트하면 비교적 간단하게 수정됩니다. 유지 보수 단계까지 동일한 오류가 수정되지 않으면 수정 사항에는 훨씬 더 큰 사양, 코드, 사용자 및 유지 보수 매뉴얼 및 교육 자료가 포함됩니다.
또한, 늦은 수정에는 훨씬 더 공식적인 변경 승인 및 제어 프로세스와 수정을 재확인하기위한 훨씬 더 광범위한 활동이 포함됩니다. 이러한 요소가 결합되어 요구 사항 단계보다 대형 프로젝트의 유지 보수 단계에서 오류를 수정하는 데 일반적으로 100 배 더 비쌉니다.
보헴은 또한 규모가 작은 두 개의 소규모 프로젝트를 살펴보면서 비용이 증가했지만 대규모 프로젝트에서 확인 된 100 배보다 훨씬 덜 중요하다는 것을 알았습니다. 차트를 보면 요구 사항 단계보다 시스템이 작동 한 후 요구 사항 결함을 수정하기 위해 차이가 4 배 더 큰 것으로 보입니다. 그는 프로젝트를 구성하는 아이템의 재고가 적고 형식이 줄어들어 더 간단한 고정을 더 빨리 구현할 수있게 되었기 때문입니다.
소프트웨어 공학 경제학의 Boehm에 따르면 Code Complete의 표는 다소 부풀어 있습니다 (범위의 하한이 너무 높음). 단계 내에서 변경을 수행하는 비용은 실제로 1입니다. Software Engineering Economics의 그림 4-2에서 추정하면 요구 사항 변경은 아키텍처에서 1.5-2.5 배, 코딩에서 2.5-10 배, 테스트에서 4-20, 4- 100 유지 보수 중입니다. 프로젝트의 규모와 복잡성 및 사용 된 프로세스의 형식에 따라 다릅니다.
Barry Boehm의 부록 E와 Richard Turner의 균형 조정 민첩성 및 규율 에는 변경 비용에 관한 실험 결과가 포함되어 있습니다.
첫 단락은 Beck을 인용하면서 Kent Beck의 Extreme Programming Explained를 인용합니다. 시간이 지남에 따라 변경 비용이 느리게 상승하면 가능한 한 늦게 결정이 내려지고 필요한 것만 구현 될 것이라고 말합니다. 이것을 "플랫 커브"라고하며 익스트림 프로그래밍의 원동력입니다. 그러나, 이전 문헌에서 발견 된 것은 5 : 1의 변화를 갖는 작은 시스템 (<5 KSLOC) 및 100 : 1의 변화를 갖는 큰 시스템을 갖는 "스티프 곡선"이었다.
이 섹션에서는 메릴랜드 대학교의 경험 기반 소프트웨어 엔지니어링 센터 (National Science Foundation 후원)를 인용합니다. 그들은 이용 가능한 문헌을 검색했으며 결과는 100 : 1 비율을 확인하는 경향이 있으며 일부 결과는 70 : 1 ~ 125 : 1 범위를 나타냅니다. 불행히도, 이들은 일반적으로 "큰 디자인 초기"프로젝트였으며 순차적 인 방식으로 관리되었습니다.
Extreme Programming을 사용하여 실행되는 "작은 상업용 Java 프로젝트"샘플이 있습니다. 각 스토리마다 오류 수정, 새로운 디자인 및 리팩토링의 노력이 추적되었습니다. 데이터는 시스템이 개발됨에 따라 (더 많은 사용자 스토리가 구현 됨) 평균 노력이 사소한 비율로 증가하는 경향이 있음을 보여줍니다. 리팩토링 노력은 약 5 % 증가하고 노력 수정 노력은 약 4 % 증가합니다.
내가 배우는 것은 시스템 복잡성이 필요한 노력의 양에 큰 역할을한다는 것입니다. 시스템을 통해 수직 슬라이스를 구축하면 파일을 쌓는 대신 복잡성을 천천히 추가하여 커브 속도를 늦출 수 있습니다. 복잡한 요구 사항, 복잡한 아키텍처, 복잡한 구현 등을 다루는 대신 매우 간단하게 시작하여 추가 할 수 있습니다.
이것이 수정 비용에 어떤 영향을 미칩니 까? 결국, 아마도 많지 않을 것입니다. 그러나 기술 부채 관리를 통해 복잡성을보다 효과적으로 제어 할 수 있다는 장점이 있습니다. 또한, 애자일과 관련이있는 빈번한 결과물은 "시스템"을 전달하는 대신 프로젝트가 더 빨리 종료 될 수 있음을 의미하며, 비즈니스 요구가 충족되거나 새로운 시스템 (및 새 프로젝트)에 비해 크게 변경 될 때까지 결과물이 전달됩니다. 필요합니다.
소프트웨어 품질 엔지니어링 의 Stephen Kan의 지표 및 모델에는 6 단계에서 위상 결함 제거의 비용 효율성에 대한 섹션이 있습니다.
그는 Fagan의 1976 년 논문 (소프트웨어 엔지니어링 경제학에 인용)을 인용하여 높은 수준의 디자인 (시스템 아키텍처), 낮은 수준의 디자인 (상세한 디자인)에서 수행 된 재 작업이 10 ~ 100 배 저렴할 수 있다고 언급했습니다. 구성 요소 및 시스템 레벨 테스트 중에 수행 된 작업보다
또한 1982 년부터 1984 년까지 Freedman과 Weinberg의 대형 시스템에 대한 두 개의 출판물을 인용했습니다. 첫 번째는 "워크 스루, 검사 및 기술 검토 핸드북"이고 두 번째는 "검토, 연습 및 검사"입니다. 개발주기 초기에 검토를 적용하면 테스트 단계에 도달하는 오류 수를 10 배 줄일 수 있습니다. 이러한 결함 수의 감소는 테스트 비용을 50 %에서 80 %까지 줄입니다. 연구를 좀 더 자세히 읽어야하는데 비용에는 결함을 찾아 수정하는 비용도 포함되어 있습니다.
Remus의 1983 년 "검사 / 검토 관점에서 통합 소프트웨어 검증"연구는 캘리포니아의 IBM 산타 테레사 연구소 (Santa Teresa Laboratory)의 데이터를 사용하여 여러 단계, 특히 설계 / 코드 검사, 테스트 및 유지 보수에서 결함을 제거하는 비용을 연구했습니다. 인용 된 결과는 1:20:82의 비용 비율을 나타냅니다. 즉, 설계 또는 코드 검사에서 발견되는 결함의 변경 비용은 1입니다. 동일한 결함이 테스트에서 빠져 나오면 20 배 더 비쌉니다. 사용자에게 완전히 이탈하면 수정 비용이 최대 82 배까지 증가합니다. Kan은 미네소타 주 IBM Rochester의 샘플 데이터를 사용하여 AS / 400 프로젝트의 결함 제거 비용이 유사하다는 것을 발견했습니다. 1:13:92에. 그러나 그는 비용의 증가는 결함을 찾는 데 어려움이 증가했기 때문일 수 있다고 지적했다.
소프트웨어 검사에 대한 Gilb의 1993 ( "소프트웨어 검사" ) 및 1999 ( "소프트웨어 엔지니어링 사양 및 품질 관리 프로세스 최적화") 간행물은 다른 연구를 뒷받침하기 위해 언급되었습니다.
추가 정보는 Construx의 결함 비용 증가 페이지에서 찾을 수 있으며 결함 수리 비용 증가에 대한 여러 참조를 제공합니다. Code Complete의 저자 인 Steve McConnell은 Construx를 설립하고 근무하고 있습니다.
최근에는 2010 년 Lone Star Ruby Conference에서 Glenn Vanderburg가 발표 한 Real Software Engineering의 강연을 들었습니다 . 2011 년 Scottish Ruby Conference 및 Erubycon , 2012 년 QCon San Francisco 및 O'Reilly Software Architecture Conference 에서 같은 강연을했습니다. 2015 년에 . 나는 론스타 루비 컨퍼런스 (Lone Star Ruby Conference)를 들었으나 그의 아이디어가 구체화되면서 시간이 지남에 따라 대화가 발전했다.
벤더 버그 (Venderburg)는이 모든 과거 데이터가 프로젝트가 단계를 거치지 않아도 시간이 경과함에 따라 결함을 수정하는 비용을 실제로 보여주고 있다고 제안합니다. 앞에서 언급 한 논문과 서적에서 검토 된 많은 프로젝트는 단계와 시간이 함께 이동하는 순차적 "폭포"프로젝트였습니다. 그러나 반복 및 증분 프로젝트에서 유사한 패턴이 나타날 수 있습니다. 결함이 한 번의 반복으로 주입 된 경우 해당 반복을 수정하는 것이 상대적으로 저렴합니다. 그러나 반복이 진행됨에 따라 많은 일이 발생합니다. 소프트웨어가 더욱 복잡해지고 사람들은 특정 모듈이나 코드의 일부에서 작업하는 것에 대한 사소한 세부 사항을 잊어 버립니다. 요구 사항이 변경됩니다. 이 모든 것들이 결함 수정 비용을 증가시킵니다.
아마도 이것이 현실에 더 가깝다고 생각합니다. 워터 폴 프로젝트에서는 업스트림 문제로 인해 수정해야하는 아티팩트 양으로 인해 비용이 증가합니다. 반복 및 증분 프로젝트에서는 소프트웨어의 복잡성이 증가하여 비용이 증가합니다.