소프트웨어 개발 작업 평가

Software development effort estimation

소프트웨어 개발에서 노력 평가란 불완전하고 불확실하며 잡음이 많은 입력을 바탕으로 소프트웨어를 개발하거나 유지하는 데 필요한 가장 현실적인 노력(인원 시간 또는 돈으로 표현)을 예측하는 과정입니다.작업량 추정치는 프로젝트 계획, 반복 계획, 예산, 투자 분석, 가격 책정 프로세스 및 입찰 [1][2]라운드에 대한 입력 자료로 사용할 수 있습니다.

최신 기술

평가 실무에 관한 발표된 조사에 따르면 소프트웨어 개발 [3]노력을 추정할 때 전문가 평가가 지배적인 전략임을 알 수 있다.

일반적으로 노력 추정치는 지나치게 낙관적이며 정확성에 대한 자신감이 매우 높습니다.평균 작업 오버런은 약 30%이며 시간이 지남에 따라 감소하지 않는 것으로 보입니다.작업량 추정 오류 조사의 검토는 [4]를 참조하십시오.그러나 추정 오차의 측정에는 문제가 있습니다. 자세한 내용은 추정치의 정확성 평가를 참조하십시오.작업량 추정치의 정확성에 대한 강한 자신감은 소프트웨어 전문가가 평균적으로 최소 최대 간격에 실제 작업을 포함시킬 자신이 90%이거나 "거의 확실"하다면 실제 작업을 포함하는 빈도는 60-70%[5]에 불과하다는 것을 알게 됨으로써 드러납니다.

현재 "노력 견적"이라는 용어는 가장 가능성이 높은 노력 사용(모달값), 50% 이하의 확률에 해당하는 노력(중간값), 계획된 노력, 예산된 노력 또는 고객에게 입찰 또는 가격을 제안하기 위해 사용되는 노력 등 다양한 개념을 나타내기 위해 사용됩니다.통신 문제가 발생할 수 있고 개념이 서로 다른 [6][7]목표에 기여하기 때문에 이는 불행한 것으로 여겨집니다.

역사

소프트웨어 연구자 및 실무자는 적어도 1960년대부터 소프트웨어 개발 프로젝트의 작업 평가 문제에 대처해 왔습니다. 예를 들어 Farr 및 [10]Nelson의 작업을[8][9] 참조하십시오.

대부분의 연구는 공식적인 소프트웨어 작업 평가 모델의 구축에 초점을 맞추고 있습니다.초기 모델은 일반적으로 회귀 분석에 기초하거나 다른 영역의 이론에서 수학적으로 도출되었다.그 이후 사례 기반 추론, 분류 및 회귀 트리, 시뮬레이션, 신경 네트워크, 베이지안 통계, 요건 사양 사전 분석, 유전자 프로그래밍, 선형 프로그래밍, 경제 생산 모델, 소프트 컴퓨팅, 푸와 같은 많은 모델 구축 접근법이 평가되었다.zzy 로직 모델링, 통계 부트스트래핑 및 이러한 두 개 이상의 모델의 조합입니다.오늘날 가장 일반적인 추정 방법은 모수 추정 모델인 COCOMO, SEER-SEM 및 SLIM입니다.1970년대와 1980년대에 수행된 추정 연구에 기반을 두고 있으며, 이후 새로운 교정 데이터로 업데이트되었으며, 마지막 주요 릴리스는 2000년에 COCOMO II이다.기능성 기반 크기 측정(예: 기능점)에 기초한 추정 접근법도 1970년대와 1980년대에 수행된 연구에 기초하지만, 변경된 크기 측정법과 1990년대의 사용 사례[11] 지점이나 객체 지점과 같은 다른 계수 접근법으로 재보정된다.

견적접근법

