지금까지는 FP, UCP, COCOMO 모델에 의하여 시험노력을 추정하거나, 또는 개발한 수많은 프로젝트 데이터 측정을 통하여 각 단계별 노력 투입 비율에 의거 시험단계에 투입된 시험노력을 추정하였다. 본 연구에서는 소프트웨어 시험노력 추정을 소프트웨어 개발노력 추정과 독립적으로 이루어질 수 있도록 시험노력 추정 모델을 만들고 또 시험노력 추정절차를 제시한다. 모델은 시험노력이 테스트 케이스의 수와 복잡도에 비례하는 특성을 반영하고, 통합시험, 시스템시험, 인수시험 등 시험 태스크를 수행하는 시험 조직의 역량에 영향을 받는 점을 고려하였다. 제시한 시험노력 추정 모델과 절차에 의해 기존의 프로젝트 데이터에 시험에 관련된 추정 데이터를 이용하여 시험노력을 추정한 결과와, 개발계획 수립을 위하여 추정한 개발노력 상에서 배분된 시험노력과 비교하였을 때 4.7% 정도의 오차를 보였다. 시험 조직이 갖는 기술적인 경험, 구축된 시험환경의 정도, 프로젝트의 복잡성과 개발조직의 환경 등을 측정하여 주어진 모델의 조정 계수 값에 반영한다면, 보다 정교한 독자적인 시험노력 추정이 가능하다.
지금까지는 FP, UCP, COCOMO 모델에 의하여 시험노력을 추정하거나, 또는 개발한 수많은 프로젝트 데이터 측정을 통하여 각 단계별 노력 투입 비율에 의거 시험단계에 투입된 시험노력을 추정하였다. 본 연구에서는 소프트웨어 시험노력 추정을 소프트웨어 개발노력 추정과 독립적으로 이루어질 수 있도록 시험노력 추정 모델을 만들고 또 시험노력 추정절차를 제시한다. 모델은 시험노력이 테스트 케이스의 수와 복잡도에 비례하는 특성을 반영하고, 통합시험, 시스템시험, 인수시험 등 시험 태스크를 수행하는 시험 조직의 역량에 영향을 받는 점을 고려하였다. 제시한 시험노력 추정 모델과 절차에 의해 기존의 프로젝트 데이터에 시험에 관련된 추정 데이터를 이용하여 시험노력을 추정한 결과와, 개발계획 수립을 위하여 추정한 개발노력 상에서 배분된 시험노력과 비교하였을 때 4.7% 정도의 오차를 보였다. 시험 조직이 갖는 기술적인 경험, 구축된 시험환경의 정도, 프로젝트의 복잡성과 개발조직의 환경 등을 측정하여 주어진 모델의 조정 계수 값에 반영한다면, 보다 정교한 독자적인 시험노력 추정이 가능하다.
Test effort estimated so far is as a by-product of the development effort estimation activity which is based on the FP, UCP, COCOMO model, or calculated data from the project knowledge base which is containing test effort information for the test phase on software development life cycle. In this pap...
Test effort estimated so far is as a by-product of the development effort estimation activity which is based on the FP, UCP, COCOMO model, or calculated data from the project knowledge base which is containing test effort information for the test phase on software development life cycle. In this paper, test effort estimation model and calculating procedures are suggested, which is independent from software development effort estimation model. Generally test efforts is depends on the number and the complexity of test cases, and also maturity of test organization that performs test activities, such as integration test, system test, acceptance test and so on. The estimated results with the suggested test effort estimation model has deviation of 4.7% compare to the corresponding test efforts generated by the development effort estimationprocedures. The suggesting model will be accurate more and more with refinements of coefficients which reflect the technical and environmental maturity level of test organization, and also including the software complexity level of projects.
Test effort estimated so far is as a by-product of the development effort estimation activity which is based on the FP, UCP, COCOMO model, or calculated data from the project knowledge base which is containing test effort information for the test phase on software development life cycle. In this paper, test effort estimation model and calculating procedures are suggested, which is independent from software development effort estimation model. Generally test efforts is depends on the number and the complexity of test cases, and also maturity of test organization that performs test activities, such as integration test, system test, acceptance test and so on. The estimated results with the suggested test effort estimation model has deviation of 4.7% compare to the corresponding test efforts generated by the development effort estimationprocedures. The suggesting model will be accurate more and more with refinements of coefficients which reflect the technical and environmental maturity level of test organization, and also including the software complexity level of projects.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
제안 방법
ACIC 프로젝트의 분석 결과 제시된 26개의 use case에 대하여 (표 4)과 같이S/M/C등급별 테스트 케이스의 수를 독자적으로 추정하였다. 이러한 추정은 실제 프로젝트가 진행되면서 더 정교한 값으로 반영이 될 수 있지만 초기에는 경험과 이전 프로젝트 자료에 의해 추정이 가능하다.
FP에 의한 시험노력 추정 방식도 경험 데이터를 이용한다. LOC의경우 사용언어와 프로젝트의 복잡성, 난이도의 차이점을 반영할 수 있는 방법을 보정계수를 이용한 반면, FP 방식에서는 입출력 데이터, 입출력 파일, 인터페이스, 질의어의 수 등measuring parameters의 데이터를 분석하여 프로그램의 구현 복잡도를 반영하고, 프로젝트의 기술적인 난이도 14항목에 대하여 5단계 가중치를 반영하여 FP 점수를 산정한다. 산정된 점수에 점수 당 생산성 매트릭을 통하여 개발노력을 산정한다.
참고자료[8]에 제시된 Rational의 UCP 방식은 프로젝트에 구현할 use case를 그 use case에 속한 transaction 수에 의해 단순, 보통, 복잡(S/M/C) 상태로 분류하고, 각 상태의 use case 수 x (상태 별 가중치)에 의해 UUCP(Unadjusted Use Case Point)를 계산한다. UUCP에 기술적인 난이도와 환경적인 난이도를 반영하여 UCP를 산출한다. 즉,
시험점수를 정제하기 위하여 시험 수행 상의 고려사항 즉, 기술적인 복잡도와 시험수행 환경의 수준을 반영하기 위한 TR, ER 점수를 구한다. 구해진 TR, ER 점수는 시험조직의 역량을 반영하는 계수조정 으로 시험점수 TP를 구하는 절차와 함께 연산모델을 제시하였다.
본 논문에서는 프로젝트의 특성을 파악하여 use case를 도출한 다음, use case별 테스트 케이스의 수를 예측한다. 테스트 케이스 별로 시험 난이도가 다른 점을 고려하여 예측된 테스트 케이스를 simple/medium/complex 3등급으로 분류한다.
테스트 케이스 별로 시험 난이도가 다른 점을 고려하여 예측된 테스트 케이스를 simple/medium/complex 3등급으로 분류한다. 분류된 테스트 케이스 등급별 가중치를 반영하여 UTP를 구한다. 시험점수를 정제하기 위하여 시험 수행 상의 고려사항 즉, 기술적인 복잡도와 시험수행 환경의 수준을 반영하기 위한 TR, ER 점수를 구한다.
생산성 매트릭을 이용하여 총 시험노력을 구한다.
시험에 대한 기술적인 복잡성과 환경적인 요소 및 조직의 역량을 UTP에 반영하여 TP를 계산한다.
분류된 테스트 케이스 등급별 가중치를 반영하여 UTP를 구한다. 시험점수를 정제하기 위하여 시험 수행 상의 고려사항 즉, 기술적인 복잡도와 시험수행 환경의 수준을 반영하기 위한 TR, ER 점수를 구한다. 구해진 TR, ER 점수는 시험조직의 역량을 반영하는 계수조정 으로 시험점수 TP를 구하는 절차와 함께 연산모델을 제시하였다.
이KLOC’는 개발에 필요한 실질적인 프로그램의 크기이며, 이KLOC 값을 COCOMO 모델에 적용하여 개발노력을 산정하고, 총 개발노력의50%를 시험노력으로 제시하였다.
본 논문에서는 프로젝트의 특성을 파악하여 use case를 도출한 다음, use case별 테스트 케이스의 수를 예측한다. 테스트 케이스 별로 시험 난이도가 다른 점을 고려하여 예측된 테스트 케이스를 simple/medium/complex 3등급으로 분류한다. 분류된 테스트 케이스 등급별 가중치를 반영하여 UTP를 구한다.
이러한 추정은 실제 프로젝트가 진행되면서 더 정교한 값으로 반영이 될 수 있지만 초기에는 경험과 이전 프로젝트 자료에 의해 추정이 가능하다. 테스트 케이스 수를 추정하기 위하여 프로젝트 개발 노력 추정에 사용한 use case의 수, use case 당 구현노력, use case당transaction의 수를 고려하였으며, 그 결과를 표 4의 5번째 칼럼에 제시되어 있다.
0사이의 값으로 평가할 수 있도록 하였다. 특히 그는 평가자에 의한 각 기준의 평가를 triangular membership value weight 에 의한 퍼지 방식으로 평가를 하고, 평가자들의 평가 결과를 행렬식으로 나타내고 각 행렬식의 항목별로 preference value를 반영한 다음 low, medium, high로 구별되는 영역에서 gravity center를 택해 confidence value C를 구한다. C가 구해지면 수정된 (KLOC’) = KLOC x C를 구한다.
대상 데이터
추정 모델을 검증하기 위하여 참고자료 [1]에서 제시된 ACIC 프로젝트의 Project Knowledge Base(PKB)에 제시된 자료를 활용하였다. 자료에서는 UCP를 이용하여 반복적인 개발방법론을 적용한 사례를 제시하고 있으면서, Waterfall model에 의하여 개발하는 경우와 비교되어 있다.
이론/모형
요구사항을 참조하여 테스트 케이스의 수를 추정한다. 테스트 케이스의 추정은 Delphi 방식을 이용하여 추정하도록 권고한다. 전체적으로 총괄 추정이 어려운 경우에는 Customer Service 또는 Use Case 단위로 추정을 진행한다.
성능/효과
78.54 MD의 test effort가 추정되는데, Infosys에서 추정한 개발노력에서 (표 1)을 통하여 배분된 시험단계(integration test, regression test, acceptance test)에 소요되는 시험노력 추정치 75 MD 와는 3.54MD가 많은 4.7 % 정도의 오차를 보인다. 대체적으로 추정한 값이 실제 투입된 노력 값보다 적은 경향을 보이는 것을 고려한다면4.
본 모델을 이용하여 프로젝트 시험노력을 예측한 결과 실제 투입된 시험노력과 4.7%의 오차를 보였다. 시험 추정 데이터로서 양호한 것으로 판단된다.
시험노력은 테스트 케이스의 수와 테스트 케이스의 난이도에 비례하는 것을 알 수 있으며, 테스트 케이스의 수행은 시간에 비례하여 증가하고, 비용은 지수 함수로 증가한다는 것을 알 수 있었다. 동작시험과 디버깅시험에서 테스트 케이스의 도출 결과가 다를지라도 궁극적으로 시험노력의 최적화는 테스트 케이스의 최적화가 필요하다.
요약하면 소프트웨어의 시험노력이 프로그램의 테스트 케이스의 수에 비례한다는 것과, 시험노력을 단축하기 위한 방법이 동작시험과 디버깅시험으로 나누어, 동작시험에서는 통계적으로 그리고 디버깅시험에서는 논리적으로 존재하는 du-Path를 찾고 축소하는 것이 중요한 것으로 간주하였다.
후속연구
TR, ER을 계산하기 위하여 (표 2)과 (표 3)에 제시한 rate와 weight가 많은 프로젝트를 통하여 좀더 정교하게 조정이 된다면 시험노력 추정도 정교하게 될 것이다. TP 계산절차 4단계에서 제시된 조정계수 α, β, γ, δ는 조직의 특성에 맞추어 경험 데이터로 결정되어야 하는데, Infosys의 UCP 기반의 개발노력 계산에 적용한 값을 고려하여 α, β, γ, δ 값을 0.
앞으로는 어플리케이션의 종류에 따라 구별하여 적용할 수 있는 모델로 발전시키는 것이 필요하다. 자료처리, 온라인 게임, 통신 어플리케이션 등 소프트웨어 종류에 따라 시험의 난이도와 투입노력은 가중치에서 구별이 되어야 한다.
질의응답
핵심어
질문
논문에서 추출한 답변
개발비용 산정을 위한 개발 모델은 무엇이 있는가?
소프트웨어 개발 노력을 추정하는 모델은 많이 제시되었으나, 시험을 예측하는 모델은 독자적으로 존재하지 못하고 개발 모델과 더불어 제시되었다. 개발비용 산정을 위한 개발 모델은 Kilo Line of Code(KLOC). Cost Constructive Model(COCOMO), Function Point(FP), Use Case Point(UCP) 등이 있는데, 이를 통하여 전체 개발 비용을 산출하고, 그 개발 프레임에서 시험이 차지하는 비중을 계산하여 시험노력을 추정하는 방법이다. 따라서 시험노력을 추정하기 위해서는 개발 노력을 먼저 추정하여야 하고, 그 개발 노력에서 시험에 투입될 노력을 추정하는 것이 대부분의 방법이다.
시험방법론의 특징은 무엇인가?
소프트웨어 시험에 관련된 연구는 시험방법론, 품질보 증, 시험노력추정 등과 같은 분야에서 발전이 이루어졌다. 시험방법론은 많은 양의 테스트 케이스를 가능한 축소시켜 시험노력을 줄이면서 소프트웨어의 신뢰도를 보장할 수 있는 방법을 강구하고 있고, 품질보증 분야에서는 어떤 시험방법을 적용하여도 소프트웨어의 에러는 완벽하게 제거가 될 수 없다는 가정하에서 소프트웨어의 신뢰도를 예측하고 에러 제거능력의 범위와 함께 프로그램의 에러 포함 정도를 추적한다. 이러한 분야의 연구는 일단 구현이 된 소프트웨어에 대한 검증 방식의 시도인데 비하여, 시험노력 추정에 대한 연구는 소프트웨어 구현 이전 단계에서 시험활동의 종류와 각 활동 별 투입 노력을 예측하는 것이다.
시험에 투입할 노력의 적정량 산출을 위해 필요한 과정은 무엇인가?
Sherer에 의하면 프로그램의 디버깅시험 비용에 대한 손익추정이 가능한데, 만일 시험 비용과 그에 따라 얻을 이익을 비교하여 손익의 교차점 이전에 시험을 중단할 시점을 결정할 수 있다면, 시험에 투입할 노력의 적정량 산출이 가능하다. 이를 위해서는 (1) 프로그램에 잠재된 오류(faults)를 도출하고, (2) 각각의 오류에 의해 야기되는 경제적인 손실을 평가하고, (3) 예정된 프로그램 운용 기간에 고장(failure)이 발생할 확률에 의해 리스크 R을 계산하는 과정으로 진행된다.
M. H. Halstead, "Elements of Software Science," New York: Elsevier North-Holland, 1977.
H. Halstead, "Toward a Theoretical Basis for Estimating Programming Effort," Writings of the Revolution selected reading on Software Engineering edited by Edward Yourdon, YOUTDON inc., 1982
J. C. Huang, "Software Error Detection through Testing and Analysis," A John Wiley & Sons, Inc., Publication (ISBN 978-0-470-40444-7), 2009.
S.A. Sherer, "A Cost-Effective Approach to Testing," IEEE Software, vol.8, no2, Mar. 1991, pp.34-40.
P. R. Srivastava, "Optimal Software Release Using Time and Cost benefits via Fuzzy Multi-Criteria and Fault Tolerance," Journal of Information Processing Systems, Vol. 8, No. 1, March 2012, pp.21-54 .
Sang-Un Lee, "Sigmoid Curve Model for Software Test-Effort Estimation," Journal D of Korea Information Processing Society, Vol. 11D, No. 4, Aug., 2004, pp.885-892.
Ju-Seok Park, "An Estimating Method for Software Testing Manpower," Journal D of Korea Information Processing Society, Vol. 11D, No. 7, Dec., 2004, pp.1491-1498.
I. Sommerville, "Software Engineering," 8th Ed. Addison-Wesley (ISBN 978-0-321-31379-9), 2007.
E. Choi, "Software Engineering," 5th ed., Jeongiksa, 2011.
B. W. Boehm, "Software Engineering Economics," Prentice Hall, 1981
A. J. Albrecht et. al., "Software Function, Source Line of Code and Development Effort Prediction : A Software Science Validation," IEEE Transaction on Software Engineering, Vol.SE-9, No.6, pp.639-648, 1983
Qu Yi Zhou Bo, et. al., "Early Estimate the Size of Test Suites from Use Cases," 15th Asia-Pacific Software Engineering, IEEE Computer Society, 2008
Daniel Guerreiro e Silva, et. al., "A Simple Approach For Estimation of Execution of Function Test Case," IEEE-International Conference on Software Testing Verification and Validation, 2009
Priya Chaudhary, C.S. Yadav, "An Approach for Calculating the Effort Needed on Testing Projects," International Journal of Advanced Research in Computer & Technology, Vol.1 Issue 1, March 2012
※ AI-Helper는 부적절한 답변을 할 수 있습니다.