문서요약 - 소프트웨어 생명 주기의 한 부분으로서의 소프트웨어 유지보수 by Erdil

제목: 소프트웨어 생명 주기의 한 부분으로서의 소프트웨어 유지보수(Software Maintenance As Part of the Software Life Cycle)

저자: Kagan Erdil 외 5인, Department of Computer Science, Tufts University, 미국

문서유형: Academic Technical Report(총 49페이지), 2003년

 

 

소프트웨어 유지보수에 대한 기본 설명 자료

 

---

 

소프트웨어 유지보수(Maintenance)란

• 소프트웨어 생명 주기의 마지막 단계. 소프트웨어 개발은 요구사항 분석(Requirements Engineering), 아키텍쳐 결정(Architecting), 설계(Design), 구현(Implementation), 테스팅(Testing), 소프트웨어 전개(Software Deployment), 유지보수(Maintenance)의 단계로 이루어짐
• 제품이 출시된 후(또는 소프트웨어가 고객/사용자에게 전달된 후) 환경 변화(environment changes) 및 사용자 요구 변화에 따라 소프트웨어를 지속적으로 업데이트 하는 일이 유지보수 단계에서 이루어진다.
• IEEE[1993]의 소프트웨어 유지보수 정의: 결함 수정, 성능 및 기타 다른 속성 개선, 변화된 환경에 적응 등을 목적으로 제품 인도 후 이루어지는 소프트웨어 제품의 변경
• 유지보수를 효율적으로 수행하기 위해서는 이전 단계가 제대로 수행되어야만 한다. 즉 제품이 유지보수가 용이하도록(maintainable) 구축되어야 하는데, 설계 단계에서는 구조를 쉽게 변경 할 수 있도록 설계해야 하고 구현 단계에서 쉽게 읽고, 이해하고, 변경할 수 있는 코드를 생성해야 한다. 

 

효율적인 유지보수 프로세스를 방해하는 요인

• 비구조적인 코드(unstructured code)
• 유지보수 인력의 시스템에 대한 지식이 불충분
• 개발 문서의 부재 또는 문서 업데이트가 안되어 내용이 안 맞거나 불충분
• 소프트웨어 유지보수에 대한 올바른 인식 부족

 

위와 같은 문제점들이 소프트웨어 생명 주기의 초기 단계에 해결되어야만 유지보수 단계가 성공적으로 수행될 수 있다.

 

 

소프트웨어 전체 생명 주기에서 유지보수의 비중

• 여러 연구에 따르면 시스템 유지보수 비용은 전체 생명 주기 비용(the entire life cycle costs)의 50% 이상을 차지한다.
• Takang와 Grubb[1996]의 연구에 따르면 제약회사에서는 유지보수 비용의 비중이 49%에 달하고 자동차 회사에서는 유지보수 비용이 75%에 달한다.
• Zelkowitz[1979]에 의하면 많은 대규모 소프트웨어 시스템에서 소프트웨어 개발 비용은 전체 생명 주기 비용의 4분의 1 내지는 3분의 1 정도만 차지하며, 아래 그림처럼 운영 및 유지보수 단계에 더 많은 노력이 들어간다.

 

소프트웨어 유지보수의 유형(Four types of software maintenance)

Lientz와 Swanson[1980]에 따르면 유지보수는 아래와 같은 4가지 유형으로 나뉜다.

1)    수리 유지보수(Corrective maintenance): 최종사용자가 보고한 버그를 수정

2)    적응 유지보수(Adaptive maintenance): 환경 변화(예, 비즈니스 규칙, 정부 정책, 업무 패턴, 소프트웨어와 하드웨어 운영 플랫폼 등의 변화) 또는 신규 환경에 소프트웨어를 맞추는 작업

3)    완전지향 유지보수(Perfective maintenance): 새로운 또는 변경된 사용자 요구사항을 반영하여 소프트웨어 업데이트(예, 시스템의 성능 또는 사용자 인터페이스를 향상시키기 위해 시스템의 기능적 개선 수행)

