Software Engineering – Software evolution

Software change

• software가 사용되면서 새로운 요구사항이 도출된다.
• 비즈니스 환경이 변한다
• 거르지 못한 Errors는 반드시 수정되어야 한다.
• 새로운 컴퓨터, hardware으로 인한 software의 변화가 수반되는 일 등이 일어난다.
• Software의 신뢰성이나 성능은 향상되어야 한다.
  • 원자력 발전소나 건물 등도 자연 재해 등의 요인을 고려하면 향상되어야 하듯이 소프트웨어도 성능적 신뢰적 측면에서 바뀌어야 한다.
• 가장 주요한 문제는 기존에 존재하는 시스템에 change를 구현하고 관리해야 하는 것이다.

Importance of evolution

• 기업들은 software에 상당히 많은 투자를 하고 있다.
  • 기업들의 business assets에 중요한 부분이 되었다.
• Software의 기능은 기업에게 매우 중요하므로 변화하고 업데이트되어야 한다.
• 새로운 소프트웨어의 개발보다 기존의 소프트웨어를 발전시키는 예산이 대부분을 차지한다.
  - 새로운 소프트웨어를 개발하기 위해 다시 요구사항 분석 등의 단계를 거치기에는 어렵다.
  - 기존의 소프트웨어에는 설계서에 반영되지 않은 요구사항(긴급하게 기능을 구현하고 설계서에 반영하지 않은 경우)도 반영되어 있기 때문에 새로운 소프트웨어보다 기존의 소프트웨어를 발전시킨다.
  - 기존의 코드 안에는 비즈니스의 변화들이 반영되어 있기 때문에 교체하기 어렵다.
  

Evolution and servicing

Evolution

• 운영을 하며 사용하면서, 새로운 요구사항을 반영한 기능을 추가하는 등의 작업을 한다.

Servicing

• 버그 수정 등 운영에 필요한 작업만 수반되며, 새로운 기능은 추가되지 않는다.

Phase-out

• 운영 중지되거나 단종되거나 다음 버전으로 이동한다.

Evolution processes

• Change identification과 지속적인 변화는 system lifetime 전체에서 일어난다.

Evolution process에 영향을 주는 요인

• 소프트웨어의 유형 (embedded, 순수한 소프트웨어 등 / custom 또는 내부 고객을 위한 제품)
• 소프트웨어가 개발된 방법 (water fall / agile 등)
• 숙련된 개발자의 참여 여부 (agile이 널리 퍼지면서 사람의 중요성이 커졌다)

Proposals for change

• System evolution의 시작점이자 동기가 된다.
• Evolution에 수반되는 변화에 영향을 받는 연결되는 components를 고려하여야 하며, 변화에 필요한 비용과 인력 등에 대해 평가되어야 한다.
  
• 요구를 식별한 후 비용, 인력을 고려해서 change proposals하며, 진화 과정을 거치고, 전체 과정을 계속 반복한다.
• Top – down : spiral
• Agile : sprint
  

Impact analysis

• 변화에 수반되는 인력, 자원 등을 분석한다.

Release planning

• 출시 계획을 수립한다.
• Fault repair : 거르지 못한 에러이거나 출시 후 발생한 에러를 수정한다.
• Platform adaptation : 운영체제나 하드웨어 등이 변경되었을 때 알맞게 수정한다.
• System enhancement : 시장 환경, 법규 규정 등의 변화나 non-functional한 변화에 맞춰 수정

Change implementation

• 변화를 하기 위해서는 변화된 요구사항을 다시 분석해야 한다.
• 변화된 요구 사항으로 인해 재수정이 필요할 수 있으며, release planning을 재수립한다.
• 요구사항 명세서, 설계서를 다시 작성하고 다시 개발의 과정으로 진입한다.
  • Water-fall의 경우 문서를 재작성하는 것이 우선 순위
  • Agile의 경우 문서를 업데이트하는 시간을 줄지만, 코드를 분석하는 시간이 늘어난다.

개발팀과 evolution팀이 같은 경우

• 내부 고객이 사용하는 경우, 개발팀과 evolution팀이 한 회사인 경우, naver나 google과 같이 개발과 운영을 회사 내에서 진행하는 경우
• 개발 과정을 반복하면서 evolution을 진행할 수 있다.

