Software Evolution(진화)와 유지보수, 리팩토링, 리엔지니어링

Software Change

• Software change is inevitable: 소프트웨어는 계속해서 변화를 겪어야 한다. 소프트웨어 사용 중에 새로운 요구사항이 생기고, 비즈니스 환경이 변하며, 에러를 수정해야 하고, 새로운 컴퓨터나 장비가 시스템에 추가될 수 있다. 또한 시스템의 성능이나 신뢰성을 개선할 필요가 있을 수 있다.
• Key problem for organizations: 모든 조직에서 중요한 문제는 기존 소프트웨어 시스템에 변경을 구현하고 관리하는 것이다. 대기업의 경우, 소프트웨어 예산의 대부분은 새로운 소프트웨어 개발보다는 기존 소프트웨어의 변경과 발전에 사용된다.

---

A Spiral Model of Development and Evolution

• Spiral model은 소프트웨어 개발 및 진화에서 반복적인 과정을 강조하는 모델로, 개발이 점진적으로 이루어지고 새로운 요구사항과 변경사항이 지속적으로 반영된다. 이 모델은 개발과 진화가 반복적이고 점진적인 과정을 거쳐 이루어짐을 보여준다.

---

Evolution and Servicing

1. Evolution (진화):
   • 소프트웨어 시스템의 생애 주기에서 운영 중인 시스템이 새로운 요구사항에 맞춰 진화하는 단계이다. 이 과정에서 시스템은 계속해서 기능을 확장하고, 기존의 요구를 처리하며 발전한다.
2. Servicing (유지보수):
   • 이 단계에서 소프트웨어는 여전히 유용하지만, 주로 버그 수정과 환경 변화에 따른 적응을 위한 변경만 이루어진다. 새로운 기능은 추가되지 않으며, 기존 기능의 유지와 운영에 필요한 변경만 이루어진다.
3. Phase-out (단종):
   • 소프트웨어가 여전히 사용될 수 있지만, 더 이상 변경이 이루어지지 않는 상태이다. 시스템은 유지되지만 더 이상의 발전이나 기능 추가는 없으며, 주로 지원 종료를 의미한다.

---

Evolution Processes

• Software Evolution는 소프트웨어가 유지보수되고 발전하는 방식이다. 이 과정은 여러 요소에 따라 달라진다:
  • 유지보수하는 소프트웨어의 유형: 시스템의 성격에 따라 진화하는 과정이 달라진다.
  • 사용된 개발 프로세스: 개발 프로세스가 어떻게 설정되었는지에 따라 소프트웨어 진화가 영향을 받는다.
  • 사람들의 기술과 경험: 개발과 진화 과정에 참여하는 사람들의 경험에 따라 진화 방식도 달라질 수 있다.
• Proposals for change: 시스템 진화의 주요 동력은 변경 제안이다. 제안된 변경 사항은 영향을 받는 구성 요소와 연결되어야 하며, 변경의 비용과 영향을 추정할 수 있어야 한다. 또한, 변경 사항을 추적하고 진화하는 과정은 시스템의 생애 주기 동안 지속적으로 이루어진다.

---

The Software Evolution processes

 

---

Urgent Change Requests

• Urgent changes는 종종 소프트웨어 공학 프로세스를 전부 거치지 않고 즉시 적용해야 할 수 있다. 예를 들어:
  • 심각한 시스템 결함이 발견되어 정상적인 운영을 계속할 수 없을 때,
  • 시스템 환경(예: OS 업그레이드)의 변경이 예상치 못한 영향을 미쳤을 때,
  • 비즈니스 변경(예: 경쟁 제품 출시)으로 인해 빠른 대응이 필요한 경우 등이다.

---

Agile Methods and Evolution

• Agile methods는 점진적인 개발 방식을 채택하므로 개발과 진화 사이의 전환이 원활하게 이루어진다. 진화는 시스템의 자주적인 릴리스를 기반으로 개발 과정을 계속 이어가는 방식이다.
• Automated regression testing은 시스템 변경 시 매우 유용하다. 새로운 기능 추가나 변경이 기존 시스템에 미치는 영향을 확인할 수 있다.
• 변경 사항은 user stories로 표현될 수 있으며, Agile development teams가 유지되고 있다는 가정 하에 Handover 문제를 피할 수 있다.

---

Handover Problems

