L17L18-Software Evolution (Ch09)

Topics covered (다루는 주제)

• Evolution processes
  소프트웨어 진화 프로세스
• Legacy systems
  레거시 시스템
• Software maintenance
  소프트웨어 유지보수

Software change (소프트웨어 변경)

• Software change is inevitable. Why?
  소프트웨어 변경은 불가피하다. 왜 그럴까?
• A key problem for all organizations is implementing and managing change to their existing software systems.
  모든 조직이 겪는 주요 문제는 기존 소프트웨어 시스템에 대한 변경을 실행하고 관리하는 것이다.

Importance of evolution (진화의 중요성)

• Organisations have huge investments in their software systems - they are critical business assets.
  조직들은 소프트웨어 시스템에 막대한 투자를 하며, 이는 핵심 비즈니스 자산이다.
• To maintain the value of these assets to the business, they must be changed and updated.
  이 자산의 가치를 유지하려면 소프트웨어를 변경하고 업데이트해야 한다.
• The majority of the software budget in large companies is devoted to changing and evolving existing software rather than developing new software.
  대기업의 소프트웨어 예산 대부분은 새로운 소프트웨어 개발이 아니라 기존 소프트웨어의 변경과 진화에 사용된다.

A spiral model of development and evolution (개발과 진화의 나선형 모델)

 

Evolution and servicing (소프트웨어 진화와 서비스 단계)

• Evolution
  진화
  • The stage in a software system’s life cycle where it is in operational use and is evolving as new requirements are proposed and implemented in the system.
    시스템이 운영 중이며, 새로운 요구사항이 제안되고 구현되면서 지속적으로 진화하는 생명주기 단계이다.
• Servicing
  서비스 유지
  • At this stage, the software remains useful but the only changes made are those required to keep it operational i.e. bug fixes and changes to reflect changes in the software’s environment. No new functionality is added.
    이 단계에서는 소프트웨어가 여전히 유용하지만, 버그 수정이나 환경 변화 반영과 같은 최소한의 변경만 이루어진다. 새로운 기능은 추가되지 않는다.
• Phase-out
  단계적 폐기
  • The software may still be used but no further changes are made to it.
    소프트웨어는 사용되지만 더 이상의 변경은 이루어지지 않는다.

 

 

 

[2] Evolution processes (진화 프로세스)

Evolution processes (진화 프로세스)

• Software evolution processes depend on
  소프트웨어 진화 프로세스는 다음에 따라 달라진다
  • (※ 원문 누락: 보통 시스템 구조, 변경 요청 성격, 조직의 개발 방식 등으로 채움)
• Proposals for change are the driver for system evolution.
  변경 제안은 시스템 진화를 이끄는 핵심 요인이다.
• Should be linked with components that are affected by the change, thus allowing the cost and impact of the change to be estimated.
  변경이 영향을 주는 컴포넌트와 연결되어야 하며, 이를 통해 변경의 비용과 영향을 예측할 수 있다.
• Change identification and evolution continues throughout the system lifetime.
  변경 사항 식별과 진화는 시스템 생명주기 전반에 걸쳐 지속된다.

Change identification and evolution processes (변경 식별 및 진화 프로세스)

c.f., Issue tracking system
참고: 이슈 추적 시스템

 

The software evolution process (소프트웨어 진화 프로세스)

e.g., https://issues.apache.org/jira/projects/DRILL/issues/DRILL-7705?filter=doneissues
예시: 아파치 JIRA 이슈 시스템

 

Change implementation (변경 구현)

• Iteration of the development process where the revisions to the system are designed, implemented and tested.
  시스템의 변경 사항이 설계되고 구현되며 테스트되는 개발 프로세스의 반복 단계이다.
• A critical difference is that the first stage of change implementation may involve program understanding, especially if the original system developers are not responsible for the change implementation.
  주요 차이점은 변경 구현의 첫 단계에서 프로그램 이해가 필요하다는 점이다. 특히 원 개발자가 변경을 담당하지 않는 경우 더욱 그렇다.
• During the program understanding phase, you have to understand how the program is structured, how it delivers functionality and how the proposed change might affect the program.
  프로그램 이해 단계에서는 프로그램의 구조, 기능 제공 방식, 그리고 제안된 변경이 프로그램에 어떤 영향을 줄지를 파악해야 한다.

Urgent change requests (긴급 변경 요청)

