유지보수(Maintenance)
- 개발 후에 이루어지는 소프트웨어 변경 작업
- 소프트웨어가 유용하게 활용되는 기간 동안, 환경과 비즈니스 요구에 따라 계속 진화
- 유지보수에는 상당한 노력이 든다.
1. 유지보수 소개
레거시(legacy) 시스템
- 대체하려면 비용이 많이 든다
- 시스템 안에 지식/경험/지능이 녹아 있음
1.1 변경의 이유와 유지보수 유형
유지보수가 발생하는 이유
- 버그 제거
- 운영 환경 변화
- 정부 정책/규례 변화
- 비즈니스 절차 변화
- 미래 문제를 배제하기 위한 변경
유지보수 유형(4가지)
- 수정형(corrective): 발견된 결함을 고치기 위해 수정
- 적응형(adaptive): 변경된 환경에서도 계속 쓰도록 이식/변경
- 완전형(perfective): 성능 또는 유지보수성을 개선하기 위한 변경
- 예방형(preventive): 오류 발생을 방지하기 위해 수행
(추가 표기) 유지보수의 종류(응급형 포함 버전)
- 교정형(corrective): 오류 원인을 찾아 계획적으로 해결
- 적응형(adaptive): OS/HW/자료 등 환경 변경에 맞춰 이식
- 완전형(perfective): 성능/유지보수성 개선
- 응급형(emergency): 응급처치 목적의 무계획적 유지보수
1.2 Lehman의 법칙
- 소프트웨어 시스템이 시간이 지남에 따라 변화하고, 유지보수가 필수적이며, 지속적인 개선이 필요하다는 사실을 설명하는 법칙이다.
- 이는 소프트웨어 개발이 한 번 완료되면 끝나는 것이 아니라, 환경 변화와 사용자 요구사항에 맞춰 지속적으로 진화해야 한다는 점을 강조한다.
- 시스템 타입
- E 타입: 계속 진화하는 타입
- S 타입: 완벽히 정의할 수 있는 타입(예: 체스 게임)
- 이 원칙들은 E 타입인 경우에 적용된다.
- 지속적인 변경의 원칙
- 엔트로피/복잡도 증가의 법칙:
소프트웨어 시스템의 구조는 변경이 되면서 계속 나빠진다.
결과적으로 점점 이해하고 유지보수하기가 어려워진다.
이런 경우 재구조화나 리엔지니어링이 필요하다. - 자기 통제의 법칙
- 안정성 유지의 법칙
- 친근성 유지의 법칙
- 지속적 성장의 법칙
- 품질 저하의 법칙
- 피드백 시스템의 법칙
2 유지보수 작업 과정
2.1 유지보수 작업
- 현재 프로그램 이해
- 프로그램 로직을 추적하거나 요구/설계 등에 대한 이해가 필요
- 변경 파악과 분석
- 필요한 변경을 파악
- 영향도, 소요 비용, 변경 리스크 분석
- 변경 영향 파악
- 이해당사자에게 알리고 피드백 획득
- 변경 구현·테스트·설치
- 시스템 수정 → 확인(테스트) → 설치
유지보수 작업 분포
- 개발은 코딩 중심이지만, 유지보수는 이해 중심 + 통합된 작업 성격이 강함
2.2 유지보수 프로세스 모델
즉시 수정 모델
임시방편적인 유지보수 작업 모델
문제가 날 것을 대비하여 기다리다가 가능하면 빨리 문제를 해결하는 방식
반복적 개선 모델
소프트웨어에 대한 변경이 전체 생명주기 단계에 반복적으로 일어나 시스템이 계속 개선된다는 전제를 기초로 한다.
재사용 중심 모델
유지보수 작업을 프로그램 컴포넌트의 재사용이라고 본다.
- 재사용 후보가 될 만한 시스템의 부품을 파악한다
- 시스템의 부품을 이해한다.
- 시스템 부품을 새로운 요구에 맞추어 변경한다.
- 변경된 부품을 새 시스템으로 통합한다.
유지보수 프로세스 모델의 비교
2.3 프로그램의 이해
- 원시코드로부터 설계/명세를 추출해 멘탈 모델로 표현
- 개발 프로세스와 반대로 추상성을 추구하는 방향 (개발 프로세스와는 반대 방향)
- 상향식 이해 모델
- 상향식(bottom-up)
- 묶음화(chunking)
상향식 이해 모델
2.4 변경 파악과 분석
- 변경 요구를 바탕으로 변경할 부분을 찾음
- 다른 상용 컴포넌트(COTS)도 고려
- 변경 분석
- 변견효과를 분석
- 변경 구현·테스트 비용/시간 예측
- 리스크 파악
객체지향 소프트웨어의 변경 효과 분석
변경 효과는 클래스 사이의 의존관계로 파악한다.
- B가 A의 서브클래스이면 B는 A에 의존
- B가 A의 집합(aggregation)이면 B는 A에 의존
- B가 A를 사용하면 B는 A에 의존
- B가 A와 다른 클래스 사이의 연관을 위한 클래스이면 B는 A에 의존
3. 형상관리(Configuration Management)
- 형상 관리
- 개발 주기 동안 생성된 문서/소프트웨어 컴포넌트 상태를 추적·관리하는 작업
- 변경이 잘 조정되지 않으면 문서/결과물 불일치가 발생
- 클래스 변경 시 의존 클래스 업데이트 필요
- 하드웨어에 적용되던 전통적 원리를 SW 개발에 적용
3.1 형상 관리의 목적
베이스라인(Baseline)
- 소프트웨어 형상 항목(configuration item)의 집합
- 목적
- 프로젝트의 중요한 상태 정의
- 프로덕트가 특정 상태에 도달했는지 표시
- 지속 개발/유지보수의 기준
- 형상 항목 변경을 제어하는 메커니즘
베이스 라인과 형상 항목
변경 관리
버전 관리
릴리스 관리
협업과 감사
형상관리 필요성
- 소수 개발자가 한 장소에서 일하면 필요성이 낮을 수 있음
- 하지만 대개는
- 여러 팀/개발자 협력 및 동기화 필요
- 여러 버전 유지 필요
- 다양한 고객용 제품 유지 필요
3.2 형상 관리 절차
- 소프트웨어 형상 파악
- 형상 변경 제어
- 소프트웨어 형상 감사
- 소프트웨어 형상 상태 보관
형상 관리 절차
형상 파악
베이스라인과 각 베이스라인의 형상 항목을 정의하는 것
| 형상 항목 | 설명 |
|---|---|
| 고유 식별자(ID number) | 소프트웨어 형상 항목을 구별하기 위한 고유 번호로, 형상 항목의 기능을 나타내기 위한 의미를 가져야 한다. 예를 들면 도서관 정보 시스템의 도메인 모델의 버전 1이라면 LIS-Inc1-DM과 같이 고유 식별자를 붙일 수 있다. |
| 이름 | 형상 항목의 이름. 예를 들면 문헌 대출 유스케이스, 문헌 대출 시퀀스 다이어그램과 같다. |
| 문서 종류 | 형상 항목의 문서 종류. 예를 들면 요구분석 명세서, 설계 문서, 테스트 케이스 등 |
| 문서 파일 | 문서 파일 이름과 경로 |
| 저자 | 형상 항목을 만든 개발자 |
| 생성 날짜, 타깃 완성일 | 형상 항목의 상태를 파악하기 위한 정보 |
| 버전 번호 | 형상 항목의 버전을 추적하기 위한 정보 |
| 업데이트 이력 | 누가 언제 업데이트하였는지 간단히 요약한 리스트 |
| 설명 | 형상 항목에 대한 설명 |
| SQA 담당자 | 형상 항목의 품질 보증 책임자 |
| SCM 담당자 | 형상 항목을 체크할 책임자 |
형상 변경 제어
- 변경 이유 파악
- 결함, HW 변경, 운영 요구 변경, 개선 요구, 예산/일정 변경 등
- 변경 분석
- 변경 제안 준비(이유/영향 항목/노력/일정 영향)
- 평가
- 변경을 추가
형상 감사
- 베이스라인 구축 메커니즘 정의
- 향후 구축될 베이스라인과 승인된 베이스라인
- 형상 항목 검토
- 업데이트되어도 차이가 없음을 보장하여야
- 형상 항목 확인(정확성 체크)
- 올바른 문제를 해결하였는지 확증하기 위하여 정확성을 체크
형상 상태 보관
4. 역공학과 리엔지니어링
4.1 역공학
- 대상 시스템을 분석해 컴포넌트와 관계를 찾아내고,
같은 수준의 다른 표현 또는 더 높은 수준의 표현으로 만드는 작업 - 프로그램의 추상 수준을 점진적으로 복구해 나가는 과정
역공학 작업순서
- 원시코드에서 소프트웨어 결과물들을 추출하는 것
- 역공학을 수작업으로 하는 것은 어렵다
- 역공학은 기계적인 작업이며 충분히 도구가 개발되어 자동화할 수 있다.
역공학 도구의 구성
역공학의 용도
역공학에 의하여 복원된 다이어그램은 여러 방면에서 사용된다.
- 프로그램 이해(구조/기능/동작 이해)
- 정형적 분석(문제 감지)
- 테스트 케이스 생성(흐름도 경로 기반)
- 리엔지니어링
재문서화
- 재문서화: 의미적으로 같은 추상 수준의 표현 생성(문서 개선/최신화)
- 목적
- 소프트웨어의 이해를 증진시키기 위하여 시스템의 다른 관점
- 현재 보유한 문서를 개선
- 새로 수정된 프로그램의 문서화
설계 복구
- 설계 복구: 원시코드를 검토해 의미 있는 추상 표현을 찾아내는 작업
- 복구된 설계
- 원시코드 이해에 도움이 될 수 있음
- 향후 유지보수 또는 리엔지니어링을 위한 베이스라인으로 사용
- 유사한 다른 애플리케이션을 위하여 사용될 수도 있음
- 프로그래밍 언어 구조에 크게 좌우
- OO 프로그램은 UML 도구로 자동화 가능
- 객체지향이 아닌 경우 원시코드에 내재된 설계의 의미, 의사결정을 파악 설계로 표현하는 작업이 필요함.
- 도메인 지식이 필요할 수도 있음
4.2 리엔지니어링
- 시스템 또는 컴포넌트를 재구조화하는 과정
- 소프트웨어는 지속적으로 변경된다. (리만의 법칙)
- 이는 소프트웨어 시스템의 구조가 계속 나빠지고 있음을 의미함.
- 유지보수 비용을 줄이기 위하여 시스템의 재구조화가 필요함.
리엔지니어링 목적
- 소프트웨어 아키텍처 개선
- 소프트웨어 복잡도 경감
- 변경에 대한 적응성 개선
- 성능/효율/자원 유용성 개선
- 소프트웨어 시스템의 유지보수성 개선
리엔지니어링 과정
- 개선이 필요한 위치 파악
- 개선 전략 선택
- 개선 구현
- 목표 기준으로 시스템 평가
리엔지니어링 과정
5. 지속적 통합과 배포
비니비니히비니의 정리블로그