문서요약 – 소프트웨어 유지보수 by Canfora

제목: 소프트웨어 유지보수(Software Maintenance)

저자: Gerardo Canfora 외 1인, University of Sannio, 이탈리아

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

 

소프트웨어 유지보수 관련 기본적인 정보를 기술한 자료

---

소프트웨어 유지보수 정의

• 소프트웨어 시스템이 운영에 들어간 이후에 수행되는 모든 작업을 포함하는 광범위한 활동이다(예, 에러 수정, 기능 개선/추가/삭제, 운영 환경 변화에 적응, 데이터 요구사항 변화에 적응, 성능/사용성/기타 품질 특성 향상 등)
• IEEE의 정의: 소프트웨어 유지보수는 결함 수정, 성능 및 기타 속성 향상, 변화된 환경에 적응 등을 목적으로 고객 인도 이후에 소프트웨어 시스템이나 컴포넌트를 변경하는 프로세스이다.
• 소프트웨어 유지보수가 제품 인도 후 이루어지는 활동이라는 근시안적 관점에서 벗어나 개발 주기 초반부터 유지보수를 고려하고 관련 활동이 이루어져야 한다는 접근 방법도 제기됨

소프트웨어 유지보수의 난제(Challenges)

소프트웨어 유지보수에서 가장 많은 노력을 요구하는 작업으로 프로그램 이해(program comprehension), 영향 분석(impact analysis), 회귀 테스팅(regression testing)을 들 수 있다.

• 프로그램 이해(program comprehension): 소프트웨어 변경이 생길 때마다 유지보수 담당자의 중요한 일 중 하나가 수정될 시스템의 구조, 동작, 기능을 완전히 이해하는 것이다. 유지보수 담당자는 코드 및 관련 문서를 읽고 이해하는데 많은 시간을 보내는데, 예측에 따르면 유지보수 시간의 50%~90%가 프로그램 이해 작업에 소요된다. 유지보수 담당자와 코드 개발자가 다른 경우, 개발과 유지보수 시점 사이에 오랜 시간이 경과된 경우, 현 상황에 맞게 업데이트된 완전한 문서가 없는 경우에는 프로그램 이해 작업이 더 어려워진다.
• 영향 분석(impact analysis): 예상 못한 부작용(side effects)을 최소화하려는 목적으로 제안된 변경이 나머지 시스템에 미치는 영향을 평가하는 활동. 제안된 변경이 적절한지(the appropriateness)를 평가하고, 해당 변경이 자원, 공수, 일정에 미치는 영향을 예측하여 변경 구현에 따른 위험을 식별한다. 또한 제안된 변경의 영향으로 인해 수정될 필요가 있는 시스템 부분도 식별한다.
• 회귀 테스팅(regression testing): 일단 변경이 구현되면 소프트웨어 시스템이 (변경된) 명세대로 작동하는지 확신을 얻기 위해 재테스트가 필요하다. 이렇게 변경이 일어난 후에 시스템을 테스팅 하는 프로세스를 회귀 테스팅이라 부른다. 회귀 테스팅은 가해진 변경이 정확한지 확인하는 목적과 시스템의 변경이 안된 부분이 의도하지 않은 영향을 받지 않는다는 것을 확인하기 위한 두 가지 목적이 있다. 회귀 테스팅은 재사용할 수 있는 테스트 케이스 집합이 존재한다는 점에서 개발 단계 중에 수행되는 테스팅과 다르다. 유지보수 단계에서 가해진 변경의 범위는 대개 소규모이므로 변경이 있을 때마다 기존 테스트 케이스 집합 전체를 다시 실행하는 접근법은 경제적이지 못하다. 따라서 테스트 효과성 측면에서는 영향을 주지 않으면서 기존 테스트 케이스들의 부분 집합을 선택하여 회귀 테스팅을 수행하는 다양한 방법들이 제안되었다. 

유지보수 모델(Models)

1) 빠른 수정 모델(the quick-fix model)

