소프트웨어 공학 - Chpater 9. 소프트웨어 진화

오늘은 9장을 업데이트 할것이다.

기준은 한티 미디어 소프트웨어 공학 제 10판이다.

소프트웨어 진화 목차

• 소프트웨어 진화
  • 진화 프로세스
  • 레거시 시스템
  • 소프트웨어 유지보수

Software Change [260p]

• 소프트웨어 변경은 불가피 하다
  • 소프트웨어를 사용하면서 새로운 요구사항이 생김
  • 변화하는 비즈니스 환경에 적응
  • 운영 중 발견된 오류를 수정
  • 하드웨어와 소프트웨어 플랫폼이 변화
  • 성능이나 신뢰성 등 비기능적 특성 개선
• 소프트웨어 진화의 중요성
  • 조직의 소프트웨어는 중요한 비즈니스 자산
  • 자산의 가치를 유지하기 위해서는 변경이 필요
  • 대규모 기업은 기존 시스템 유지 보수에 더 많은 비용을 지출
    • (소프트웨어 비용의 60% 이상이 진화 비용)

Evolution Process [263p]

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

Testing Process

Change Implementation [264~265p]

• 개발과 진화가 통합되어 있는 경우
  • 변경 구현은 개발 프로세스의 반복
• 개발과 진화가 다른 팀에 의해 수행되는 경우
  • 변경 구현을 위해 프로그램을 이해하는 단계가 필요
  • 프로그램의 구조와 제안된 변경이 프로그램에 미치는 영향을 이해
• 요구사항 명세와 설계 문서를 수정
  • 새로운 요구사항을 기록, 분석,
  • UML 모델 등 설계 문서를 수정해야 한다
• 변경 요구는 긴급하게 해결해야 하는 경우가 존재
  • 요구사항과 설계를 수정하지 않고 프로그램을 긴급하게 수정
  • 요구사항, 설계, 코드가 일치하지 않게 되는 결과를 초래

Agile methods and Evolution [265~266p]

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

Legacy Systems [266~267]

• 레거시 시스템
  • 더 이상 사용되지 않는 언어와 기술에 의존하는 시스템
• 레거시 시스템의 논리적 부분과 그 관계
  • 시스템 하드웨어
  • 지원 소프트웨어
    • OS, 유틸리티, 컴파일러 등
  • 애플리케이션 소프트웨어
    • 다른 시기에 개발된 여러 개의 프로그램으로 구성
  • 애플리케이션 데이터
    • 막대한 양의 데이터가 존재할 수 있다
    • 일관성 없고 중복된 여러 데이터베이스에 걸친다
  • 비즈니스 프로세스
    • 레거시 시스템의 기능에 의해 제약을 받는다

Leagcy System Replacement [268p]

• 레거시 시스템의 문제점
  • 기술(자) 부족
    • EX) COBOL 프로그래머
  • 보안 취약점
    • EX) 인터넷 활용 이전 개발
  • 인터페이스 문제
    • EX) 최근의 프로그래밍 언어 시스템과의 인터페이스
  • 하드웨어 유지 보수 문제
    • EX) 유지 보수 비용이 증가
• 레거시 시스템을 교체하지 않는 이유
  • 교체하는데 비용이 너무 많이 들 수 있다
  • 교체하는 리스크가 너무 클 경우
  • 레거시 시스템이 효과적으로 작동하는 경우
• 레거시 시스템 교체가 비용이 많이 들고 리스크가 높은 이유
  • 완전한 명세서가 없고 시스템의 변경 사항이 반영되어 있지 않음
  • 비즈니스 프로세스와 레거시 시스템이 밀접하게 얽혀 동작함
  • 중요한 비즈니스 규칙이 소프트웨어 안에 내장되어 있고 문서화 되어 있지 않음
  • 새로운 소프트웨어 시스템 개발은 리스크가 높으며 예상치 못한 문제가 발생 가능
  • 개발이 오래 걸리고 예산을 초과할 수 있다
• 레거시 시스템 진화 선택
  • 시스템의 완전한 폐기
    • 시스템이 비즈니스 프로세스에 효과적 기여를 하지 못하는 경우 선택
  • 시스템을 변경 없이 놔두고 정기적인 유지 보수를 계속
    • 시스템이 요구되지만 비교적 시스템 변경을 요하지 않는 경우 선택
  • 유지보수성을 향상시키기 위해 시스템을 재공학
    • 변경으로 인해 시스템 품질이 나빠지고, 변경이 여전히 요구되는 경우 선택
  • 시스템 전체나 일부를 새로운 시스템으로 대체
    • 구형 시스템을 더 이상 운영하지 못하거나 합리적인 가격으로 새로 개발 가능할 경우 선택
• 시스템의 4가지 구분
  • 낮은 품질, 낮은 비즈니스 가치 -> 폐기
  • 낮은 품질, 높은 비즈니스 가치 -> 재공학
  • 높은 품질, 낮은 비즈니스 가치 -> 유지보수 혹은 폐기
  • 높은 품질, 높은 비즈니스 가치 -> 유지보수