• Urgent changes may have to be implemented without going through all stages of the software engineering process
  긴급한 변경은 소프트웨어 공학의 모든 단계를 거치지 않고 바로 수행될 수 있다
  • If a serious system fault has to be repaired to allow normal operation to continue;
    심각한 시스템 오류로 인해 정상 작동을 유지하기 위해 즉시 수리가 필요한 경우
  • If changes to the system’s environment (e.g. an OS upgrade) have unexpected effects;
    시스템 환경(예: OS 업그레이드) 변화가 예기치 않은 영향을 미치는 경우
  • If there are business changes that require a very rapid response (e.g. the release of a competing product).
    매우 빠른 대응이 필요한 비즈니스 변화가 있을 경우 (예: 경쟁 제품 출시)

The emergency repair process (긴급 수리 프로세스)

 

Agile methods and evolution (애자일 방법론과 진화)

• Agile methods are based on incremental development so the transition from development to evolution is a seamless one.
  애자일 방법론은 점진적 개발을 기반으로 하므로, 개발에서 진화로의 전환이 자연스럽다.
  • Evolution is simply a continuation of the development process based on frequent system releases.
    진화는 잦은 시스템 릴리스를 기반으로 하는 개발 프로세스의 연속일 뿐이다.
• Automated regression testing is particularly valuable when changes are made to a system.
  시스템에 변경이 생길 때 자동화된 회귀 테스트는 매우 유용하다.
• Changes may be expressed as additional user stories.
  변경 사항은 추가적인 사용자 스토리로 표현될 수 있다.

Handover problems (인계 시 문제점)

• Where the development team have used an agile approach but the evolution team is unfamiliar with agile methods and prefer a plan-based approach.
  개발팀은 애자일 방식을 사용했지만, 진화팀은 이를 잘 알지 못하고 계획 기반 방식을 선호하는 경우
  • The evolution team may expect detailed documentation to support evolution and this is not produced in agile processes.
    진화팀은 세부 문서를 기대하지만, 애자일 프로세스에서는 그런 문서가 제공되지 않는 경우가 많다.
• Where a plan-based approach has been used for development but the evolution team prefer to use agile methods.
  개발은 계획 기반으로 진행되었지만, 진화팀이 애자일 방식을 선호하는 경우
  • The evolution team may have to start from scratch developing automated tests and the code in the system may not have been refactored and simplified as is expected in agile development.
    진화팀은 자동화 테스트를 처음부터 개발해야 할 수 있으며, 시스템의 코드는 애자일 개발에서 기대되는 리팩토링이나 단순화가 되어 있지 않을 수 있다.

 

 

 

[3] Legacy systems (레거시 시스템)

Legacy systems (레거시 시스템)

• Legacy systems are older systems that rely on languages and technology that are no longer used for new systems development.
  레거시 시스템은 더 이상 새로운 시스템 개발에 사용되지 않는 언어나 기술에 의존하는 오래된 시스템이다.
• Legacy software may be dependent on older hardware, such as mainframe computers and may have associated legacy processes and procedures.
  레거시 소프트웨어는 메인프레임 컴퓨터와 같은 오래된 하드웨어에 의존할 수 있으며, 관련된 레거시 프로세스와 절차를 포함할 수 있다.
• Legacy systems are not just software systems but are broader socio-technical systems that include hardware, software, libraries and other supporting software and business processes.
  레거시 시스템은 단순한 소프트웨어 시스템이 아니라 하드웨어, 소프트웨어, 라이브러리, 기타 지원 소프트웨어 및 비즈니스 프로세스를 포함하는 광범위한 사회기술 시스템이다.

The elements of a legacy system (레거시 시스템 구성 요소)

 

Legacy system components (레거시 시스템 구성요소)

• System hardware: Legacy systems may have been written for hardware that is no longer available.
  시스템 하드웨어: 레거시 시스템은 더 이상 사용되지 않는 하드웨어를 위해 작성되었을 수 있다.
• Support software: The legacy system may rely on a range of support software, which may be obsolete or unsupported.
  지원 소프트웨어: 레거시 시스템은 더 이상 지원되지 않거나 오래된 다양한 지원 소프트웨어에 의존할 수 있다.
• Application software: The application system that provides the business services is usually made up of a number of application programs.
  응용 소프트웨어: 비즈니스 서비스를 제공하는 응용 시스템은 일반적으로 여러 개의 응용 프로그램으로 구성된다.
• Application data: These are data that are processed by the application system. They may be inconsistent, duplicated or held in different databases.
  응용 데이터: 응용 시스템에서 처리하는 데이터이며, 불일치하거나 중복되었거나 서로 다른 데이터베이스에 존재할 수 있다.