• Agile approach를 사용한 개발 팀이 있지만 evolution team이 Agile 방식에 익숙하지 않고 계획 기반의 접근 방식을 선호하는 경우, evolution team은 세부적인 문서를 요구할 수 있다. 하지만 Agile에서는 그런 문서가 제대로 생성되지 않기 때문에 문제가 발생할 수 있다.
• 반대로 계획 기반 접근을 사용한 개발 팀에서 evolution team이 Agile 방법을 선호하는 경우, automated tests를 새로 개발해야 할 수 있으며, 기존 코드가 refactor되지 않거나 단순화되지 않은 상태일 수 있어 Agile 개발 기대에 맞지 않을 수 있다.

---

Legacy Systems

Legacy systems는 더 이상 새로운 시스템 개발에 사용되지 않는 언어와 기술에 의존하는 오래된 시스템이다. 이러한 시스템은 구형 하드웨어 (예: 메인프레임 컴퓨터)에 의존할 수 있으며, 구형 프로세스와 절차들이 함께 사용될 수 있다.

또한 Legacy systems는 종종 넓은 사회 기술적 시스템의 일환으로, 하드웨어, 소프트웨어, 라이브러리 및 기타 지원 소프트웨어와 비즈니스 프로세스를 포함한다.

---

레거시 시스템의 요소들

1. System hardware (시스템 하드웨어):
   • Legacy 시스템은 더 이상 사용되지 않는 하드웨어에 맞춰 작성된 경우가 많다. 예를 들어, 오래된 메인프레임 컴퓨터나 특수 하드웨어에 의존하는 시스템들이 이에 해당한다.
2. Support software (지원 소프트웨어):
   • Legacy 시스템은 다양한 지원 소프트웨어에 의존할 수 있으며, 이 소프트웨어는 구식이거나 더 이상 지원되지 않는 경우가 많다. 이러한 소프트웨어의 유지 보수와 업데이트가 어려운 경우가 많다.
3. Application software (응용 소프트웨어):
   • 비즈니스 서비스를 제공하는 응용 시스템은 여러 개의 응용 프로그램으로 구성된다. 이러한 소프트웨어는 특정 비즈니스 요구를 충족시키기 위해 설계되었으나, 시간이 지나면서 최신 기술에 맞지 않거나 유지보수가 어려워진 경우가 많다.
4. Application data (응용 데이터):
   • Legacy 시스템에서 처리되는 데이터는 종종 불일치, 중복 또는 다른 데이터베이스에 분산되어 있을 수 있다. 이러한 데이터는 관리가 복잡하고 오류가 발생할 수 있다.
5. Business processes (비즈니스 프로세스):
   • 비즈니스 프로세스는 비즈니스 목표를 달성하기 위해 사용되는 과정들이다. Legacy 시스템은 이러한 비즈니스 프로세스가 설계되고, 그 기능에 의해 제약을 받는 경우가 많다.
6. Business policies and rules (비즈니스 정책과 규칙):
   • 비즈니스 정책과 규칙은 비즈니스 운영 방식을 정의하고, 비즈니스에 대한 제약을 설정하는 규칙들이다. Legacy 시스템은 이러한 정책과 규칙에 내장되어 있어, 시스템의 변경이 비즈니스 운영에 영향을 미칠 수 있다.

---

Legacy System Replacement and Change

Legacy 시스템 교체는 위험하고 비용이 많이 드는 작업이다. 그 이유는 다음과 같다:

• 시스템이 여전히 사용되고 있기 때문에 교체가 쉽지 않다.
• 시스템 사양이 완전하지 않음.
• 시스템과 비즈니스 프로세스가 강하게 통합되어 있음.
• 비즈니스 규칙이 문서화되지 않고 Legacy 시스템에 내장되어 있음.
• 새로운 소프트웨어 개발이 지연되거나 예산을 초과할 수 있음.

또한, Legacy 시스템 변경(수정)은 비용이 많이 든다. 그 이유는 다음과 같다:

• 일관되지 않은 프로그래밍 스타일.
• 구식 프로그래밍 언어 사용, 이에 해당하는 언어 능력을 가진 사람의 수가 매우 적음.
• 불충분한 시스템 문서화.
• 시스템 구조의 퇴화.
• 프로그램 최적화가 이루어져 있어 코드가 이해하기 어려운 경우가 많음.
• 데이터 오류, 중복, 불일치 문제 등.

---

Legacy System Management