4)    예방 유지보수(preventive maintenance): 문서 업데이트, 코멘트 추가, 시스템 모듈 구조 개선, 코드 최적화와 같은 시스템 유지보수성(maintainability)을 개선하는 목적의 작업

 

- 위 4가지 유지보수 타입 중 수리 유지보수(corrective maintenance)만이 전통적인 유지보수 개념으로(traditional maintenance) 여겨지고 나머지는 ‘소프트웨어 진화(software evolution)’의 개념으로 간주되기도 한다.

- 수리 유지보수, 적응 유지보수, 완전지향 유지보수에 의한 시스템 변경이 장시간 쌓이게 되면 시스템 복잡도(complexity)가 증가하는 결과를 낳는다. 따라서 예방 유지보수 활동을 통해 시스템 유지보수성을 향상시키는 노력이 요구된다.

 

- Lientz와 Swanson[1980]이 487개의 데이터 프로세싱 조직의 유지보수 타입에 따른 비중을 조사한 결과를 보면 수리 유지보수가 20%를 약간 상회하고, 적응 유지보수가 25%에 약간 못 미치며, 완전지향 유지보수가 50% 이상이고, 예방 유지보수는 5%만을 차지한다. 

 

소프트웨어 유지보수 단계의 기본 절차

①    기존에 존재하는 설계를 이해하려는 노력을 한다.

②    제품 설계를 재검토하고 재구조화하는 역공학(reverse engineering)이 이루어진다.

 

③    새로운 변경이 제대로 작동하도록 하기 위해 제품을 테스트하고 디버그 한다.

 

유지보수용이성(maintainability)에 영향을 주는 시스템 특성(characteristics)

• 시스템 크기(system size): 큰 규모의 시스템을 익히는데 시간이 더 오래 걸리고 기능도 더 복잡하므로 큰 규모의 시스템이 작은 시스템보다 더 많은 유지보수 노력을 요구. 소스 코드 길이는 초기 개발 비용과 유지보수 비용을 결정하는 주요 요인이다. 예를 들어 200라인 코드의 10% 변경이 100라인 코드의 20% 변경보다 더 비용이 많이 든다.
• 시스템 나이(system age): 오래된 시스템이 신규 시스템보다 더 많은 유지보수 노력을 필요로 한다. 소프트웨어 시스템은 유지보수 단계의 변경으로 인해 시간이 지나면서 규모가 점점 커지고 구조의 조직화 정도는 점점 낮아지는 경향을 보이며, 또한 이직 같은 유지보수 인력의 변동(staff turnover)으로 인해 시스템에 대한 이해 정도도 낮아지게 된다.
• 입/출력 데이터 항목 수(number of input/output data items)
• 애플리케이션 타입(application type)
• 프로그래밍 언어(programming language)
• 구조화 정도(the degree of structure)

 

유지보수에 소요되는 노력을 줄여주는 요인

Martin와 McClure[1983]에 따르면 유지보수에 들어가는 노력을 줄일 수 있는 요인들로 아래 같은 것들이 있다.

• 구조화 기법 사용(Use of structured techniques)
• 최신 소프트웨어 사용(Use of modern software)
• 자동화 도구 사용(Use of automated tools)
• 데이터베이스 기법 사용(Use of data-base techniques)
• 적절한 데이터 관리(Good data administration)
• 숙련된 유지보수 담당자(Experienced maintainers)

 

유지보수 작업 유형(Maintenance tasks)

유지보수 활동은 1) 고립 및 문제 분석(isolating and analyzing the problem), 2) 변경 설계(designing a fix), 3) 변경 구현(implementing this fix), 4) 결과 시스템 테스팅(testing the resulting system), 5) 가해진 변경을 반영하는 문서 업데이트(updating documentation to reflect the changes made)의 다섯 개 카테고리로 구분된다.