• Business processes: These are processes that are used in the business to achieve some business objective.
  비즈니스 프로세스: 비즈니스 목표를 달성하기 위해 사용되는 프로세스이다.
  • Business processes may be designed around a legacy system and constrained by the functionality that it provides.
    이러한 비즈니스 프로세스는 레거시 시스템에 맞춰 설계되어 그 기능에 제약을 받을 수 있다.
• Business policies and rules: These are definitions of how the business should be carried out and constraints on the business. Use of the legacy application system may be embedded in these policies and rules.
  비즈니스 정책 및 규칙: 비즈니스 수행 방식과 제약 조건을 정의하며, 레거시 응용 시스템의 사용이 이러한 정책과 규칙에 통합되어 있을 수 있다.

Legacy system layers (레거시 시스템 계층)

Legacy system replacement (레거시 시스템 교체)

• Legacy system replacement is risky and expensive so businesses continue to use these systems.
  레거시 시스템 교체는 위험하고 비용이 많이 들기 때문에 기업은 이를 계속 사용한다.
• System replacement is risky for a number of reasons.
  시스템 교체는 여러 가지 이유로 위험하다.
  • (※ 항목 누락됨 — 예: 데이터 마이그레이션 문제, 조직 내 사용자 교육, 시스템 통합 실패 등으로 채울 수 있음)

Legacy system change (레거시 시스템 변경)

• Legacy systems are expensive to change for a number of reasons:
  레거시 시스템은 다음과 같은 여러 이유로 변경 비용이 크다:
  • No consistent programming style
    일관된 프로그래밍 스타일이 없음
  • Use of obsolete programming languages with few people available with these language skills
    오래된 프로그래밍 언어 사용 및 해당 언어에 능숙한 개발자가 거의 없음
  • Inadequate system documentation
    불충분한 시스템 문서화
  • System structure degradation
    시스템 구조의 붕괴
  • Program optimizations may make them hard to understand
    성능 최적화로 인해 프로그램이 이해하기 어려움
  • Data errors, duplication and inconsistency
    데이터 오류, 중복, 불일치 문제

Legacy system management (레거시 시스템 관리)

• Organisations that rely on legacy systems must choose a strategy for evolving these systems. (Scrap - Maintain - Transform - Replace)
  레거시 시스템에 의존하는 조직은 해당 시스템을 진화시키기 위한 전략을 선택해야 한다. (폐기 - 유지 - 변환 - 교체)
  • Scrap (discard) the system completely and modify business processes so that it is no longer required;
    시스템을 완전히 폐기하고, 더 이상 필요하지 않도록 비즈니스 프로세스를 수정한다.
  • Continue maintaining the system;
    시스템을 계속 유지관리한다.
  • Transform the system by re-engineering to improve its maintainability;
    시스템을 재공학을 통해 변환하여 유지보수성을 향상시킨다.
  • Replace the system with a new system.
    시스템을 새로운 시스템으로 교체한다.
• The strategy chosen should depend on the system quality and its business value.
  선택된 전략은 시스템의 품질과 비즈니스 가치에 따라 달라져야 한다.

An example of a legacy system assessment (레거시 시스템 평가 예시)

Legacy system categories (레거시 시스템 분류)

• Low quality, low business value
  낮은 품질, 낮은 비즈니스 가치
• Low quality, high business value
  낮은 품질, 높은 비즈니스 가치
• High quality, low business value
  높은 품질, 낮은 비즈니스 가치
• High quality, high business value
  높은 품질, 높은 비즈니스 가치

Business value assessment (비즈니스 가치 평가)

• Assessment should take different viewpoints into account.
  평가는 다양한 관점을 고려해야 한다.
  • System end-users;
    시스템 최종 사용자
  • Business customers;
    비즈니스 고객
  • Line managers;
    부서 관리자
  • IT managers;
    IT 관리자
  • Senior managers.
    고위 관리자
• Interview different stakeholders and collate results.
  다양한 이해관계자와 인터뷰하고 결과를 종합한다.
• The use of the system
  시스템의 사용 정도
  • If systems are only used occasionally or by a small number of people, they may have a low business value.
    시스템이 가끔 사용되거나 소수의 사람만 사용한다면 비즈니스 가치가 낮을 수 있다.
• The business processes that are supported
  시스템이 지원하는 비즈니스 프로세스
  • A system may have a low business value if it forces the use of inefficient business processes.
    시스템이 비효율적인 비즈니스 프로세스를 강제한다면 그 가치는 낮다.
