[소공 시험공부] Software Evolution

비즈니스 환경이 변하고, 컴퓨터 장비 스펙도 오르고, 신뢰성 향상을 위해서는 소프트웨어의 변화는 필요하다

 

Software 시스템 자체로서 중요한 비즈니스 자산이고, 이 가치를 유지하기 위해서는 반드시 change, update가 필요하다.

대부분 예산을 새로운 것들을 개발하는게 아니라, SW 변경과 진화에 사용하게 된다.

 

그래서 대부분 소프트웨어는 개발(development), 진화(evolution), 서비스(servicing), 퇴출(retirement) 과정을 거치게 된다

 

이 중 development와 evolution 단계에서는 명세(specification), 구현(implementation), 운영(operation), 검증(validation) 단계가 반복된다.

 

 

Program understanding : 소프트웨어 변경이 필요하다면, 영향을 분석하고

출시 계획(release planning)과 변경 구현(change implementation)을 반복하다

시스템 출시(system release)를 하게된다

 

사실 여기까지는 그렇게 중요한 내용은 아니다.이제부터가 중요한 내용이니 집중!!!

 

Software Evolution이 꼭 필요한 시스템들이 있다. Legacy System이 대표적이다.

 

Legacy System 이 뭔가요?

새로운 시스템에 사용되지 않는 언어와 기술에 의존하는 오래된 시스템이다. 소프트웨어 시스템부터 하드웨어, 라이브러리, 비즈니스 프로세스 등등 Range가 굉장히 넓은 System이다.

 

• System hardware : 더 이상 사용할 수 없는 하드웨어용으로 만들어져있는 시스템이다
• Support Software : 거의 사용하지 않고, 지원하지 않는 소프트웨어에 의존하는 시스템이다
• Application software : 비즈니스 서비스를 제공하는 Application System은 다수의 Application으로 구성되어 있다.
• Application data : 데이터가 일관성이 없거나, 중복되거나, 다른DB에 보관될 수도 있다
• Business process : 비즈니스 목표를 달성하기 위해 사용되는 프로세스로, 레거시 시스템 중심으로 설계되어 시스템이 제공하는 기능에 의해 제한될 수 있다.
• Business polices and rules(비즈니스 정책 및 규칙): 비즈니스를 수행하는 방법과 비즈니스에 대한 제약 사항에 대한 정의입니다.

요런 것들을 다 포괄한다고 보면 된다

 

Legacy system 을 그냥 뜯어 고치면 되는거 아닌가요?

보통 변경하기에 비용이 많이 들고,

일관되지 않은 프로그래밍 스타일, 사용되지 않는 프로그래밍 언어로 작성되어 있거나, 불충분한 시스템 문서화, 시스템 구조의 저하, 프로그램 최적화, 데이터 오류, 중복, 불일치 등의 문제가 존재합니다. risky하고 expensive해서 Legacy system change가 어려워요

 

여기서 부터는 진짜 중요하기 때문에 외워요!

그러면 이 Legacy system 을 어떻게 관리해야하죠?

처음에 말했든 System evolution 을 반드시 해야하기 때문에, 시스템을 평가해서 적절한 전략을 선택해야 한다.

 

Legacy system evolution Strategy?

• 시스템을 완전히 폐기(Scrap)하고 비즈니스 프로세스를 수정하여 더 이상 필요하지 않게 함.
• 시스템을 계속 유지(maintaining)함.
• 시스템을 재공학(re-engineering)하여 유지 관리성(maintainability)을 향상시킴.
• 새 시스템으로 교체(Replace)함

Legacy System 평가는 어떻게 하나요?

System quality와 business value를 기준으로 평가하면 됩니다

• 낮은 품질(low quality), 낮은 비즈니스 가치(low business value)
  • 이러한 시스템은 폐기되어야 합니다.
  • 좋은 점이 없는데 굳이 가지고 갈 필요가 없죠?
