[소프트웨어공학] 소프트웨어 진화 프로세스와 레거시 시스템

소프트웨어 진화

개발과 진화의 나선형 모델

 

• 소프트웨어 공학은 나선형 프로세스로 생각할 수 있음
  • 시스템의 수명동안 요구분석, 설계, 구현, 테스팅이 반복
    
    
• 지난 10년 동안 나선의 반복 사이 시간은 극적으로 줄어듦
• 경쟁자들의 압박과 사용자들의 피드백에 빠르게 반응해야 함
• 동일한 회사가 소프트웨어의 수명 동안 책임을 지는 경우에 적용 가능

 

 

 

 

 

맞춤식 소프트웨어의 진화

• 나선형 모델을 따르지 않음
  • 고객이 소프트웨어 지원과 진화를 감당
  • 고객이 시스템 지원과 진화를 담당하는 외부 회사와 별도 계약을 체결
    
    
• 진화 프로세스가 불연속적일 가능성 있음
  • 요구사항과 설계 문서가 한 기업에서 다른 기업으로 전달되지 않을 수 있음
    
    
• 소프트웨어 유지보수
  • 소프트웨어가 개발에서 진화로 매끄럽게 전이되지 않을 때,
    사용자에게 인도된 이후의 소프트웨어 변경 프로세스를 의미

 

 

 

진화와 서비스 제공

• 진화
  • 소프트웨어 아키텍처와 기능에 상당한 변경이 가해지는 단계
    • 중요한 변경과 새로운 요구사항의 구현이 점점 덜 비용 효과적이게 되는 전이점에 도달
      → 이 시점에서 소프트웨어는 진화에서 서비스 제공 단계로 이동
      
      
• 서비스 제공
  • 상대적으로 작지만 필수적인 변경만 가해지는 단계
  • 사용자는 문제를 발견할 경우 해당 문제를 피하는 차선책을 사용해야 함

 

 

 

 

 

진화 프로세스

• 소프트웨어마다 적합한 진화 프로세스가 다름
• 모바일 앱과 같은 유형의 시스템
  • 소프트웨어 진화가 정형화되지 않은 프로세스일 수 있음
  • 변경 요구는 주로 시스템 사용자들과 개발자들 사이의 대화로부터 나옴
    
    
• 중대한 시스템과 같은 유형의 시스템
  • 소프트웨어 진화가 프로세스 각 단계에서 생성되는 구조화된 문서를 가지도록 정형화될 수 있음
    
    
• 정형적 또는 비정형적 시스템 변경 제안이 시스템 진화를 주도
• 변경 및 식별 프로세스는 순환하고 시스템의 수명동안 계속됨

 

 

 

 

 

 

변경 식별과 진화 프로세스

 

 

 

 

시스템 진화 프로세스

• 기본적 활동 포함
  • 변경 분석, 릴리스 계획 수립, 시스템 구현, 고객에게 릴리스 등
    
    
• 변경의 비용 및 영향이 평가
• 제안된 변경이 수용되면서 새로운 릴리스가 계획됨
• 변경이 구현되고 확인되고 나면 시스템의 새로운 버전이 릴리스

 

 

 

 

 

개발과 진화의 통합/분리에 따른 특성

• 개발과 진화가 통합된 상황
  • 변경 구현은 단순히 개발 프로세스의 반복
  • 초기 개발과 진화의 차이
    • 인도 이후의 고객의 피드백이 애플리케이션의 새 릴리스를 계획할 때 고려되어야 함
      
      
• 개발과 진화가 상이한 팀에 의해 수행되는 경우
  • 변경 구현의 초기 단계가 프로그램의 이해를 필요로 한다는 점이 가장 중요한 특징
    • 구현된 변경이 기존 시스템 도입에 도입될 때 새로운 문제를 만들지 않도록 해야 함

 

 

 

 

 

변경 구현 프로세스

• 변경 구현 프로세스 중 요구된 변경을 반영하기 위해 명세서와 문서도 함께 업데이트해야 함
• 제안된 변경 : 변경의 영향 및 비용을 평가하는 변경 분석 프로세스의 일부분
  • 프로토 타이핑 가능

 

 

 

 

 

