[소프트웨어공학] 7장. 유지보수

해당 게시물은 김정욱 교수님의 '소프트웨어공학' 강의를 수강하며
학습한 내용을 개인적으로 정리한 글입니다.

---

📌 목차 - 7장. 유지보수

7-1. 유지보수
7-2. 레거시 시스템, 리먼의 소프트웨어 변화 법칙
7-3. 유지보수 프로세스 모델
7-4. 유지보수 작업 과정
7-5. 소프트웨어 형상 관리
7-6. 역공학

---

📌 7-1. 유지보수

* 유지보수
- 소프트웨어가 사용자에게 인수, 설치된 이후 발생하는 모든 공학적인 작업 활동 (폐기될 때까지)
- 소프트웨어를 계속 수정, 보완하는 활동
- 필요성: 소프트웨어는 환경과 비즈니스 요구에 따라 진화한다.
- 소프트웨어 비용 중 유지보수 비용이 가장 큰 비용을 차지한다.
- 소프트웨어는 개발 완료가 끝이 아니라 그때부터 시작이다. 만들어진 하드웨어는 새로운 기능을 추가하기 어렵지만 소프트웨어는 새로운 기능을 추가할 수 있다.

* 요지보수 중요성
- 자동차의 관리와 유사하게, 소프트웨어의 유지보수도 "해당 제품을 값어치 있게 사용하기 위한" 매우 중요한 요소다.

* 유지보수 유형
- 수정형 유지보수: 테스트 단계에 발견하지 못한 잠재적인 오류를 찾아서 수정한다.
- 적응형 유지보수: 프로그램 환경변화(운영체제, 하드웨어)에 맞추기 위해 수행한다.
- 완전형 유지보수: 새로운 기능을 추가하거나 기존 기능을 개선한다.
- 예방형 유지보수: 잠재적인 오류발생에 대비하기 위해 선재적으로 수행한다.

* 개발 vs 유지보수
- 과정: 분석, 설계, 구현, 테스팅
- 개발: 코딩 중심, System Integration (SI) 직군, 개발비용-구현에서 최고점
- 유지보수: 이해 중심, System Management (SM) 직군, 개발비용-분석, 이해 등의 초기 단계에 가장 많은 비용을 사용한다.

---

📌 7-2. 레거시 시스템, 리먼의 소프트웨어 변화 법칙

* 레거시(Legacy) 시스템
- 낡은 기술, 방법론, 소프트웨어를 통틀어 이르는 말
- 종류 1: 현대까지도 남아 쓰이는 시스템 ex. NASA의 스페이스 셔틀
- 종류 2: 더 이상 쓰지 않더라도 현대의 기술에 영향을 주는 시스템
- 지식, 경험이 녹아있다.
- 레거시 시스템을 대체하지 못하는 이유
- 높은 비용
- 전문가, 사용자들의 수십 년 동안의 경험, 지식이 녹아있기 때문
- 새로운 시스템이 더 좋다는 보장이 없기 때문
- 하지만 레거시 시스템을 사용하는 것은 잠재적인 문제가 있다.
- 추구해야 하는 방향: 레거시 시스템 -> 현대화된 시스템

* 리먼(Lehman)의 소프트웨어 시스템의 타입
- E 타입: 시스템이 계속 진화하는 타입, 확실하게 정의가 불가능하다.
- S 타입: 완전히 확실하게 정의할 수 있는 타입 ex. 체스 게임

 

* 리먼의 소프트웨어 변화 8가지 법칙
1. 지속적인 변경의 원칙: 시스템이 릴리즈 된 후 변경은 그 시스템이 대체될 때까지 계속된다.
2. 엔트로피, 복잡도 증가의 법칙: 시스템의 구조는 변경되면서 더 나빠진다.
3. 자기 통제의 법칙: 프로그램별로 변경되는 사항은 고유한 패턴/추세가 있다.
4. 안정성 유지의 법칙: 개발 생산성이 변화에 민감하지 않고 안정적이다.
5. 친근성 유지의 법칙: 시스템의 평균 성장률은 소멸될 때까지 일정하다.
6. 지속성 성장의 법칙: E 타입 시스템은 사용자를 만족시키기 위해 기능적 성장을 계속 해야한다.
7. 품질 저하의 법칙: E 타입 시스템의 품질은 운영 환경의 변화에 적응하지 못하면 저하된다.
8. 피드백 시스템의 법칙: 진화 프로세스는 여러 단계의 반복, 여러 관련자들의 피드백으로 구성된다.

---

📌 7-3. 유지보수 프로세스 모델

