소프트웨어 공학 CH9. Evolution

Alpha, Orderly·2023년 5월 26일
0

소프트웨어 공학

목록 보기
9/9

Software evolution

Software change

  • 소프트웨어의 변경은 필연적이다.
    • 새로운 요구사항
    • 에러 수정
    • 새로운 시스템의 등장
    • 시스템의 전반적 성능 향상

Importance of evolution

  • 소프트웨어 시스템에 보통 큰 투자를 한다.
  • 그 자산들의 가치를 유지하기 위해선 변경점이 꾸준히 존재해야 한다.
  • 대기업 소프트웨어의 대부분은 새로운 개발보다는 유지보수에 초점을 둔다.


Evolution process

  • 진화 프로세스가 영향을 받는 요소
    • 소프트웨어의 유형
    • 조직의 소프트웨어 개발 프로세스
    • 관여하는 사람의 기술 혹은 경험
  • 변경 제안이 진화 프로세스를 주도한다.
    • 변경 요청 (Change Requests) 라고도 함
    • 구현되지 않은 기존 요구사항, 새로운 요구사항, 버그 보고, 개선을 위한 새로운 아이디어 등을 기반
    • 변경 제안을 받아들이기 전 변경해야 하는 컴포넌트를 분석, 변경 비용 및 변경의 영향을 추정할 수 있다.
  • 변경 식별 및 진화 프로세스는 시스템의 일생동안 계속 된다.




Change implementation

  • 변경사항을 디자인/구현/테스트
  • 첫번째 단계로 프로그램을 이해하는것이 필요, 특히 시스템 개발자와 변경 개발자가 다를시 중요하다.
  • 프로그램의 이해 단계에서 프로그램의 구조, 기능 제공법을 이해하고 변경이 미칠 영향성을 파악하는것이 중요하다.

Urgent change request

  • 긴급한 수정사항의 경우 모든 단계를 거치지 않고 진행될수 있다.
    • 긴급한 시스템 결함 : 정상 작동을 위해 고쳐질 필요가 있다.
    • OS 업그레이드와 같은 환경 변화 : 예기치 못한 부작용이 발생할수 있다.
    • 경쟁사 제품 출시와 같은 매우 빠른 응답이 필요한 사업적 변화


Agile and Evolution

  • Agile은 증분개발에 기반하기에, Evolution과 맥락을 같이한다.
  • 개발과 동시에 테스트를 추가 및 자동화 하는것이 중요하다.
  • 변경사항은 유저 스토리의 추가로 표현될수 있다.

Handover problem

프로그램은 Agile, 진화는 Plan-based

  • 진화 담당 팀이 Agile에서 제공하지 않는 자세한 문서를 필요로 할수 있다.

프로그램은 Plan-based, 진화는 Agile

  • Agile 진화 팀이 필요로 하는 변경 가능한 test가 있지 않을수 있다.

Legacy System

  • 레거시 시스템은 이전 기술/언어에 의존하며 새로운 시스템 개발에 더이상 쓰이지 않는것을 의미한다.
  • 고전 하드웨어에 의존적일수 있다.
  • 소프트웨어 시스템 뿐만 아니라 하드웨어, 라이브러리, 비즈니스 프로세스 등을 포함한다.

Legacy system replacement

  • 위험하고 값비싸다.
    • 완전한 명세서가 부족하다.
    • 시스템-비즈니스 프로세스 간 연관이 너무 강하다.
    • 문서화 되지 않은 기능이 있을수 있다.
    • 예산이 부족하다.
  • 값비싼 이유는 아래와 같다.
    • 고정된 프로그래밍 스타일이 없다.
    • 그 언어를 이해하는 사람이 적다.
    • 문서화가 부족하다.
    • 최적화가 이해 안될수 있다.
    • 데이터 에러 및 일관성이 없다.

Legacy System Management

  • 레거시 시스템에 변화를 주는 방법
    • 시스템을 버리고 비즈니스 프로세스를 개변한다.
    • 시스템을 보수한다.
    • re-engineering 을 통해 시스템을 변화해 유지보수성을 늘린다.
    • 새로운 시스템으로 교체한다.

  • 우하단 : 폐기 혹은 유지보수
  • 우상단 : 유지

Business value Assessment

  • 위의 business value를 측정하는것
    • 시스템 이용
      • 자주 사용되지 않을 경우 가치가 적다.
    • 지원되는 비즈니스 프로세스
      • 많은 프로세스를 지원할수록 가치가 크다.
    • 시스템 의존성
      • 시스템이 고객에 영향을 미치는것이 적을수록 가치가 적다.
    • 시스템 산출물
      • 산출물의 중요성에 따라 가치가 정해진다.

