소프트웨어 테스트 방법론은 결함이있는 데이터에 의존합니까?


45

소프트웨어 엔지니어링에서 버그를 발견 한 개발 후반에 버그 수정 비용이 기하 급수적으로 증가한다는 것은 잘 알려진 사실입니다. 이는 Code Complete에 게시 된 데이터에 의해 지원되며 다른 여러 게시에 적용됩니다.

그러나이 데이터는 존재하지 않는 것으로 나타났습니다 . Code Complete가 인용 한 데이터는 분명히 이러한 비용 / 개발 시간 상관 관계를 보여주지 않으며 유사한 게시 된 표는 일부 특수한 경우에만 상관 관계가 있고 다른 경우에는 평평한 곡선 만 나타 냈습니다 (예 : 비용 증가 없음).

이를 입증하거나 반박 할 독립적 인 데이터가 있습니까?

그리고 만약 사실이라면 (즉, 최근 발견 된 버그에 대해 기하 급수적으로 더 높은 비용을 지원할 데이터가 없다면) 이것이 소프트웨어 개발 방법론에 어떤 영향을 미칩니 까?


대부분의 경우 나중에 버그가 발견되면 데이터가 손상되므로 논리적으로 들립니다. 더구나, 손상된 데이터가 있으면 나중에 버그를 수정하는 과정에서 발견되면 비즈니스 비용이 많이 듭니다.
EL Yusubov

8
@ElYusubov 그것은 실제로 않습니다. 그러나 상식은 매우 기만적 일 수 있습니다 . 우리의 마음은 실제로 다른 방향 일 때 명백한 논리에 의해 쉽게 속입니다. 증거 기반 소프트웨어 엔지니어링이 중요한 이유입니다.
Konrad Rudolph


2
기록 (및 내 대답에 언급 됨)에 대해 내가 찾은 가장 빠른 언급은 Code Complete 이전입니다. 1976 년 Fagan과 Stephenson의 연구는 (내가 독립적으로) 내가 찾을 수있는 가장 빠른 언급이다. Code Complete의 첫 번째 버전은 거의 20 년 후인 1993 년까지 출판되지 않았습니다. 1980 년대 Barry Boehm의 작업으로 인해이 아이디어의 인기가 높아질 것으로 예상됩니다. Boehm의 작업은 1980 년대의 소프트웨어 엔지니어링 프로세스에 영향을 미쳤으며 심지어 2000 년대 후반에도 영향을 미쳤습니다.
토마스 오웬스

1
이것을 포함하여 소프트웨어 엔지니어링 통계에 관한 진술이 잘못되었다는 것은 공리적입니다. (나중에 찾은 버그는 일반적으로 더 복잡한 버그입니다. 그리고 버그를 수정하는 것은 후기에 수정 된 "컨트롤"에 의해 더 복잡합니다.)
Daniel R Hicks

답변:


25

소프트웨어 테스트 방법론은 결함이있는 데이터에 의존합니까?

그렇습니다. 민첩한 변화 비용 곡선을 살펴보면 XP에 대한 Kent Beck의 연구의 일부 (그의 동기 또는 정당화의 일부인지 확실하지 않음)는 " Code Complete 테이블 뒤에있는 지수 곡선. 그렇습니다. 테스트 우선 개발을 대중화하는 데 가장 많이 사용 된 방법론 중 하나 이상에 대한 작업은 적어도 부분적으로 결함이있는 데이터를 기반으로합니다.

이를 입증하거나 반박 할 독립적 인 데이터가 있습니까?

그렇습니다. 여러분이 볼 수있는 다른 데이터가 있습니다. 제가 알고있는 가장 큰 연구는 Hughes Aircraft에서 CMM 평가 프로그램의 일부로 수행 된 결함을 분석하는 것입니다 . 이 보고서는 결함 비용이 단계 따라 어떻게 달라 졌는지를 보여줍니다 . 해당 보고서의 데이터에는 차이가 포함되어 있지 않으므로 너무 많은 "이 것보다 비용이 많이 드는"결론을 도출하는 것에주의해야합니다. 또한 방법론과 상관없이 1980 년대와 오늘날 사이에 이러한 데이터의 관련성을 불러 일으키는 도구와 기술이 변경되었음을 알 수 있습니다.