개발팀과 evolution팀이 다른 경우

• SI업체에서 소스 코드, 설계서 등을 받아 고객이 직접 evolution하는 경우
• 신규 소프트웨어 개발팀과 evolution팀이 따로 작업하는 경우
• 프로그램에 대한 이해가 가장 먼저 선행되야 할 중요한 일이다.
  

Urgent change requests

• Urgent change로 인해 명세서에 반영이 안되거나 코드 구조가 이상해지는 등 품질 저하를 발생 시킨다.
• Urgent change에 한해서는 모든 진화 과정을 거치지 않는다.
  - 심각한 system fault가 발생하여 정상적인 동작이 안되는 경우
  - OS Upgrade 등의 시스템 환경이 바뀐 경우
  - 법규의 변화나 다른 제품과의 경쟁 때문에 시급하게 바꿔야 하는 경우
  

Agile methods and evolution

• 원래 incrementally하게 개발되는 개발 방법론이기 때문에 evolution은 개발의 연장선상에 있으며 쉽게 이루어진다.
• System에 변화가 일어날 때 automated regression testing을 사용하는 것이 효과적이다.
• 변화는 새로운 user stories로 나타날 수 있다.

Handover problems

• 개발팀과 진화팀의 개발 방법이 다를 수 있다.
• 계약 당시에 결과물을 명시할 수 있다.
• 개발팀이 agile, 진화팀이 plan-based 방식을 채택했다면 진화팀은 개발팀에게 상세한 문서를 요구하거나 개발된 소프트웨어를 분석하여 많은 양의 문서를 작성하는 작업을 진행해야 한다.
• 개발팀이 plan-based, 진화팀이 agile 방식을 채택했다면, 개발팀에게 자동화된 테스트 코드를 요청하거나 진화팀 자체로 테스트 코드를 추가적으로 개발해야 하며, 추가적으로 코드에 대해 refactoring과정과 단순화하는 과정을 거쳐야 한다.

Legacy systems

• 새로운 시스템 개발에 사용하지 않는 기술이나 프로그래밍 언어로 구현되어 있다.
• 단종된 하드웨어에 dependent하거나 오래된 프로세스에 의존할 수 있다.
• 과거의 소프트웨어, 하드웨어, 라이브러리를 포함하고 있다.
  
• Business processes, 관련된 법규나 규제 등을 업데이트하지 않고, 눈에 보이는 소프트웨어만 향상시킨 경우에는 business processes는 의미가 없어지며, 소프트웨어가 사라지면 유지하고 있는 business process나 관련 법규 모두 삭제된다.

Legacy system components

• system hardware legacy system : 단종된 하드웨어를 사용
• support software the legacy system : OS나 라이브러리 등이 단종된 경우
• Application software : 더 이상 사용되지 않는 프로그래밍 언어로 작성된 경우
• Application data : data base 가 단종되는 등의 경우
• Business processes : process업데이트 없이 software만 업데이트하여 사용하는 경우
• Business policy & rules

Legacy system replacement

• 시스템의 교체는 굉장히 위험하고 비싼 작업이기 때문에 대부분 시스템을 그대로 사용한다.
  • 시스템 명세서의 내용이 부족하기 때문에
  • 문서화되지 않은 business rule 등이 동작하는 시스템에 내장되어 있기 때문에 시스템을 교체한다는 것은 business rule 손실로 인한 전체적인 업무 마비를 일으킬 수 있다.
  • 새로운 개발은 돈이 많이 든다.

Legacy system change

• 수정 또한 비싼 작업이다.
  • 프로그래밍 스타일(프로그래밍 언어) 등은 일정하지 않기 때문에 스타일을 맞추기 어렵고 사멸된 프로그래밍 언어의 경우에는 숙련된 개발자를 구하기 어렵다.
  • 불충분한 시스템 설계서/문서
  • 과거의 시스템은 제한된 하드웨어 때문에 상당한 편법을 많이 썼는데 수정함으로써 오히려 성능을 저하시킬 수 있다.
  • 과거의 개발자들과 같은 수준으로 이해하기 어렵다.

Legacy system management