* 즉시 수정 모델
- 코드에 문제가 발견, 확인되면 가능한 빨리 문제를 해결하는 방식이다.
- 장기적인 효과를 자세히 분석하지 않고 바로 수정해서 문서 수정이 최소화된다.
- 일부의 유지보수 담당자가 시스템을 잘 알고 있으며, 문서 없이 관리할 수 있으면 적절하다.
- 장점: 고객의 빠른 수정요구를 적용할 수 있다.
- 단점: 인력과 자원이 긴급 보수에 투입된다. -> 문서 변경에 투자하는 시간이 감소된다. -> 오류 탐색 기회가 감소한다.

* 반복적 개선 모델
- 소프트웨어 변경이 전체 생명주기 단계에 반복될 때 사용하는 모델이다.
- 변경이 일어나게 되면 새 시스템의 개발이라는 반복 사이클이 시작된다.
- 현재 시스템의 요구 명세와 설계는 변경을 구축하는데 기초가 된다.
- 즉시 수정 모델을 더 체계화된 형태로 만들어냈다.

* 재사용 중심 모델
- 문제가 있는 컴포넌트(모듈)를 재사용할 수 있도록 개선하는 모델이다.
- 재사용 후보가 될 시스템 부품을 파악한다.
- 해당 시스템 부품을 새로운 요구에 맞춰 변경한다.
- 변경된 부품을 새 시스템으로 통합한다.

---

📌 7-4. 유지보수 작업 과정

* 현재 프로그램의 이해
- 유지보수를 위한 변경 전에 변경할 소프트웨어에 대해 알아야 한다.
- 프로그램 로직을 추적하거나 요구, 설계 등에 대한 이해가 필요하다.
- 소스코드로부터 설계나 명세를 추출하는 작업이다.
- 상향식(Bottom-up) & 묶음화(Chunking) 원리를 사용한다.
- 상위 묶음(함수, 모듈, 프로시저), 하위 묶음(문장, 블록)

* 변경 파악과 분석
- 변경 요구를 기초로 어떤 부분을 변경할 지 찾아낸다.
- 변경 분석
- 여러가지 방안을 평가하고 추구해야 할 방안을 선택한다.
- 변경을 구현하고 결과를 테스트하는데 드는 비용과 시간을 예측한다.
- 리스크를 파악하고 해결채겡 대한 측정 방법을 정의한다.

* 변경 영향 파악
- 시스템 컴포넌트에 가해진 변경은 다른 컴포넌트에 영향을 줄 수 있다.
- 모듈이 변경되어 영향 받는 다른 모듈은 어던 것인지 파악한다.
- 변경의 이해당사자들에게 알리고 피드백을 얻어야 한다.
- 의존관계가 있다면 변경 시 영향이 간다.

* 변경 구현, 테스트, 설치
- 변경을 반영해서 시스템을 수정한다. (변경 구현)
- 시스템이 올바르게 변경되었는지 확인한다. (리그레션 테스트)
- 이후 설치를 진행한다.

---

📌 7-5. 소프트웨어 형상 관리

* 소프트웨어 형상
- 소프트웨어 개발 각 단계 또는 프로세스 마다 소프트웨어의 모습을 반영한 문서 산출물을 생산한다.
- 따라서 소프트웨어의 형상관리는 각 개발 단계의 산출물을 관리하는 모든 활동이다.

* 소프트웨어 형상 관리
- 개발 주기동안 생성된 문서를 관리하고 소프트웨어 시스템과 컴포넌트의 상태를 추적하는 작업이다.
- 소프트웨어 개발 및 유지보수 과정에서 발생하는 각종 결과물(소스코드, 문서, 인터페이스 등)에 대해서 형상을 만들고, 형상에 대한 변경을 체계적으로 관리, 제어하기 위한 활동이다.

* 소프트웨어 형상 관리 필요성
- 프로젝트는 요구사항의 변화가 많다.
- 산출물에 대한 수정 결과가 관련자들에게 제대로 통보되지 않는다.
- 많은 개발자들이 동일한 산출물에 대해 개별적으로 이중 작업을 실시한다.
- 하나의 산출물이 여러 개의 사본으로 존재해서 작업에 혼란을 초래할 수 있다.
=> 소프트웨어의 특징으로 인해 발생할 수 있는 위험을 최소화하기 위함이다.