따라서 우리가 여전히이 숫자를 정당화하는 데 문제가 있다고 가정하면 :

이것이 소프트웨어 개발 방법론에 어떤 영향을 미칩니 까?

우리가 확인할 수없는 숫자에 의존했다는 사실은 사람들이 일화와 경험을 바탕으로 진전을 멈추게하지 않았습니다. 많은 마스터 견습생 거래가 배우는 것과 같은 방법입니다. 나는 중세기의 증거 기반 석조 술 저널이 있다고 생각하지 않지만 , 크고 인상적이고 오래 지속되는 많은 건물이 그럼에도 불구하고 약간의 성공으로 건설되었습니다. 그 의미는 우리가 주로 "나에게 또는 내가 만난 사람들을 위해 일한 것"에 기초하여 우리의 관행을 기초로한다는 것입니다. 나쁜 것은 아니지만 현재 기술 시대의 초석을 제공하는 수백만 명의 사람들을 개선하는 가장 효율적인 방법은 아닙니다.

나는 이른바 공학 분야에서 경험주의의 더 나은 기반을 가지고 있지 않다는 것을 실망스럽게 생각하며, 우리가 우리의 기술과 방법론을 개선하는 데 더 좋고 분명한 진보를 이룰 수 있다고 의심합니다 (확실히 증명할 수는 없지만). 임상 의학이 증거에 기반을 둔 실습에 의해 변화된 것처럼 보이는 기초 그것은 몇 가지 큰 가정을 기반으로합니다.

  • 대부분의 소프트웨어 엔지니어링 실무의 독점적 특성으로 인해 유용하고 관련된 데이터가 충분히 수집되는 것을 막을 수는 없습니다.
  • 이러한 데이터에서 도출 된 결론은 일반적으로 적용 가능합니다 (소프트웨어 엔지니어링은 숙련 된 직종, 경험의 개인적 차이, 능력 및 취향이 그러한 적용 가능성에 영향을 줄 수 있기 때문에);
  • "현장에서"소프트웨어 엔지니어는 이렇게 얻은 결과를 활용할 수 있고 동기를 부여합니다. 과
  • 실제로 어떤 질문을해야하는지 알고 있습니다. 소프트웨어 엔지니어링 개선 에 대해 이야기 할 때 개선 하고자하는 것은 무엇입니까? 측정은 무엇입니까? 측정을 개선하면 실제로 결과가 향상됩니까? 아니면 시스템을 게임합니까? 예를 들어, 회사의 경영진이 실제 프로젝트 비용과 예측 된 프로젝트 비용 간의 비율을 줄이겠다 고 결정했다고 가정합니다. 모든 비용 추정치에 퍼지 계수를 곱하기 시작하면 "목표"를 달성 할 수 있습니다. 그렇다면 모든 추정치를 퍼지하는 것이 표준 산업 관행이되어야합니까?

증거 기반 엔지니어링에 관한 멋진 메타 답변. 감사.
Konrad Rudolph

4
젠장, 나는 이것이 말의 입에서 곧 나온다는 것을 깨달았습니다. 헤헤 대박.
Konrad Rudolph

1
나는 모든 사람들이 "결함이있는 데이터"의 사용을 "완전히 사실이 아니며 반대가 사실"이라고 해석하고 있다는 느낌을 받지만, 당신의 입장이 그것이 사실이 아닐 수도 있다고 지적한다는 느낌을받습니다 . 이 올바른지?
Daniel B

3
@DanielB 맞습니다. 실제로 잘못 되었다는 증거를 보여 주시면 마음이 바뀔 수 있습니다. 그때까지 나는 그것이 명백히 옳지 않다는 것을 안다 .

1
@GrahamLee 나는 당신의 요점을 본다 (구절이 불필요하게 조금 공격적이라고 생각하십시오). 호기심으로, 나는 여기서 Fagan 논문을 발견했으며 , "원점 근처에서 재 작업이 가능합니다 ... 프로세스의 마지막 절반에서 수행되는 것보다 10 ~ 100 배 저렴합니다"라고 말합니다. 그래도이 텍스트 근처에 인용이 보이지 않습니다.
Daniel B

