유지보수 (Maintenance)
소프트웨어 시스템을 개발하고 릴리즈하여 운영하기를 시작하면 본격적으로 사용 단계에 접어들게 된다. 사용자가 시스템의 기능을 사용하면서 시스템 또한 안정된다. 그러나 빈도는 점차 줄어들겠지만 시스템의 버그와 결함에 대한 수정 작업은 계속 진행되어야 한다. 이와 같이 소프트웨어 개발 이후에 진행되는 변경 작업을 “유지보수”라고 한다.
유지보수가 지속되면서 소프트웨어는 계속 진화하며, 이 기간은 소프트웨어 생명 주기의 많은 부분을 차지한다. 따라서 유지보수는 소프트웨어 엔지니어링에서 매우 중요하다.
유지보수의 목적
과거에 구축된 많은 소프트웨어 시스템이 오늘날까지 사용되는데, 이러한 오래된 시스템들이 현재까지 여전히 사용되는 것을 “래거시 시스템(Legacy System)”이라고 한다. 래거시 시스템은 쉽게 소멸되지 않는데, 이는 시스템을 대체하기 위해서 많은 비용이 들고 또한 대체되는 새로운 시스템이 래거시 시스템에 비해 좋다는 보장이 없기 때문이다.
결국, 이러한 래거시 시스템의 구조를 개선하고 지속적으로 변경해나가는 작업을 진행하게 된다. 릴리스된 시스템의 변경이 필요하게 되는 목적은 다음과 같다.
- 버그 제거
- 운영 환경의 변화
- 정부 정책, 규례의 변화
- 비즈니스의 절차의 변화
- 미래 문제를 배제하기 위한 변경
유지보수의 유형
유지보수 작업은 변경의 이유에 따라서 작업의 형태가 달라진다. IEEE에 의하여 소프트웨어 유지보수의 종류를 분류하면 다음과 같다.
- `수정형 유지보수`: 소프트웨어 설치 후에 발견된 결함을 고치기 위하여 소프트웨어 제품을 수정하는 작업 유형
- `적응형 유지보수`: 소프트웨어 설치 후에 변경된 환경에서도 계속 사용할 수 있도록 소프트웨어를 이식하거나 변경하는 작업 유형
- `완전형 유지보수`: 소프트웨어 설치 후에 성능이나 유지보수성을 개선하기 위하여 실시하는 작업 유형
- `예방형 유지보수`: 오류 발생을 방지하기 위하여 소프트웨어 복잡성을 줄이는 유지보수 작업 유형
Lehman의 법칙
Lehman이 발견한 유지보수에서의 변경에 대한 추세와 패턴에 대한 사실은 다음과 같다. 이를 소프트웨어 진화의 법칙이라고 부른다.
지속적인 변경의 원칙
시스템이 릴리즈 된 후 변경은 기 시스템이 대체될 때까지 변경된다. 시스템의 요구는 항상 변화하기에 소프트웨어가 계속 사용되기 위해서는 끊임없이 좋은 방향으로 진화되어야 한다.
엔트로피, 복잡도 증가의 법칙
시스템이 변경될수록 구조는 더욱 복잡해지고 컴포넌트 사이의 결합은 증가한다. 시스템 구조를 단순화시키기 위한 많은 노력이 필요하며 재구조화나 리엔지니어링을 통해서 시스템 구조를 개선해야 한다.
자기 통제의 법칙
시스템 진화 과정은 자기 통제의 과정이다. 일정한 규모의 조직과 프로젝트에서는 시간이 지나면서 개발 속도, 변경 빈도, 결함율 등이 예측 가능하고 안정된 분포를 보인다
안정성 유지의 법칙
진화하는 시스템의 유지보수 프로세스는 시스템이 소멸될 때까지 일정한 평균 작업량을 보인다.
친근성 유지의 법칙
시스템의 평균 성장률은 소멸될 때까지 일정하다. 시스템 개발 전 단계에 걸쳐 각 버전의 변화는 거의 일정하다.
지속적 성장의 법칙
계속 진화하는 E 타입의 시스템은 사용자를 만족시키기 위해 기능적 성장을 계속해야 한다.
품질 저하의 법칙
E 타입 시스템의 품질은 운영 환경의 변화에 완전히 적응하지 못하는 한 저하된다.
피드백 시스템의 법칙
진화 프로세스는 여러 단계의 어려 번 반복, 중요한 역할을 담당하는 여러 관련자들의 피드백으로 구성된다.
유지보수 작업 과정 (Maintenance Work Process)
유지보수 작업은 개발 작업과는 다르게 수정하기 위해 프로그램 로직을 이해하고 문서를 리뷰하는 일이 많다. 실제 변경을 계획하고 구현하고 수정된 것을 문서에 반영하는 일은 상대적으로 적다. 유지보수에는 다음의 작업들이 기본적으로 포함된다.
- `현재 프로그램의 이해`: 유지보수를 위해서 엔지니어는 프로그램 로직을 추적하고 요구, 설계에 대한 이해가 필요하다.
- `변경 파악과 분석`: 필요한 변경을 파악하고 영향도와 소요 비용, 변경에 대한 리스크를 분석해야 한다.
- `변경 영향 파악`: 시스템의 컴포넌트가 변경되면 다른 컴포넌트에 영향을 줄 수 있기에 이러한 부분을 인지해야 한다.
- `변경 구현, 테스트, 설치`: 변경이 승인되면 현재 시스템을 수정하고, 구현으로부터 설계를 복구하거나 변경된 요구를 만족시키기 위해 설계를 변경하기도 한다. 변경을 반영하여 시스템을 수정하고 테스트를 실시하고 시스템을 운영 환경에 설치한다.
유지보수 프로세스 모델
소프트웨어 개발 작업처럼 유지보수 작업도 프로세스가 필요하다. 소프트웨어에 유지보수성을 형성하기 위한 요구가 어떤 것인지 인식하기 위해 모델이 필요하다.
- `즉시 수정 모델`: 임시방편적인 유지보수 작업 모델로, 문제가 발견되어 확인되면 가능한 빨리 문제를 해결하는 방식이다.
- `반복적 개선 모델`: 소프트웨어에 대한 변경이 전체 생명주기 단계에 반복적으로 일어나 시스템을 계속 개선시키는 방식으로, 변경의 필요성이 생길 때마다 분석, 재설계, 구현 작업을 반복하고 계속 파급되어 시스템을 개선시킨다.
- `재사용 중심 모델`: 프로그램 컴포넌트의 재사용을 중심적으로 여기는 방식이다.
변경 파악과 분석
소프트웨어 유지보수는 변경 요구를 기초로 어떤 부분을 변경해야 하는지 찾는 것이다. 지정된 컴포넌트가 변경되어 영향을 받는 다른 컴포넌트는 어떤 것인지를 파악하고, 변경을 구현하고 결과를 테스트하는데 드는 비용과 시간을 예측해야 하며, 리스크를 파악하고 해결책에 대한 측정 방법을 정의해야 한다.
형상 관리 (Configuration Management)
소프트웨어 개발 주기 동안 생성된 문서를 관리하고 소프트웨어 시스템과 컴포넌트의 상태를 추적하는 작업을 “소프트웨어 형상 관리”라고 한다.
베이스라인 (Baseline)
소프트웨어 개발 주기 각 단계에 결과물이 성공적으로 만들어졌는지 체크하는 것은 프로젝트의 진도를 측정하고자 하는 것이다. 베이스라인은 소프트웨어 프로젝트의 진척 상태를 나타내고, 소프트웨어 결과물의 집합으로 구성된다. 베이스라인은 다음의 목적을 지닌다.
- 프로젝트 진행의 중요한 상태를 정의한다.
- 프로젝트나 프로덕트가 특정 상태에 이르렀는지를 나타낸다.
- 계속되는 개발 또는 유지보수 작업의 기준이 된다.
- 형상 항목에 대한 변경을 제어하는 메커니즘이다.
프로젝트의 베이스라인을 정의하고 베이스라인을 공식적으로 확립하기 위한 메커니즘을 제공함으로 형상 관리를 진행할 수 있다. 결국, 형상 항목 관리는 베이스라인에 대한 업데이트이다.
형상 관리 절차
형상 관리는 다음 네 가지 기능으로 구성된다.
- `소프트웨어 형상 파악`: 베이스라인과 형상 항목, 아이템을 구별하기 위한 명명 체계를 정의한다.
- `형상 변경 제어`: 시스템 형상의 일관성과 개발자 사이의 협력을 확인하기 위해 형상 항목에 대한 변경을 관리한다.
- `소프트웨어 형상 감사`: 소프트웨어 형상에 대하여 요청된 변경이 적절히 이루어졌는지 확인하고 베이스라인과 형상 항목들을 검증한다.
- `소프트웨어 형상 상태 보관`: 소프트웨어 형상에 대한 정보를 추적하고 유지하기 위해 형상의 상태를 보관하고 관리한다.
역공학 (Reverse Engineering)
역공학은 완제품으로부터 설계를 해독해내는 과정을 말한다. 소프트웨어 작업 과정에서 역공학은 설계, 요구 명세, 문제 정의를 회복하기 위하여 코드를 변환하는 개발 프로세스의 역방향 프로세스를 말한다.
대상 시스템을 분석하여 시스템의 컴포넌트와 관계를 찾고 같은 수준의 다른 표현이나 더 높은 추상 수준의 표현으로 만드는 것이다. 반면, 논리적/구현 독립적 설계에서 시스템의 물리적 구현으로 진행하는 프로세스를 순공학이라고 한다.
역공학 작업 순서
역공학 프로세스의 단계는 다음과 같다.
- 원시코드에서 소프트웨어 결과물들을 추출한다.
- 파악된 각 요소는 다이어그램으로 그리기 위해 레이아웃을 계산한다.
- 디스플레이 컴포넌트가 레이아웃에 따라 다이어그램으로 그려진다.
역공학 용도
역공학에 의하여 복원된 다이어그램은 여러 방면에 사용된다.
- `프로그램 이해`: 역공학 도구에 의해 생성된 다이어그램은 유지보수하고 있는 소프트웨어의 구조, 기능, 동작의 이해를 용이하게 한다.
- `정형적 분석`: 정형적 분석 기술은 역공학 도구에 의하여 생성된 다이어그램을 소프트웨어에 존재할 수 있는 문제를 감지하기 위해 사용될 수 있다.
- `테스트 케이스 생성`: 역공학 도구에 의하여 생성된 다이어그램은 테스트 케이스 생성을 용이하게 한다.
- `리엔지니어링`: 역공학에 의하여 생성된 다이어그램은 리엔지니어링을 위하여 사용
설계 복구
설계 복구는 원시코드를 자세히 검토하여 의미있는 추상성이 높은 표현을 찾아내고 추출하는 작업이다. 이때, 복구된 설계는 원래 설계가 아닐 수도 있다. 복구된 설계는 원시코드 이해에 도움이 되고 유지보수나 리엔지니어링을 위한 베이스라인으로도 사용될 수 있다.
리엔지니어링 (Re-Engineering)
리엔지니어링이란 소프트웨어의 어떤 측면을 개선하기 위해서 시스템 또는 컴포넌트를 재구조하는 과정이다. 리엔지니어링은 소프트웨어 시스템의 구조를 개선하여 향후 유지보수 작업이 효율적으로 이루어지게 하기 위해서 필요하다.
리엔지니어링 목적
소프트웨어 리엔지니어링은 여러 가지 목적으로 수행된다.
- 소프트웨어 아키텍처 개선
- 소프트웨어의 복잡도 경감
- 변경에 대한 적응성 개선
- 성능, 효율성, 자원 유용성 개선
- 소프트웨어 시스템의 유지보수 개선
리엔지니어링 과정
소프트웨어 리엔지니어링 과정은 다음과 같다.
- 개선이 필요한 위치 파악: 소프트웨어를 분석하여 개선이 필요한 위치를 파악한다.
- 개선 전략 선택: 개선할 것으로 파악된 항목에 대한 개선 전략을 개발한다.
- 제안된 개선 구현: 제안된 개선을 구현하고 리엔지니어링한 소프트웨어가 요구를 만족하는지 테스팅을 실시한다.
- 목표를 기준으로 시스템 평가: 변경된 시스템을 목표 대비하여 평가하고 추가 개선이 필요하면 프로세스를 반복한다.