빠르고 적은 비용으로 변경을 하기 위해 아래 그림처럼 기존 시스템을 수정하는 코드를 먼저 작성하고 이후에 관련 문서에 변경 내용을 반영. 대개 적절한 계획, 설계, 영향분석, 회귀 테스팅의 과정 없이 변경이 즉석에서 구현되며, 시간 및 예산의 압박으로 인해 코드 수정에 따른 문서 변경이 제대로 안되어 문서의 이용가치가 떨어지기도 한다. 이런 변경이 반복되면서 원래의 설계가 점차 무너져 향후 시스템 유지보수를 어렵게 만든다.

2) 진화적 생명 주기 모델(Evolutionary life cycle model)

진화적 생명 주기 모델은 시스템 요구사항을 한번에 완전히 수집하고 이해하기는 어렵다는 원칙하에 사용자 피드백을 반영한 여러 빌드를 구축하여 점진적으로 시스템을 개발한다. 진화적 생명 주기 모델에서는 이전 빌드의 요구사항, 설계, 코드, 테스트 문서를 분석하여 새로운 빌드를 구축하는(즉, 이전 빌드를 변경하는) 과정이 유지보수에 해당한다. 이 모델은 코드 변경에 따른 문서 업데이트가 지속적으로 이루어진다는 장점이 있다. Visaggio의 연구에 따르면 진화적 생명 주기 모델이 빠른 수정 모델(quick-fix model)에 비하여 유지보수용이성(maintainability)을 장기간 유지하고 변경 작업도 더 빠르게 수행할 수 있다.

3) 완전 재사용 모델(the full-reuse model)

Basili가 제안한 완전 재사용 모델에서는 유지보수를 재사용 기반 소프트웨어 개발(reuse-oriented software development)의 한 유형으로 본다. 즉, 유지보수가 신규 시스템에 대한 요구사항 분석과 설계에서 출발하여 이전 버전 시스템의 적절한 요구사항, 설계, 코드, 테스트 리소스를 찾아 재사용하는 과정으로 이어진다. 완전 재사용 모델의 핵심은 저장소(a repository)인데, 이 곳에 현 시스템의 과거 버전 및 동일한 애플리케이션 영역의 타 시스템들을 정의한 문서와 컴포넌트를 저장하고 있다. 위의 진화적 모델이 긴 생명 주기를 가지고 장시간에 거쳐 진화하는 시스템에 적합하다면, 완전 재사용 모델은 관련된 여러 제품들로 구성된 제품 라인의 개발에 적합한 방식이다. 이 모델을 적용하기 위해 여러 종류와 여러 추상화 레벨의 재사용 가능한 컴포넌트를 축적해야 하므로 단기적인 측면에서는 높은 비용이 요구되고 장기적인 측면에서 비용 효과성을 보인다.

소프트웨어 유지보수 프로세스

여러 버전의 소프트웨어 유지보수 프로세스 모델이 제안되었지만 성공적인 유지보수를 위해 필수적인 활동인 기존 시스템 이해(the comprehension of the existing system), 제안된 변경의 영향 평가(the assessment of the impact of a proposed change), 회귀 테스팅(the regression testing)은 공통적으로 포함하고 있다.

 

1) IEEE-1219 표준

IEEE 표준은 유지보수 프로세스를 아래 그림처럼 7 단계(phases)로 나눈다.  