• System dependability
  시스템 신뢰성
  • If a system is not dependable and the problems directly affect business customers, the system has a low business value.
    시스템이 신뢰할 수 없고 문제가 비즈니스 고객에게 직접 영향을 미친다면, 그 가치는 낮다.
• The system outputs
  시스템 출력
  • If the business depends on system outputs, then the system has a high business value.
    비즈니스가 시스템 출력에 의존한다면, 시스템은 높은 비즈니스 가치를 가진다.

System quality assessment (시스템 품질 평가)

• Business process assessment
  비즈니스 프로세스 평가
  • How well does the business process support the current goals of the business?
    현재 비즈니스 목표를 얼마나 잘 지원하는가?
• Environment assessment
  환경 평가
  • How effective is the system’s environment and how expensive is it to maintain?
    시스템 환경은 얼마나 효과적인가? 유지 관리 비용은 어느 정도인가?
• Application assessment
  애플리케이션 평가
  • What is the quality of the application software system?
    응용 소프트웨어의 품질은 어떤가?

Business process assessment  (비즈니스 프로세스 평가)

• Use a viewpoint-oriented approach and seek answers from system stakeholders
  관점 중심 접근 방식을 사용하여 시스템 이해관계자에게 질문한다
  • Is there a defined process model and is it followed?
    정의된 프로세스 모델이 존재하고 준수되고 있는가?
  • Do different parts of the organisation use different processes for the same function?
    조직의 서로 다른 부서가 동일한 기능에 대해 다른 프로세스를 사용하는가?
  • How has the process been adapted?
    해당 프로세스는 어떻게 수정되어 왔는가?
  • What are the relationships with other business processes and are these necessary?
    다른 비즈니스 프로세스와 어떤 관계가 있으며 그것은 필수적인가?
  • Is the process effectively supported by the legacy application software?
    해당 프로세스가 레거시 응용 소프트웨어에 의해 효과적으로 지원되는가?
• Example - a travel ordering system may have a low business value because of the widespread use of web-based ordering.
  예: 웹 기반 예약이 일반화되어 있는 상황에서 여행 주문 시스템은 낮은 비즈니스 가치를 가질 수 있다.

Some factors used in environment assessment (환경 평가에 사용되는 주요 요소들)

Factor	Questions
Supplier stability	Is the supplier still in existence? Is the supplier financially stable and likely to continue in existence? If the supplier is no longer in business, does someone else maintain the systems?
	공급업체가 아직 존재하는가? 재정적으로 안정적인가? 공급업체가 사라졌다면, 시스템을 유지 관리하는 다른 주체가 있는가?
Failure rate	Does the hardware have a high rate of reported failures? Does the support software crash and force system restarts?
	하드웨어에 자주 실패가 보고되는가? 지원 소프트웨어가 자주 충돌하고 시스템 재시작을 유도하는가?
Age	How old is the hardware and software? The older the hardware and support software, the more obsolete it will be. It may still function correctly but there could be significant economic and business benefits to moving to a more modern system.
	하드웨어와 소프트웨어의 연식은 어느 정도인가? 오래될수록 더 오래된 기술이 될 가능성이 크며, 여전히 작동하더라도 최신 시스템으로 교체함으로써 경제적·비즈니스 측면에서 이점이 있을 수 있다.
Performance	Is the performance of the system adequate? Do performance problems have a significant effect on system users?
	시스템의 성능은 충분한가? 성능 문제는 사용자에게 큰 영향을 미치는가?
Support requirements	What local support is required by the hardware and software? If there are high costs associated with this support, it may be worth considering system replacement.
	하드웨어 및 소프트웨어 유지보수를 위해 어떤 로컬 지원이 필요한가? 이 지원에 높은 비용이 발생한다면, 시스템 교체를 고려할 수 있다.
Maintenance costs	What are the costs of hardware maintenance and support software licences? Older hardware may have higher maintenance costs than modern systems. Support software may have high annual licensing costs.
	하드웨어 유지관리 및 소프트웨어 라이선스 비용은 어느 정도인가? 오래된 하드웨어는 최신 시스템보다 유지관리 비용이 높을 수 있으며, 지원 소프트웨어도 높은 연간 라이선스 비용이 발생할 수 있다.
Interoperability	Are there problems interfacing the system to other systems? Can compilers, for example, be used with current versions of the operating system? Is hardware emulation required?
	다른 시스템과의 연동에 문제가 있는가? 예를 들어, 현재 운영 체제 버전에서 사용 가능한 컴파일러가 있는가? 하드웨어 에뮬레이션이 필요한가?

 

 

