Ch09. 소프트웨어 진화

Ch09. 소프트웨어 진화

📌 [교재] 소프트웨어 공학 10판

[소프트웨어 변경] Software change

✅소프트웨어 변경은 불가피함

• SW를 사용하면서 새로운 요구사항이 생김
• 변화하는 비즈니스 환경에 적응
• 운영 중 발견된 오류를 수정
• 하드웨어와 소프트웨어 플랫폼이 변화
• 성능이나 신뢰성 등 비기능적 특성 개선

✅소프트웨어 진화의 중요성

• 조직의 소프트웨어는 중요한 비즈니스 자산
• 자산의 가치를 유지하기 위해서는 변경이 필요함
• 대규모 기업은 기존 시스템 유지보수에 더 많은 비용을 지출

(소프트웨어 비용은 60% 이상이 진화 비용)

9.1 진화 프로세스

[진화 프로세스] Evolution processes

✅진화 프로세스는 다음의 영향을 받음

• 소프트웨어의 유형
• 조직의 소프트웨어 개발 프로세스
• 관영하는 사람의 기술이나 경험

✅변경 제안(change proposals)이 시스템 진화를 주도

• 변경 요청(change requests) 이라고도 함
• 국현되지 않ㅇ느 기존 요구사항, 새로운 요구사항, 버그 보고, 개선을 위한 새로운 아이디어 등을 기반
• 변경 제안을 받아들이기 전 변경해야 하는 컴포넌트를 분석, 변경 비용 및 변경의 영향을 추정할 수 있음

✅변경 식별 및 진화 프로세스는 시스템의 일생 동안 계속됨

[변경 구현] Change implementation

✅개발과 진화가 통합되어 있는 경우

• 변경 구현은 개발 프로세스의 반복

✅개발과 진화가 다른 팀에 의해 수행되는 경우

• 변경 구현을 위해 프로그램을 이해하는 단계가 필요
• 프로그램의 구조와 제안된 변경이 프로그램에 미치는 영향을 이해

✅요구사항 명세와 설계 문서를 수정

• 새로운 요구사항을 기록, 분석, 확인해야 함
• UML 모델 등 설계 문서를 수정해야 함

✅변경 요구는 긴급하게 해결해야 하는 경우가 있음

• 요구사항과 설계를 수정하지 않고 프로그램을 긴급하게 수정
• 요구사항, 설계, 코드가 일치하지 않게 되는 결과 초래

[애자일 방법과 진화] Agile methods and evolution

✅애자일 방법과 진화

• 애자일 방법은 점증적인 개발이므로 개발과 진화가 매끄럽게 연결됨
• 진화는 잦은 시스템 릴리스를 기반으로 하는 개발 프로세스의 연속으로 생각될 수 O
• 테스트 주도 개발(TDD)과 자동화된 회귀 테스팅(reqression testing)은 시스템 변경이 있을 때 유용
• 시스템 변경은 사용자 스토리(user stories)로 표현할 수 있음
• 고객의 참여는 변경 사항의 우선 순위를 정하는데 도움이 될 수 있음
• 수행되어야 할 작업 목록에 초점을 맞추는 스크럼(Scrum) 접근법은 변경 사항의 우선순위를 정하는데 도움이 됨

9.2 레거시 시스템

[레거시 시스템] Legacy systems *용어**

✅레거시 시스템

• 더 이상 사용되지 않는 언어와 기술에 의존하는 기존 (옛날의) 구형 시스템

✅구성요소

• 시스템 하드웨어
• 지원 소프트웨어

: OS, 유틸리티, 컴파일러 등

• 애플리케이션 소프트웨어

: 다른 시기에 개발된 여러 개의 프로그램으로 구성

• 애플리케이션 데이터

: 막대한 양의 데이터가 존재할 수 있음

: 일관성이 없고 중복, 여러 데이터베이스에 걸침

