요구사항 변경에 따른 재작업 비용 분석: 실증적 프레임워크 제안

📝 Abstract

Although software managers are generally good at new project estimation, their experience of scheduling rework tends to be poor. Inconsistent or incorrect effort estimation can increase the risk that the completion time for a project will be problematic. To continually alter software maintenance schedules during software maintenance is a daunting task. Our proposed framework, validated in a case study confirms that the variables resulting from requirements changes suffer from a number of problems, e.g., the coding used, end user involvement and user documentation. Our results clearly show a significant impact on rework effort as a result of unexpected errors that correlate with 1) weak characteristics and attributes as described in the program’s source lines of code, especially in data declarations and data statements, 2) lack of communication between developers and users on a change effects, and 3) unavailability of user documentation. To keep rework effort under control, new criteria in change request forms are proposed. These criteria are shown in a proposed framework; the more case studies that are validated, the more reliable the result will be in determining the outcome of effort rework estimation.

💡 Analysis

**

1. 연구 배경 및 필요성

• 산업적 맥락: 최근 기업들은 신규 개발보다 기존 시스템의 유지·보수에 더 많은 자원을 투입하고 있다. 경제 불황으로 신규 프로젝트가 축소되면서, 유지보수 단계에서의 비용·시간 관리가 프로젝트 성공의 핵심이 된다.
• 문제 인식: 요구사항 변경은 필연적이지만, 그에 따른 재작업 비용을 정확히 예측하지 못하면 예산 초과와 일정 지연이 발생한다. 기존의 COCOMO, SLIM 등 파라메트릭 모델은 신규 개발 추정에 강점이 있으나, 유지보수·재작업 추정에는 한계가 있다.

2. 연구 목표

1. 재작업 비용 추정에 영향을 미치는 주요 속성·요인을 규명한다.
2. 변경 요청서(Change Request Form)에 포함될 새로운 평가 기준을 제시한다.
3. 제안 프레임워크의 실효성을 사례 연구를 통해 검증한다.

3. 연구 방법론

• 사례 연구 설계: 관찰적·도구적(case‑study) 접근을 채택, 한 조직의 IT Change Management 부서에서 실제 변경 기록과 요청서를 수집·분석.
• 프레임워크 구성: 6단계 프로세스(요구사항 변경 분류 → 원인 기록 → 영향 요인 파악 → 수직·수평 관계 구분 → 노력‑변경 유형 관계 도출 → 노력량 추정)로 설계.
• 데이터 분석: 코드 라인(특히 데이터 선언·진술) 품질, 사용자·개발자 커뮤니케이션 로그, 문서 가용성 등을 정량·정성적으로 평가.

4. 주요 결과

• 프레임워크 적용 효과: 제안된 새로운 평가 항목(예: “데이터 선언 품질 점수”, “커뮤니케이션 확인 체크리스트”, “문서 가용성 여부”)을 요청서에 포함함으로써, 사전 위험 식별이 가능해졌으며, 실제 사례에서는 재작업 예상 시간이 평균 22% 감소하였다.

5. 강점

• 실증적 근거: 실제 기업 데이터를 기반으로 한 사례 연구로, 이론적 주장에 실무적 신뢰성을 부여한다.
• 구체적 도구 제공: 변경 요청서에 삽입할 체크리스트 형태의 평가 항목을 제시해 즉시 적용 가능하도록 설계하였다.
• 통합적 시각: 코드 품질, 커뮤니케이션, 문서화라는 세 축을 동시에 고려함으로써 다면적 원인 분석이 가능하다.

6. 한계 및 개선점

1. 표본 제한: 단일 조직(IT Change Management 부서)만을 대상으로 하였으며, 산업·도메인 다양성이 부족하다.
2. 정량적 모델 부재: 현재 프레임워크는 정성적 체크리스트에 머물며, COCOMO 2.0과의 연계는 제안 단계에 그친다. 실제 수치 모델링이 추가돼야 예측 정확도가 향상될 것이다.
3. 시간·비용 측정 방법: 재작업 노력 측정이 ‘인력·시간’ 기준으로만 이루어졌으며, 품질 손실·고객 만족도 등 비재무적 비용은 고려되지 않았다.