• 분석/고립화(Analysis/isolation tasks): 영향 분석(impact analysis), 비용 효과 분석(cost benefit analysis), 고립(isolation) 작업으로 구성. 영향 분석과 비용 효과 분석에서는 여러 개의 구현 대안(implementation alternatives)들을 분석하여 이들이 일정, 비용, 운영에 어떤 영향을 주는지 비교한다. 고립은 문제점 또는 제안된 시스템 개선 사항을 이해하는데 소요되는 시간이다.
• 설계(Design): 요구되는 변경에 대한 이해를 바탕으로 시스템을 재설계한다. 릴리즈 검토 문서(release review documents) 같은 반공식적인 문서화(semiformal documentation) 작업도 수반한다.
• 구현(Implementation): 변경에 따른 코딩 및 단위 테스팅에 소요되는 시간. 소프트웨어 변경 테스트 계획(the software modification test plan) 같은 반공식적인 문서화(semiformal documentation) 작업도 수반. 단위 테스팅은 변경을 한 유지보수 담당자에 의해 수행되며 대개 사용자의 워크스테이션에서 국소적으로(locally) 수행된다.
• 테스팅(Testing): 통합 테스팅, 승인 테스팅, 회귀 테스팅으로 구성된다. 통합 테스팅(Integration testing)은 컴포넌트들을 통합하는 작업이며, 승인 테스팅(acceptance testing) 변경된 시스템이 사용자 요구사항에 부합하는지를 검증한다. 승인 테스팅은 의도한 변경이 성공적으로 구현되었는지 확인하기 위해 최종 사용자(the end users)에 의해 수행된다. 회귀 테스팅(Regression testing)은 가해진 변경이 소프트웨어 다른 부분의 기능에 영향을 주지 않는다는 것을 확인하는 작업이다.
• 문서화(Documentation): 시스템 문서화, 사용자 문서화, 그리고 기타 문서화로 구성. 시스템 문서화(System documentation)는 시스템 기술 문서를 작성하고 수정하는 작업이고, 사용자 문서화(User documentation)는 사용자 가이드(the user’s guide)와 시스템 문서를 제외한 다른 공식 문서를 작성하고 수정하는 일이다. 향후 변경들이 이전 변경(the previous changes/modifications)을 기술한 문서에 기반하여 이루어지게 되므로 문서화는 매우 중요한 작업이다.

 

소프트웨어 유지보수 도구(software maintenance tools)

유지보수 담당자의 작업(프로그램 이해, 역공학, 테스팅, 형상관리, 문서화)을 지원하여 효율성 및 생산성을 높이도록 해주는 여러 도구들이 존재한다.

 

1) 프로그램 이해 및 역공학 도구(Tools for program understanding and reverse engineering)

프로그래머의 이해를 돕기 위해 시스템 모델을 그려주는 다양한 시각화 도구(visualization tools)들로 프로그램 슬라이싱 도구(the program slicer), 정적 분석기(static analyzer), 동적 분석기(dynamic analyzer), 상호참조 분석기(cross-referencer), 종속관계 분석기(dependency analyzer) 등이 여기 해당한다. 유지보수에서의 시간과 노력의 절반 이상이 변경을 수행하는데 투입되므로 프로그램에 대한 이해(Program understanding)는 유지보수의 핵심적인 부분이다.

• 슬라이싱 도구: 슬라이싱(Slicing)은 프로그램의 특정 시점에 변수 값에 영향을 줄 수 있는 프로그램 코드의 모든 부분(all the sections of a program text)을 기계적으로 표시하는 프로세스이다. 프로그램 슬라이싱 도구는 변경에 영향을 받는 프로그램 부분만을 프로그래머가 골라서 볼 수 있도록 해준다.
• 정적 분석기(Static analyzer): 모듈, 프로시져, 변수, 데이터 항목(data elements), 오브젝트, 클래스 등과 같은 프로그램의 일부분을 분석하는데 사용된다. 정적 분석기는 변수나 오브젝트 같은 선택된 특정 항목이 프로그램 코드에서 어떻게 사용되고 있는지 요약 정보를 생성해 준다.
• 동적 분석기(A dynamic analyzer): 실행중의 프로그램을 분석하는데 사용될 수 있다.
• 데이터 플로우 분석기(A data flow analyzer): 유지보수 담당자가 프로그램의 모든 가능한 데이터 플로우 경로와 컨트롤 플로우 경로를 추적할 수 있게 해 주는 정적 분석 도구이다. 프로그램의 로직을 더 잘 파악할 수 있게 해주고 시스템 컴포넌트들간의 관계(the relationship)를 가시화 하는데도 도움을 준다.
• 상호참조 분석기(A cross-referencer): 프로그램 사용(the usage of a program)에 대한 정보를 생성하여 변경에 의해 영향을 받는 부분에 사용자가 집중할 수 있게 도와준다.
• 종속관계 분석기(A dependency analyzer): 유지보수 담당자가 프로그램 엔터티들간의 상호관계(the interrelationships)를 분석 및 이해할 수 있도록 지원해 준다. 또한 프로그램에서의 의존관계(the dependencies)를 그래픽하게 표현해 준다.

 