* 소프트웨어 형상 관리 절차
1. 형상 식별: 형상 관리 대상을 구분, 베이스 라인의 기준을 정한다.
(1) 형상 항목 선정: 어떤 항목을 관리 대상으로 할지 결정한다.
- ex. 계획서, 요구사항명세서, 설계/인터페이스 명세서, 소스코드, 테스트 설계서
(2) 형상 식별자 규칙 선정: 어떤 프로젝트에서 사용되는 파일인지, 어떤 내용의 문서인지, 버전이 어떻게 되는지 알아볼 수 있도록 이름을 명명하는 규칙을 사용한다.
- ex. 파일이름_ver1.2
(3) 베이스라인 기준 선정: 소프트웨어 개발 과정 중 특정 시점에 만들어진 산출물의 집합을 선정한다.
- 프로젝트 진행의 중요한 상태를 정의한다.
- 프로젝트가 특정 상태에 이르렀는지 나타낸다.
- 계속되는 개발, 유지보수 작업의 기준 - 요구에 대한 베이스라인 설정 후 변경을 자유롭게 할 수 없다.
- 형상 항목에 대한 변경을 제어하는 메커니즘이다.
2. 형상 통제: 형상 변경 요청을 승인해서 베이스라인에 반영될 수 있도록 통제한다.
(1) 변경 요청: 변경 사항이 생겼을 때 변경 요청서를 작성해서 변경 관리 담당자에게 제출한다.
(2) 변경 심사: 형상 통제 위원회는 변경 요청서를 검토해서 변경 요청의 수락/거절을 결정한다.
(3) 변경 실시: 변경을 수락했으면 변경 작업을 수행한다. 변경을 위해서 보관중인 항목을 가져와서 변경 + 이력관리를 한다.
(4) 변경 확인: 변경 완료 시 개정 이력과 함께 새로운 버전 번호를 부여한다.
- 새롭게 저장된 변경 항목은 새로운 베이스라인으로 수립된다.
3. 형상 감사: 형상 항목의 변경이 계획에 따라 제대로 이뤄졌는지 검토/승인한다.
- 승인된 변경 요청이 제대로 반영되었는지 검증한다.
- 승인되지 않은 내용이 반영되었는지 검증한다.
- 승인된 변경과 관련된 항목들이 갱신되었는지 검증한다.
4. 형상 기록/보고: 소프트웨어 개발 상태에 대한 보고서를 제공한다.
- 베이스라인으로 설정된 형상 항목의 구조와 변경 상태를 기록한다.
- 관련된 사람들에게 보고한다.
- 내용: 변경 횟수, 베이스라인 상태, 변경 제어 상태 등

---

📌 7-6. 역공학

* 순공학 vs 역공학
- 순공학: 요구사항분석 -> 설계 -> 구현
- 역공학: 구현 -> 설계 -> 요구사항분석

* 역공학 (Reverse Engineering)
- 이미 만들어진 시스템을 역으로 추적해서 처음의 문제나 설계 기법 등의 자료를 얻어내는 일이다.
- 프로그램의 추상 수준을 점증적으로 복구해 나가는 과정이다.

* 역공학 필요성
- 현재 시스템의 유지봅수가 어려운 경우 -> 유지보수를 쉽게 할 수 있다.
- 변경이 빈번해서 시스템 효율이 저하된 경우 -> 효율을 높일 수 있다.
- 프로그램을 이해할 수 있다.
- 역공학에 의해 생성된 다이어그램은 유지보수하고 있는 소프트웨어의 구조, 기능, 동작의 이해를 용이하게 한다.
- 장점
- 상용화되거나 개발된 소프트웨어의 분석을 도와준다.
- 해당 프로그램의 내부동작과 설계 개념을 추적할 수 있다.
- 기존 시스템의 자료, 정보를 설계 수준에서 분석할 수 있다. -> 유지 보수성 향상
- 문제점
- 소스코드를 비롯한 전체적인 작동원리를 알아낼 수 있다. -> 의도적인 공격을 할 수 있다. -> 불법 프로그램 생성 및 게임 핵 프로그램 생성이 가능하다.

* 역공학 작업 순서
(1) 원시코드에서 소프트웨어 결과물을 추출 후 데이터 베이스에 저장한다. (input->output 관계를 저장)
(2) 파악된 각 요소를 다이어그램으로 그리기 위해서 레이아웃을 계산한다.
(3) 디스플레이 컴포넌트가 레이아웃에 따라 다이어그램으로 그린다.

* 리엔지니어링(Re-Engineering)
- 역공학에 의해 생성된 다이어그램은 리엔지니어링을 위해 사용된다.
- 리엔지니어링: 소프트웨어의 특정 측면을 개선하기 위해 재구축하는 과정이다.
- 소프트웨어는 지속적으로 변경된다. -> 시스템의 구조가 나빠진다. -> 유지보수의 비용이 높아진다. -> 유지보수 비용을 줄이기 위해서 재구조화한다.

* 리엔지니어링 목적
- 소프트웨어 아키텍처 개선
- 소프트웨어 복잡도 경감
- 변경에 대한 적응성 개선
- 성능, 효율성, 자원 유용성 개선
- 소프트웨어 시스템의 유지보수 개선

* 리엔지니어링 과정
- 개선이 필요한 위치 파악: 소프트웨어 분석을 통해서 개선이 필요한 위치를 파악한다.
- 개선 전략 선택: 소요 시간과 비용의 분석 결과를 기반으로 개선 전략을 선택한다.
- 제안된 개선의 구현: 리엔지니어링한 SW가 요구를 만족하는지 테스팅, 리그레션 테스팅을 실시한다.
- 목표를 기준으로 시스템을 평가: 목표와 대비해서 평가한다.

---