Some factors used in application assessment 애플리케이션 평가에 사용되는 주요 요소들

Factor	Questions
Understandability	How difficult is it to understand the source code of the current system? How complex are the control structures that are used? Do variables have meaningful names that reflect their function?
	현재 시스템의 소스 코드를 이해하기 어려운가? 사용된 제어 구조는 복잡한가? 변수들은 기능을 반영하는 의미 있는 이름을 가지고 있는가?
Documentation	What system documentation is available? Is the documentation complete, consistent, and current?
	사용 가능한 시스템 문서는 어떤 것이 있는가? 문서는 완전하고, 일관성 있으며 최신 상태인가?
Data	Is there an explicit data model for the system? To what extent is data duplicated across files? Is the data used by the system up to date and consistent?
	시스템에 명시적인 데이터 모델이 존재하는가? 파일 간 데이터가 어느 정도 중복되는가? 시스템에서 사용하는 데이터는 최신이며 일관성이 있는가?
Performance	Is the performance of the application adequate? Do performance problems have a significant effect on system users?
	응용 프로그램의 성능은 충분한가? 성능 문제는 사용자에게 큰 영향을 미치는가?
Programming language	Are modern compilers available for the programming language used to develop the system? Is the programming language still used for new system development?
	시스템에 사용된 프로그래밍 언어에 대해 최신 컴파일러를 사용할 수 있는가? 그 언어는 여전히 신시스템 개발에 사용되는가?
Configuration management	Are all versions of all parts of the system managed by a configuration management system? Is there an explicit description of the versions of components that are used in the current system?
	시스템의 모든 버전이 형상 관리 시스템에 의해 관리되고 있는가? 현재 시스템에서 사용되는 컴포넌트의 버전에 대한 명확한 설명이 있는가?
Test data	Does test data for the system exist? Is there a record of regression tests carried out when new features have been added to the system?
	시스템에 대한 테스트 데이터가 존재하는가? 새로운 기능이 추가될 때마다 회귀 테스트가 수행되었고 그 기록이 있는가?
Personnel skills	Are there people available who have the skills to maintain the application? Are there people available who have experience with the system?
	응용 프로그램을 유지관리할 수 있는 기술을 가진 인력이 있는가? 해당 시스템에 대한 경험이 있는 인력이 존재하는가?

System measurement (시스템 측정)

• You may collect quantitative data to make an assessment of the quality of the application system
  응용 시스템의 품질을 평가하기 위해 정량적인 데이터를 수집할 수 있다.
  • The number of system change requests: The higher this accumulated value, the lower the quality of the system.
    시스템 변경 요청 수: 누적 요청 수가 많을수록 시스템 품질이 낮다는 신호일 수 있다.
  • The number of different user interfaces used by the system: The more interfaces, the more likely it is that there will be inconsistencies and redundancies in these interfaces.
    시스템에서 사용되는 사용자 인터페이스 수: 인터페이스 수가 많을수록 비일관성이나 중복 가능성이 커진다.
  • The volume of data used by the system: As the volume of data (number of files, size of database, etc.) processed by the system increases, the inconsistencies and errors in that data can increase.
    시스템이 처리하는 데이터 양(파일 수, DB 크기 등): 데이터 양이 많아질수록 불일치나 오류 발생 가능성도 높아진다.
    • Cleaning up old data is a very expensive and time-consuming process
      오래된 데이터를 정제하는 것은 매우 비용이 많이 들고 시간이 많이 소요되는 작업이다.

 

 

 

[4] Software maintenance (소프트웨어 유지보수)

Software maintenance (소프트웨어 유지보수)

• Modifying a program after it has been put into use.
  프로그램이 사용되기 시작한 이후에 이를 수정하는 것.
• The term is mostly used for changing custom software. Generic software products are said to evolve to create new versions.
  이 용어는 주로 맞춤형 소프트웨어의 변경을 의미하며, 일반 소프트웨어 제품은 새로운 버전으로 '진화'한다고 표현된다.
• Maintenance does not normally involve major changes to the system’s architecture.
  유지보수는 일반적으로 시스템의 아키텍처에 대한 주요 변경을 수반하지 않는다.
• Changes are implemented by modifying existing components and adding new components to the system.
  변경은 기존 컴포넌트를 수정하거나 새 컴포넌트를 추가함으로써 이루어진다.

Types of maintenance (유지보수의 종류)