• 비즈니스 프로세스

: 레거시 시스템의 기능에 의해 제약을 받음

[레거시 시스템 교체] Legacy system replacement

✅레거시 시스템의 문제점

• 기술(자) 부족: COBOL 프로그래머
• 보안 취약점: 인터넷 활용 이전 개발
• 인터페이스 문제: 최근의 프로그래밍 언어 시스템과의 인터페이스
• 하드웨어 유지보수 문제: 유지보수 비용이 증가

✅레거시 시스템을 교체하지 않는 이유

• 교체하는데 비용이 너무 많이 들 수 있음
• 교체하는 리스크가 너무 큼
• 레거시 시스템이 효과적으로 작동

✅레거시 시스템 교체가 비용이 많이 들고 리스크가 높은 이유

• 완전한 명세서가 없고 시스템의 변경 사항이 반영되어 있지 않음
• 비즈니스 프로세스와 레거시 시스템이 밀접하게 얽혀 동작함
• 중요한 비즈니스 규칙이 소프트웨어 안에 내장되어 있고 문서화 되어있지 않음
• 새로운 소프트웨어 시스템 개발은 리스크가 높으며 예상치 못한 문제가 발생할 수 있음.

개발이 오래 걸리고 예산을 초과할 수 있음

[1. 레거시 시스템 관리] Legacy system management

✅레거시 시스템 진화 선택 (4가지 옵션)

• 시스템의 완전한 폐기

: 비즈니스 프로세스가 변경되어 레거시 시스템에 의존하지 않을 때

• 정기적인 유지보수를 계속

: 시스템이 필요하고 안정적이며 변경 요청이 거의 없을 때

• 유지보수성을 향상시키기 위해 시스템 재공학

: 변경에 의해 시스템 품질이 저하되었지만 새로운 변경이 필요한 경우

• 시스템 전체나 일부를 새로운 시스템으로 대체

: 하드웨어 등의 요인으로 이전 시스템을 사용할 수 없을 때나 기성품 시스템을 이용하여 합리적인 비용으로 새로운 시스템을 개발할 수 있을 때

✅레거시 시스템 구분

• 낮은/높은 품질
• 낮은/높은 비즈니스 가치

9.3 소프트웨어 유지보수

[유지보수의 유형] Types of maintenance

• 3가지 상이한 유형의 SW 유지보수가 존재한다.

✅결합 수리 (fault repair)

• 버그와 취약점을 고침

✅환경 적응 (environmental adaptation)

• 새로운 플랫폼과 환경에 맞추기 위한 적응

✅기능성 추가 (Functionality addition)

• 새로운 기능을 추가하고 새로운 요구사항을 지원

▷ 그림(p.277) : 유지보수 노력의 분포

• 1980년부터 2005년까지 유지보수 비용 분포
• 유지보수 비용의 분포가 거의 변하지 않음

[기존 유지보수 유형 분류]

✅수정 유지보수 (corrective maintenance)

• 결함 수리

✅적응 유지보수 (adaptive maintenance)

• 새로운 환경, 새로운 요구사항에 적응

✅완전 유지보수 (perfective maintenance)

• 새로운 요구사항 구현 또는 시스템의 구조와 기능

✅예방 유지보수 (preventive maintenance)

• 장래 변경 시 발생할 수 있는 문제를 감소시킴

[유지보수 비용들] Maintenance costs

✅유지보수 과정에서 기능 추가하는 것이 개발 과정에서 구현하는 것보다 비용이 더 多

• 1) 새로운 팀이 유지보수 되는 프로그램을 이해해야 함
• 2) 유지보수와 개발의 분리는 개발 팀이 유지보수하기 쉬운 SW를 작성할 유인이 X - 3) 프로그램 유지보수를 좋아하지 않음
• 4) 프로그램이 오래될수록 구조가 저하되고 변경이 어려워짐

✅문제의 원인과 해결