• 문제/변경 식별, 분류, 우선순위선정(Problem/modification identification, classification, and prioritization): 사용자/고객/프로그래머/관리자의 변경 요청에 대한 승인 또는 기각의 의사결정을 하고, 승인된 변경 요청의 유지보수 타입과 우선순위를 정하고 고유 식별 번호를 할당한다.
• 분석(Analysis): 설계, 구현, 테스트, 인도(delivery)에 대한 일차적인 계획을 구상한다. 분석은 타당성 분석(feasibility analysis)과 상세 분석(detailed analysis)의 2 레벨에 거쳐 수행된다. 타당성 분석에서는 해결책의 여러 대안 식별과 각 대안이 미치는 영향과 비용을 평가하고, 상세 분석에서는 변경 요구사항을 정의하고 테스트 전략 및 구현 계획을 세운다.
• 설계(Design): 시스템과 프로젝트의 모든 문서, 기존 소프트웨어와 데이터베이스, 분석 단계의 산출물 등을 기반으로 시스템 변경을 설계한다. 이 단계의 활동으로 영향을 받는 소프트웨어 모듈 식별, 소프트웨어 모듈 문서 업데이트, 새로운 설계에 대한 테스트 케이스 생성, 회귀 테스트 대상 식별 등이 있다.
• 구현(Implementation): 코딩, 단위 테스팅, 변경된 코드의 통합, 통합/회귀 테스팅, 위험 분석(risk analysis), 검토(review) 등을 수행한다. 다음 단계인 시스템/회귀 테스팅을 할 준비가 되었는지 평가하는 테스트 완성도 검토(a test-readiness review)도 이루어진다.
• 회귀/시스템 테스팅(Regression/system testing): 원래의 요구사항과 변경 요구사항에 부합하는지 확인하기 위해 전체 시스템을 테스팅한다. 기능 테스팅 및 인터페이스 테스팅과 더불어 기존에 없던 새로운 결함이 발생하지는 않는지 확인하는 회귀 테스팅이 수행된다. 다음 단계인 승인 테스팅(acceptance testing)을 할 준비가 되었는지도 확인한다.
• 승인 테스팅(Acceptance testing): 사용자, 고객, 또는 고객의 위임을 받은 제 3자가 완전히 통합된 시스템을 테스팅한다. 기능 테스트(functional tests), 상호운영성 테스트(interoperability tests), 회귀 테스팅(regression tests)이 수행된다.
• 인도(Delivery): 설치 및 운영을 위해 변경된 시스템을 릴리즈한다. 사용자 그룹에게 공지, 설치 및 교육/훈련 수행, 백업용 저장 버전 준비 등의 이루어진다.

2) ISO-12207 표준

소프트웨어 생명 주기 전반의 프로세스를 다룬 ISO-12207은 아래 왼편 그림처럼 3개 카테고리(메인 프로세스, 지원 프로세서, 조직 프로세스)의 총 17개의 프로세스로 구성되어 있는데, 유지보수는 5개의 메인 프로세스 중 하나이다. 아래 우측 그림은 이 유지보수 프로세스에 포함된 활동들을 나열하고 있다(활동들 간의 시간 순서적인 관계는 없음).

• 프로세스 구현(Process implementation): 소프트웨어 유지보수를 위한 계획과 절차를 개발하고, 유지보수 요청의 수신, 기록, 추적 절차를 생성하며, 형상 관리 프로세스와의 조직적 인터페이스를 확립한다. 이 프로세스 구현 활동은 시스템 생명 주기의 초반에 시작되어야 하며, 유지보수 계획도 개발 계획과 병행하여 준비되어야 한다. 유지보수의 범위를 정의하고, 여러 대안(예, 유지보수 업무를 제 3자에게 아웃소싱)을 식별 및 분석하고, 유지보수 팀을 조직하여 책임과 자원을 할당하는 일도 포함된다.
• 문제/변경 분석(Problem and modification analysis): 유지보수 요청(문제점 보고서 또는 변경 요청서)을 분석하여 분류하고, 변경 범위를 규모/비용/소요 시간 측면에서 결정하고, 해당 변경의 중요도를 평가한다. 유지보수 조직은 해당 문제를 재현해 보거나 요청된 변경에 대한 확인을 하는 것이 바람직하다. 변경 요청 사항을 구현할 수 있는 여러 대안을 분석 및 문서화하고, 선택된 대안을 계약에 기반하여 승인한다.
• 변경 구현(Modification implementation): 변경되어야 할 항목들을 식별하고, 실제 변경을 구현하는 개발 프로세스에 착수한다. 신규 및 수정된 요구사항이 완전하고 정확하게 구현되었는지 그리고 변경 대상에 포함되지 않는 원래의 요구사항이 영향을 받지는 않는지 확인하기 위한 테스팅 절차가 개발 프로세스에 추가된다.
• 유지보수 검토/승인(Maintenance review/acceptance): 변경된 시스템의 무결성(the integrity of the modified system)을 평가하고, 유지보수 요청이 만족스럽게 완성되었다는 승인을 얻으면 작업을 종료한다. 품질 보증 프로세스, 검증 프로세스(the verification process), 확인 프로세스(the validation process), 공동 검토 프로세스(the joint review process) 등의 여러 지원 프로세스가 수반되기도 한다.
• 이전(Migration): 소프트웨어 시스템이 한 환경에서 다른 환경으로 이동할 때 수행되는 활동. 이전 계획(migration plans)을 수립하여 사용자/고객이 해당 문서를 볼 수 있게 하고, 왜 기존 환경이 더 이상 지원되지 않는지의 이유와 새로운 환경에 대한 설명 및 가용 시점도 알린다. 기존 환경과 새로운 환경의 병행 운영(the parallel operations)이라든지 새로운 환경으로 이전에 따른 영향을 평가하는 운영 후 검토(the post-operation review) 등의 작업도 일어난다.
• 소프트웨어 퇴거(Software retirement): 마지막 유지보수의 활동으로서 소프트웨어 시스템 퇴거를 위해 퇴거 계획(a retirement plan)을 세우고 사용자들에게 공지하는 활동이다.