추정 접근 방식을 분류하는 방법은 여러 가지가 있습니다. 예를 들어,[12][13] 을 참조하십시오.최상위 카테고리는 다음과 같습니다.

  • 전문가의 평가:정량화 단계, 즉 판단 [14]프로세스를 기반으로 견적이 생성되는 단계입니다.
  • 형식 추정 모형:정량화 단계는 기계적 과정(예: 과거 데이터에서 도출된 공식 사용)에 기초한다.
  • 조합 기반 추정:정량화 단계는 서로 다른 출처의 추정치의 판단적, 기계적 조합에 기초한다.

다음은 각 범주 내의 추정 접근법의 예입니다.

견적접근법 카테고리 추정 접근법 구현 지원 사례
유추에 근거한 평가 형식 추정 모형 ANGEL, 가중치 마이크로 기능 포인트
WBS 기반(바텀업) 추정 전문가의 평가 프로젝트 관리 소프트웨어, 기업 고유의 액티비티 템플릿
파라메트릭 모델 형식 추정 모형 COCOMO, SLIM, SEER-SEM, 진정한 소프트웨어 계획
크기 기반 추정[15] 모델 형식 추정 모형 기능 포인트 분석,[16] 유스케이스 분석, 유스케이스 포인트, SSU(소프트웨어 사이즈 유닛), 신속한 변화를 위한 소프트웨어 개발의 스토리 포인트 평가, 오브젝트 포인트
그룹 추정 전문가의 평가 플래닝 포커, 와이드밴드 델파이
기계적 조합 조합기준추정 유추 기반 및 작업 구조 기반 작업[17] 평가의 평균
판단 조합 조합기준추정 파라메트릭 모델 및 그룹 추정치에 기초한 전문가 판단

추정 접근법 선택

다른 추정 접근법과 모델의 추정 정확도 차이에 대한 증거는 "최상의 접근법"이 없으며 다른 접근법이나 모델을 비교한 상대적인 정확도는 [18]상황에 따라 크게 좌우된다는 것을 시사한다.이는 서로 다른 조직이 서로 다른 추정 접근법으로부터 이익을 얻는다는 것을 의미한다.접근방식의[19] 예상 정확도에 기초한 추정 접근방식의 선택을 지원할 수 있는 조사 결과는 다음과 같다.

  • 전문가 추정은 적어도 모델 기반 노력 추정만큼 정확합니다.특히, 관계가 불안정한 상황 및 모형에 포함되지 않은 중요도가 높은 정보는 전문가 추정의 사용을 제안할 수 있다.물론 관련 경험을 가진 전문가가 있다고 가정합니다.
  • 특정 조직의 상황에 맞게 조정되지 않은 공식 추정 모델은 매우 부정확할 수 있습니다.추정 모델의 핵심 관계(예: 공식 모수)가 유사한 프로젝트 맥락에 기초하는지 확신할 수 없는 경우, 자체 과거 데이터의 사용은 결과적으로 중요하다.
  • 공식 추정 모델은 (자신의 과거 데이터를 사용하거나 모델이 유사한 프로젝트와 컨텍스트에서 파생된) 조직의 상황에 맞게 조정되는 상황에서 특히 유용할 수 있으며, 전문가의 추정은 강한 수준의 희망 사항의 대상이 될 수 있습니다.

많은 예측 영역에서 가장 강력한 연구 결과는 다른 접근방식을 적용하는 것이 바람직하며 독립 출처의 추정치 조합이 평균적으로 추정 [19][20][21]정확도를 향상시킨다는 것이다.

소프트웨어 개발 [22]생산성 측정에 있어 각각의 기존 접근 방식의 한계를 인식하는 것이 중요합니다.

또한 접근법의 이해와 결과 전달의 용이성, 접근법의 사용 편의성 및 접근법의 도입 비용과 같은 다른 요소들을 선택 과정에서 고려해야 한다.

추정치의 정확성 평가

평균 추정 정확도에 대한 가장 일반적인 척도는 MMRE(Mean Midge of Relative Error)이며, 각 추정치의 MRE는 다음과 같이 정의됩니다.