긴급한 수정 프로세스

• 발생 이유
  • 심각한 시스템 결함 감지
  • 운영 환경의 변화가 정상적인 운영을 중단시키는 예상치 못한 영향
  • 비즈니스 운영에 대한 예측하지 못한 변화

 

 

 

 

긴급한 수정 프로세스의 특징

• 요구사항, 소프트웨어 설계, 코드가 일치하지 않게 될 수도 있음
  • 긴급한 수정이 문서화보다 우선순위가 높음
    • 긴급한 수정이 계속되면 원래의 변경사항은 잊히고 시스템 문서와 코드는 재정비되지 않음
      
      
• 시스템 노후화 과정이 가속됨
  • 변경이 점차 더 어려워지고 유지보수 비용이 증가

 

 

 

 

 

애자일 방법에서의 진화

• 애자일 방법 및 프로세스는 점증적 개발을 기반으로 함
  • 개발자로부터 인도 후의 진화로 가는 전이가 매끄러워야 함
    
    
• 진화 프로세스에 적용 가능한 애자일 기법들
  • 테스트 주도 개발과 자동화된 회귀 테스트와 같은 기법은 시스템 변경 시 유용
  • 시스템 변경은 사용자 스토리로 표현될 수 있음
  • 고객의 참여는 변경 사항의 우선순위를 정하는데 도움
    
    
• 프로그램 유지보수 및 진화에 사용될 때에는 변형되어야 할 수도 있음

 

애자일 방법에서의 진화 적용 시 고려사항

• 개발과 진화를 담당하는 팀이 다를 경우 문제 발생
  • 개발 팀 → 애자일, 진화팀 → 계획 기반 접근
    = 진화 팀은 진화를 위한 자세한 문서가 있다고 생각하지만 없음
    
    
  • 개발 팀 → 계획 기반 접근, 진화팀 → 애자일
    = 진화 팀은 자동화된 테스트 개발을 처음부터 다시 시작해야 할 수도 있음

 

 

 

 

 

레거시 시스템

• 신형 시스템 개발에서는 더 이상 사용되지 않는 언어와 기술에 의존하는 구형 시스템
  • 오랜 기간 유지보수 되어옸고, 변경들로 인해 그 구조가 저하
    
    
• 메인프레임과 같은 구형 하드웨어에 의존적일 수도 있고, 레거시 프로세스 및 절차에 연관되어 있을 수 있음
• 효과적인 비즈니스 프로세스를 위한 변경이 불가능할 수 있음
  • 새로운 프로세스를 지원하기 위해 수정될 수 없기 때문
    
    
• 소프트웨어 시스템에 국한되지 않는 광범위한 사회기술적 시스템

 

레거시 시스템 구성요소

• 시스템 하드웨어
  • 더 이상 생산되지 않고, 유지보수 비용이 비싸며, 조직의 현재 IT 구매 정책과 호환되지 않는
    하드웨어에 대해 작성되어 있음.
    
    
• 지원 소프트웨어
  • 운영체제, 컴파일러 등은 다양한 지원 소프트웨어에 의존
    → 구식이며, 더 이상 원래 생산자에 의해 지원되지 않음.
    
    
    • 어떤 운영체제? → 하드웨어 생산자에 의해서 제공된 운영체제
    • 어떤 컴파일러? → 유틸리티부터 시스템 개발에 사용된 컴파일러
      
      
• 애플리케이션 소프트웨어
  • 비즈니스 서비스를 제공하는 애플리케이션 시스템은 상이한 시기에 개발된 여러 프로그램으로 구성됨
    → 이 프로그램 중 몇몇은 다른 애플리케이션 소프트웨어 시스템의 일부분이 될 것
    
    
• 애플리케이션 데이터
  • 애플리케이션 시스템에 의해서 처리된 데이터
    • 막대한 양의 데이터가 시스템의 수명 동안 쌓여옴
      
      
  • 일관성이 없으며, 여러 파일이 중복, 여러 개의 다른 데이터베이스에 걸쳐져 있을 수 있음
    
    