• Fault repairs
  결함 수정
  • Changing a system to fix bugs/vulnerabilities and correct deficiencies in the way meets its requirements.
    시스템의 버그나 취약점을 수정하고, 요구사항을 충족하지 못하는 부분을 고치는 것.
• Environmental adaptation
  환경 적응
  • Maintenance to adapt software to a different operating environment
    소프트웨어를 다른 운영 환경에 맞게 적응시키기 위한 유지보수.
  • Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation.
    시스템이 원래 구현된 환경과 다른 컴퓨터나 운영 체제에서 작동하도록 변경하는 것.
• Functionality addition and modification
  기능 추가 및 수정
  • Modifying the system to satisfy new requirements.
    새로운 요구사항을 충족시키기 위해 시스템을 수정하는 것.

Maintenance effort distribution (유지보수 노력 분포)

Maintenance costs (유지보수 비용)

• Usually greater than development costs (2* to 100* depending on the application).
  유지보수 비용은 보통 개발 비용보다 많으며, 애플리케이션에 따라 2배에서 100배까지 차이 난다.
• Affected by both technical and non-technical factors.
  기술적 요인과 비기술적 요인 모두에 영향을 받는다.
• Increases as software is maintained.
  소프트웨어가 유지보수될수록 비용은 증가한다.
  • Maintenance may corrupts the software structure so makes further maintenance more difficult.
    유지보수가 소프트웨어 구조를 손상시켜 향후 유지보수를 더 어렵게 만들 수 있다.
• Ageing software can have high support costs.
  오래된 소프트웨어는 지원 비용이 높을 수 있다.
• (e.g. old languages, compilers etc.)
  (예: 오래된 언어, 컴파일러 등)
• It is usually more expensive to add new features to a system during maintenance than it is to add the same features during development. Why?
  유지보수 시 새로운 기능을 추가하는 것은 개발 중 추가하는 것보다 더 비싼 경우가 많다. 그 이유는?
  • (※ 누락된 항목은 예: 구조가 이미 복잡함, 문서 부족, 기존 코드 이해 필요 등으로 보완 가능)

Maintenance prediction (유지보수 예측)

• Maintenance prediction is concerned with assessing which parts of the system may cause problems and have high maintenance costs
  유지보수 예측은 어떤 시스템 부분이 문제를 일으킬 가능성이 높고 유지보수 비용이 많이 드는지를 평가하는 것이다.
  • Change acceptance depends on the maintainability of the components affected by the change;
    변경 수용 여부는 변경에 영향을 받는 컴포넌트의 유지보수 가능성에 따라 달라진다.
  • Implementing changes degrades the system and reduces its maintainability;
    변경을 구현하는 과정은 시스템의 품질을 저하시키고 유지보수성을 낮춘다.
  • Maintenance costs depend on the number of changes and costs of change depend on maintainability.
    유지보수 비용은 변경 횟수에 따라 달라지고, 변경 비용은 유지보수성에 따라 달라진다.

 

Change prediction (변경 예측)

• Predicting the number of changes requires an understanding of the relationships between a system and its environment.
  변경 횟수를 예측하려면 시스템과 환경 간의 관계를 이해해야 한다.
• Tightly coupled systems require changes whenever the environment is changed.
  밀접하게 결합된 시스템은 환경이 변경될 때마다 함께 변경되어야 한다.
• Factors influencing this relationship are
  이 관계에 영향을 주는 요인은 다음과 같다
  • Number and complexity of system interfaces;
    시스템 인터페이스의 수와 복잡도
  • Number of inherently volatile system requirements;
    본질적으로 자주 변경되는 시스템 요구사항의 수
  • The business processes where the system is used.
    시스템이 사용되는 비즈니스 프로세스의 특성

Complexity metrics (복잡도 지표)

• Predictions of maintainability can be made by assessing the complexity of system components.
  시스템 컴포넌트의 복잡도를 평가함으로써 유지보수성 예측이 가능하다.
• Studies have shown that most maintenance effort is spent on a relatively small number of system components.
  대부분의 유지보수 노력은 소수의 시스템 컴포넌트에 집중된다는 연구 결과가 있다.
• Complexity depends on
  복잡도는 다음에 따라 달라진다
  • Complexity of control structures;
    제어 구조의 복잡도
  • Complexity of data structures;
    데이터 구조의 복잡도
  • Object, method (procedure) and module size.
    객체, 메소드(프로시저), 모듈의 크기

Process metrics (프로세스 메트릭)

