새로운 요구사항이 발생하고, 비즈니스 환경이 변화하고, 오류를 수정해야 하고, 시스템에 새로운 장비가 추가되기 때문에
소프트웨어의 변경은 불가피하다.
이렇게 조직에게 핵심 문제는 기존 소프트웨어 시스템에 대한 변경을 실행하고 관리하는 것이다.
대기업에서는 개발보다 기존 소프트웨어의 유지보수로 비용을 사용한다.
진화
- 소프트웨어 시스템이 운영 중이며 시스템에 새로운 요구사항이 제안되고 구현되는 동안 소프트웨어 시스템 수명
주기의 단계
유지보수
- 이 단계에서 소프트웨어는 여전히 유용하지만 운영을 유지하기 위해 버그 수정 및 소프트웨어 환경 변경을 반영하는
변경사항만이 이루어진다. (기능 추가는 X)
폐기 단계
- 사용가능하지만 , 더 이상 변경은 못함
소프트웨어 진화 과정은 유지보수 되는 소프트웨어의 종류, 사용되는 개발 프로세스 등에 의존한다.
긴급한 변경 사항은 소프트웨어 공학 프로세스의 모든 단계를 거치지 않고 구현되어야 할 수 있다.
여기서 긴급한 변경 사항이란
- 정상적인 운영을 계속하기 위해 심각한 시스템 오류를 복구해야 할 경우
- 시스템 환경의 변경이 예상치 못한 영향을 미칠 경우
- 경쟁 제품의 출시와 같이 매우 신속한 대응을 필요로 하는 비즈니스 변화가 있는 경우
애자일 방법론은 점진적인 개발에 기반을 하고 있어서, 개발에 진화로의 전환은 원할학 ㅔ이루어진다.
Handover problems
개발팀이 애자일 접근 방식을 사용했지만, 진화팀은 계획 접근 방식을 선호하는 경우
즉 서로 선호하는 방식이 다른 경우
레거시 시스템
- 레거시 시스템은 새로운 시스템 개발에 더 이상 사용되지 않는 언어와 기술에 의존하는 오래된 시스템
- 단순히 소프트웨어 시스템이 아니라 하드웨어, 소프트웨어, 라이브러리 및 기타 지원 소프트웨어와 비즈니스 프로세스를 포함한 보다 포괄적인 사회 기술 시스템
Legacy system 구성요소
- 시스템 하드웨어 : 레거시 시스템은 더 이상 이용되지 않는 하드웨어를 위해 작성될 수 있다.
- 지원 소프트웨어 : 레거시 시스템은 다양한 지원 소프트웨어에 의존할 수 있으며, 이러한 소프트웨어는 쓸모 없다니 지원이 중단될 수 있다.
- 응용 소프트웨어 : 비즈니스 서비스를 제공하는 응용 시스템은 일련의 응용프로그램으로 구성되어 있다.
- 응용 데이터 : 응용 시스템에서 처리되는 데이터
- 비즈니스 프로세스 : 비즈니스 목표를 달성하기 위해 비즈니스에서 사용되는 프로세스
- 비즈니스 프로세서는 레거시 시스템을 기반으로 설계되며, 제공되는 기능에 따라 제약을 받을 수 있다.
레거시 시스템 교체는 위험하고 비요이 많이 들기 때문에 계속 사용
왜 비용이 많이 들까?
- 일관된 프로그래밍 스타일이 없다.
- 적은 인력으로 사용 가능한 오래된 프로그래밍 언어를 사용
- 불충분한 시스템 문서화
- 시스템 구조의 저하
- 프로그램 최적화로 인해 이해하기 어려움
- 데이터 오류, 중복 및 일관성 부족
레거시 시스템 종류
- 품질이 낮고 비즈니스 가치가 낮은 경우
- 이러한 시스템은 폐기되어야 함.
- 품질이 낮지만 비즈니스 가치가 높은 경우
- 이러한 시스템은 중요한 비즈니스 기여를 하지만 유지 비용이 높다
적합한 시스템으로 대체
- 이러한 시스템은 중요한 비즈니스 기여를 하지만 유지 비용이 높다
- 품질이 높지만 비즈니스 가치가 낮은 경우
- COTS로 대체, 폐기 유지
- 품질이 높고 비즈니스가치가 높은 경우
- 정상적인 시스템 유지보수를 통해 계속해서 운영
시스템 평가
- 시스템의 품질을 평가하기 위해 데이터
- 시스템 변경 요청의 수 : 누적 값이 높을수록 시스템의 품질이 낮을 가능성이 높다
- 인터페이스 수 : 인터페이슥 ㅏ많을수록 인터페이스 간의 일관성과 중복성이 증가할 가능성이 높다
- 데이터 양: 시스템이 처리하는 데이터의 양이 증가하면 오류와 데이터 불일치가 증가
- 오래된 데이터 정리는 매우 비용이 많이 들고 시간이 많이 소요됨.
소프트웨어 유지
- 프로그램이 사용된 후에 수정하는 것을 말한다.
- 맞춤형 소프트웨어를 변경하는 데 사용됨.
- 유지보수는 일반적으로 시스템 아키텍처에 대한 큰 변경을 포함하지 않는다.
- 변경사항은 기존 구성 요소를 수정하고 시스템에 새로운 구성요소를 추가하여 구현
유지의 종류
- 결함 수리
- 시스템은 수정. 버그 취약점을 수정하고 요구사항을 충족시키는 데 있어서의 결함을 수정
- 환경 적응
- 소프트웨어를 다른 운영 환경에 적응시키기 위한 유지보수
- 초기 구현과는 다른 환경에서 시스템이 작동하도록 변경하는 것
- 기능 추가 및 수정
- 새로운 요구사항을 충족시키기 위해 시스템을 수정하는 것
유지보수 비용은 일반적으로 개발 비용보다 크고, 할수록 비용이 증가한다.
새로운 기능을 추가하는 것보다 더 많은 비용이 든다.
유지보수 비용은 변경의 수와 변경비용이 유지 가능성에 따라 달라진다.
변경의 수를 예측하려면 시스템과 그 환경 간의 관계를 이해해야 한다.
강하게 결합된 시스템은 환경이 변화될 때마다 변경이 필요하다.
영향을 주는 요소
- 인터페이스의 수와 복잡성
- 본질적으로 불안정한 시스템 요구사항의 수
- 시스템을 사용하는 비즈니스 프로세스
Complexity metrics
- 유지가능성의 예측은 시스템 구성 요소의 복잡성을 평가하여 할 수 있다.
- 유지보수 작업은 상대적으로 적은 수의 시스템 구성요소에 소요된다.
- 제어 구조의 복잡성
- 데이터 구조의 복잡성
- 객체, 메서드 및 모듈의 크기
Process metrics
- 유지가능성을 평가하기 위해 프로세스 지표를 사용할 수 있다.
- 수정 유지보수 요청의 수
- 영향 분석에 필요한 평균 시간
- 변경 요청의 구현에 소요된 평균 시간
- 처리되지 않는 변경 요청의 수
- 이러한 지표 중 하나 이상이 증가하면 유지가능성의 저하
Software Reengineering
- 기능을 변경하지 않고 레거시 시스템의 일부 또는 전체를 재구성, 재작성
- 더 큰 시스템의 일부 하위시스템이 빈번한 유지보수가 필요한 경우
- 재공학은 유지보수를 보다 쉽게 하기 위한 노력이다.
이점
- 위험성이 감소함.
- 새로운 소프트웨어 개발에는 높은 위험이 따르기 때문(개발, 인력, 명세서)
- 감소된 비용
- 재공학의 비용은 새로운 개발비용보다 상당히 적다.
활동
- 소스 코드 변환
- 코드를 새로운 언어로 변환
- 역 공학
- 프로그램을 분석하여 이해
- 프로그램 구조 개선
- 이해하기 쉽도록 자동으로 구조를 재구성
- 프로그램 모듈화
- 프로그램 구조를 재조직
- 데이터 재공학
- 시스템 데이터를 정리하고 재구조화
Reengineering 비용 결정 요소
- 재공학 대상 소프트웨어의 품질
- 재공학을 지원하는 도구의 가용성
- 필요한 데이터 변환의 범위
- 재공학을 위한 전문 인력의 가용성
리펙토링
- 프로그램의 저하를 줄이기 위해 개선을 가하는 과정
- 미래의 변경에 대한 문제를 줄이는 '예방적인 유지보수'로 생각할 수 있다.
- 리팩터링은 프로그램의 구조를 개선하고 복잡성을 감소시키거나 이해하기 쉽도록 수정
- 프로그램을 리팩터링 할 때 기능을 추가하는 것이 아닌, 프로그램 자체를 개선하는 데 집중
리엔지니어링은 시스템이 일정기간 동안 유지보수되고 유지보수 비용이 증가하는 상황에서 진행
-> 유지보수가 더 용이한 시스템을 생성하는 것이 목표
리팩터링은 개발 및 진화 과정 전반에 걸쳐 지속적으로 개선하는 과정
-> 시스템의 구조와 코드 저하를 피하고 유지보스의 비용과 어려움이 증가하지 않도록 한다.
안 좋은 행동
- 중복코드
- 동일하거나 유사한 코드가 여러 위치에 포함 -> 제거하고 필요할 때 호출하는 메서드나 함수로 구현해라
- 긴 메소드
- 메서드가 너무 길다면 여러 개의 짧은 메서드로 재설계
- Switch
- 이해하기 어려우므로, 다형성을 이용해서 제거
- 데이터 클럼핑
- 데이터를 캡슐화하는 객체로 대체
- 추측적 일반성
- 개발자들이 미래에 필요한 경우를 대비하여 프로그램에 일반성을 포함하는 경우 발생
요약
- 소프트웨어 개발 및 진화는 통합된 반복적인 과정으로 생각할 수 있다.
- 맞춤 시스템의 경우 소프트웨어 유지보수 비용이 일반적으로 소프트웨어 개발 비용을 초과한다.
- 소프트웨어 진화 과정은 변경 요청에 의해 주도되며, 변경 영향 분석, 릴리스 계획 및 변경 구현이 포함된다.
- 레거시 시스템은 구식 소프트웨어 및 하드웨어 기술을 사용하여 개발된 오래된 소프트웨어 시스템으로 비즈니스에서 여전히 유용
- 레거시 시스템을 유지하는 것은 현대 기술을 사용하여 대체 시스템을 개발하는 것보다 비용이 적고 위험이 적다.
- 버그 수정, 새로운 환경에서 작동하도록 소프트웨어 수정, 새로운 , 변경된 요구사항의 구현 등 3가지 유형의 유지보수가 있다.
- 재공학은 소프트웨어를 재구조화하고 재문서화하여 이해와 변경이 용이하도록 하는 것에 관련이 있다.
- 기능을 유지한 채로 프로그램 변경을 수행하는 리팩토링은 예방적인 유지보수의 한 형태
'Computer Science > Software Engineering' 카테고리의 다른 글
[소프트웨어 공학] - 소프트웨어 테스팅 (0) | 2023.06.07 |
---|---|
[소프트웨어 공학] - 아키텍처 설계 (0) | 2023.06.06 |
새로운 요구사항이 발생하고, 비즈니스 환경이 변화하고, 오류를 수정해야 하고, 시스템에 새로운 장비가 추가되기 때문에
소프트웨어의 변경은 불가피하다.
이렇게 조직에게 핵심 문제는 기존 소프트웨어 시스템에 대한 변경을 실행하고 관리하는 것이다.
대기업에서는 개발보다 기존 소프트웨어의 유지보수로 비용을 사용한다.
진화
- 소프트웨어 시스템이 운영 중이며 시스템에 새로운 요구사항이 제안되고 구현되는 동안 소프트웨어 시스템 수명
주기의 단계
유지보수
- 이 단계에서 소프트웨어는 여전히 유용하지만 운영을 유지하기 위해 버그 수정 및 소프트웨어 환경 변경을 반영하는
변경사항만이 이루어진다. (기능 추가는 X)
폐기 단계
- 사용가능하지만 , 더 이상 변경은 못함
소프트웨어 진화 과정은 유지보수 되는 소프트웨어의 종류, 사용되는 개발 프로세스 등에 의존한다.
긴급한 변경 사항은 소프트웨어 공학 프로세스의 모든 단계를 거치지 않고 구현되어야 할 수 있다.
여기서 긴급한 변경 사항이란
- 정상적인 운영을 계속하기 위해 심각한 시스템 오류를 복구해야 할 경우
- 시스템 환경의 변경이 예상치 못한 영향을 미칠 경우
- 경쟁 제품의 출시와 같이 매우 신속한 대응을 필요로 하는 비즈니스 변화가 있는 경우
애자일 방법론은 점진적인 개발에 기반을 하고 있어서, 개발에 진화로의 전환은 원할학 ㅔ이루어진다.
Handover problems
개발팀이 애자일 접근 방식을 사용했지만, 진화팀은 계획 접근 방식을 선호하는 경우
즉 서로 선호하는 방식이 다른 경우
레거시 시스템
- 레거시 시스템은 새로운 시스템 개발에 더 이상 사용되지 않는 언어와 기술에 의존하는 오래된 시스템
- 단순히 소프트웨어 시스템이 아니라 하드웨어, 소프트웨어, 라이브러리 및 기타 지원 소프트웨어와 비즈니스 프로세스를 포함한 보다 포괄적인 사회 기술 시스템
Legacy system 구성요소
- 시스템 하드웨어 : 레거시 시스템은 더 이상 이용되지 않는 하드웨어를 위해 작성될 수 있다.
- 지원 소프트웨어 : 레거시 시스템은 다양한 지원 소프트웨어에 의존할 수 있으며, 이러한 소프트웨어는 쓸모 없다니 지원이 중단될 수 있다.
- 응용 소프트웨어 : 비즈니스 서비스를 제공하는 응용 시스템은 일련의 응용프로그램으로 구성되어 있다.
- 응용 데이터 : 응용 시스템에서 처리되는 데이터
- 비즈니스 프로세스 : 비즈니스 목표를 달성하기 위해 비즈니스에서 사용되는 프로세스
- 비즈니스 프로세서는 레거시 시스템을 기반으로 설계되며, 제공되는 기능에 따라 제약을 받을 수 있다.
레거시 시스템 교체는 위험하고 비요이 많이 들기 때문에 계속 사용
왜 비용이 많이 들까?
- 일관된 프로그래밍 스타일이 없다.
- 적은 인력으로 사용 가능한 오래된 프로그래밍 언어를 사용
- 불충분한 시스템 문서화
- 시스템 구조의 저하
- 프로그램 최적화로 인해 이해하기 어려움
- 데이터 오류, 중복 및 일관성 부족
레거시 시스템 종류
- 품질이 낮고 비즈니스 가치가 낮은 경우
- 이러한 시스템은 폐기되어야 함.
- 품질이 낮지만 비즈니스 가치가 높은 경우
- 이러한 시스템은 중요한 비즈니스 기여를 하지만 유지 비용이 높다
적합한 시스템으로 대체
- 이러한 시스템은 중요한 비즈니스 기여를 하지만 유지 비용이 높다
- 품질이 높지만 비즈니스 가치가 낮은 경우
- COTS로 대체, 폐기 유지
- 품질이 높고 비즈니스가치가 높은 경우
- 정상적인 시스템 유지보수를 통해 계속해서 운영
시스템 평가
- 시스템의 품질을 평가하기 위해 데이터
- 시스템 변경 요청의 수 : 누적 값이 높을수록 시스템의 품질이 낮을 가능성이 높다
- 인터페이스 수 : 인터페이슥 ㅏ많을수록 인터페이스 간의 일관성과 중복성이 증가할 가능성이 높다
- 데이터 양: 시스템이 처리하는 데이터의 양이 증가하면 오류와 데이터 불일치가 증가
- 오래된 데이터 정리는 매우 비용이 많이 들고 시간이 많이 소요됨.
소프트웨어 유지
- 프로그램이 사용된 후에 수정하는 것을 말한다.
- 맞춤형 소프트웨어를 변경하는 데 사용됨.
- 유지보수는 일반적으로 시스템 아키텍처에 대한 큰 변경을 포함하지 않는다.
- 변경사항은 기존 구성 요소를 수정하고 시스템에 새로운 구성요소를 추가하여 구현
유지의 종류
- 결함 수리
- 시스템은 수정. 버그 취약점을 수정하고 요구사항을 충족시키는 데 있어서의 결함을 수정
- 환경 적응
- 소프트웨어를 다른 운영 환경에 적응시키기 위한 유지보수
- 초기 구현과는 다른 환경에서 시스템이 작동하도록 변경하는 것
- 기능 추가 및 수정
- 새로운 요구사항을 충족시키기 위해 시스템을 수정하는 것
유지보수 비용은 일반적으로 개발 비용보다 크고, 할수록 비용이 증가한다.
새로운 기능을 추가하는 것보다 더 많은 비용이 든다.
유지보수 비용은 변경의 수와 변경비용이 유지 가능성에 따라 달라진다.
변경의 수를 예측하려면 시스템과 그 환경 간의 관계를 이해해야 한다.
강하게 결합된 시스템은 환경이 변화될 때마다 변경이 필요하다.
영향을 주는 요소
- 인터페이스의 수와 복잡성
- 본질적으로 불안정한 시스템 요구사항의 수
- 시스템을 사용하는 비즈니스 프로세스
Complexity metrics
- 유지가능성의 예측은 시스템 구성 요소의 복잡성을 평가하여 할 수 있다.
- 유지보수 작업은 상대적으로 적은 수의 시스템 구성요소에 소요된다.
- 제어 구조의 복잡성
- 데이터 구조의 복잡성
- 객체, 메서드 및 모듈의 크기
Process metrics
- 유지가능성을 평가하기 위해 프로세스 지표를 사용할 수 있다.
- 수정 유지보수 요청의 수
- 영향 분석에 필요한 평균 시간
- 변경 요청의 구현에 소요된 평균 시간
- 처리되지 않는 변경 요청의 수
- 이러한 지표 중 하나 이상이 증가하면 유지가능성의 저하
Software Reengineering
- 기능을 변경하지 않고 레거시 시스템의 일부 또는 전체를 재구성, 재작성
- 더 큰 시스템의 일부 하위시스템이 빈번한 유지보수가 필요한 경우
- 재공학은 유지보수를 보다 쉽게 하기 위한 노력이다.
이점
- 위험성이 감소함.
- 새로운 소프트웨어 개발에는 높은 위험이 따르기 때문(개발, 인력, 명세서)
- 감소된 비용
- 재공학의 비용은 새로운 개발비용보다 상당히 적다.
활동
- 소스 코드 변환
- 코드를 새로운 언어로 변환
- 역 공학
- 프로그램을 분석하여 이해
- 프로그램 구조 개선
- 이해하기 쉽도록 자동으로 구조를 재구성
- 프로그램 모듈화
- 프로그램 구조를 재조직
- 데이터 재공학
- 시스템 데이터를 정리하고 재구조화
Reengineering 비용 결정 요소
- 재공학 대상 소프트웨어의 품질
- 재공학을 지원하는 도구의 가용성
- 필요한 데이터 변환의 범위
- 재공학을 위한 전문 인력의 가용성
리펙토링
- 프로그램의 저하를 줄이기 위해 개선을 가하는 과정
- 미래의 변경에 대한 문제를 줄이는 '예방적인 유지보수'로 생각할 수 있다.
- 리팩터링은 프로그램의 구조를 개선하고 복잡성을 감소시키거나 이해하기 쉽도록 수정
- 프로그램을 리팩터링 할 때 기능을 추가하는 것이 아닌, 프로그램 자체를 개선하는 데 집중
리엔지니어링은 시스템이 일정기간 동안 유지보수되고 유지보수 비용이 증가하는 상황에서 진행
-> 유지보수가 더 용이한 시스템을 생성하는 것이 목표
리팩터링은 개발 및 진화 과정 전반에 걸쳐 지속적으로 개선하는 과정
-> 시스템의 구조와 코드 저하를 피하고 유지보스의 비용과 어려움이 증가하지 않도록 한다.
안 좋은 행동
- 중복코드
- 동일하거나 유사한 코드가 여러 위치에 포함 -> 제거하고 필요할 때 호출하는 메서드나 함수로 구현해라
- 긴 메소드
- 메서드가 너무 길다면 여러 개의 짧은 메서드로 재설계
- Switch
- 이해하기 어려우므로, 다형성을 이용해서 제거
- 데이터 클럼핑
- 데이터를 캡슐화하는 객체로 대체
- 추측적 일반성
- 개발자들이 미래에 필요한 경우를 대비하여 프로그램에 일반성을 포함하는 경우 발생
요약
- 소프트웨어 개발 및 진화는 통합된 반복적인 과정으로 생각할 수 있다.
- 맞춤 시스템의 경우 소프트웨어 유지보수 비용이 일반적으로 소프트웨어 개발 비용을 초과한다.
- 소프트웨어 진화 과정은 변경 요청에 의해 주도되며, 변경 영향 분석, 릴리스 계획 및 변경 구현이 포함된다.
- 레거시 시스템은 구식 소프트웨어 및 하드웨어 기술을 사용하여 개발된 오래된 소프트웨어 시스템으로 비즈니스에서 여전히 유용
- 레거시 시스템을 유지하는 것은 현대 기술을 사용하여 대체 시스템을 개발하는 것보다 비용이 적고 위험이 적다.
- 버그 수정, 새로운 환경에서 작동하도록 소프트웨어 수정, 새로운 , 변경된 요구사항의 구현 등 3가지 유형의 유지보수가 있다.
- 재공학은 소프트웨어를 재구조화하고 재문서화하여 이해와 변경이 용이하도록 하는 것에 관련이 있다.
- 기능을 유지한 채로 프로그램 변경을 수행하는 리팩토링은 예방적인 유지보수의 한 형태
'Computer Science > Software Engineering' 카테고리의 다른 글
[소프트웨어 공학] - 소프트웨어 테스팅 (0) | 2023.06.07 |
---|---|
[소프트웨어 공학] - 아키텍처 설계 (0) | 2023.06.06 |