8

제게는 "이것이 소프트웨어 개발 방법론에 어떤 영향을 미치는가"에 대한 대답은 "별로"아닙니다.

개발자 또는 최종 사용자에 의해 잡 히든, 사용자에 의해 잡힌 후 문제를 해결하는 데 더 많은 돈이 걸리든 아니든, 시스템에서 버그가 발견되었다는 사실이 남아 있습니다. 개발자가 발견 하면 빠른 수정이 되길 바랍니다 . 사용자가 발견 한 버그에 대해서도 같은 희망이 있습니다.

최종 사용자가 발견 한 버그를 수정하는 실제 개발자 시간 비용과 상관없이 코더가 자신이하는 일에 빠지는 고정 관념을 유지하는 데 드는 무형 비용이 있습니다. 사용자가 버그를 발견하면 개발자의 잘못입니다. 따라서 최종 사용자가 발견 한 각 버그는 시스템에 대한 사용자의 신뢰를 떨어 뜨립니다. 그것은 당신이 사고 싶은 집을 여행하고 집의 한쪽 구석에 천장을 통해 물 얼룩이 보이는 것을 보는 것과 같습니다. 그것은 그 자체로 쉽게 고칠 수 있지만, 그 원인과 그 근본 원인이 어떤 영향을 미쳤는지 궁금합니다. 마음의 평화는 무엇입니까? 벽을 스터드로 찢어 내고 얼룩이 격리 된 사건으로 인한 것인지 확인하기 위해 모든 것을 육안으로 검사해야 할 수도 있습니다. 그 가능성을 알고 있다고해서 집에 대해 확신을 가지지는 않습니다. 비슷하게,

이러한 무형의 비용은 버그가 빨리 잡히면 피할 수 있는데, 이는 TDD 스타일 방법론의 명시된 목적입니다. 개발자 또는 파트너가 쌍으로 타이핑하는 동안 발견 된 버그, 컴파일시 발견 된 버그 또는 단위 / 통합 테스트 (TDD에 의해 추가 된 계층)에 의해 포착 된 버그는 사용자가 알 필요가없는 버그입니다. 프로젝트 관리자는 결코 사과 할 필요가 없으며 몇 주 후에 남겨둔 시스템의 일부에서 기어를 결함 수정 모드로 전환하기 위해 두 번째로하고있는 일에서 벗어날 필요가 없습니다. 전에, 먼저, 현재 기준 그 시간 직전에 일어난 일.


3
흥미로운 답변. 사용자에게 개발이 반복적 인 프로세스이거나 개선 및 개선이라는 것을 사용자에게 이해 시키려고합니다. 나는 그들에게 무언가를 매우 빨리 줄 수 있고, 그들이 문제를 발견하거나 개선을 원한다면 그 변화를 매우 빠르게 (몇 분 또는 몇 주가 아닌 몇 분 또는 몇 시간) 바꿀 수 있습니다. 시스템은 시간이 지남에 따라 더욱 안정적이되지만 사양 프로세스와 첫 번째 빌드가 아닌 개발 프로세스와 최종 결과에 대한 신뢰로 사라집니다. (물론 당신이 일하는 환경에 달려 있습니다. 나는 비즈니스 응용 프로그램을 작성하고 있으므로 중단되면 고정됩니다.)
커크 브로드 허스트

불행히도, 제품이 필드에있을 때 발견 된 요구 사항 오류가 제품이 필드에있을 때 발견 된 구현 오류보다 비용이 많이 든다는 원래의 증거는 더 나은 검증이 아닌 더 나은 검증의 필요성을 암시합니다. 테스트를 사용하여 요구 사항에 대해 제품을 검증하는 TDD는 이러한 버그를 찾는 것과 관련이 없습니다.
피트 Kirkham

6