• 시스템과 비즈니스 프로세스를 검토하고 수정함으로써 legacy 시스템이 더 이상 필요하지 않게 한다.
• 계속 유지/보수하면서 시스템을 유지한다.
  • Virtual machine을 이용하여 단종된 하드웨어 문제를 해결하여 경제적인 이점을 얻을 수 있다.
• 시스템을 re-engineering(구조 개선, 하드웨어 이동)등을 통하여 유지성을 높인다.
• Legacy 시스템을 새로운 시스템으로 바꾼다.

System quality와 business value를 평가하여 전략을 선택해야 한다.

Low quality

• 시스템이 형편 없거나 유지 보수 비용이 너무 많이 들어가는 경우

High quality

• 시스템 유지 보수 비용이 적은 경우

Business value

• 경제적인 이득을 수치화

Low quality, low business value

• 낮은 이윤과 높은 유지보수 비용, system은 교체되어야 한다.

High-quality, low-business value

• 낮은 유지보수비용과 낮은 이윤
• COTS로 대체한다.
• 이득이 발생하는 부분이 있기 때문에 사업체의 판단에 따라 제거하거나 유지한다.

Low-quality, high-business value

• 유지보수 비용이 많이 드나 높은 이득을 창출한다.
• RE-enginnering하거나 대체 가능한 system이 있는 경우 교체한다.

High-quality, high business value

• 유지보수 비용도 적으며 높은 이윤을 창출하기 때문에 계속 유지한다.

Business value assessment

• System end-user / business customer / line managers / IT managers / Senior manager 등의 관점에서의 설명을 취합한다.
• Stakeholder와 관련된 사람들에 대한 인터뷰를 진행하여 가치를 평가한다.

Issues in business value assessment

The use of the system

• 사용하는 사람들과 빈도 수에 따라 평가한다.

The business process that are supported

• Business process에 크게 도움이 되지 않는다면 가치가 낮다고 평가한다.

System dependability

• 시스템이 안정적이지 못하면 가치가 낮다고 평가한다.

The system outputs

• 결과물을 만들어 내고 business에 영향을 준다면 가치가 높다고 판단한다.

System quality assessment

Business process assessment

Legacy system과 관련된 다양한 사람들을 만나 의견을 들어본다.

• Legacy system이 process model을 정의하고 그것을 따르고 있는지 확인한다.
• 다른 조직에서 동일한 시스템을 다른 프로세스로 사용하고 있는지 확인한다.
  • 있다면 Legacy system을 제거할 수 있다.
• 조절이나 변형을 통해 개선을 이룰 수 있는지 확인한다.
• 다른 비즈니스 프로세스와의 상관 관계 등 Legacy system의 필요성을 확인한다.
• Legacy system이 비즈니스 프로세스가 효율적으로 지원하고 있는지 확인한다.

Environment assessment

공급자의 안정성

• 공급자가 여전히 존재하는지, 공급자가 경제적으로 안정적인지, 공급자가 없다면 다른 누군가에게 유지를 맡길 수 있는지를 확인한다.
• Failure rate
  • 하드웨어나 소프트웨어가 죽는 경우가 많은지 확인한다.
• Age
  • 오래 되었다면 가치가 낮다고 판단한다.
• Performance
  • 요구한 성능을 충족할 수 있는지에 대해 평가한다.
• Support requirements
  • 필요시에 제시간에 지원을 받을 수 있는지 혹은 교체시에 많은 비용이 드는지에 대해 평가
• Maintenance costs
  • 소프트웨어 라이선스의 가격이 어떻게 되었는지에 대해 평가한다
  • 현대의 시스템에 낡은 하드웨어는 더 많은 유지보수 비용을 필요로 한다.
  • Support software의 라이선스 비용으로 매년 많은 비용이 청구된다.
• interoperability
  • 하드웨어, 소프트웨어 적으로 다른 컴퓨터와 연결이 가능한지의 여부를 평가한다.

Application assessment

• Understandability & personnel skills
  • 현재의 시스템의 소스 코드를 이해할 수 있는지
  • 시스템의 구조가 복잡하지 않는지
  • 함수의 내용을 반영하는 변수의 이름이 적절하게 지정되었는지

Documentation

• 시스템 문서가 사용 가능한지 / 완전하고 일관되게 작성되었는지
• Data
  • 명확한 데이터 모델을 가지고 있는지