MRE = (열심히) - (열심히) /(일단 노력)

이 측정에는 더 대칭적인 측정,[26] 상대 오차 사분위의 가중 평균(WMQ) 및 추정치에서 평균 변동(MVFE)[28]과 같은 몇 가지 대체 측정이 있습니다[24][25].

개별 항목이 치우친 경우 MRE는 신뢰할 수 없습니다.추정 정밀도 측정으로는 PRED(25)가 바람직하다.PRED(25)는 실제 값의 25% 이내에 있는 예측 값의 백분율을 측정합니다.

높은 추정 오차는 자동으로 낮은 추정 능력을 나타내는 지표로 해석될 수 없습니다.경쟁 또는 보완적인 이유로는 프로젝트의 저비용 관리, 개발 작업의 복잡성, 당초 예상보다 더 많은 기능 제공 등이 있습니다.추정 오차 측정의 개선된 사용 및 해석을 위한 프레임워크가 [29]에 포함된다.

심리적 문제

노력 추정의 정확성을 높이기 위해 다루어져야 하는 지나치게 낙관적인 노력 추정의 강한 경향을 잠재적으로 설명하는 많은 심리적 요인이 있다.이러한 요인은 공식 추정 모델을 사용할 때에도 필수적입니다. 왜냐하면 이러한 모델에 대한 입력의 대부분은 판단에 기반하기 때문입니다.중요한 것으로 판명된 요인은 다음과 같습니다.희망사항, 고정, 계획 오류 및 인지 부조화.이러한 요인 및 기타 요인에 대한 논의는 Jörgensen과 Grimstad의 [30]연구에서 찾을 수 있다.

  • 당신이 알고 있는 것을 추정하는 것은 쉽다.
  • 당신이 알고 있는 것을 당신이 모르는 것을 추정하는 것은 어렵다.(알 수 없는 것)
  • 모르는 것을 추정하는 것은 매우 어렵다.(알 수 없는 정보가 표시됨)

유머

개발 노력의 만성적인 과소평가로 인해 아이러니컬하게도 작업을 "프로그래밍의 작은 문제"라고 언급하고 과소평가 관련 법을 인용하는 등 수많은 유머 속담이 유행하고 있습니다.

코드의 처음 90%는 개발 시간의 처음 90%를 차지합니다.나머지 10%의 코드는 개발 [31]시간의 90%를 차지합니다.

--

호프스타터의 법칙:호프스타터의 법칙을 고려하더라도 항상 예상보다 오래 걸립니다.

--

한 명의 프로그래머가 한 달에 할 수 있는 것은 두 명의 프로그래머가 두 달에 할 수 있는 것이다.

--

게다가 개발 작업의 견적은 어려운 일이지만, 자원을 더 할당하는 것이 항상 도움이 되는 것은 아닙니다.

개발 견적 소프트웨어 비교

소프트웨어 예정견적 비용 견적 비용 모델 입력 보고서 출력 형식 지원되는 프로그래밍 언어 플랫폼 비용. 면허증.
AFCA REVIC[33] 네. 네. 리비전 KLOC, 스케일 팩터, 비용 요인 독자 사양, 텍스트 조금도 DOS 공짜 독자 사양
/공중 배포 무료
소프트웨어 선택 네. 네. SEER- SLOC, 기능 포인트, 사용 사례, 상향식, 객체, 기능 독점, Excel, Microsoft Project, IBM Rational, Oracle Crystal Ball 조금도 Windows, Any(웹 기반) 상업의 독자 사양
슬림하다[34] 네. 네. 슬림하다 크기(SLOC, 기능 포인트, 사용 사례 등), 제약사항(크기, 지속시간, 노력, 직원), 스케일 팩터, 이력 프로젝트, 이력 독점, Excel, Microsoft Project, Microsoft PowerPoint, IBM Rational, 텍스트, HTML 조금도 Windows, Any(웹 기반)[35] 상업의 독자 사양
진정한 계획[36] 네. 네. 가격. 컴포넌트, 구조, 액티비티, 비용 드라이버, 프로세스, 기능 소프트웨어 크기(SLOC, 기능 포인트, 유스케이스 변환 포인트(UCP), 예측 객체 포인트(POP) 등) Excel, CAD 조금도 창문들 상업의 독자 사양