나는 내가 찾은 것의 대부분이 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 ConferenceErubycon , 2012 년 QCon San FranciscoO'Reilly Software Architecture Conference 에서 같은 강연을했습니다. 2015 년에 . 나는 론스타 루비 컨퍼런스 (Lone Star Ruby Conference)를 들었으나 그의 아이디어가 구체화되면서 시간이 지남에 따라 대화가 발전했다.

벤더 버그 (Venderburg)는이 모든 과거 데이터가 프로젝트가 단계를 거치지 않아도 시간이 경과함에 따라 결함을 수정하는 비용을 실제로 보여주고 있다고 제안합니다. 앞에서 언급 한 논문과 서적에서 검토 된 많은 프로젝트는 단계와 시간이 함께 이동하는 순차적 "폭포"프로젝트였습니다. 그러나 반복 및 증분 프로젝트에서 유사한 패턴이 나타날 수 있습니다. 결함이 한 번의 반복으로 주입 된 경우 해당 반복을 수정하는 것이 상대적으로 저렴합니다. 그러나 반복이 진행됨에 따라 많은 일이 발생합니다. 소프트웨어가 더욱 복잡해지고 사람들은 특정 모듈이나 코드의 일부에서 작업하는 것에 대한 사소한 세부 사항을 잊어 버립니다. 요구 사항이 변경됩니다. 이 모든 것들이 결함 수정 비용을 증가시킵니다.

아마도 이것이 현실에 더 가깝다고 생각합니다. 워터 폴 프로젝트에서는 업스트림 문제로 인해 수정해야하는 아티팩트 양으로 인해 비용이 증가합니다. 반복 및 증분 프로젝트에서는 소프트웨어의 복잡성이 증가하여 비용이 증가합니다.


@AndresF. 내가 이러한 인용을 추적 할 때 발견 한 문제점 중 하나는 Bossavit가 귀하가 연결 한 책에서 "건초 더미의 바늘"문제라고 묘사 한 것입니다. 책을 인용하는 것은 난독 화입니다. 인용문을 읽을 때 여전히 인쇄본으로되어 있어도 인용 저자의 주장을 뒷받침하는 작은 덩어리를 찾고있는 수백 페이지를 읽을 수 있습니다.

3

단순한 논리입니다.

사양에서 오류가 감지되었습니다.

Case : Error found while reviewing UseCase/Function spec.
Actions:
        Rewrite paragraph in error.

Case : Error found during unit test.
Actions:
        Fix code.
        (Possibly) rewrite paragraph in spec.
        rerun unit test.

Case : Error found in integration test.
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.

Case : Error found in UAT
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.


Case : Error found in production
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        Build release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.
        deploy release to production.

나중에 볼 수 있듯이 오류가 더 많이 감지되면 더 많은 사람들이 더 많은 작업을 다시 수행해야하고 "정상"환경에서 UAT에 도달하면 서류 작업과 관료주의가 기하 급수적으로 증가합니다.

프로덕션 소프트웨어 오류 (판매 손실, 주문 초과, 고객 해킹 등)로 인해 비즈니스에 발생할 수있는 비용을 포함하지 않아도됩니다.

프로덕션에 버그가없는 사소한 시스템을 만든 사람은 아무도 없다고 생각하지만, 일찍 버그를 잡기 위해 할 수있는 일은 무엇이든 장기적으로 시간과 노력을 절약 할 수 있습니다. 사양 검토, 코드 검토, 광범위한 단위 테스트, 다른 코더를 사용한 테스트 작성 등은 모두 버그를 조기에 발견하는 입증 된 방법입니다.


2
여기에는 한 가지 경우 만 해당됩니다. 사양에서 감지 된 오류, 즉 처음에 소개 된 오류. 그러나 모든 개발 단계 (배포 후 버그 수정 포함)에서 오류가 발생할 수 있으며 이러한 오류를 수정 하면 시스템의 작은 부분에 영향을 줄 수 있으므로 훨씬 더 쉽습니다.
Konrad Rudolph

2
그러나 문제는 버그 수정으로 인해 예기치 않은 부작용이 발생할 수 있으므로 수정 사항이 SIT UAT 등을 다시 실행하는 데 붙어있는 특정 하위 구성 요소에만 영향을 줄 수 있음을 절대 보장 할 수 없다면. 변화.
제임스 앤더슨