• 낮은 품질, 높은 비즈니스 가치(high business value)
  • 중요한 비즈니스 기여 --> 폐기는 못하겠다. 그런데 유지 관리 비용이 많이 든다
  • 적합한 시스템이 있을 경우 재공학(re-engineered)하거나 교체해야 합니다.
• 높은 품질(high quality), 낮은 비즈니스 가치(Low-business value)
  • COTS로 교체하거나 완전히 폐기하거나 유지 관리합니다.
  • 비즈니스 가치가 낮기 때문에 폐기를 고려할 수 있고, 품질이 높아서 유지관리도 고려할 수 있다
  • quality가 높기 때문에 재공학을 할 필요는 없고, 굳이 교체를 한다면 COTS로 하자
• 높은 품질(high quality), 높은 비즈니스 가치(High business value)
  • 정상적인 시스템 유지 관리를 사용하여 계속 운영합니다.
  • 아직은 좀 더 지켜봐도 괜찮다

Business value 는 어떻게 평가하나요?

• The use of the system(시스템 사용)
  • 시스템이 가끔이나 소수의 사람들에 의해서만 사용된다면, 비즈니스 가치가 낮을 수 있습니다.
• The business processes that are supported(지원되는 비즈니스 프로세스)
  • 시스템이 비효율적인 비즈니스 프로세스를 강제한다면 비즈니스 가치가 낮을 수 있습니다.
• 시스템 의존성(system dependability)
  • 시스템이 믿을 수 없고 그 문제가 비즈니스 고객에게 직접적인 영향을 미친다면 비즈니스 가치가 낮습니다.
• 시스템 출력(system outputs)
  • 비즈니스가 시스템 출력에 의존한다면, 시스템은 높은 비즈니스 가치를 가집니다.
  • Output이 많을 수록 분석 등에서 용이해서 비즈니스 가치가 높음
  • 이 시스템이 우리에게 출력하고 있는게 무엇인가?

얼마나 많은 사람이 쓰는지, 사용할 수 있는 비즈니스 프로세스가 제한되지는 않는지, 믿을만 한지, Output이 많은지를 고려하자

 

System quality는 어떻게 평가하나요?

• 비즈니스 프로세스 평가(business process assessment)
  • 비즈니스 프로세스가 비즈니스의 현재 목표를 얼마나 잘 지원하는지?
  • 불필요한 것 때문에 비즈니스 프로세스가 방해받지 않아야 함
• 환경 평가(environment assessment)
  • 시스템 환경이 얼마나 효과적이며 유지 관리하는 데 얼마나 비용이 드는지?
  • ex) 티켓팅 시스템의 서버
• 응용 프로그램 평가(application assessment)
  • 응용 소프트웨어 시스템의 품질은 어떠한가?
  • 우리가 작성한 코드 자체가 얼마나 깔끔한가? 외부 라이브러리는 어떻게 사용하고 있는가? 보안은?...

비즈니스 프로세스와 잘 맞는지, 시스템이 돌아가는 환경은 괜찮은지?(32비트만 지원한다던지 이러면 곤란), application quality(코드 구조라던지, 보안이라던지, 전반적으로 개발을 잘 해왔는지) 요런 것들을 고려하자

 

평가 기준을 통해서 전략을 선택했으면, 이제 직접 전략을 실천해야 겠죠?

 

System maintenance 를 한다는 것은 어떤 것을 한다는 거죠?

이미 개발되서 사용되는 시스템을 수정하는 것! 시스템 주요 구조는 그대로 나두고, 소소한 변경만 한다.

시스템에 존재하는 component를 수정하거나, 새로운 component를 추가하면 된다. 다음과 같은 유형으로 분류할 수 있다.

• Fault repair : 버그 및 취약점 수정
• environmental adaption : 초기 구현과 다른 환경에서 작동하도록 시스템을 바꿔버린다
• Functionallity addition and modification : 새로운 요구사항에 맞게 기능을 추가 / 수정한다.