2) 테스팅 지원 도구

테스팅은 소프트웨어 유지보수에서 요구되는 시간과 노력 정도가 가장 높은 작업이므로 도구의 사용으로 가장 큰 효과를 얻을 수 있다. 

• 테스트 시뮬레이터(A test simulator tool): 변경을 실제 시스템에 구현하기 전에 통제된 환경(a controlled environment)에서 해당 변경이 어떤 영향을 미치는지 미리 테스트 해 볼 수 있게 해준다.
• 테스트 케이스 생성기(A test case generator): 변경된 시스템 기능을 테스트 하는데 사용되는 테스트 데이터를 생성해 준다.
• 테스트 경로 생성기(a test path generator): 변경에 영향을 받는 모든 데이터 플로우 경로(data flow paths)와 컨트롤 플로우 경로(control flow paths)를 찾는데 도움을 준다.
• 버그 추적 도구(bug tracking tools): Bugzilla, Test Director, Silk Radar, QA director 등과 같은 잘 알려진 상용 결함 관리 도구들을 유지 보수 단계의 버그 추적에 사용 가능

 

3) 형상 관리 도구(configuration management tools)

• 형상 관리 및 버전 통제 도구(Configuration management and version control tools): 소프트웨어 시스템을 형성하는 오브젝트들을 저장하는데 도움을 준다.
• 소스 코드 통제 시스템(A source control system): 여러 버전의 관리 및 파일 변경 내용을 프로그래머가 추적할 수 있도록 파일 이력(a history of the files)을 보관한다.  

 

유지보수 도구 선정 기준

작업에 맞는 적절한 도구를 선택하는데 있어 아래와 같은 선정 기준을 고려한다.

• 지원 능력(capability): 도구가 작업(the task)을 지원할 수 있는 능력이 되는지를 판단한다.
• 기능(features): 작업과 관련된 도구의 세부 기능(the features)을 검토한다.
• 비용/효과(cost/benefit): 도구에 투자되는 비용 대비 얻는 효과(품질, 생산성, 반응속도, 비용감소 등)를 분석한다.
• 플랫폼(platform): 도구가 돌아가는 환경인 플랫폼(the platform)을 확인한다.
• 프로그래밍 언어(programming language): 소스 코드의 언어를 확인한다. 해당 산업의 표준 언어를 지원하는 도구를 선택하는 것이 좋다.
• 사용용이성(ease of use): 사용자가 이미 익숙한 환경과 유사한 느낌을 지원하는 도구가 바람직하다.
• 아키텍쳐 개방성(openness of architecture): 유지보수 작업에서 오직 하나의 도구만을 사용하는 것이 아니고 다수의 도구들을 함께 가동할 필요가 있을 수 있으므로, 다른 벤더의 도구와 통합이 가능한 도구가 바람직하다.
• 벤더 신용(the vendor’s credibility): 공급 업체가 향후에도 계속 도구를 지원할 수 있는 능력이 되어야 한다. 벤더가 사업을 접거나 하면 도구의 기술 지원을 받을 수 없는 문제 발생하므로 확인이 필요하다.
• 조직 문화(organizational culture): 모든 조직이 자신들 고유의 작업 패턴이 있으므로 대상 사용자들이 도구를 받아들일 것인지 검토하는 것도 중요하다.