2
나는 이것이 늦게 발견되었을 때 버그를 수정하는 것이 항상 더 비쌀 것이라는 것을 여전히 확신하지 못한다. 도입 후 시간이 지남에 따라 버그를 수정하는 데 비용이 더 많이 든다고 주장합니다 . 즉, 늦게 소개되고 곧 발견되고 수정 된 버그는 매우 일찍 소개되고 일찍 발견 된 버그보다 저렴하지만 첫 번째 경우보다 더 긴 지연이 있습니다. 적어도 이것이 이것이 어떻게 작동하는지 상상할 수 있습니다.
Konrad Rudolph

@KonradRudolph 좀 더 자세히 설명해 주시겠습니까? 이 게시물은 제 이해이기도합니다. 시간이 중요한 이유는 보이지 않지만 단계는 중요하지 않습니다. 나에게 프로젝트의 시간 측정은 현재 단계이며 때로는 모든 단계를 거치는 타임 박스 반복입니다. 세부 설계의 3 일차와 300 일차에 수행 된 작업의 차이를 보지 못합니다. 세부 설계 작업 제품은 다른 작업 제품을 만드는 데 사용되지 않았으므로 세부 디자인에 주입 된 결함은 한 곳에만 존재합니다. 거기에 변화가 필요합니다. 나는 일의 흐름이 어떻게 중요한지 알지 못한다.
토마스 오웬스

3
@ 토마스 나는 단지 가설입니다. 그러나 도입 된 대부분 의 코드 또는 사양 기능은 시간이 지남에 따라 더 많은 구성 요소에 영향을 미치기 때문에 시간이 중요합니다. 고도로 전문화되어 있지 않고 직접적 또는 간접적으로 다른 어떤 것도 의존하지 않습니다. 따라서 도입 된 단계에 관계없이 오랫동안 존재하는 버그는 잠재적으로 시스템의 많은 부분에 영향을 미치며 제거시 해당 프로세스에서 다른 구성 요소가 손상되지 않도록해야합니다.
Konrad Rudolph

2

저는 이것이 위험 관리와 경제에 관한 것이라고 생각합니다. 향후 결함의 영향에 대한 현재 가치와 결함 수를 줄이는 비용은 얼마입니까? Angry Birds에서 노란 새가 약간 벗어난 궤도는 토마 호크 순항 미사일이 벗어난 궤도와 동일하지 않습니다. 두 프로젝트 중 하나의 소프트웨어 개발자는 해당 테이블을 기반으로 의사 결정을 할 수 없습니다. 이와 관련하여 아무것도 변하지 않습니다.

이것이 효과가 있다고 생각하는 방식은 피드백을 통한 것이며, 현장의 비싼 버그로 인해 회사는 품질 프로세스를 강화하고 현장의 불만은 회사에서 휴식을 취하지 않습니다. 따라서 시간이 지남에 따라 소프트웨어 개발 회사는 자신에게 도움이되는 무언가 (+/-)를 중심으로 수렴하거나 진동하는 경향이 있습니다. Code Complete는 일부 초기 값에 영향을 주거나 회사를 약간 씩 끌어 올릴 수 있습니다. 아무도 알아 채지 못할 결함을 제거하기 위해 너무 많은 노력을 기울이는 회사는 아마도 더 최적화 된 접근 방식을 가진 경쟁 업체와 비즈니스를 잃게 될 것입니다. 한편, 버그가있는 제품을 출시 한 회사도 사업을 중단 할 것입니다.

빠른 검색의 일부 관련 논문 (전체 논문을 읽고, 더 많은 연구를하고 자신의 의견을 구하십시오) :

소프트웨어 품질 비용 연구에 대한 체계적인 문헌 검토 (2011)