• 시스템의 비즈니스 가치 주제
  • 시스템 이용
  • 지원되는 비즈니스 프로세스
  • 시스템 확실성
  • 시스템 산출물
• 애플리케이션 시스템의 기술적 품질을 평가 하기 위해선
  • 시스템 확실성
  • 유지보수 난이도
  • 시스템 문서화에 관련된 다양한 요인들

을 평가해야 한다.

• 환경 평가에 이용되는 요인

Testing Process

• 애플리케이션 평가에 이용되는 요인들

Testing Process

Legacy System Managemnet [271p]

• 레거시 시스템 진화 선택
  • 시스템의 완전한 폐기
    • 비즈니스 프로세스가 변경되어 레거시 시스템에 의존하지 않을 때
  • 정기적인 유지보수를 계속
    • 시스템이 필요하고 안정적이며 변경 요청이 거의 없을 때
  • 유지보수성을 향상시키기 위해 시스템 재공학
    • 변경에 의해 시스템 품질이 저하되었지만 새로운 변경이 필요한 경우
  • 시스템 전체나 일부를 새로운 시스템으로 대체
    • 하드웨어 등의 요인으로 이전 시스템을 사용할 수 없을 때나 기성품 시스템을 이용하여 합리적인 비용으로 새로운 시스템을 개발할 수 있을 때
• 레거시 시스템 구분
  • 낮은 / 높은 품질
  • 낮은 / 높은 비즈니스 가치

Types of Maintenance [275~276p]

• 소프트웨어 유지보수 3 유형
  • 결함 수리 (Fault Repair)
    • 버그와 취약점을 고침
    • 코딩 오류는 보통 정정하는 데 적은 비용이 든다. 설계 오류는 여러 개의 프로그램 컴포넌트들을 다시 작성하는 것을 포함할 수 있으므로 더 많은 비용이 든다. 요구사항 오류는 광범위한 시스템 재설계가 필요할 수 있기 때문에 수정하는 데 가장 많은 비용이 든다
  • 환경 적응 (Environmental Adaption)
    • 새로운 플랫폼과 환경에 맞추기 위한 적응
    • 이러한 유형의 보수는 하드웨어, 플랫폼 운영체제, 다른 지원 소프트웨어와 같은 시스템 환경의 어떤 측면이 변할 때 필요하다. 이러한 환경의 변화에 대처하기 위해 애플리케이션 시스템이 수정되어야 할 수 있다.
  • 기능성 추가 (Functionality Addition)
    • 새로운 기능을 추가하고 새로운 요구사항을 지원
    • 이러한 유형의 유지보수는 조직이나 비즈니스 변화에 대응하기 위해 시스템 요구사항이 변할 때 필요하다. 소프트웨어 요구되는 변경의 규모는 종종 다른 유형의 유지보수 보다 훨씬 크다.
• 유지보수 비용 분포 -> 유지보수 비용의 분포는 거의 변하지 않음
  • 58% -> 기능성 추가
  • 24% -> 결함 수리
  • 19% -> 환경 적응
  • 시스템 결함을 수리하는 것이 가장 비용이 많이 드는 유지보수 활동이 아니다. 새로운 환경과 새롭거나 변경된 요구사항에 대처하기 위해 시스템을 진화시키는 것에 대부분의 유지보수 노력이 소모된다.
• 기존 유지보수 유형 분류
  • 수정 유지보수 (Corrective Maintenance)
    • 결함 수리
  • 적응 유지보수 (Adaptive Maintenance)
    • 새로운 환경, 새로운 요구사항에 적응
  • 완전 유지보수 (Perfective Maintenance)
    • 새로운 요구사항 구현 또는 시스템의 구조와 기능 개선
  • 예방 유지보수 (Preventive Maintenance)
    • 장래 변경 시 발생할 수 있는 문제를 감소시킴

Maintenance Costs [277~278p]

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

• 유지보수 과정에서 새로운 기능을 추가하는 것이 초기 개발 과정에서 동일한 기능을 구현하는 것보다 비용이 많이 드는 이유 4가지
  • 새로운 팀이 유지보수 되는 프로그램을 이해해야 함
    • 기존 시스템에 대한 변경을 구현하기 전에 시스템을 이해하는 시간이 필요하다.
  • 유지보수와 개발의 분리는 개발 팀이 유지보수하기 쉬운 소프트웨어를 작성할 유인이 없음
    • 개발팀이 소프트웨어를 유지보수하기 쉽도록 만드는 데 노력을 투자하는 것에 대한 이득이 없기 때문이다.
  • 프로그램 유지보수를 좋아하지 않음
  • 프로그램이 오래될수록 구조가 저하되고 변경이 어려워짐
    • 프로그램에 변경이 가해짐에 따라 구조가 저하되는 경향이 있다 결과적으로 이해하고 변경하기 어렵다
• 문제의 원인과 해결
  • 많은 조직들이 개발과 유지보수를 별개의 활동으로 간주, 시스템이 개발 프로세스에서 계속 진화해 나간다고 생각해야 한다
  • 반복되는 수정에 의해 구조가 망가짐, 소프트웨어 재공학과 리팩토링을 적용