• 성능
  • 적정한 성능을 낼 수 있는지
• Programming language
  • 컴파일러나 인터프리터가 사용가능한가 / 프로그래밍 언어를 다룰 수 있는 개발자가 있는가
• Configuration management
  • 버전 등의 관리가 제대로 이루어지고 있는가
• Test data
  • 수정할 때 사용할 수 있는 test data가 존재하는지

System measurement

The number of system change requests

• 수정 요청 수가 많아진다면 성능이 좋지 않다고 평가한다.

The number of different user interfaces used by systems

• 다른 시스템과 연결이 많이 되었다면 interface가 일관되지 못하거나 중복이 많이 발생하기 때문에 좋지 않다고 평가한다.
• 인터페이스만 따로 구현하는 방법을 채택할 수도 있다.

The volume of data used by system

• 데이터를 많이 다루고 있다면 시스템의 위험도가 높다고 평가한다.
• 예전의 데이터를 정제/수정하는 것은 매우 비싸고 시간이 오래 걸리는 작업이다.

Software maintenance

• 필요에 따라 프로그램을 수정하는 행위를 포함한다.
• 시스템의 구조를 바꾸는 등의 주요 변화를 포함하지 않는다.
• 기존의 구성 요소를 수정하거나 시스템에 새로운 기능을 추가하는 행위를 지칭한다.

Type of maintenance

Fault repairs

• 요구사항에 맞게 버그를 수정하거나 취약점을 개선한다.

Environmental adaptation

• 하드웨어나 OS의 변화에 맞게 시스템을 수정한다.

Functionality addition and modification

• 미처 반영되지 못한 새로운 기능을 추가하는 작업

Maintenance costs

• 유지보수 비용은 개발 비용의 2~100배까지 소요된다.
• 유지 보수 비용은 기술적인 요인과 비기술적 요인 모두에 영향을 받는다.
• 유지 보수를 하며 기능을 추가하기 때문에 유지보수 비용은 증가하며 추가할수록 소프트웨어 구조상 문제가 발생할 수 있기 때문에 유지보수가 더 어려워진다.
• 시간이 갈수록 old language, complier 등 legacy system과 유사한 문제로 비용이 증가한다.
• 개발팀과 유지보수팀을 따로 두는 경우가 많으며 따라서 소프트웨어의 이해의 필요성이 증가함에 따라 유지보수 비용이 증가한다.
• 개발과 유지보수 중 개발에 집중함으로써 유지보수팀에게는 인센티브가 수여되지 않아 유지보수를 더 어렵게 만든다.
• 유지보수를 평가절하하거나 능력이 떨어지는 인원을 유지보수에 배치하기 때문에 더 어려워진다.
• 시간이 갈수록 구조가 퇴화하며 수정하기 어려워진다.

Maintenance prediction

• 어느 부분이 문제를 야기할지, 가장 많은 유지보수비용이 사용될지에 대하여 예측한다.
• 예측을 통하여 한정된 인력을 효율적으로 배치할 수 있으며, 차기 개발에 참고함으로써 유지보수 비용을 줄일 수 있다.
• 변화에 의해 영향을 받는 components의 유지보수 가능성에 의해 change acceptance가 결정
• 변화를 구현하는 것은 시스템을 퇴화시키고 유지 보수성을 감소시킨다.
• 유지보수 비용은 변화의 수와 유지보수성의 비용에 의해 결정된다.

Predicting maintainability

• 어떤 부분이 유지 보수함에 있어 가장 많은 비용이 지불될지 예측한다.

Predicting maintenance costs

• 시스템의 생애 주기 전체동안 유지보수 비용이 얼마나 될지 예측한다.
• 연 단위 유지보수 비용이 얼마나 될지 예측한다.

Predicting system changes

• 얼마나 많은 변화가 요구될지에 대하여 예측한다.

Change prediction

• 요구되는 변화의 개수를 예측하고, 시스템과 환경 간의 관계를 이해한다.
• 밀결합된 시스템은 환경이 수정될 때 같이 수정이 필요하다.
• 소프트웨어의 변화가 수반되는 관계 또는 환경의 요인
  • 시스템이 사용되는 business processes이 변경
  • Inherently volatile system(회사 내규, 사회적 시선, 법적인 조치 등) requirement 수
  • 시스템 인터페이스의 복잡도와 수