"커뮤니티가 연구 영역의 구조에 대한 건전한 이해를 개발하는 동안 경험적 검증은 종종 부족합니다. 분석 된 기사의 3 분의 1만이 사례 연구 또는보다 광범위한 경험적 결과를 제시합니다. 이는 소프트웨어 품질 비용 연구에 불충분 한 것으로 보입니다. 새로운 결과를 도출하기 위해 정량적 데이터에 크게 의존하고있다. 따라서 양질의 비용 데이터를 수집하기위한 새로운 접근 방법뿐만 아니라 이러한 데이터를 이용 가능하게하기 위해 산업과 연구 간의보다 강력한 협력이 필요하다. "

소프트웨어 품질 비용 평가 (1998)

"마지막으로 소프트웨어 적합성 및 부적합 비용을 모니터링하여 소프트웨어 품질의 총 비용을 줄이기 위해 적합성 정책을 조정할 수 있다는 것을 알게되었습니다."

소프트웨어 결함의 비용 행동 (2004)

개요 ... "현재의 연구는 결함과 결함을 수정하는 비용 (또는 수정하지 않은 채로 두는 것)이 소프트웨어의 최종 비용에 영향을 미치는 방식에 대한 우리의 지식을 업데이트하려고 시도합니다. "해결되지 않은 각 단계와 함께"

테스트 범위 및 검증 후 결함 : 여러 사례 연구 (2009)

"또한 우리는 테스트 범위가 테스트 범위와 함께 기하 급수적으로 증가한다는 것을 알지만, 필드 범위의 감소는 테스트 범위와 함께 선형 적으로 증가합니다. 이는 대부분의 프로젝트에서 최적 범위의 범위가 100 %에 미치지 못할 가능성이 높습니다."

소프트웨어 테스트 프로세스와 비즈니스 가치 간 격차 해소 : 사례 연구 (2009)


0

나는 단순히 확인하지 않았기 때문에 질문의 첫 부분에 대답 할 수 없습니다. 그러나 나는 두 번째 질문에 대한 답을 공식화하고 첫 번째 질문에 대한 가능한 대답을 암시 할 수 있습니다.

버그 수정 비용, 개발 툴을 사용하기 어려운 어려운 요소, 제품의 본질적 복잡성 및 사용자가 해당 제품을 얼마나 잘 이해할 수 있는지에 대한 가장 중요한 요소는 말할 것도 없습니다.

코드의 본질적 복잡성을 처리 할 수있는 개발자가 코드를 작성하고 유지 관리한다는 가정하에 코드에 대해 두 번째로 초점을 맞 춥니 다 (전적으로 사실이 아니고 자체 토론이 필요할 수 있음). 유지 보수 및 버그 수정에서 결정적인 중요성은 해당 코드 를 이해 하는 관리자의 능력 입니다.

불행히도 대부분 저조하거나 부적절하게 사용되는 입증 된 소프트웨어 엔지니어링 도구를 사용하면 코드를 이해하는 기능이 크게 향상됩니다. 올바른 수준의 추상화, 모듈화, 모듈 응집력 향상 및 모듈 결합 감소는 올바른 사용이 필요한 복잡성을 극복하는 데 중요한 도구입니다. 인터페이스에 코딩하거나 OOP에서 컴포지션에 대한 상속을 과도하게 사용하지 않고 피처별로 패키징하는 것은 코딩에 불충분 한주의를 기울이는 기술 중 일부입니다.

업계 경쟁의 현실은 소프트웨어 개발에 품질 향상 방법을 고용하는 데 부정적인 영향을 미치며 지속적인 성공의 척도로서 소프트웨어의 본질적인 품질을 낮게 유지합니다.

결과적으로, 업계에서는 소프트웨어가 커질수록 버그 수정 비용이 더 많이 발생하는 경향이 있다고 생각합니다. 이러한 제품에서는 시스템이 커짐에 따라 시스템을 이해하기가 어렵 기 때문에 시간이지나면서 버그를 수정하기가 더 어려워집니다. 각 기능에 의해 도입 된 문제는 다른 문제와 과도하게 결합되어 이해하기 어렵습니다. 또는 올바른 추상화 레벨을 사용하지 않아서 관리자가 시스템의 적절한 모델과 시스템에 대한 이유를 공식화하기 어렵습니다. 문서 부족은 확실히 도움이되지 않습니다.