이런 maintenance 는 새롭게 development하는 것보다 당연히 비용이 훨씬 많이 들고, 노후화 될 수록 구조가 복잡해서 비용이 많이든다

 

Software Reengineering 을 한다는 것은 어떤 것을 한다는 거죠?

기능은 변경하지 않고 레거시 시스템 일부/전체를 재구조화하는 것이다.

Source code translation, Reverse engineering, Program 모듈화, Data reengineering이 포함될 수 있어요

 

Reengineering을 하면 좋은 점은 뭘까요?

• 유지관리가 용이해집니다. 그래서 하위 시스템의 유지관리가 자주 필요한 큰 시스템에 적용될 수 있어요!
• 새로운 SW를 개발하는 것보다 Risk가 감소합니다
• 새로 개발하는 것보다는 비용이 적어요

Refactoring 과 혼동하지 말자

Refactoring은 프로그램 개선을 통해 변화에 따른 퇴화를 늦추는 과정으로,

프로그램 개발 및 진화 과정 전반에 걸친 예방적 차원의 개선 과정이에요. 프로그램 기능을 추가하고 이런게 아닙니다

 

Reengineering은 시스템이 유지 보수 되어서 오랜 시간 지난 후, 유지보수 비용이 증가해서 갈아 엎는 겁니다.

 

 

결국에는 코드를 잘 작성해야 maintability도 올라가겠죠?

그래서 다음과 같은 코드는 피하는게 좋아요(여기는 그냥 참고만 하면 될 듯)

• 중복 코드(Duplicate code, 일명 코드 클론(Code Clones)): 
  • 프로그램의 다양한 장소에서 동일하거나 매우 유사한 코드가 포함될 수 있습니다. 이는 제거되고 필요에 따라 호출되는 단일 메소드나 함수로 구현될 수 있습니다.
  • Code Clones : 중복된 코드가 문제가 되는 경우가 많음 (버그가 복사된다던지 등등)
  • 비슷한 코드가 여러 군데에 흩어져 있는 상황을 예로 들 수 있다.
    • 위의 경우 하나의 함수로 만들어 주는 방식 등으로 해결할 수 있다.
• 긴 메소드(Long methods)
  • 메소드가 너무 길면, 여러 개의 더 짧은 메소드로 재설계될 수 있습니다.
  • 메서드 하나가 엄청나게 긴 경우(modularity가 낮음) 메서드 하나를 private 메서드로 분리할 수 있다.
    • private 메서드에 비해 public 메서드는 더 신경 써줘야 한다.
• 스위치 문(Switch (case) statements)
  • 이들은 종종 중복을 포함하며, 스위치 문은 값의 유형에 따라 달라집니다. 
  • switch 문은 프로그램 전반에 scattered 되어 있을 수 있다. 객체 지향 언어에서는 동일한 기능을 달성하기 위해 다형성을 사용할 수 있습니다.
  • 언제 if-else를 쓰고 Switch를 쓸 건지, 아니면 다른 방식으로 처리할 건지

• 데이터 뭉치(Data clumping)
  • 동일한 데이터 항목 그룹(필드, 메소드의 매개변수)이 프로그램의 여러 곳에서 반복됩니다. 
  • 이들은 종종 모든 데이터를 캡슐화하는 객체로 대체될 수 있습니다.
  • ex)
  • method1(int[] block, Block currBlock), method2(int[] block, Block currBlock), method(int[] block, Block currBlock)
  • --> 파라미터를 Board 클래스로 뽑아서, 클래스 인스턴스를 파라미터로 설정한다
• 추측적 일반성(Speculative generality)
  • 개발자가 미래에 필요할 수 있는 일반성을 프로그램에 포함시키는 경우입니다. 
  • 이는 종종 간단히 제거될 수 있습니다.
  • 과연 이걸 specific하게 작성하면 나중에 새로운 기능을 추가할 때 이 부분의 작업이 증가하지 않을까?
  • 너무 generality를 높이면 오히러 작업 시간이 증가하고, 구조가 안좋아질 수 있다.