IEEE-1219 표준의 유지보수 계획서(a maintenance plan) 템플리트

1. 서론 소프트웨어 유지보수의 의도, 목표, 범위를 정하고 표준과 달라지는 점이 무엇이지도 기술 2. 참고문서 유지보수 활동에 제약을 주거나 이를 지원하는 문서들 식별 3. 정의 본 계획서를 이해하는데 필요한 용어를 정의하거나 관련 참고 자료 기술 4. 소프트웨어 유지보수 개요 유지보수 프로세스의 조직, 일정 우선순위, 자원, 역할 및 책임, 도구, 기법, 방법 등을 기술  4.1 조직 4.2 일정 우선순위 4.3 자원 요약 4.4 역할 및 책임 4.5 도구, 기법, 방법 5. 소프트웨어 유지보수 프로세스 유지보수 프로세스 각 단계의 수행할 활동(actions)들을 식별하고, 각 활동의 입력물(input), 출력물(output), 프로세스(process), 통제 방법(control)을 정의 5.1 문제/변경의 식별, 분류, 우선순위선정 단계 5.2 분석 단계 5.3 설계 단계 5.4 구현 단계 5.5 시스템 테스팅 단계 5.6 승인 테스팅 단계  5.7 인도(Delivery) 6. 소프트웨어 유지보수 보고 요구사항(Software Maintenance Reporting Requirements) 정보가 어떻게 수집되고 유지보수 조직 구성원에게 제공되는지를 기술 7. 소프트웨어 유지보수 관리 요구사항(Software Maintenance Administrative Requirements) 문제 해결과 보고에 대한 표준, 관행, 규칙 등을 기술 7.1 문제 해결과 보고(Anomaly Resolution and Reporting) 7.2 원칙 위반에 대한 정책(Deviation Policy) 7.3 통제 절차(Control Procedures) 7.4 표준, 관행, 협약(Standards, Practices, and Conventions) 7.5 성능 추적(Performance Tracking) 7.6 계획의 품질 통제(Quality Control of Plan) 8. 소프트웨어 유지보수 문서화 요구사항(Software Maintenance Documentation Requirements) 유지보수 프로세스의 결과물 기록 및 공개와 관련된 절차를 기술

역공학(Reverse engineering)과 재공학(Re-engineering)

소프트웨어 유지보수와 관련된 주요 기술로 역공학과 재공학이 있다.

1) 역공학(Reverse engineering)