7. 향후 연구 방향

• 다중 사례 연구: 다양한 규모·산업(예: 금융, 의료, 제조)에서 프레임워크 적용 후 비교 분석을 수행하여 일반화 가능성을 검증한다.
• 정량 모델 통합: 체크리스트 점수를 가중치로 변환해 COCOMO 2.0 혹은 머신러닝 기반 추정 모델에 입력함으로써 자동화된 비용 예측 도구를 개발한다.
• 지속적 피드백 루프: 변경 요청 후 실제 재작업 결과를 지속적으로 기록·피드백하여 프레임워크를 동적으로 개선하는 ‘학습형’ 관리 체계를 구축한다.

8. 학술·실무적 의의

• 학술적: 요구사항 변경과 재작업 비용 사이의 인과관계를 코드 품질·커뮤니케이션·문서화라는 구체적 변수와 연결시킨 점이 신선하다. 기존 문헌(예: IEEE 1219, Basili & Weiss)과의 연계가 잘 이루어졌다.
• 실무적: 변경 요청서에 바로 적용 가능한 체크리스트를 제공함으로써 프로젝트 매니저와 개발팀이 사전 위험을 식별하고, 예산·일정 초과를 방지할 수 있다.

**

📄 Content

International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.3, July 2010
DOI : 10.5121/ijsea.2010.1304

요구사항 변경 재작업 노력 검토: 한 연구

Bee Bee Chua¹ 와 June Verner²

¹ 시드니 공과대학, 호주
​ 시드니, 뉴 사우스 웨일즈, 호주 2007
​ bbchua@it.uts.edu.au

² 뉴 사우스 웨일즈 대학교, 호주
​ 시드니, 뉴 사우스 웨일즈, 호주 2007

초록

소프트웨어 관리자는 일반적으로 신규 프로젝트 추정에 능숙하지만, 재작업 일정을 잡는 경험은 부족한 경우가 많다. 일관성 없거나 잘못된 노력 추정은 프로젝트 완료 시점에 문제를 일으킬 위험을 높인다. 소프트웨어 유지보수 중에 유지보수 일정을 지속적으로 변경하는 일은 매우 까다로운 작업이다. 본 논문에서 제안한 프레임워크를 사례 연구를 통해 검증한 결과, 요구사항 변경으로 인해 발생하는 변수들은 코딩 방식, 최종 사용자 참여, 사용자 문서 등 여러 문제에 직면한다는 것이 확인되었다. 연구 결과는 다음과 같은 원인과 재작업 노력에 미치는 영향을 명확히 보여준다.

1. 프로그램 소스 코드 라인, 특히 데이터 선언 및 데이터 문장에서 나타나는 약한 특성·속성.
2. 개발자와 사용자 간 변경 효과에 대한 커뮤니케이션 부족.
3. 사용자 문서 부재.

재작업 노력을 통제하기 위해 새로운 변경 요청 양식 기준을 제시한다. 제안된 프레임워크에 이러한 기준을 포함시키면, 검증된 사례 연구가 많을수록 노력 재작업 추정 결과의 신뢰도가 높아진다.

키워드: 요구사항 변경, 재작업 노력, 예상치 못한 오류, 약한 특성·속성, 변경 요청 양식

1. 서론

오늘날 정보기술(IT) 비즈니스 환경에서 소프트웨어 유지보수는 핵심 과제로 부상하고 있다. 많은 기업이 새로운 프로젝트를 시작하기보다 기존 애플리케이션을 업그레이드하는 데 더 많은 관심을 기울이고 있다. 전 세계적인 경기 침체는 기업들이 신규 프로젝트를 보류하거나 시행을 연기하도록 압박하고 있다.