• 비즈니스 프로세스
  • 어떤 비즈니스 목적에 달성하기 위해 사용된 프로세스
    • 보험회사 - 보험 증권 발행하는 것
    • 제조공장 - 주문받고 관련된 제조 공정 설정하는 것
      
      
  • 레거시 시스템을 기반으로 설계되고 시스템이 제공하는 기능에 의해 제약받음
    
    
• 비즈니스 정책과 규칙
  • 비즈니스가 수행되는 방법과 비즈니스에 대한 제약을 정의
  • 레거시 애플리케이션 시스템의 사용은 이 정책과 규칙들에 내장

 

 

 

 

 

레거시 시스템 계층

• 계층 구조로 생각하는 방식 → 레거시 시스템의 컴포넌트를 보는 다른 관점

• 각 계층은 바로 아래에 있는 계층에 의존하고 그 계층과 연동
• 인터페이스가 유지되면, 인접한 계층들에 영향을 주지 않고 현재 계층 안에서 변경을 반영 가능

→ 이러한 캡슐화는 지나친 단순화이다.

• 이유 : 시스템의 한 계층을 변경하면 결과로 일어나는 변경이 아래위 계층으로 요구될 수도..
  • 시스템의 한 계층 변경하여 기능 도입 → 그 기능 이용하도록 상위 계층 변경
  • 소프트웨어 변경하면 시스템이 느려질 수도 있고, 시스템 성능 향상 위해 새로운 하드웨어가 필요
  • 새로운 하드웨어가 도입되면 하드웨어 인터페이스를 유지하는 것이 종종 불가능

 

 

 

 

레거시 시스템의 현황 및 문제점

• 얼마나 많은 레거시 코드가 아직 사용되고 있는지 정확히 알기 어려움
• 레거시 시스템을 유지보수하는 문제
  • 기술 부족 - 프로그래머 부족
  • 보안 취약점 - 인터넷이 광범위하게 사용되기 전에 개발되었기 때문
  • 현대적인 프로그램 언어로 작성된 시스템과 인터페이스 하는데 문제가 있음

 

 

 

 

레거시 시스템 교체

• 교체하기에는 비용이 너무 많이 들고 리스크가 너무 크기 때문에 레거시 시스템을 계속 운용
• 시스템 교체 리스크가 큰 이유
  • 레거시 시스템은 완전한 명세서가 없음
  • 비즈니스 프로세스와 레거시 시스템은 종종 서로 밀접하게 얽혀 동작
  • 중요한 비즈니스 규칙이 소프트웨어 안에만 내장되어 있고 다른 곳에는 설명되어 있지 않을 수도 있음
  • 새로운 시스템은 제 때에 예상된 가격에 제공되지 않을 수 있음

 

 

 

 

 

레거시 시스템 변경

• 레거시 소프트웨어 시스템 변경에 비용이 많이 드는 이유?
  1. 프로그램 스타일 및 규칙 일관성 X → 코드 이해 난해
  2. 시스템이 구식 프로그래밍 언어로 구현 → 언어에 대한 지식 있는 사람 찾기 어려움
  3. 시스템 문서가 불충분 ← 소스코드가 유일한 문서일 수도..
  4. 시스템 구조가 엉망진창 → 다년간의 유지보수 문제, 임시변통으로 인터페이스..
  5. 최적화된 소프트웨어는 이해하기 어려움
     → 기계 및 언어 최적화를 포항 한 어려운 소프트웨어일 확률이 높음
     
     
  6. 데이터 중복 혹은 이전 데이터, 부정확하거나 불완전할 수도 있음

 

 

 

 

 

레거시 시스템 관리 - 시스템 진화를 위한 가장 적합한 전략 결정

• 시스템의 완전한 폐기
  • 시스템이 비즈니스 프로세스에 효과적으로 기여못할 때 선택
    
    
• 시스템을 변경 없이 두고, 정기적인 유지 보수
  • 시스템이 여전히 요구되거나, 매우 안정적이고 시스템 변경이 거의 요구되지 않을 때 선택
    
    
• 유지보수성을 향상하기 위해 시스템을 재공학
  • 변경으로 인해 시스템 품질이 나빠지고 시스템에 대한 변경이 요구되는 경우 선택
    
    