System Quality Assessment

  • 위의 System quality를 측정하는것
  • 시스템 확실성
  • 유지보수 난이도
  • 시스템 문서화에 관련된 다양한 요인들


System measurement

  • 정량화된 값들을 모으는것이 중요하다, 이들을 통해 system quality를 측정한다.
    • 변경 요구가 많을수록 퀄리티가 떨어진다.
    • 유저 인터페이스의 갯수가 많을수록 비일관적이고 복잡하다.
    • 시스템이 사용하는 데이터의 크기가 증가할수록 데이터에 에러 및 비일관성이 생길수 있다.
    • 이전 데이터를 버리는 과정은 매우 비싸고 시간이 많이 든다.

Software maintenance

  • 사용중인 프로그램을 변경하는것
  • 새로운 버전을 내는것에 해당한다.
  • 시스템 아키텍처에 큰 변화를 주지는 않는다.
  • 새로운 컴포넌트 추가 혹은 변경을 통해 발생한다.

Type of maintenance

  • Fault repair : 버그 수정
    • 버그 수정 및 취약점을 수정하는것
  • Environmental adaption : 플랫폼 적응
    • 다른 OS에서 작동할수 있도록 소프트웨어를 수정
  • Funtionally addition / modification
    • 새로운 요구사항에 맞춰 프로그램을 수정
    • 다수를 차지한다.

Maintenance cost

  • 개발 비용보다 유지보수 비용이 2~100배정도 더 든다.
  • 기술적 / 비기술적 요인에 영향을 받는다.
  • 유지보수가 진행될수록 소프트웨어가 복잡해져 비용이 더 들게 된다.
  • 개발 도중보다 유지보수때 새 기능을 추가하는것이 비용이 더 든다.
    • 새로운 팀이 유지보수 되는 프로그램을 이해해야 함
      • 기존 시스템에 대한 변경을 구현하기 전에 시스템을 이해하는 시간이 필요하다.
    • 유지보수와 개발의 분리는 개발 팀이 유지보수하기 쉬운 소프트웨어를 작성할 유인이 없음
      • 개발팀이 소프트웨어를 유지보수하기 쉽도록 만드는 데 노력을 투자하는 것에 대한 이득이 없기 때문이다.
    • 프로그램 유지보수를 좋아하지 않음
      • 프로그램이 오래될수록 구조가 저하되고 변경이 어려워짐
      • 프로그램에 변경이 가해짐에 따라 구조가 저하되는 경향이 있다 결과적으로 이해하고 변경하기 어렵다

Maintenence prediction

  • 유지 관리 예측은 시스템에서 높은 유지 관리 비용으로 이어질 수 있는 문제를 일으킬 가능성이 있는 부분을 평가하는 것과 관련이 있습니다.

Change prediction

  • 변경 요구의 갯수와 시스템-환경간 관계를 예측
  • 강하게 묶인 시스템은 환경 변화에 따라 변화가 요구된다.
    • 시스템/인터페이스의 복잡도 및 갯수에 따라 변화
    • 본질적으로 변동성이 큰 시스템 요구 사항 수에 따라 변화
    • 시스템이 사용하는 비즈니스 프로세스에 따라 변화

Complexity metrics

  • 유지보수성을 확인하기 위해 본다.
  • 아래에 영향을 받는다.
    • 관리 구조의 복잡도
    • 데이터 구조의 복잡도
    • 객체/메소드/모듈 크기

Process metrics

  • 유지보수성을 확인하기 위해 사용된다.
  • 아래에 영향을 받는다.
    • 유지보수 요청 건수
    • 분석에 걸리는 시간
    • 변경 요청 수락에 걸리는 시간
    • 미해결 변경 요청 수

Software reengineering

  • 기능을 유지하면서 일부 혹은 전부를 재 구축 혹은 재작성 하는 과정
  • 자주 유지보수가 필요할 경우 사용한다.
  • 유지보수성을 좋게 만든다.

장점

  • 새로운 개발보다 리스크가 적다.
  • 새로운 개발보다 비용이 적다.

과정

  • 소스 코드 변환 : 최신 버전이나 다른 언어로 변환
  • 역공학 (Reverse Engineering) : 프로그램을 분석하고 정보를 추출
  • 프로그램 구조 개선 : 프로그램 제어 구조의 개선
  • 프로그램 모듈화 : 중복성 제거 및 아키텍처 변환
  • 데이터 재공학 : 데이터베이스 스키마 재정의 , 데이터 정리

비용 추산

  • 소프트웨어 퀄리티
  • 지원되는 툴
  • 데이터 변환의 범위
  • 전문가가 있는지
profile
만능 컴덕후 겸 번지 팬

0개의 댓글