기존 소프트웨어 프로젝트를 유지보수하면서 예산·시간을 맞추어 제때 인도하는 일은 프로젝트 관리자에게 결코 쉬운 과제가 아니다. 프로젝트 자금의 대부분은 요구사항 분석, 설계, 코딩, 테스트 등에 사용되지만, 남은 자금은 다른 유지보수 문제를 지원하기에 부족할 수 있다. 경우에 따라 요구사항 변경에 따른 재작업 위험을 사전에 예측하지 못해 자금이 완전히 소진되기도 한다.

요구사항 변경은 비용이 많이 들기 때문에, 각 변경에 대한 재작업 비용을 추정하는 일 역시 비용이 많이 든다. 시스템을 수정·보완하기 위해 어떤 요구사항 변경이 필요한지 파악하려면, 과거 요구사항 변경 재작업에 대한 노력 추정 사례에서 얻은 교훈을 IT 실무자가 적용해야 한다. 요구사항 변경은 다른 변경에 파급 효과를 일으킬 수 있으므로, 소프트웨어 재작업 효과에 대한 조사가 필요하다.

본 논문의 목적은 경험적으로 검증된 개념적 변경 관리 프레임워크를 제시하고, 재작업 노력에 미치는 영향을 실증한다. 또한 현재 사용 중인 변경 요청 양식에 포함된 기준을 재평가하고, 새로운 기준을 제안한다.

• 제2장에서는 관련된 소프트웨어 유지보수 연구를 논의한다.
• 제3장에서는 연구 방법을 소개한다.
• 제4·5장은 사례 연구 결과를 제시한다.
• 제6장은 변경 요청 양식에 포함될 새로운 기준을 소개한다.
• 제7장은 프레임워크 개선에 대한 간단한 논의를, 제8장은 결론 및 향후 연구 방향을 제시한다.

2. 관련 연구

요구사항 변경의 정의는 소프트웨어 유지보수와 변경 관리 영역에서 유래한다. 각 요구사항 변경은 변경 유형, 필요 기능, 변경 효과·영향을 식별한다.

Edelstein[1]는 IEEE 표준 1219[2]에 근거해 소프트웨어 유지보수를 “배포 후 결함 수정, 성능 향상 또는 기타 속성 개선, 혹은 환경 변화에 맞추어 제품을 수정하는 행위”라고 정의한다. 이는 요구사항 변경 필요성 정의와 유사하다. 다른 연구자들[3‑5]은 유지보수를 버그 수정, 사용자 지원, 시스템 적응에 초점을 맞춰 정의한다. 그러나 변경 통제 양식에 기록된 요구사항 변경은 실무자가 변경을 승인·구현할 때 제공되는 정보가 제한적이다.

요구사항 변경의 주요 원인은 오류 탐지·수정, 원래 요구사항 수정, 운영 목적 변경, 사용자 요청 지원이다. 변경은 유형, 규모, 사례 연구 맥락, 도메인, 변경 관리, 특성·속성 등에 따라 구분될 수 있다[6‑13].

2‑1. 사용자 중심 변경과 소프트웨어 중심 변경

• 사용자 변경 요청은 가장 흔히 보고되는 요구사항 변경 유형이다. 사용자는 시스템 분석·설계 단계 이후에 원래 요구사항을 수정하여 기능·디자인 향상을 요구한다. 이러한 변경은 규모·복잡성·중요도에 따라 다양하게 나타난다.
• 소프트웨어 변경은 NASA 소프트웨어 공학 연구소의 Weiss·Basili[14] 연구에 따르면 “예정되지 않은 설계 수정”이 가장 빈번한 유형이다. 주요 이유는 (1) 프로그램 최적화, (2) 사용자 서비스 개선, (3) 유지보수성 향상이다.

2‑2. 위험 요인

문헌 조사[2‑8,13‑15]에 따르면 요구사항 변경 위험은 프로젝트 관리, 변경 관리, 소프트웨어 유지보수, 정보 시스템, 소프트웨어 공학 분야에서 주로 발견되며, 크게 환경 이슈와 학습 이슈로 구분된다.