「 」를 참조해 주세요.

레퍼런스

  1. ^ "What We do and Don't Know about Software Development Effort Estimation".
  2. ^ "Cost Estimating And Assessment Guide GAO-09-3SP Best Practices for developing and managing Capital Program Costs" (PDF). US Government Accountability Office. 2009.
  3. ^ Jørgensen, M. (2004). "A Review of Studies on Expert Estimation of Software Development Effort". Journal of Systems and Software. 70 (1–2): 37–60. doi:10.1016/S0164-1212(02)00156-5.
  4. ^ Molokken, K. Jorgensen, M. (2003). "A review of software surveys on software effort estimation". 2003 International Symposium on Empirical Software Engineering, 2003. ISESE 2003. Proceedings. pp. 223–230. doi:10.1109/ISESE.2003.1237981. ISBN 978-0-7695-2002-5. S2CID 15471986.{{cite book}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  5. ^ Jørgensen, M. Teigen, K.H. Ribu, K. (2004). "Better sure than safe? Over-confidence in judgement based software development effort prediction intervals". Journal of Systems and Software. 70 (1–2): 79–93. doi:10.1016/S0164-1212(02)00160-7.{{cite journal}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  6. ^ Edwards, J.S. Moores (1994). "A conflict between the use of estimating and planning tools in the management of information systems". European Journal of Information Systems. 3 (2): 139–147. doi:10.1057/ejis.1994.14. S2CID 62582672.
  7. ^ 굿윈, P. (1998년)판매량 예측 강화:실험실 연구의 역할.판단력 있는 예측G. 라이트와 P.굿윈.뉴욕, John Wiley & Sons: 91-112.안녕
  8. ^ Farr, L. Nanus, B. "Factors that affect the cost of computer programming, volume I" (PDF). Archived from the original (PDF) on February 21, 2017.{{cite web}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  9. ^ Farr, L. Nanus, B. "Factors that affect the cost of computer programming, volume II" (PDF). Archived from the original (PDF) on July 28, 2018.{{cite web}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  10. ^ 넬슨, E. A. (1966)컴퓨터 프로그래밍 비용 견적을 위한 관리 핸드북.AD-A648750, Systems Development Corp.
  11. ^ : CS1 maint: 여러 이름: 작성자 목록(링크) ISBN 9783540002345, 9783540362098Anda, B. Angelvik, E. Ribu, K. (2002). "Improving Estimation Practices by Applying Use Case Models". Lecture Notes in Computer Science. 2559: 383–397. CiteSeerX 10.1.1.546.112. doi:10.1007/3-540-36209-6_32. ISBN 978-3-540-00234-5.{{cite journal}}.
  12. ^ Briand, L. C. 및 Wieczorek, I. (2002)소프트웨어 엔지니어링 자원 견적.소프트웨어 엔지니어링 백과사전.J. J. Marcinak.뉴욕, John Wiley & Sons: 1160-1196.
  13. ^ Jørgensen, M. Shepperd, M. "A Systematic Review of Software Development Cost Estimation Studies".{{cite web}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  14. ^ "Custom Software Development Services - Custom App Development - Oxagile".
  15. ^ Hill Peter (ISBSG) - 견적 워크북 2 - International Software Benchmarking Standards Group ISBSG - 견적 및 벤치마킹 리소스 센터 (Wayback Machine에서 2008-08-29년 아카이브 완료)
  16. ^ Morris Pam - Function Point Analysis Total Metrics 개요 - Function Point Resource Center
  17. ^ 스리니바사 고팔과 미낙시 디수자, 2012년.사례 기반 추론 및 결합된 추정 접근법을 사용하여 추정 정확도를 향상시킵니다.제5회 인도 소프트웨어 엔지니어링 컨퍼런스(ISEC '12)의 속행.ACM, 뉴욕, 뉴욕, 미국, 75-78.doi:10.1145/2134.2134267
  18. ^ Shepperd, M. Kadoda, G. (2001). "Comparing software prediction techniques using simulation". IEEE Transactions on Software Engineering. 27 (11): 1014–1022. doi:10.1109/32.965341.{{cite journal}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  19. ^ a b Jørgensen, M. "Estimation of Software Development Work Effort:Evidence on Expert Judgment and Formal Models".
  20. ^ Winkler, R.L. (1989). "Combining forecasts: A philosophical basis and some current issues Manager". International Journal of Forecasting. 5 (4): 605–609. doi:10.1016/0169-2070(89)90018-6.
  21. ^ Blattberg, R.C. Hoch, S.J. (1990). "Database Models and Managerial Intuition: 50% Model + 50% Manager". Management Science. 36 (8): 887–899. doi:10.1287/mnsc.36.8.887. JSTOR 2632364.{{cite journal}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  22. ^ BlueOptima (2019-10-29). "Identifying Reliable, Objective Software Development Metrics".
  23. ^ Shepperd, M. Cartwright, M. Kadoda, G. (2000). "On Building Prediction Systems for Software Engineers". Empirical Software Engineering. 5 (3): 175–182. doi:10.1023/A:1026582314146. S2CID 1293988.{{cite journal}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  24. ^ Kitchenham, B. Pickard, L.M. MacDonell, S.G. Shepperd. "What accuracy statistics really measure".{{cite web}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  25. ^ Foss, T. Stensrud, E. Kitchenham, B. Myrtveit, I. (2003). "A Simulation Study of the Model Evaluation Criterion MMRE". IEEE Transactions on Software Engineering. 29 (11): 985–995. CiteSeerX 10.1.1.101.5792. doi:10.1109/TSE.2003.1245300.{{cite journal}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  26. ^ Miyazaki, Y. Terakado, M. Ozaki, K. Nozaki, H. (1994). "Robust regression for developing software estimation models". Journal of Systems and Software. 27: 3–16. doi:10.1016/0164-1212(94)90110-4.{{cite journal}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  27. ^ Lo, B. Gao, X. "Assessing Software Cost Estimation Models: criteria for accuracy, consistency and regression".{{cite web}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  28. ^ Hughes, R.T. Cunliffe, A. Young-Martos, F. (1998). "Evaluating software development effort model-building techniquesfor application in a real-time telecommunications environment". IEE Proceedings - Software. 145: 29. doi:10.1049/ip-sen:19983370.{{cite journal}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  29. ^ Grimstad, S. Jørgensen, M. (2006). "A Framework for the Analysis of Software Cost Estimation Accuracy".{{cite web}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  30. ^ Jørgensen, M. Grimstad, S. "How to Avoid Impact from Irrelevant and Misleading Information When Estimating Software Development Effort".{{cite web}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  31. ^ Bentley, Jon (1985). "Programming pearls". Communications of the ACM (fee required). 28 (9): 896–901. doi:10.1145/4284.315122. ISSN 0001-0782. S2CID 5832776. {{cite journal}}: format=필요. url=(도움말)
  32. ^ 괴델, 에셔, 바흐: 영원한 황금 땋은 머리.창립 20주년 기념판, 1999년, 페이지 152ISBN 0-465-02656-7.
  33. ^ AFCA Revic 9.2 매뉴얼 Revic 메모리얼 사이트
  34. ^ "SLIM Suite Overview". Qsm.com. Retrieved 2019-08-27.
  35. ^ "SLIM-WebServices". Qsm.com. Retrieved 2019-08-27.
  36. ^ TruePlanning 통합 비용 모델 2015-11-05년에 Wayback Machine에서 아카이브된 PRICE 시스템 사이트