Legacy 시스템 관리를 위한 전략을 선택하는 것은 매우 중요하다. 조직은 다음 중 하나의 전략을 선택해야 한다:

• 시스템을 완전히 폐기하고, 비즈니스 프로세스를 수정하여 시스템을 더 이상 필요하지 않도록 만든다.
• 시스템을 계속 유지한다.
• 시스템을 재구성하여 유지보수를 개선한다.
• 시스템을 새로운 시스템으로 교체한다.

---

Legacy System Assessment

Legacy 시스템의 상태를 평가하기 위해서는 비즈니스 가치 평가와 시스템 품질 평가가 필요하다. 평가 항목은 4가지 범주로 나눌 수 있다:

1. Low quality, low business value (저품질, 낮은 비즈니스 가치):
   • 이 시스템들은 폐기해야 한다.
2. Low quality, high business value (저품질, 높은 비즈니스 가치):
   • 이 시스템은 비즈니스에 중요한 기여를 하지만 유지보수 비용이 높다. 이런 시스템은 재구성하거나 적절한 시스템으로 교체해야 한다.
3. High quality, low business value (고품질, 낮은 비즈니스 가치):
   • 이 시스템은 COTS(상용 소프트웨어)로 교체하거나 폐기하거나 유지해야 한다.
4. High quality, high business value (고품질, 높은 비즈니스 가치):
   • 이 시스템은 정상적인 시스템 유지보수를 통해 계속 운영할 수 있다.

---

Software Maintenance

• Software Maintenance:
  소프트웨어 유지보수는 소프트웨어가 사용된 후 프로그램을 수정하는 과정을 의미한다. 주로 custom software의 변경을 위해 사용된다.
  • Generic software products는 새로운 버전을 만들기 위해 진화한다고 할 수 있다.
  • 변경 사항은 기존 구성 요소를 수정하거나 시스템에 새로운 구성 요소를 추가하여 구현된다.
  • 보통 시스템 아키텍처에 대한 주요 변경은 포함되지 않는다.

---

Types of Maintenance

1. Fault Repairs (결함 수정):
   • 시스템을 변경하여 버그나 취약점을 수정하고 요구사항을 충족하지 못한 부분을 고친다.
2. Environmental Adaptation (환경 적응):
   • 소프트웨어가 다른 운영 환경에서 작동할 수 있도록 유지보수한다.
   • 예를 들어, 시스템이 초기 구현 환경과 다른 컴퓨터나 운영 체제에서 작동할 수 있도록 시스템을 변경하는 과정이다.
3. Functionality Addition and Modification (기능 추가 및 수정):
   • 시스템을 수정하여 새로운 요구 사항을 만족시킨다.

---

Maintenance Costs

• Maintenance Costs는 보통 개발 비용보다 크다.
  • 예를 들어, 애플리케이션에 따라 2배에서 100배 이상 차이가 날 수 있다.
  • 기술적 및 비기술적 요인 모두 영향을 미친다.
  • 소프트웨어가 유지보수될수록 유지보수 비용은 증가한다.
  • 유지보수는 소프트웨어 구조를 손상시킬 수 있기 때문에, 추가 유지보수가 점점 더 어려워진다.
  • 오래된 소프트웨어는 높은 지원 비용을 초래할 수 있다 (예: 구식 언어, 컴파일러 등).

---

Maintenance Prediction

• Maintenance Prediction (유지보수 예측):
  시스템에서 어떤 부분이 문제를 일으킬 수 있는지, 그리고 유지보수 비용이 얼마나 들지 예측하는 과정이다.
  • change acceptance은 변경된 구성 요소의 유지보수성에 달려 있다.
  • 변경을 구현하면 시스템이 degrade되고, 유지보수성이 떨어진다.
  • 유지보수 비용은 변경 수와 변경 비용에 따라 달라진다.

---

Change Prediction

• Change Prediction (변경 예측):
  시스템과 환경 간의 관계를 예측하는 데 필요하다.
  • Tightly coupled systems에서는 환경이 변경될 때마다 시스템도 변경해야 한다.
  • 이 관계에 영향을 미치는 요소들은 다음과 같다:
    • 시스템 인터페이스의 수와 복잡성
    • 본질적으로 변동성이 큰 시스템 요구 사항의 수
    • 시스템이 사용되는 비즈니스 프로세스

---

Metrics for Change Prediction