• 시스템 컴포넌트와 컴포넌트들간의 관계를 식별하고 시스템을 상위 추상화 레벨로(또는 다른 형태로) 표현하기 위해 대상 시스템을 분석하는 프로세스
• 역공학의 목표로 복잡성 극복(coping with complexity), 대안적 관점 생성(generating alternate views), 손실된 정보 복구(recovering lost information), 부작용 발견(detecting side effects), 상위 추상화 레벨의 산출물 생성(synthesizing higher abstractions), 재사용 촉진(facilitating reuse)을 들 수 있다.
• IEEE-1219 표준은 소스 코드만 존재하고 신뢰할만한 산출물이 없는 시스템을 다루는 지원 기술로 역공학을 추천
• 역공학은 정보 추출(information extraction)과 정보 추상화(information abstraction)의 두 단계로 구성된 프로세스이다. 정보 추출은 원천 데이터를 모으기 위해 대상 시스템(대개 소스 코드)를 분석하고, 정보 추상화는 다양한 관점에서 시스템을 조명하는 사용자 지향의 문서를 생성한다.

2) 재공학(Re-engineering)

• 시스템을 새로운 형태로 재구성하고 향후 작업도 새롭게 구성된 형태에서 진행하기 위해 대상 시스템을 검사하고 개조하는 기술
• 소프트웨어 재공학은 작업자의 소프트웨어에 대한 이해를 돕고, 향상된 유지보수성/재사용성/진화성 등을 목적으로 소프트웨어 자체를 개선하는 활동이다.
• 재공학은 소프트웨어 시스템을 더 잘 이해하고 유지보수하기 위한 방법으로 유지보수 분야에서 오랫동안 인정해 온 기술이다.
• 재공학에서 시스템의 상위 추상화 레벨 뷰를 생성하기 위해 역공학을 일부 수행하기도 한다. 이렇게 생성된 상위 레벨 뷰는 순공학(forward engineering) 과정을 거쳐 새로운 형태의 시스템을 구현하는데 활용된다(아래 그림 참조).

레거시 시스템(legacy systems)의 유지보수

소프트웨어 유지보수에 특히나 많은 비용이 드는 것이 레거시 시스템이다.

1) 레거시 시스템이란

• 적어도 20~30년 이전에, 대개 메인프레임 환경에서, 체계적인 개발 방법론의 적용 없이, 지금은 폐용된 프로그래밍 언어로 개발된 시스템
• 오랜 시간 동안의 유지보수 변경을 거쳐 시스템 구조화 수준이 저하됨
• 시스템 현 상태와 일치하는 문서나 기존 테스트 케이스가 존재한지 않음
• 업무의 핵심 시스템으로서 중요도가 매우 높음(대부분의 레거시 시스템이 테라바이트의 실제 업무 데이터를 보유)
• 애플리케이션 영역의 많은 양의 심도 깊은 업무 지식과 노하우를 담고 있음
• 때때로 레거시 코드(the legacy code)가 조직의 사업 지식과 규칙이 기록된 유일한 소스여서 구 시스템을 대체할 신규 시스템 개발하는 경우에도 레거시 시스템에 담긴 정보에 의존하는 것이 필수적임
• Brodie와 Stonebraker는 레거시 시스템을 “지속적으로 변화하는 비즈니스 요구사항을 충족하기 위한 변경과 진화에 현저하게 저항하는 정보 시스템”이라고 정의

2) 레거시 시스템 처리 방안

• 레거시 시스템을 버리고 대체 할 시스템을 구축
• 레거시 시스템을 현 상태로 얼려서(즉, 더 이상 변경 불가) 더 큰 신규 시스템의 컴포넌트로 사용
• 계속해서 레거시 시스템을 유지보수
• 수명 연장을 위해 레거시 시스템을 변경. 이런 변경으로 규모나 복잡도를 줄이는 시스템을 단순화(a simplification of the system), 재문서화, 재구조화, 재공학 등의 예방 유지보수(preventive maintenance), 인터페이스 변경, wrapping, 시스템 이전(migration) 등의 적응 유지보수(adaptive maintenance)가 있다.