• 시스템 전체나 일부를 새로운 시스템으로 대체
  • 구형 시스템을 계속 운영할 수 없을 때 선택
  • 기성품 시스템을 이용하여 합리적인 가격으로 새로운 시스템을 개발할 수 있을 때 선택
    
    

→ 비즈니스 가치와 시스템 품질을 바탕으로 전략 선택

 

 

 

 

 

레거시 시스템 평가

• 낮은 품질, 낮은 비즈니스 가치
  • 이 시스템들은 폐기
    
    
• 낮은 품질, 높은 비즈니스 가치
  • 비즈니스에 중요한 기여하기 때문에 폐기 X, 유지보수 비용 많이 들어감
  • 품질을 향상하기 위해 재공학되거나 적당한 기성품 시스템으로 교체되어야 함
    
    
• 높은 품질, 낮은 비즈니스 가치
  • 계속 사용하다가 비용이 많이 드는 유지보수가 필요해지면 폐기
    
    
• 높은 품질, 높은 비즈니스 가치
  • 계속 운영되어야 하며, 정상적인 시스템 유지보수가 계속되어야 함

 

 

 

 

 

비즈니스 가치

• 다른 시스템을 사용하는 것에 비해 그 시스템이 얼마나 효율적인지에 대한 척도
  
  
  
• 네 가지 주제
  • 시스템 이용
    • 시스템이 가끔 사용되거나, 소규모 팀이 사용 → 비즈니스 가치가 낮다.
      
      
  • 지원되는 비즈니스 프로세스
    • 시스템이 융통성이 없을 경우 비효율적인 비즈니스 프로세스 강제 → 비즈니스 가치 낮음
      
      
  • 시스템 확실성
    • 시스템을 믿을 수 없고, 문제가 고객에게 직접적인 영향 → 비즈니스 가치가 낮음
      
      
  • 시스템 산출물
    • 비즈니스가 시스템 산출물에 의해 좌우됨 → 비즈니스 가치가 높음

 

 

 

 

 

소프트웨어 시스템 평가

• 애플리케이션 시스템 자체와 그 시스템이 운영되는 환경 둘 다 고려할 필요가 있음
• 비즈니스 프로세스 평가
  • 관점 중심 접근 방식을 사용하여 시스템 이해 관계자로부터 답변을 받는 방식 활용
  • 비즈니스 프로세스가 비즈니스의 현재 목표에 얼마나 잘 지원하는가
    
    
• 환경 평가
  • 시스템의 환경이 얼마나 효과적이며, 유지보수 비용이 얼마나 되는가
  • 환경 - 시스템을 유지보수하는 데 필요한 하드웨어, 관련된 지원 소프트웨어, 개발 환경 포함
  • 시스템 변경이 곧 환경 변화의 결과이기 때문에 중요
  • 평가 과정 중 가능하다면, 시스템 및 시스템 변경에 대한 데이터를 수집해야 함
  • 평가에 이용되는 요인
    • 공급자 안정성, 고장률, 나이, 성능, 지원 요구사항, 유지보수 비용, 상호 운용성
      
      
• 애플리케이션 평가
  • 시스템 확실성, 시스템 유지보수 난이도, 시스템 문서화에 관련된 다양한 요인들을 평가
  • 시스템 품질을 판단하는데 도움이 되는 데이터
    
    • 시스템 변경 요구 횟수
      • 시스템 변경은 시스템 구조를 훼손시키고, 변경을 더욱 어렵게 만듦
      • 누적될수록 시스템 품질이 떨어짐
        
        
    • 사용자 인터페이스의 수
      • 개별 양식이 별도의 사용자 인터페이스로 간주될 수 있는 양식 기반 시스템에서 중요한 요인
      • 인터페이스가 많을수록 인터페이스들 간에 비일관성과 중복성이 있을 가능성 높음
        
        
    • 시스템이 이용하는 데이터의 양
      • 시스템에 의해 처리되는 데이터의 양이 증가할수록 비일관성과 오류가 증가
        
        
  • 평가에 이용되는 요인
    • 이해가능성, 문서화, 데이터, 성능, 프로그래밍 언어, 형상관리, 테스트 데이터, 개인의 기술