• Metrics for Change Prediction (변경 예측을 위한 지표):
  
  • 이들 중 하나라도 증가하면 유지보수성이 감소했을 수 있다.
  • Process metrics:
    • 수정 유지보수 요청 수
    • 영향 분석에 필요한 평균 시간
    • 변경 요청을 구현하는 데 걸린 평균 시간
    • 미결 변경 요청 수
  • Complexity metrics:
    • 제어 구조의 복잡성
    • 데이터 구조의 복잡성
    • 객체, 메소드(절차), 모듈 크기

---

Software Reengineering

• Reengineering (소프트웨어 리엔지니어링):
  리엔지니어링은 기능을 변경하지 않고 레거시 시스템의 일부 또는 전체를 재구성하거나 다시 작성하는 것이다.
  • 일부 서브시스템이 자주 유지보수가 필요한 경우에 적용된다.
  • 리엔지니어링은 시스템을 더 쉽게 유지보수할 수 있도록 하는 데 필요한 추가 노력을 포함한다.
  • 시스템은 재구성되고, 문서화가 다시 이루어진다.
• Advantages of Reengineering (리엔지니어링의 장점):
  1. Reduced risk (위험 감소): 새로운 소프트웨어 개발에는 많은 위험이 존재한다. 개발 문제, 인력 문제, 사양 문제 등이 발생할 수 있다.
  2. Reduced cost (비용 감소): 리엔지니어링의 비용은 새로운 소프트웨어를 개발하는 비용보다 상당히 적다.

---

Reengineering Process Activities

1. Source code translation (소스 코드 번역):
   • 코드를 새로운 언어로 변환한다.
2. Reverse engineering (역공학):
   • 프로그램을 분석하여 시스템을 이해한다.
3. Program structure improvement (프로그램 구조 개선):
   • 이해하기 쉽게 자동으로 프로그램 구조를 재구성한다.
4. Program modularization (프로그램 모듈화):
   • 프로그램 구조를 재조직화한다.
5. Data reengineering (데이터 리엔지니어링):
   • 시스템 데이터를 정리하고 재구성한다

---

Refactoring

• Refactoring는 프로그램의 구조를 개선하거나 복잡성을 줄여서 변경을 통한 저하를 늦추는 과정이다. 이는 예방적 유지보수로, 미래에 발생할 수 있는 변경 문제를 줄이기 위한 노력이다.
• 리팩토링은 프로그램을 수정하여 구조를 개선하고, 복잡성을 줄이며, 프로그램을 더 이해하기 쉽게 만드는 작업이다. 이 과정에서는 기능 추가가 아니라 프로그램 개선에 집중한다.

Refactoring과 Reengineering

• Reengineering(재설계)은 시스템이 일정 기간 동안 유지보수된 후, 유지보수 비용이 증가할 때 수행된다. 이 과정에서는 자동화된 도구를 사용하여 구형 시스템(legacy system)을 처리하고, 더 유지보수가 용이한 새로운 시스템을 만든다.
• Refactoring은 개발과 진화 과정 내내 지속적으로 이루어지는 개선 과정이다. 이는 시스템을 유지보수하는 데 드는 비용과 어려움을 증가시키는 구조와 코드의 저하를 피하기 위한 작업이다.

---

‘Bad Smells’ in Program Code

• Duplicate code (중복 코드): 동일하거나 매우 유사한 코드가 프로그램 내 여러 곳에 포함되어 있을 수 있다. 이는 하나의 메서드나 함수로 묶어 필요한 곳에서 호출할 수 있도록 수정하여 제거할 수 있다.
• Long methods (긴 메서드): 메서드가 너무 길다면, 여러 개의 짧은 메서드로 다시 설계하는 것이 좋다.
• Switch (case) statements (Switch문): switch 문은 종종 값의 타입에 따라 중복이 발생하는 경우가 있다. 프로그램 곳곳에 분산되어 있을 수 있는데, 객체지향 언어에서는 다형성(polymorphism)을 활용하여 같은 작업을 할 수 있다.
• Data clumping (데이터 뭉치기): 동일한 데이터 항목(클래스의 필드, 메서드의 파라미터)이 여러 곳에서 반복되는 경우, 이들을 하나의 객체로 묶어서 대체할 수 있다.
• Speculative generality (추측적 일반화): 개발자가 미래에 필요할 수도 있다고 예상하여 프로그램에 일반성을 추가하는 경우가 있다. 그러나 대부분은 불필요한 코드로 제거할 수 있다.