소요 시간 및 프로젝트 성공 및 개발 시간에 미치는 영향

글쓰기에 소요되는 시간이나 요구 사항에 대한 생각이 개발 시간에 영향을 줄 것이라는 증거가 있습니까? Standish (1995)의 연구에 따르면 불완전한 요구 사항 (13.1 %)이 프로젝트 실패에 기여한 것으로 나타났습니다. 요구 사항 분석에 소요 된 시간이 프로젝트의 개발 시간에 영향을 미치거나 프로젝트의 성공 여부에 영향을 미치는 연구 결과가 있습니까?

software-engineering

— 켄 리
소스

애자일 모델은 여기에 어떻게 맞습니까? 요구 시간 (온 / 오프)에 시간을 소비하지만 "단계"라는 요구 사항은 없다고 주장 할 수 있습니다.

— Raphael

@Raphael에 동의하십시오. 우리는 소프트웨어 엔지니어링에 대해 질문을 할 것입니까? 아니면이 시점에서 "컴퓨터 과학"과 "소프트웨어 엔지니어링"을 구분할 가치가없는 사이트의 공식 정책입니까?

— Patrick87

@ Patrick87 이것을 메타 로 옮기자 .

— Raphael

이 질문이 기존 소프트웨어 엔지니어링 및 프로젝트 관리 사이트에 더 적합 할 것 같습니다 .

— Adam Lear

답변:

표 3-1, Steve McConnell의 코드 완성을 참조하십시오. 그는 결함이 소개되고 감지되는 시점을 기준으로 결함을 수정하는 평균 비용을 비교합니다. 시공시 탐지 비용은 소요 시간시 탐지보다 5-10 배, 출시 후 10-100 배 더 비쌉니다.

이 테이블은 다음 소스를 기반으로합니다.

"프로그램 개발시 오류를 줄이기위한 설계 및 코드 검사"(Fagan 1976)
소프트웨어 결함 제거 (Dunn 1984)
"휴즈 항공기의 소프트웨어 프로세스 개선"(Humphrey, Snyder 및 WIllis 1991)

그리고 몇 가지 더

— 조
소스

그것만으로는 충분하지 않습니다. 비싼 실수 할 일이 자주 할 필요가 잡힌 적절한 요구 사항을 오는에 의해 자주. 그렇지 않으면 요구 사항을 충족하는 데 드는 추가 비용이 여전히 실수 비용보다 클 수 있습니다.

— Raphael

사실입니다. 요구 사항을 서두르지 않는 특정 지점까지는 요구 사항에 오류가 적다는 것을 의미한다고 가정해야하지만 너무 많이 들지는 않습니다.

— Joe

예,이 주제에 대한 많은 연구가 있습니다. 물론이 질문은 모든 종류의 소프트웨어 개발 프로젝트에 대답하기에는 너무 일반적이지만 요구 사항 분석을 올바르게 수행하면 구현 단계에 긍정적 인 영향을 줄 것이라는 개념을 뒷받침하는 여러 가지 상황의 증거가 있습니다. 이 증거는 부분적으로 "법률"로 수집되었으며 다음 세 가지 예가 있습니다.

Glass의 법칙 : 요구 사항 부족은 프로젝트 실패의 주요 원인입니다.

이 법은 대규모 소프트웨어 개발 프로젝트의 사례 연구 증거로 뒷받침됩니다. Glass는 실패한 경우에 너무 많은 요구 사항이 있었고, 늦은 변경으로 인해 불안정하고, 모호하고 불완전하다는 것을 발견했습니다.

이는 요구 사항의 질과 프로젝트 결과 사이에 관계가 있음을 시사합니다.

Boehm의 첫 번째 법칙 : 요구 사항 및 설계 활동 중에 오류가 가장 빈번하며 나중에 제거할수록 더 비쌉니다.

이것은 사례 연구 증거에 의해 뒷받침되며 다음과 같은 방식으로 질문에 대답하는 데 기여합니다. 요구 사항을 올바르게 수행하면 시스템의 오류 수가 줄어들고 구현을 시작하기 전에 오류를 수정하는 것이 오류를 찾는 것보다 비용이 적게 듭니다. 구현이 이미 시작된 경우 (또는 시스템이 이미 배송 된 경우) 더 이상 작동하지 않습니다.

Boehm의 두 번째 법칙 : 프로토 타이핑은 특히 사용자 인터페이스의 경우 요구 사항과 설계 오류를 크게 줄입니다.

이것은 학생의 상황에서 통제 된 실험에 의해 뒷받침됩니다. 가능한 해석 중 하나는 요구 사항과 설계 단계가 전적으로 문서 중심적이고 이론적 일 필요는 없다는 것입니다. 대신, 요구 사항 및 설계 단계의 일부로 프로토 타이핑을 수행하면 시간을 소비하고 요구 사항에 대해 생각하는 것이 프로젝트 성공 및 구현 시간에 영향을 미칩니다.

같은 방향을 가리키는 다른 증거도 많이 있습니다. 구현 준비에 시간을 투자하는 것은 위험이 적고 놀라움으로 인해 일정이 초과 될 가능성이 적습니다. 문제는 테스트에 관한 것이 아니지만 적절한 준비는 테스트에도 긍정적 인 영향을 미칩니다.

이 법률에 대한 참조는 다음과 같습니다.

유리 법 : 유리, RL : 소프트웨어 런 어웨이. 대규모 소프트웨어 프로젝트 실패에서 배운 교훈. 뉴저지 북부 새들 리버 : Prentice Hall 1998

Boehm의 첫 번째 법칙 : Boehm, BW, McClean, RK, Urfrig, DB : 대규모 신뢰할 수있는 소프트웨어 설계에 대한 자동화 된 지원에 대한 경험. IEEE Trans on Software Engineering 1, 1 (1975), 125–133

Boehm의 두 번째 법칙 : Boehm, BW, Gray, TE, Seewaldt, T .: 프로토 타이핑 대 지정 : 다중 프로젝트 실험. IEEE 소프트웨어 공학 10, 3 (1984), 290–302

또한 Endres, A. 및 Rombach, D. Software and Systems Engineering의 핸드북을 참조하십시오. 경험적 관찰, 법률 및 이론. 소프트웨어 공학에 관한 프라운호퍼 IESE 시리즈. 애디슨 웨슬리, 2003.

— 파비안 파거 홀름
소스