Complexity metrics

복잡도에 영향을 주는 요인

• 데이터 구조의 복잡도 / Control 구조의 복잡도 / 객체, method, module의 크기
  • 누구나 이해하기 쉬운 평이하고 간결한 코드를 만드는 것이 중요하다.

Process metrics (maintenance process의 평가 지표를 의미한다)

유지 보수 가능성에 평가하기 위하여 process metrics가 사용된다.

• 요구 받는 Change request의 수
• 변화가 주는 영향을 분석하는데 소요되는 평균적인 시간
• Change request를 구현하는데 걸리는 시간
  • 앞서 한 예측을 바탕으로 중요도에 따른 시간과 비용, 그 수를 측정한다.
• 아직 해결되지 않은 Change request의 수
  • 문제를 일으키는 소수의 구성 요소를 제거함으로써 많은 change request를 줄일 수 있다
  • 체계적인 maintenance가 필요하다.

Software re-engineering (소프트웨어 개선)

• 함수의 변경 없이 legacy 시스템의 구조를 다시 만들거나 일부분을 재작성한다.
• 시스템 전체가 아닌 유지보수가 자주 필요한 작은 부분에 대하여 적용 가능하다.
• 시스템의 구조를 재조직하면서 다시 문서를 작성하기도 한다. (reverse engineering)

Advantages of reengineering

• Reduced risk
  • 구조만 일부 재조직함으로써 새로운 소프트웨어를 개발할 때 발생하는 문제, staffing 문제, 명세서 작성 등의 문제를 회피할 수 있다.
• Reduced cost
  • 새로운 소프트웨어를 개발하는 것보다 비용이 적게 든다.

Reengineering process activities

Source code translation

• Code를 분석한다
• 소스 코드가 없는 실행 파일에 코드를 만들어 낸다.
• 새로운 프로그래밍 언어로 완전 전환하는 방법도 사용된다.

Reverse engineering

• 프로그램을 이해하기 위해 분석한다.
• 프로그램을 보고 문서를 작성하는 순으로 역으로 진행된다.

Program structure improvement

• 이해 가능성을 높이기 위해 자동적으로 시스템의 구조를 재조직한다.

Program modularization

• 프로그램의 구조를 재조직한다.

Data reengineering

• System data를 재조직하거나 압축 기법을 사용하거나 정제할 수 있다.

Reengineering cost factors

• Reengineering 될 소프트웨어의 품질이 비용에 영향을 미친다.
• 사용 가능한 support tool의 여부가 비용에 영향을 미친다.
• 변환이 필요한 데이터의 범위가 비용에 영향을 미친다.
• 전문적인 개발자의 가용 여부가 비용에 영향을 미친다.

Refactoring (agile 관점 강조)

• 성능을 향상시키거나 구조를 개선하거나 복잡도를 낮추기 위해 수정이 동반된다.
• 변화에 의한 퇴화 속도를 늦추기 위해 refactoring이 사용된다.
• 미래의 변화에 대한 문제를 낮추기 위한 예방적인 유지 보수라고 생각할 수 있다.
• 성능을 추가하기 보다는 성능의 개선에 집중해야 한다.

Refactoring and reengineering

reengineering

• 오랜 시간 유지되었고, 유지 보수 비용이 증가했을 때 reenginnering을 한다.
• 더 유지보수가 쉬운 시스템을 개발하기 위해 자동화된 도구 등을 사용하여 reengineering을 할 수 있다.

Refactoring

• 소프트웨어의 개발과 진화 과정 전체에서 연속적으로 나타나는 프로세스다.
• 유지 보수의 비용과 난이도를 높이는 코드와 구조를 피하기 위해 실행된다.

코드에 나타나는 안 좋은 습관들

• 중복된 코드 : 함수로 구현하여 필요할 때 호출하는 방법으로 사용될 수 있다.
• 긴 함수/메소드 : 짧은 길이로 재구성함으로써 다양하게 자주 사용되게 해야 한다.
• Switch case 구문 : 중복을 많이 발생시킬 수 있다.
• 데이터의 중복성 , 현재는 사용하지 않으나 미래에 사용될 만한 코드를 삽입하는 행위