예외가 있습니다. 나는 훌륭한 개발자들이 지켜야 할 확실한 관행이 없다면 구글이 빠른 속도로 기능하지 않을 것이라고 확신한다. 그리고 다른 사람들도 같은 상황에 처해있을 것입니다. 그러나 대부분의 소프트웨어에 대해 데이터 실제로 Code Complete 의 주장을 확인한 경우 놀라지 않을 것입니다 .


나는 부정적인 평가로도 ​​대답을 기다립니다. 최근에 최고 은행 중 하나의 온라인 뱅킹 도구를 유지 관리하는 후보자를 인터뷰했습니다. 우연한 채팅 중에는 복사 붙여 넣기가 많이 재사용되고 거칠은 구조로 인해 사용하지 말 것을 제안했습니다. 이전에는 Lehman, MS, UBS와 같은 은행을위한 분석 도구를 작성하는 회사의 개발자였으며 ​​도메인 전문가로 활동하여 대부분의 희소 문서에서 else 지점에 배치 할 다음 사항을 찾아야했습니다. 특정 관행에 동의하지 않더라도 전반적인 메시지 : 산업은 사실입니다.
Mihai Danila

-1

또 다른 대답! 이번에는 제목 문제 "소프트웨어 결함이 결함있는 데이터에 의존 하는가?"

실제 답변은 "데이터가 없습니다"입니다. 소프트웨어 프로젝트에 결함이 있거나 시장 출시 성공 등의 신뢰할만한 데이터가 많지 않기 때문에.

이러한 데이터를 수집하려는 모든 시도는 자금 부족, 통계적 결함 또는 특정 프로젝트에 따라 다르므로 일반적인 결론을 도출 할 수 없습니다.

또한 소프트웨어 개발 프로세스가 너무 주관적이고 엄격한 측정을 위해 미끄러 워질 것이라고 생각하지 않습니다. 이러한 데이터 (대형 소프트웨어 하우스 및 시스템 통합 자)를 수집하는 데 가장 적합한 조직은 성능에서 수집 한 수치가 매우 당황 스럽다는 것을 마음에 알고 있습니다.

소프트웨어 프로젝트의 비용과 성공에 대한 수치를 게시하는 유일한 조직
은 정부 부서이며, 그럴 경우에만 그 수치를 파악해야합니다.

결론적으로 모든 소프트웨어 연구는 객관적인 결론을 내릴 실제 데이터가 없기 때문에 순수하게 주관적입니다.


1
아냐, 나는 이것을 사지 않는다. 우선, 거기 이다 당신이 결함의 권리 것을 할 수 있지만 데이터입니다. 그러나 이것은 일반적인 해고가 아닌 각 데이터 세트에 대한 개별적인 비판이 필요합니다. 그리고 나는 데이터가 없을 것이라는 논쟁과“너무 주관적”이라는 이유에 대해 깊이 의심합니다. 그것은 본질적 으로 상상력이 부족하다는 주장입니다 . 여기서 신뢰할 수있는 통계를 수집하는 것은 쉽지 않다고 생각하지만 완전히 실현 가능하다고 주장합니다. 다른 분야에서는 더 복잡한 시스템이 성공적으로 분석되는 방법이 있습니다.
Konrad Rudolph

@Konrad- "결함 수"와 같은 기본적이고 간단한 것을 취하고, 일부 상점은 단위 테스트 실패를 계산하고, 일부 상점은 UAT까지 결함 추적을 시작하지 않으며, 일부 상점은 코드의 결함 만 추적하며, 일부 상점은 문서, 구성 및 결함 추적 프로세스의 배포 스크립트 잘못된 배경색을 갖는 것이 결함으로 간주됩니까? 일부 프로젝트는이를 무시하는 결함으로 추적합니다.
제임스 앤더슨

그것들은 모두 교구 적 문제, 즉 해결할 수있는 문제입니다. 그들은 가능한 것에 근본적인 제약을 두지 않고 해결이 필요한 어려움을 추가합니다.
Konrad Rudolph
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.