• Process metrics may be used to assess maintainability
  유지보수성을 평가하기 위해 프로세스 메트릭이 사용될 수 있다
  • Number of requests for corrective maintenance;
    결함 수정을 위한 요청 수
  • Average time required for impact analysis;
    영향도 분석에 걸리는 평균 시간
  • Average time taken to implement a change request;
    변경 요청 구현에 걸리는 평균 시간
  • Number of outstanding change requests.
    해결되지 않은 변경 요청 수
• If any or all of these is increasing, this may indicate a decline in maintainability.
  위 항목 중 하나라도 증가하고 있다면, 유지보수성 저하를 의미할 수 있다.

 

Software reengineering (소프트웨어 리엔지니어링

• Restructuring or rewriting part or all of a legacy system without changing its functionality.
  레거시 시스템의 기능을 변경하지 않고 일부 또는 전체를 재구조화하거나 다시 작성하는 것.
• Applicable where some but not all sub-systems of a larger system require frequent maintenance.
  대형 시스템 중 일부 하위 시스템만 자주 유지보수가 필요한 경우에 적용할 수 있다.
• Reengineering involves adding effort to make them easier to maintain. The system may be re-structured and re-documented.
  리엔지니어링은 유지보수를 쉽게 하기 위해 추가적인 노력을 들이는 것으로, 시스템을 재구조화하거나 문서화를 새로 수행하는 작업을 포함한다.

Advantages of reengineering (리엔지니어링의 장점)

• Reduced risk
  위험 감소
  • There is a high risk in new software development. There may be development problems, staffing problems and specification problems.
    새로운 소프트웨어 개발에는 개발 문제, 인력 문제, 명세 문제 등 높은 위험이 따를 수 있다.
• Reduced cost
  비용 절감
  • The cost of re-engineering is often significantly less than the costs of developing new software.
    리엔지니어링 비용은 종종 새 소프트웨어 개발보다 훨씬 저렴하다.

The reengineering process (리엔지니어링 프로세스)

Reengineering process activities (리엔지니어링 과정의 주요 활동)

• Source code translation
  소스 코드 변환
  • Convert code to a new language.
    기존 코드를 새로운 언어로 변환한다.
• Reverse engineering
  리버스 엔지니어링
  • Analyse the program to understand it.
    프로그램을 분석하여 구조와 동작을 이해한다.
• Program structure improvement
  프로그램 구조 개선
  • Restructure automatically for understandability.
    이해하기 쉽도록 자동으로 구조를 재조정한다.
• Program modularisation
  프로그램 모듈화
  • Reorganise the program structure.
    프로그램 구조를 모듈 단위로 재구성한다.
• Data reengineering
  데이터 리엔지니어링
  • Clean-up and restructure system data.
    시스템 데이터를 정제하고 구조화한다.

Reengineering approaches (리엔지니어링 접근 방식)

Reengineering cost factors (리엔지니어링 비용 요소)

• The quality of the software to be reengineered.
  리엔지니어링 대상 소프트웨어의 품질
• The tool support available for reengineering.
  리엔지니어링에 사용할 수 있는 도구의 지원 여부
• The extent of the data conversion which is required.
  필요한 데이터 변환의 범위
• The availability of expert staff for reengineering.
  리엔지니어링 전문 인력의 가용성
  • This can be a problem with old systems based on technology that is no longer widely used.
    더 이상 널리 사용되지 않는 기술 기반의 오래된 시스템은 인력 확보가 어려울 수 있다.

Refactoring (리팩토링)

• Refactoring is the process of making improvements to a program to slow down degradation through change.
  리팩토링은 변경에 따른 코드 품질 저하를 늦추기 위해 프로그램을 개선하는 과정이다.
• You can think of refactoring as ‘preventative maintenance’ that reduces the problems of future change.
  리팩토링은 미래 변경에 대한 문제를 줄이기 위한 '예방적 유지보수'라고 생각할 수 있다.
• Refactoring involves modifying a program to improve its structure, reduce its complexity or make it easier to understand.
  리팩토링은 프로그램의 구조를 개선하고, 복잡도를 줄이며, 이해하기 쉽게 만드는 작업이다.
• When you refactor a program, you should not add functionality but rather concentrate on program improvement.
  리팩토링할 때는 기능을 추가하지 않고, 코드 품질 향상에 집중해야 한다.

Refactoring and reengineering (리팩토링과 리엔지니어링)

• Re-engineering takes place after a system has been maintained for some time and maintenance costs are increasing. You use automated tools to process and re-engineer a legacy system to create a new system that is more maintainable.
  리엔지니어링은 일정 기간 유지보수가 이루어졌고 비용이 증가한 후 수행된다. 자동화 도구를 사용하여 레거시 시스템을 처리하고 더 유지보수하기 쉬운 시스템으로 재구성한다.
• Refactoring is a continuous process of improvement throughout the development and evolution process. It is intended to avoid the structure and code degradation that increases the costs and difficulties of maintaining a system.
  리팩토링은 개발과 진화 전반에 걸쳐 지속적으로 개선하는 과정이며, 시스템 유지보수 비용과 난이도를 증가시키는 구조 및 코드 품질 저하를 방지하는 데 목적이 있다.

‘Bad smells’ in program code (code smells) (프로그램 코드에서의 '악취' (코드 스멜))

• Duplicate code
  중복 코드
  • The same or very similar code may be included at different places in a program. This can be removed and implemented as a single method or function that is called as required.
    동일하거나 유사한 코드가 여러 위치에 반복되면, 이를 하나의 함수나 메소드로 통합할 수 있다.
• Long methods
  너무 긴 메소드
  • If a method is too long, it should be redesigned as a number of shorter methods.
    메소드가 너무 길다면 더 짧은 메소드들로 나누어 재설계해야 한다.
• Switch (case) statements
  과도한 switch 문
  • These often involve duplication, where the switch depends on the type of a value. The switch statements may be scattered around a program. In object-oriented languages, you can often use polymorphism to achieve the same thing.
    switch문은 값의 타입에 따라 반복되기 쉽고, 프로그램 전반에 흩어져 있을 수 있다. 객체지향 언어에서는 이를 다형성으로 대체할 수 있다.
• Data clumping
  데이터 군집화
  • Data clumps occur when the same group of data items (fields in classes, parameters in methods) re-occur in several places in a program. These can often be replaced with an object that encapsulates all of the data.
    같은 데이터 묶음(예: 클래스 필드, 메소드 파라미터 등)이 반복적으로 등장하면, 이들을 하나의 객체로 캡슐화하여 대체할 수 있다.
• Speculative generality
  과도한 일반화
  • This occurs when developers include generality in a program in case it is required in the future. This can often simply be removed.
    나중에 필요할지도 모른다는 이유로 일반성을 추가하는 것은 오히려 불필요하며 제거할 수 있다.

Key points (핵심 요점)

• Software development and evolution can be thought of as an integrated, iterative process that can be represented using a spiral model.
  소프트웨어 개발과 진화는 통합된 반복적 과정으로 볼 수 있으며, 이는 나선형 모델로 표현할 수 있다.
• For custom systems, the costs of software maintenance usually exceed the software development costs.
  맞춤형 시스템의 경우, 유지보수 비용이 개발 비용을 초과하는 경우가 많다.
• The process of software evolution is driven by requests for changes and includes change impact analysis, release planning and change implementation.
  소프트웨어 진화는 변경 요청에 의해 주도되며, 변경 영향 분석, 릴리스 계획 수립, 변경 구현을 포함한다.
• Legacy systems are older software systems, developed using obsolete software and hardware technologies, that remain useful for a business.
  레거시 시스템은 오래된 기술로 개발되었지만 여전히 비즈니스에 유용한 시스템이다.
• It is often cheaper and less risky to maintain a legacy system than to develop a replacement system using modern technology.
  최신 기술로 대체 시스템을 개발하는 것보다 기존 레거시 시스템을 유지보수하는 것이 저렴하고 위험도 낮다.
• The business value of a legacy system and the quality of the application should be assessed to help decide if a system should be replaced, transformed or maintained.
  시스템을 유지할지, 변환할지, 교체할지를 결정하기 위해 레거시 시스템의 비즈니스 가치와 응용 품질을 평가해야 한다.
• There are 3 types of software maintenance, namely bug fixing, modifying software to work in a new environment, and implementing new or changed requirements.
  소프트웨어 유지보수는 결함 수정, 새로운 환경에 맞게 변경, 새로운/수정된 요구사항 구현의 세 가지 유형으로 나뉜다.
• Software re-engineering is concerned with re-structuring and re-documenting software to make it easier to understand and change.
  소프트웨어 리엔지니어링은 소프트웨어를 이해하고 변경하기 쉽게 만들기 위해 구조화와 문서화를 다시 수행하는 것이다.
• Refactoring, making program changes that preserve functionality, is a form of preventative maintenance.
  기능을 유지하면서 코드를 개선하는 리팩토링은 일종의 예방 유지보수이다