* Software change
- Software change가 일어나는 이유
1) 새 요구사항의 등장
2) 사업 환경의 변화
3) 에러 발생
4) 새로운 장비의 도입
5) 성능, 신뢰성 향상의 필요
- 위와 같은 이유에 따라서 모든 SW는 이 단계를 피할 수 없다. 또한, 각 회사는 많은 돈을 이 과정에 투자한다.
- 소프트웨어 진화 과정은 나선형을 이룬다.
* Evolution vs Service
- Evolution = S/W + new spec
> 현재 SW를 사용하고 있으며, 지속적으로 새 요구사항이 제안되고 구현됨
- Service
> 새 요구사항 없이, SW의 환경설정 변경 또는 Bug fix를 해준다.
- Phase-out
> SW는 계속 사용되지만, evolution과 service를 해주지 않음
> 변경이 많이 요구되면 새로운 SW를 개발
* Evolution Process
- 개발자와 진화 담당자가 다를 경우에 처음으로 진화를 하는 경우에 진화담당자는 프로그램 구조등을 분석해야한다.
* Urgent change(비상적 변화)
- Urgent change를 하는 경우
> 치명적 시스템 오류가 발생 됐을때
> System의 환경이 변하는 경우
> Business 변화가 있을 경우
- 분석 및 계획 수립 과정이 생략된다.
* Handover problem(인수 문제)
- Agile methods and evolution
> 개발과 진화의 경계가 모호하다.
> 진화도 regression test를 해야 한다.
> 변화는 새로운 user story 추가로서 나타난다.
- Handover problem은 개발팀과 진화팀의 Process Activity가 달라서 발생한다.
ⓐ 개발팀 Agile > 진화팀 Plan-driven
- 개발 과정에 대해 잘 정의된 문서가 존재하지 않는다.
- 진화팀의 척도가 되는 문서가 존재 하지 않는다.
ⓑ 개발팀 Plan-driven > 진화팀 Agile
- regression test를 위한 test case가 존재 하지 않는다.
- 자동화 test tool을 제작해야 한다.
* Lehman's Law
- Lehman : 진화, 유지 보수 분야를 만듬
- 법칙
1) 변화는 지속되기 때문에 S/E적 관리가 필요하다.
2) 변화할수록 복잡도가 증가한다.
3) 각 프로그램마다 변화에 나타나는 고유의 특징이 있다.(eg. 변화 Size, release interval, error가 나오는 수)
4) 진화에 대한 속도는 개발 속도 유지와 자원의 양과 무관하다 > 변화는 관리와 무관하다.
5) 변화의 정도는 release interval과 무관하가 일정하게 변한다.
6) 변화가 지속됨에 따라 기능은 증가하지만, 품질이 떨어진다.
7) Feedback형식으로 변화가 지속된다.
- Customer system을 분석한 결과로, 재사용 기반 개발, 조금한 system 개발 등에는 잘 맞지 않을 때가 있다.
* Maintenance
- 사용된 후에 Program이 수정되는 것을 말한다.
- Customer software의 경우 maintenance라는 용어를 사용한다.
cf) Generic software : evolution
- 보통 주기능의 변화는 포함하고 있지 않는다.
- 존재하는 component 수정, 새로운 component 추가등으로 발생한다.
- Type
ⓐ Software 결함 수정, 오류 정정(17%)
ⓑ 실행환경의 변화에 맞게 수정(18%)
ⓒ System 기능을 조금 수정하거나 조금 추가하는 것(65%)
* Maintenance cost
- 개발 비용의 2배에서 100배까지, 더 크게 나타날 수 있다.
- 기술적 요소와 비 기술적요소 모두 비용에 영향을 끼친다.
- 시간이 지남에 따라 유지 보수 비용이 증가한다.
- 비용에 영향을 끼치는 요인
ⓐ 팀이 어느정도 유지 되는가?
ⓑ 유지보수가 계약에 명시 되있는가?
ⓒ 참가한 팀원의 기술력
ⓓ 프로그램 구조와 생산년도
* Maintenance Prediction
ⓐ 유지보수가 어느정도 가능한가?
- 어떤 기능을 수정하는데 얼마만큼의 비용과 노력이 필요하는지 수치화
ⓑ 유지 보수 비용 예측
- 유지 보수를 하는 전체 비용과 1년 실시하는데 드는 비용 산출
ⓒ 시스템 변화 예측
- 변화 요청이 얼마나 왔는가?
- 어느 부분의 수정 요청이 가장 많이 왔는가?
* Change Prediction Factor
- 관계가 많을 수록 변화가 많이 발생한다.
- Tightly coupled system일수록 많은 변화를 요구한다.
> Interface 수와 복잡도(Complexity Metrics)
> 불안전한 요구사항의 수
> 어떤 Business Process 사용하는가?(Process Metrics)
ⓐ Complexity metrics
- System components의 복잡도를 나타내는 측정표
- 어느정도 유지보수가 가능한지를 측정
- 요인
> 컴포넌트의 control structure
> 컴포넌트의 data structure
> object size, method개수, module 수
ⓑ Process metrics
- System마다 다음 값을 유지한다.
> 잘 못된 것에 대한 유지보수 요청 개서
> 변화를 분석하는데 걸리는 시간
> 변화를 구현하는 시간
> 변화 요구의 개수
- 4개의 값이 늘어남에 따라 유지 보수가 어려워 진다.
* System Re-engineering
- 유지보수가 어려울 경우 "재공학"기법을 적용한다.
- 구조를 재정의하고, 소스코드를 수정한다. 이때 기능은 유지 되야 한다.
- legacy system에서 많이 사용된다.
- 유지보수를 쉽게 하기 위해서 하는 것이다.
- 이점
> Reduced risk : 새로운 SW개발보다 위험이 적다.
> Reduced cost : 새로운 SW개발보다 비용이 적다.
- Process
> Source code translation : source code를 잘아는 언어로 번역
> Reverse engineering : System > Document
> Program Structure improvement : structure 개선
> Program modularization : 프로그램 모듈화
> Data Re-engineering : Data 개선
- Cost Factors
> SW품질
> Tool의 지원 범위
> Data 변경 범위
> 수행자의 경험
* Re-factoring
- 유지보수를 예방하는 작업
- 나빠지는 것의 속도를 늦춘다.
- 구조를 향상시키고, 복잡도를 감소시키며, 이해하기 편한 형태로 제작한다.
- 기능을 더하는 것이 아니라, 프로그램을 개선하는 작업이다.
※ Re-factoring vs Re-engineering
- Re-engineering : System 유지,보수 시점에서 발생하며, exe파일에서 소스코드를 추출한 tool이 필요하다.
- Re-factoring : 개발과 진화단계에서 발생하며 Program 코드 상에서 실시한다.
- Re-factoring이 필요한 SW(Bad small)
> 중복된 코드 : 기능이나 데이터 코드의 중복 > 중복을 제거하고 별도의 함수로 구현
> 한 클래스가 2가지 이상의 변화에 따라서 변화가 발생 > 1가지 변화에 따라서 변화가 발생하게 만든다.
> 유지보수의 범위가 늘어난다. 특정 class 변화가 관련된 여러 class변화를 수반한다. > 유사 기능을 한 곳으로 모은다.
> 다른 클래스로 부터 데이터를 얻어와서 기능을 수행 > 메소드를 그들이 애용하는 데이터가 위치한 클래스로 옮김
(여러 클래스가 하나의 클래스의 데이터와 지속적으로 통신)
> 데이터 항목이 여러 곳에 중복되 나타나는 경우 > 데이터를 독립된 class로 정의
> Switch, if, case문이 많이 사용됨 > 다향성을 통해서 해결을 실시
> 특정객체에 접근하기 위해 많은 class를 거쳐야 한다. > Message chain을 거치지 않고 직접 사용할 수 있도록 한다.
* Legacy system management
- 관리 방법
ⓐ System Scratch : System을 없엔다. Business 과정도 변화한다.
ⓑ 시스템 유지보수를 계속한다.
ⓒ 일정 Sub System 부분을 대체 System으로 교환을 한다.
- Type
ⓐ Low Quality, Low Business : System을 없엔다.
ⓑ Low Quality, High Business : System을 나눌 수 있다면, 최대한 나누고 적당한 System으로 대체한다.
ⓒ High Quality, Low Business : Legacy Program을 버리고 사용화된 것(COTS)를 산다
ⓓ High Quality, High Business : 유지보수를 지속적으로 실시한다.