• 대부분의 기업이 장기 유지보수 비용을 줄이기 위해 소프트웨어 개발에 더 많은 지출하는 것을 꺼리는 이유 2가지

  • 기업은 미지수의 미래 이익을 위해 돈을 지출하기를 꺼려한다.
  • 우지보수 비용을 절감할 수 있는 추가 작업을 수행함으로써 어떤 혜택도 받지 않기 때문에 작업을 할 이유가 없다.

Maintenance Prediction [281p]

• 시스템과 그 주변 환경 사이의 관계를 판단하기 위해서 살펴봐야 하는 것
  • 시스템 인터페이스의 개수와 복잡도
    • 인터페이스의 개수가 많아지고 복잡해질수록 새로운 요구사항이 제한되어 쓸 때 인터페이스 변경이 요구될 가능성이 높아진다
  • 본래 변하기 쉬운 시스템 요구사항의 개수
    • 4장 에서 설명한 것처럼 조직의 정책과 절차들을 반영하는 요구사항은 안정된 도메인 특성에 기초한 요구 사항보다 더 변하기 쉽다
  • 시스템이 사용되는 비즈니스 프로세스
    • 비즈니스 프로세스가 진화함에 따라 변경 요청이 발생하게 된다 시스템이 점점 더 많은 비즈니스 프로세스와 통합될 수 록 변경 요구가 증가한다
• 유지보수성 (Maintainability) 을 평가할 수 있는 지표
  • 수정 유지보수를 위한 요청 횟수
    • 유지보수 시 고쳐진 오류보다 새로 생긴 오류가 더 많아진 것이므로 유지보수성 하락을 의미
  • 영향 분석에 필요한 평균 시간
    • 영향 분석 시간이 증가하면 영향 받는 컴포넌트들이 많아진 것이므로 유지보수성 학을 의미
  • 변경 요청을 구현하는데 걸리는 평균 시간
    • 변경을 구현하는데 걸리는 시간의 증가는 유지보수성 하락을 의미
  • 미해결된 변경 요청 개수
    • 미해결 요청 개수가 증가하면 유지보수성 하락을 의미

Software Reengineering [281~283p]

• 소프트웨어 재공학 (Software Reengineering)
  • 시스템의 전체 또는 일부를 재구조화 하거나 다시 작성하는 것
  • 기존 시스템의 기능을 변경하지 않고 시스템을 유지보수 하기 쉽고 이해하기 쉽게 함
  • 문서화, 아키텍처 개선, 프로그래밍 언어 변환, 데이터의 구조와 값 수정 등
• 재공학 프로세스 활동
  • 소스 코드 변환 : 최신 버전이나 다른 언어로 변환
  • 역공학 (Reverse Engineering) : 프로그램을 분석하고 정보를 추출
  • 프로그램 구조 개선 : 프로그램 제어 구조의 개선
  • 프로그램 모듈화 : 중복성 제거 및 아키텍처 변환
  • 데이터 재공학 : 데이터베이스 스키마 재정의 , 데이터 정리
• 재공학이 교체에 비해 갖는 2가지 장점
  • 리스크 감소
    • 비즈니스에 중요한 소프트웨어를 다시 개발하는 것에는 매우 높은 리스크가 존재한다. 시스템 명세서에 오류가 생길 수도 잇고 개발에 문제가 있을 수도 있다,
  • 비용 절감
    • 새로운 소프트웨어를 개발하는 비용에 비해 재공학 비용은 상당히 적을 수 있다.

Refactoring [284~285p]

• 리팩토링
  • 변경에 따른 품질 저하를 늦추기 위하여 프로그램을 개선하는 것
  • 구조를 개선하고 복잡도를 줄이고 이해하기 쉽도록 프로그램을 수정
  • 리팩토링에서는 프로그램의 기능을 추가하지 않으며 개선에 집중
• 애자일 개발 (Agile) 과 리팩토링
  • 품질 저하를 방지하기 위해 리팩토링 필요
• 재공학과 리팩토링
  • 재공학은 일정 기간 유지보수 후 유지보수 비용이 증가하고 있을 때 수행
  • 리팩토링은 개발과 진화 과정 전반에 걸친 연속적인 개선 프로세스

‘Bad smells’ in Program code [284~285p]

• 리팩토링으로 개선할 수 있는 예
  • 중복 코드 (Duplicate Code)
    • 동일하거나 유사한 코드가 여러 곳에 있는 경우 메서드나 함수로 구현하여 호출
  • 긴 메서드 (Long Methods)
    • 길이가 너무 긴 메서드는 짧은 메서드들로 재설계
  • 스위치 (케이스) 문 (Switch Statements)
    • 다형성 (Polymorphism) 으로 대체할 수 있는 경우
  • 데이터 군집 (Data clumping)
    • 동일한 그룹의 데이터 항목이 여러곳에서 나타날 때 데이터를 캡슐화하는 객체로 대체
  • 불확실한 일반성 (Speculative Generality)
    • 앞으로 필요할 때를 대비하여 프로그램에 일반성을 포함시킨 경우 간단히 제거