소프트웨어 개발 프로젝트는 성공률이 30% 밖에 되지 않는 어려운 과제이다. 소프트웨어 개발 프로젝트가 실패하는 이유는 여러 가지가 있을 수 있으나, 체계적인 관리 소홀이 큰 비중을 차지하고 있다. 특히, 완성도가 떨어지는 산출물을 다음 단계로 진행시키는 것은 많은 시간과 노력을 허비하여 프로젝트를 실패로 이끌 수 있다. 이를 방지하기 위해 채택되고 있는 방식은 동료 검토(Peer Review) 또는 인스펙션(Inspection) 등과 같은 산출물들에 대한 검토활동이다. 문제가 발견된 산출물들은 다시 개발자에게 돌아가서 수정하게 되는데, 이 과정을 재작업 (Rework)이라고 한다. 프로젝트 관리자가 완성도가 떨어지는 산출물들을 다음 단계로 넘겨서 오류에 대한 막대한 비용을 지출하고 기간을 지연시키는 등의 사고를 막기 위하여, 본 연구에서는 재작업의 충실도를 높일 수 있는 방법을 연구하였다. 즉 프로젝트의 재작업 시에 작업분석을 시행함으로써 재작업된 결과의 검토 수준을 달리하는 재작업지표를 개발하였고, 이에 대한 검증을 위해 4개의 프로젝트를 선택하여 개발된 지표의 적용 여부를 관찰하고 그 효율성을 입증하였다.
소프트웨어 개발 프로젝트는 성공률이 30% 밖에 되지 않는 어려운 과제이다. 소프트웨어 개발 프로젝트가 실패하는 이유는 여러 가지가 있을 수 있으나, 체계적인 관리 소홀이 큰 비중을 차지하고 있다. 특히, 완성도가 떨어지는 산출물을 다음 단계로 진행시키는 것은 많은 시간과 노력을 허비하여 프로젝트를 실패로 이끌 수 있다. 이를 방지하기 위해 채택되고 있는 방식은 동료 검토(Peer Review) 또는 인스펙션(Inspection) 등과 같은 산출물들에 대한 검토활동이다. 문제가 발견된 산출물들은 다시 개발자에게 돌아가서 수정하게 되는데, 이 과정을 재작업 (Rework)이라고 한다. 프로젝트 관리자가 완성도가 떨어지는 산출물들을 다음 단계로 넘겨서 오류에 대한 막대한 비용을 지출하고 기간을 지연시키는 등의 사고를 막기 위하여, 본 연구에서는 재작업의 충실도를 높일 수 있는 방법을 연구하였다. 즉 프로젝트의 재작업 시에 작업분석을 시행함으로써 재작업된 결과의 검토 수준을 달리하는 재작업지표를 개발하였고, 이에 대한 검증을 위해 4개의 프로젝트를 선택하여 개발된 지표의 적용 여부를 관찰하고 그 효율성을 입증하였다.
It is reported that the success ratio of software development projects has been only 30%. Many causes lower project's chance of success, particularly lack of systematic project management. Especially, moving on the next phase of project with unsatisfactory outputs can be very problematic because it ...
It is reported that the success ratio of software development projects has been only 30%. Many causes lower project's chance of success, particularly lack of systematic project management. Especially, moving on the next phase of project with unsatisfactory outputs can be very problematic because it can cause much waste of resource, time and even lead to the failure of the whole project. Peer review and inspection are some of the practices designed to prevent such waste and possible failure. When defects are identified through such progress, each developer has to work on the product component again and fix the problem. This process is called rework. In this paper, we propose a method for improving quality of reworked product component to prevent excessive cost and time consumed caused by moving on the next phase of a project with a problematic product component. More specifically, this paper suggests a rework indicator that measures the level of rework based on its complexity and severity and is used to choose appropriate checking method on reworked product component. The research also confirmed the method's usefulness and effectiveness by applying the suggested method on four projects.
It is reported that the success ratio of software development projects has been only 30%. Many causes lower project's chance of success, particularly lack of systematic project management. Especially, moving on the next phase of project with unsatisfactory outputs can be very problematic because it can cause much waste of resource, time and even lead to the failure of the whole project. Peer review and inspection are some of the practices designed to prevent such waste and possible failure. When defects are identified through such progress, each developer has to work on the product component again and fix the problem. This process is called rework. In this paper, we propose a method for improving quality of reworked product component to prevent excessive cost and time consumed caused by moving on the next phase of a project with a problematic product component. More specifically, this paper suggests a rework indicator that measures the level of rework based on its complexity and severity and is used to choose appropriate checking method on reworked product component. The research also confirmed the method's usefulness and effectiveness by applying the suggested method on four projects.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
따라서 본 연구에서는 재작업 지표를 개발하여 재작업 된 산출물을 분석하고 이에 대한 검토 수준을 달리하여 재작업 활동의 완성도를 높이는 프로세스를 개발하였다.
실정이다. 따라서 본 연구에서는 프로젝트 통제 및 제어를 위한 활동 및 메트릭에 대하여 연구하고 재작업 지표를 개발하였다. 재작업 지표는 프로젝트의 재작업 결정이 내려진 작업에 대하여 작업분석을 시행하여 재작업 결과에 대한 검토 수준을 달리하는 것이다.
발생된 오류에서 발전될 수 있는 추가적 오류 및 반복 오류를 줄이기 위하여 재작업 활동의 완성도를 높이는 것이 본 연구의 목표이며, 이는 결과적으로 프로젝트의 품질을 높이는 데에 많은 영향을 줄 것으로 기대된다.
GQM 활동을 수행하게 된 근본적인 목표를 생각하는 단계이다[9]. 본 연구에서 목표하는 바는 재작업 활동에 대한 시간이나 비용을 투자함으로써 완성도가 떨어지는 산출물들이 후반으로 넘어가는 것을 막고, 결함의 재유입으로 인한 부작용과 비용을 줄이기 위한 것이다. 그러므로 현 단계에서 비즈니스 목표는 다음과 같다.
본 연구에서는 이러한 문제를 해결하기 위하여 프로젝트 통제 및 제어를 위한 활동 및 메트릭에 대해 연구하여 재작업 지표를 개발하였고, 개발된 지표를 통해 작업의 중요성을 판단하고 검토수준을 달리하는 프로세스를 개발하였다. 이를 프로젝트에 적용하여 연구 결과의 효율성을 검증하였다.
있다[10]. 이러한 프로세스와 관리활동들은 프로젝트에 유입되는 오류를 예방하고, 발생된 오류에 대해서는 초기에 발견하고 재작업하여 오류 수정의 비용을 줄이고자 함이다.
가설 설정
한 가지는 재작업 해야 하는 대상에 대한 중요도를 결정하는 것이었고, 다른 하나는 이에 대해 검토의 수준을 달리하는 것이다. 작업의 중요도를 파악하기 위해 작업을 분석하고 분석된 결과에 따라 검토의 수준을 달리하는 과정을 포함하여 프로젝트를 수행하면 프로젝트의 완성률 및 진도율에도 향상이 있을 것으로 가정하였다.
제안 방법
재작업 지표를 적용하였다. 4개월 과정의 프로젝트 4개를 선택하여 2팀은 지표를 사용하였고, 다른 2팀은 재작업 지표를 사용하지 않은 채로 프로젝트를 진행하였다. 연구의 타당성 및 결과의 신뢰성을 저해할 수 있는 우연적 조건들을 통제하고 실험 대상들의 수준을 유사하게 맞추기 위해 설정한 프로젝트 진행의 개요는<표 3>과 같다.
될 수 있다. 따라서 본 연구에서 개발한 지표는 재작업의 완성도를 높이기 위한 작업이므로 재작업 지표라 하였다. 재작업 지표의 활용 과정 및 재작업 완성도 지표에서 사용되는 요소들 각각에 대해 살펴보면 다음과 같다.
가장 심각하게 고려되어야 하는 요소이다. 따라서 최소한의 결합도 및 자원의 사용으로 요인을 통제한 경우 재작업의 횟수에 의해 WL이 달라지는 정도에 따라 검토 수준을 결정하고, 수준을 부여하여 지표를 설정하였다.
본 실험에서 진도율을 확인하기 위해서는 계획대비 실제 일정에 대한 기록을 확인하였고 완성률을 확인하기 위해서는 최종 산출물의 요구사항에 대한 적합성(요구사항 수에 대한 최종 결과의 만족 개수)을 확인하였다. 완성률을 보기 위해 제안된 요구사항을 체크리스트로 만들어서 요구사항의 적용 여부를 확인하였다.
이를 프로젝트에 적용하여 연구 결과의 효율성을 검증하였다. 추후 진행되어야 할 연구는 이 지표의 타당성을 부여하기 위해 다양한 프로젝트의 결과를 지표에 반영하고 재작업 지표를 더욱 정교하게 하는 것이다.
재작업 수준을 결정하기 위한 판단기준으로 GQM방법을통해 나타난 재작업의 특성 중 난이도, 결합도, 재작업횟수, 투입인원, 작업기간 총 다섯 개의 결정 요인을 선택하였다. <표 1>의 다섯 가지 요소는 동일한 비중으로 작업에 영향을 준다고 가정하여 재작업 수준에 대한 메트릭을 다음과 같이 작성하였다.
.재작업 시 새로운 오류의 유입과 기존 오류의 잔류를 검증한다.
재작업의 수준에 대한 지표의 설정을 위해 재작업 측정치들과 검토 수준 간의 관계를 고려하였다. 작업의 오류 확률이 높고 프로젝트에 영향을 많이 미칠 수 있는 사항들은 다음과 같다.
대상 데이터
본 연구의 가설을 검증하기 위해 학부 4학년 프로젝트를 대상으로 재작업 지표를 적용하였다. 4개월 과정의 프로젝트 4개를 선택하여 2팀은 지표를 사용하였고, 다른 2팀은 재작업 지표를 사용하지 않은 채로 프로젝트를 진행하였다.
이론/모형
재작업 활동에 대한 완성도를 파악하는 측정치를 찾기 위해 본 연구에서는 GQM 방법을 이용하였다. GQM을 이용하여 재작업 지표를 개발하는 단계는 다음과 같이 총 네 단계로 구성된다.
성능/효과
마지막으로 네 번째 단계는 위의 단계를 통하여 지표를 결정하는 것이다. GQM흘 통한 재작업에 대한 정보의 체계 화를 통해 재작업에 대해 식별되어야 할 내용을 파악하였고 재작업의 중요성을 결정하기 위한 지표가 요구된다는 것을 알 수 있었다. 지표에 대한 설명은 다음 장에서 자세히 다 루어 진다.
프로젝트의 진도율 및 프로젝트의 완성률, 즉 품질이다. 본 실험에서 진도율을 확인하기 위해서는 계획대비 실제 일정에 대한 기록을 확인하였고 완성률을 확인하기 위해서는 최종 산출물의 요구사항에 대한 적합성(요구사항 수에 대한 최종 결과의 만족 개수)을 확인하였다. 완성률을 보기 위해 제안된 요구사항을 체크리스트로 만들어서 요구사항의 적용 여부를 확인하였다.
후속연구
이를 프로젝트에 적용하여 연구 결과의 효율성을 검증하였다. 추후 진행되어야 할 연구는 이 지표의 타당성을 부여하기 위해 다양한 프로젝트의 결과를 지표에 반영하고 재작업 지표를 더욱 정교하게 하는 것이다.
참고문헌 (13)
Wolfhart Goethert, Matthew Fisher, 'Measuring Acquisition Process', SEPG 2002, 2002
The Standish Group International Inc., 'Latest Standish Group CHAOS Report Shows Project Success Rates Have Improved by 50%', http://www.standishgroup.com/press/, 2003
Watts S. Humphrey, 'A Personal Commitment to Software Quality', The Software Engineering Institute Carnegie Mellon University, 1994
CMMI Product Team, 'Capability Maturity Model® Integration (CMMISM), Version 1.1, CMMISM for Software Engineering (CMMI-SW, V1.1)', CMU/SEI-2002-TR-029, 2002
R.Pressman 'Software Engineering: A practitioner's approach', Addison Wesley, 2004
M.B.Chrissis, M.Konrad and S Shrum, 'CMMI Guidelines for process integration and product improvement', Addison-Wesley, 2003
John McGarry, et al, 'Practical Software Measurement-Objective Information for Decision Makers', Addison-Wesley, 2001
Donald R. McAndrews, 'Establishing a Software Measurement Process', Technical Report CMU/SEI-93-TR-016, Software Engineering Institute, 1993
Rini van Solingen, Egon Berghout, 'The Goal/Question/Metric Method: A Practical Guide for Quality Improvement of Software Development', McGraw-Hill, 1999
William A. Florac, Robert E. Park and Anita D. Carleton, 'Practical Software Measurement: Measuring for Process Management and Information'. CMU/SEI-97HB-003, Software Engineering Institute, 1997
Wolfhart Goethert and Will Hayes, 'Experiences in Implementing Measurement Programs', Technical Note CMU/SEI-2001-TN-026, Software Engineering Measurement and Analysis Initiative, 2001
James A. Rezum, 'Defining and Understanding Software Measurement Data', Software Engineering Institute
John H. Baumert, Mark S. McWhinney, 'Software Measures and the Capability Maturity Model', Technical Report CMU/SEI-92-TR-025, Software Engineering Institute, 1992
※ AI-Helper는 부적절한 답변을 할 수 있습니다.