• 많은 조직들이 개발과 유지보수를 별개의 활동으로 간주. 시스템이 개발 프로세스에서 계속 진화해 나간다고 생각해야 함
• 반복되는 수정에 의해 구조가 망가짐. 소프트웨어 재공학과 리팩토링을 적용

[1. 유지보수 예측]

[유지보수성 예측] Maintenance prediction

✅유지보수성(maintainability)를 평가할 수 있는 지표

• 수정(corrective) 유지보수를 위한 요청 횟수

: 유지보수 시 고쳐진 오류보다 새로 생긴 오류가 더 많아진 것 = 유지보수성 하락을 의미

• 영향 분석(impact analysis)에 필요한 평균 시간

: 영상 분석 시간이 증가하면 영향 받는 컴포넌트들이 많아진 것 =유지보수성 하락을 의미

• 변경 요청(change request)를 구현하는데 걸리는 평균 시간

: 변경을 구현하는데 걸리는 시간의 증가 = 유지보수성 하락을 의미

• 미해결된 변경 요청 개수

: 미해결 요청 개수가 증가 = 유지보수성 하락을 의미

[2. 소프트웨어 재공학] * 용어**

[소프트웨어 재공학] Software reengineering

✅소프트웨어 재공학

• 시스템의 전체 또는 일부를 재구조화하거나 다시 작성하는 것
• 기존 시스템의 기능을 변경하지 않고 시스템을 유지보수하기 쉽고 이해하기 쉽게 함
• 문서화, 아키텍처 개선, 프로그래밍 언어 변환, 데이터의 구조/값 수정 등

✅재공학 프로세스 활동

• 소스코드 변환 : 최신 버전이나 다른 언어로의 변화
• 역공학 (reverse engineering) ** :프로그램을 분석하고 정보를 추출

[요구사항 – 설계 – 구현 – 시험] 이 과정을 역으로 돌아가서 하는 것 =역공학 (reverse)

따라서 반복적 개발, 점증적 개발 시에는 역공학 불가피

• 프로그램 모듈화 : 중복성 제거 및 아키텍처 변환
• 데이터 재공학: 데이터베이스 스키마 재정의, 데이터 정리

[3. 리팩토링] * 용어**

✅리팩토링 (Refactoring)

• 변경에 따른 품질 저하를 늦추기 위하여 프로그램 (소스)을 개선하는 것
• 구조를 개선하고 복잡도를 줄이고 이해하기 쉽도록 프로그램을 수정
• 리팩토링에서는 프로그램의 기능을 추가하지 않으며 개선에 집중함

✅애자일 개발과 리팩토링

• 품질 저하를 방지하기 위해 잦은 리팩토링 필요

✅재공학과 리팩토링

• (+) 재공학은 ‘시스템’을, 리팩토링은 ‘소스코드 단위’의 개선이라고 생각
• 재공학은 일정 기간 유지보수 후 유지보수 비용이 증가하고 있을 때 수행
• 리팩토링은 개발과 진화 과정 전반에 걸친 연속적인 (잦은) 개선 프로세스

[리팩토링으로 개선할 수 있는 악취의 예] ‘Bad smells’ in program code

✅중복 코드 (duplicate code)

• 동일하거나 유사한 코드가 여러 곳에 있는 경우 메소드나 함수로 구현하여 호출

✅긴 메소드 (long methods)

• 길이가 너무 긴 메소드는 짧은 메소드들로 재설계

✅스위치(케이스)문 (switch statements)

• 다형성(polymorphism)으로 대체할 수 있는 경로

✅데이터 군집 (data clumping)

• 동일한 그룹의 데이터 항목이 여러 곳에서 나타날 때 데이터를 캡슐화하는 객첼로 대체

✅불확실한 일반성 (speculative generality)

• 앞으로 필요한 때를 대비하여 프로그램에 일반성을 포함시킨 경우 간단하게 제거