소프트웨어 진화

소프트웨어 진화(Software Evolution)는 소프트웨어를 처음 배포한 뒤 요구사항·운영 환경의 변화와 결함에 맞추어 시스템을 계속 바꾸어 가는 과정이다.

개요

업무에 쓰이는 소프트웨어는 한 번 만들고 끝나지 않는다. 사업 규칙이 바뀌고, 운영체제·하드웨어가 바뀌고, 사용자가 새 기능을 요구한다. 리먼 소프트웨어 변화 법칙의 '지속적 변경' 처럼, 쓰이는 시스템은 계속 고치지 않으면 점점 쓸모가 없어진다. 소프트웨어 공학에서는 배포 뒤의 이 변경 활동 전체를 진화라 부르고, 그 안에서 개별 변경을 처리하는 일을 유지보수라 한다.

시스템 진화 프로세스

소머빌(Sommerville)의 소프트웨어 공학은 변경이 처리되는 흐름을 다음과 같이 그린다. 시스템 배포 뒤 다시 변경 요청이 들어오므로 순환한다.

변경 요청 → 영향 분석 → 릴리스 계획 수립 → 변경 구현 → 시스템 배포
   ↑                                                    │
   └────────────────────────────────────────────────────┘

활동	하는 일
변경 요청(Change Request)	사용자·고객·관리자가 결함 수정, 환경 변경, 기능 추가를 요구한다
영향 분석(Impact Analysis)	변경이 시스템의 어느 부분에 영향을 주는지, 비용이 얼마나 드는지 따져 받아들일지 정한다
릴리스 계획 수립(Release Planning)	받아들인 변경을 어느 릴리스에 넣을지 정한다. 결함 수리, 플랫폼 적응, 시스템 개선으로 나누어 계획한다 → 릴리스 계획
변경 구현(Change Implementation)	요구사항 수정 → 설계·구현 → 테스트를 반복해 변경을 반영한다
시스템 배포(System Release)	새 버전을 사용자에게 내보낸다

영향 분석이 먼저다. 무엇이 얼마나 바뀌는지 알아야 릴리스 범위를 정할 수 있고, 계획에 들어간 변경만 구현한다
장애처럼 급한 변경은 이 흐름을 건너뛰고 코드를 먼저 고치는 긴급 수리로 처리하기도 한다. 이때도 나중에 요구사항·설계 문서를 맞추어야 문서와 코드가 어긋나지 않는다

유지보수와 관계

진화 프로세스의 변경은 성격에 따라 유지보수 유형으로 나뉜다.

결함 수리 → 수정 보수(Corrective)
플랫폼 적응 → 적응 보수(Adaptive)
기능 개선 → 향상 보수(Perfective)
장래 대비 구조 개선 → 예방 보수(Preventive)

레거시 시스템

오래되어 바꾸기 어려운 시스템은 계속 고칠지, 재공학(리팩토링·재구조화)할지, 새로 만들지를 사업 가치와 기술 품질로 판단한다. 문서가 없고 개발자도 떠난 코드는 외계인 코드라 부른다.

같이 보기