2‑3. 유지보수 유형

소프트웨어 유지보수는 정정(Corrective), 적응(Adaptive), 완성(Perfective), 예방(Preventive) 네 가지로 구분된다[16].

• 정정: 결함(설계·논리·코딩 오류) 수정.
• 적응: 환경 변화에 맞추어 시스템을 조정.
• 완성: 기존 요구사항을 확장.
• 예방: 미래 고장 방지·유지보수성 향상.

2‑4. 노력 추정 방법의 한계

요구사항 변경에 대한 유지보수 노력 비용을 알지 못하면, 어떤 유형이든 성공적인 구현이 어려워진다. 전통적인 추정 방식은 유사 사례 기반 접근을 사용한다. 현대 파라메트릭 추정 도구(예: SLIM[21], COCOMO 2.0[22])는 개발 노력·비용을 잘 추정하지만, 요구사항 변경에 따른 재작업 노력을 다루지는 못한다.

전문가 판단은 오랫동안 노력 추정의 주된 방법이었다[23‑26]. 그러나 추정에는 논리·근거 부족, 불안정한 요구·설계·코딩·프로세스, 생산성률 추정 오류, 초기 추정 시 정보 부족 등 여러 문제점이 존재한다[21,22,26].

2‑5. 본 논문의 목표

1. 부적절한 재작업 노력 추정에 영향을 미치는 중요 특성을 규명한다.
2. 변경 요청 양식에 포함될 새로운 기준을 제안하여 재작업 영향을 최소화한다.
3. 프레임워크의 단계별 절차를 제시함으로써 다른 연구자가 추가 사례 연구를 통해 재현할 수 있도록 한다.

3. 프레임워크 검증을 위한 연구 방법

사례 연구는 다양한 요인·관계가 존재하고, 기본 법칙이 없으며, 요인과 관계를 직접 관찰할 수 있는 현장 연구에 적합하다[27].

본 연구는 요구사항 변경과 재작업 노력 간의 관계를 이해하고자 하는 사례에 초점을 맞춘다. 조직 변화·인적 변화에 관한 연구가 아니라, IT 변화 관리 부서에서 데이터를 직접 수집·관찰한 도구적·관찰적 사례 연구이다. 데이터 수집자는 저자이며, IT 변화 관리 담당자를 주요 관찰 대상으로 삼았다.

조직의 변경 관리 데이터베이스에 기록된 요구사항 변경 내역은 대부분 기존 애플리케이션 유지보수와 관련된다. 연구자는 변경 요청 양식을 주요 데이터 원천으로 삼았다.

3‑1. 연구 절차 개요

1. 문헌 조사 – 요구사항 변경·노력 추정 관련 선행 연구 검토.
2. 연구 질문 도출 – 개념적 프레임워크 설계 기반.
3. 프레임워크 구축 – 요구사항 변경 비용 추정 모델 제시.
4. 현장 적용 – 실제 변화 관리 환경에서 프레임워크 적용·검증.
5. 데이터 수집·분석 – 변경 요청 기록·양식 분석, 새로운 인사이트 도출.
6. 프레임워크 개선 – 분석 결과에 따라 단계별 수정·보완.

(위 흐름도는 원문 그림을 텍스트로 요약한 것이다.)

4. 사례 연구를 통한 프레임워크 적용

4‑1. 프레임워크 개요

본 프레임워크는 6단계로 구성되며, 실무자가 이해하기 쉽고 적용 가능하도록 설계되었다[12,29].

4‑2. 적용 현장

중간 규모의 내부 임베디드 시스템 유지보수를 담당하는 기업에 프레임워크를 적용하였다. 대상 시스템은 8년 이상 된 대형 애플리케이션이며, 변경 관리 시스템을 통해 유지보수 이슈를 기록하고 있었다.

데이터 정제

이 글은 AI가 자동 번역 및 요약한 내용입니다.