소프트웨어 공학 (11), Software Evolution

Software Evolution

소프트웨어 출시 이후 나타나는 버그를 개선해 업데이트하는 과정

---

0. Software change

1) Software change란?

- 해당 챕터에서 기저에 놓여있는 개발 방식은 top-down, waterfall 방식이다.

- 소프트웨어는 출시 이후에 끝나는 것이 아니라 놓친 부분이나 새로운 피쳐의 등장, 비즈니스 환경의 변화 등등에 의해 새로운 기능이나 피쳐, 성능에 대한 부분, 기타 등등은 반드시 필요할 수 밖에 없다. 이는 소프트웨어의 변화를 이끈다. 

- 테스트는 프로그램이 완벽하다는 것을 증명하진 않는다. 이는 테스트 과정에서 걸러내지 못한 것을 이끌어내곤 한다. 이는 소프트웨어의 변화를 이끈다. 

- 하드웨어의 변화가 소프트웨어의 변화를 이끌수도 있다. 가상화나 GPU based의 머신러닝 등과 같은 것은 하드웨어의 기술이 진화하면서 그 능력을 사용하기 위해 소프트웨어의 인터페이스도 바뀔수밖에 없다.

- 성능이나 신뢰성에 대한 요구사항이 바뀔 수 있다. 예를 들어 후쿠시마 원전의 방사능 유출 사건 이후 원자력 발전소 설비 규정을 바꾸었다. 이전까진 자연재해나 지구의 변화에 맞춰 설비 규정을 바꾸지 않았다. 20-30년 전과 지금 짓는 건물의 설비 규정이 다르다. 특히 해안가의 자연 재해 등이 커졌기에 이를 고려해서 설비도 달라진다. 소프트웨어 또한 신뢰성, 성능 등의 측면에서 바뀔 수 밖에 없다.

- 소프트웨어가 만들어지면 이후에 변화를 반영하는 과정은 필연적이고 이를 어떻게 할 것인가가 주요 관점이다. 이번 챕터를 통해 다양한 케이스에 대해 다양한 방안을 제시할 예정이다.

 

2) Importance of evolution

- 정확하게 인지해야하는 것은 소프트웨어를 도구로 삼는 회사는 많지만 이들의 대부분은 순수 소프트웨어 회사는 아니다. 이러한 회사는 소프트웨어에 많은 투자를 하고, 소프트웨어를 통해 고객 대응, 물류 체계 등을 한다. 한번 만들어진 소프트웨어는 회사의 비즈니스 시스템에 투입되고, 비즈니스가 변경되면 이는 소프트웨어에 반영되어야한다. 결국 소프트웨어는 많은 투자를 받아야한다.

- 요구사항 등을 매우 치밀하게 설계해도 문제가 발생하면 설계 문서를 수정하고, 이를 반영하여 수정하는 것이 어렵다. 이에 따라 현실적으로 그냥 바로 그 단계에서 수정하는 경우가 많다. 즉, 문서 수정 단계로 다시 넘어가기보단 개발하다가 수정하는 경우가 많다. 소프트웨어 안에 비즈니스 로직이 구현되어있다. 현재 소프트웨어를 다른 소프트웨어로 바꾼다면 소프트웨어가 출시된 후 수정사항이 존재할 수 있고, 이를 문서에 반영되지 않을수도 있다. 이러한 일로 소프트웨어를 새로 개발하기보단 이미 많은 투자가 이루어졌고, 코드 내에 비즈니스 환경이 반영되었기에 이를 evolution하는 경우가 더 리스크 마이너한 선택이 된다.

 

spiral model of development and evolution

- top down에서도 위와 같이 사용하기도 한다.

- 가장 중요한 것부터 위의 내용을 구현하여 사용한다. 릴리즈는 우선순위에 따라 발생하기도 하고, 리포트되는 에러, 시장 상황 등에 따라 spiral하게 릴리즈가 변경될수밖에 없다.

 

3) Evolution and servicing

(1) Evolution과 servicing의 개념

- Evolution: 새로운 기능이 추가되고, 오퍼레이션하면서 사용한다.

- Servicing: 더이상 새로운 기능은 추가되지 않고, 사용자를 대응하며 버그는 fixes되지만 거의 기능이 그대로된다.

- Phase-out: 소프트웨어가 단종되거나 운영 중지되거나 새로운 시스템으로 갈아탄다.

 

(2) 프로세스

- Software development: 소프트웨어가 만들어져서 릴리즈된다.

- Software evolution: 기능 추가, 버그 제거 등 소프트웨어를 개선하여 릴리즈를 늘린다.

- Software servicing: evolution할 때도 서비스를 진행하지만 기능 추가를 하지 않는 evolution이 끝난다면 지속적으로 servicing을 한다. (하드웨어가 지탱을 못하지만 하드웨어를 바꿀 수 없는 경우나 소프트웨어를 버리는 경우) 

- Sofrware retirement: 이후 소프트웨어를 리타이어한다.

 

 

---

1. Evolution processes

1) Evolution processes란?

(1) 개요

- 소프트웨어가 어떤 형태로 되어있는지, 누가 사용하는지 등에 대한 부분이 소프트웨어 Evolution process에 영향을 줄 수 있다. ex) 순수 소프트웨어 vs 임베디드 vs 하드웨어 의존적 // 우리가 사용 vs 판매 등

- Development process(Agile, waterfall 등)가 프로세스에 영향을 미친다.

- 누가 소프트웨어를 짜는지, 경험은 어떤지, 역량은 어떤지 등이 프로세스에 영향을 미친다.

- Evolution에 대한 Proposal은 소프트웨어 내에 컴포넌트, 서브시스템 수정 시에 기술적으로 필요한 부분, 비용, 수정되는 클래스의 영향력 등을 파악해야한다.

- 어떤 과정을 거쳐서 어떻게 변화를 찾아내고, 지속가능한 소프트웨어를 만들 수 있도록 하는게 목적이다.

 

 

(2) Change identification and evolution processes

- 위와 같이 Spiral을 하는 단계가 등장한다.

- Change identification process: 버그 리포트, 비즈니스 환경 변화를 식별하고 찾아내는 과정

- Change proposals: change를 검토하고 비용, 시간을 고려해 변경하고자 하는 사항을 도출

- Software evollution process: 변화를 반영한 개발

- New system: 새로운 시스템을 다시 출시

 

 

2) 개발자의 입장에서의 Evolution Process

(1) The software evolution process

- 변화가 쌓이면 이를 긴급성, 우선순위 등을 고려해 계산해야한다. 우리의 시스템을 바꿨을 때 어떤 영향일 있을지 등에 대해 파악한다. 우리가 수정해야하는 컴포넌트와 그 컴포넌트와 연결되어있는 것들을 보고 영향력을 보고 분석한다. 이후 다음 릴리즈를 위한 계획을 세운다.

- Fault repair: 시스템을 만들었을 때 테스트에서 걸러내지 못한 변화, 출시 이후에 보안성이 강화되는 등, 시스템의 버그, 운영체제나 라이브러리에서 도출되는 보안 사항 등

- Platform adaptation: 운영체제 변경에 따른 영향, GPU의 변경 등에 따른 영향

- System enhancement: 경쟁자, 시장 환경, 법규, non-functional requirement 등의 변화

- planning 이후 계획을 실행한다. 소프트웨어 안에 분석하고 계획한 코드를 강화하는 과정이 된다.

- 수정을 가하고 있는 상황 속에서 우리가 일으킨 수정으로 인해 새로운 수정이 발생할 수 있다. 

- 이후 새로운 시스템이 등장하고 끊임없이 위의 과정을 반복한다.

 

(2) Change implementation

- 이론상 Waterfall, plan based 단계이기에 software에 변화를 일으키는 경우는 요구사항을 다시 정리해야한다. 기존 요구사항도 수정해야한다.

- Change에 대한 요구사항 분석을 해야하고, 이에 따라 기존 요구사항이 변경되어야한다면 이를 반영해 요구사항을 분석해야한다. 이후 이를 모두 다시 waterfall 단계를 순서대로 해야한다. 즉, 변화가 생겼을 때 문서 베이스의 개발을 했다면 문서를 먼저 업데이트해야하고 문서를 기반으로 다시 해야한다.

- Requirement Analysis에서는 Agile은 코드를 분석하는 것에 조금 더 초점을 맞출 것이다.

 

(3) 소프트웨어 개발과 운영

- 소프트웨어를 개발하고 운영하는 사람이 다를 수 있다. 즉, 릴리즈 1과 릴리즈 2의 개발 및 evolution 팀이 다를 수 있다. 반면 소프트웨어 evolution을 하는 팀이 같을 수도 있다. 즉, 우리 회사 안에서 우리 소프트웨어를 다른 조직이 사용하는 경우나 우리가 개발해서 우리가 운영하는 경우나 개발팀과 운영팀이 다른 경우 등등 다양한 경우가 있는데 이를 고려해야한다. 

- development하는 사람이 evolution의 책임자가 되는 경우에는 앞서 본 과정을 그대로 따르면 된다.

- development하는 팀과 evolution의 주체가 다른 경우 ex) si 업체에서 소프트웨어를 개발하고, 고객에게 납품했을 때 소프트웨어를 만들 때 필요한 소프트웨어 설계서, specification 등을 넘겨 받아서 고객이 직접 정리한다. 우리 회사에서 소프트웨어를 만들어서 고객에게 납품했는데 이후 또 계약을 맺는다. 우리가 소프트웨어 evolution도 돈을 주고 맡기겠다고 얘기한다. 그러나 si 업체의 개발 및 운영 팀이 나눠져있는 경우 등 개발과 운영이 다른 경우에는 change를 할 때 영향을 미칠 수 있기에 이를 고려하는 것이 매우 중요하다.

- 만약 개발하고 운영을 같이하면 릴리즈1, 릴리즈2가 이어지는 일련의 개발 과정이 반복된다.

- 개발과 운영이 분리되어있다면 릴리즈된 소프트웨어를 이해하는 과정이 필요하다. 프로그램의 구조는 어떤지 어떻게 기능이 이루어져있는지 확인해야한다. 이러한 경우에는 문서가 많은 plan based approach를 선호할 수 있다. 

 

(4) Urgent change requests

- 빠르게 소프트웨어를 바꿔야하는 경우 소스코드를 보고 바로 수정하지만 plan based라면 이후에 requirement를 업데이트하는 과정이 필요하다. 소프트웨어를 고친 뒤, 문서를 업데이트하지 않으면 품질이 떨어질 수 있다.

 

3) Agile methods and evolution

- Agile에서 개발팀과 운영팀이 같다면 요구사항을 반영해서 릴리즈한 뒤 이슈를 모으고 이를 기반으로 요구사항 작성 및 개발을 하면 큰 문제가 없다. TDD가 함께 이루어지기에 자동화된 테스트 툴을 그대로 사용한다. 이에 따라 수월하게 진행할 수 있다.

 

(1) Handover problems

개발팀과 운영팀의 서로 다른 개발 방법을 가지고 있는 경우에 발생할 수 있는 문제

- 개발팀과 운영팀이 다른 경우 서로의 개발 방법이 다를 수 있다. 개발팀은 Agile 스킴을 사용하지만 운영 팀이 Plan based 팀인 경우에는 운영은 문서를 요구하지만 개발팀은 문서가 없을수밖에 없다. 이에 따라 리버스 엔지니어링을 해서 다시 설계서를 만들어야하는 수고로움을 거쳐야한다. 

- plan based로 개발을 했지만 운영은 Agile을 했다면 문서보단 TDD를 요구할 수 있다. 이때 자동화된 테스트코드를 따로 만들어야할수도 있다. plan based에서는 명확히 단계를 구분하지 않지만 agile은 리팩토링(refactoring) 단계를 분명히한다. 이에 따라 TDD, 리펙토링, Simplification을 해주는 작업이 수반된다. 

 

 

---

2. Lagacy systems

오래되어서 사용하지 않는 소프트웨어의 Evolution

---

1) Legacy systems

회사 내에서 오래된 소프트웨어 중 더이상 수정하기 어려운 시스템

---

(1) 개념

- 구체적으로 단종되어 사용하지 않는 하드웨어나 많이 쓰이지 않는 프로그래밍 언어나 기술을 사용하는 것들 등을 의미한다.

- 단종된 하드웨어 부품이 있어 이를 바꾸기 어려운 경우가 있을 수 있다. 또한 특정 소프트웨어 회사의 기술지원이 안되는 경우나 유지보수가 어려운 경우 소프트웨어를 수정하기 어렵다.

 

(2) The elements of a legacy system

- Application software: 너무 오래된 언어로 만든 Application Software

- Support software: 운영체제, 라이브러리 등등

- Application data: 데이터 베이스의 단종 등등

- Business policies and rules: 올드 패션된 법규, 규제 등 비즈니스에 대한 제반 여건

- Business processes: 너무 오래된 비즈니스 프로세스

- 비즈니스 프로세스는 업데이트가 안되었지만 소프트웨어에 기능을 추가될 수 있다. 하지만 소프트웨어 근본인 비즈니스 프로세스는 업데이트가 안될 수 있다. 이러한 경우는 어플리케이션을 버리면 비즈니스 프로세스를 날리는 것이기에 문제가 발생할 여지가 있다.

 

(3) Legacy system components

- 하드웨어가 단종되었을 때

- 하드웨어 위에 올라가는 지원 소프트웨어인 운영체제나 라이브러리 등의 기술지원이 끊김

- 목표하는 소프트웨어 어플리케이션의 언어가 단종되었을 때

- 데이터베이스가 단종되었을 때

- 비즈니스 프로세스가 존재하지만 이를 프로세스가 아닌 소프트웨어에 구현해놓으면 레거시 시스템을 버리기 어렵다.

- 비즈니스 프로세스에 대한 규제가 있을 때

 

Legacy system layers

- 다양한 이유로 기술지원을 기대할 수 없는 구성요소들을 어떻게 할지가 이번 챕터에서의 요지이다.

 

(4) Legacy system replacement

- 새로운 시스템으로 바꾸는 것이기에 값이 비싸고 리스크가 매우 크다.

- 같은 일을 해야하는 시스템을 만들어야하지만 시스템 설계서나 명세서가 부족할 수 밖에 없다. 이에 따라 새로운 요구사항이 담긴 소프트웨어를 만들기 어려우니 위험성이 증가한다.

- 문서화되지 않았지만 비즈니스를 하기 위해 급하게 개발한 내용들이 존재한다. 비즈니스를 진행하기 위해 급하게 수정하기 때문에 문서를 업데이트하기 어려운 경우가 존재한다. 이러한 점들이 시간이 지남에 따라 쌓여만 가는 상황에서 replacement를 하는 것이 어렵다.

- 매우 많은 비용이 들어가기도 한다.

 

(5) Legacy system change

- 바꾸는 데에 드는 비용 또한 비쌀 수 밖에 없다.

- 필요한 부분에 필요한 것을 적용해야하지만 소프트웨어 언어가 오래되었다면 프로그래밍 스타일이 일관되지 않기도 하고, 컴파일러 기술 개선이 멈춰있다. 이에 따라 올드 패션 스타일에 맞춰 개발하기 쉽지 않다.

- 또한 이러한 오래된 프로그래밍을 다루는 개발자를 찾기 어렵다.

- 급하면 코드에 손을 대기에 문서나 설계서가 부정확해질 수 있다.

- 오래된 하드웨어 위에서 오래된 랭귀지 위에서 돌아가는 경우에는 성능 저하가 크게 발생할 수 있다. 프로그래머들이 제한된 상황에서 성능을 극대화하기 위해 심도깊게 공부해서 코드를 작성한 경우가 있는데 이에 대한 이해가 없이 코드에 손을 대면 문제가 발생할 수 있다. 즉, 프로그램 최적화를 이해하기 어려워 이를 알기 어렵다.

- 데이터인 경우에는 파일 처리에서 에러가 발생하거나 중복이 발생할 수 있다.

 

2) Legacy system management

(1) Legacy system management

- 소프트웨어가 왜 필요한지 이유가 되는 비즈니스 프로세스를 확인할 필요가 있다. 비즈니스 프로세스가 대체가능하다면 비즈니스 프로세스를 구현한 소프트웨어를 날릴 수 있다. 비즈니스를 하기위해 소프트웨어를 돌리고 있다. 비즈니스 프로세스가 대체가능하다면 시스템을 날릴 수 있다. 

- 시스템 유지(보수)를 지속한다. -> 요즘 경제성이 있다고 판단되는 방법이다. 가상화 기술이 좋아지면서 과거 컴퓨터와 운영체제에 의해 돌아간 소프트웨어가 가상 머신에서 돌릴 수 있게 되었다.

- 가능하다면 리엔지니어링을 통해 아키텍처나 개선해나가는 과정이 있을 수 있다.  

- 비즈니스 프로세스가 버릴 수 없을 때 하드웨어를 포함한 전체 시스템을 새로운 시스템을 바꾼다.

- 위에 대한 접근 방법을 선택하기 이전에 시스템 퀄리티가 얼마나 잘 만들어져있는지에 대한 기술적인 측면과 비즈니스를 운영하면서 얻을 수 있는 경제적인 가치(비즈니스 밸류)를 확인해 관리를 할지말지 정한다.

- 또한 이는 아래와 같이 그림으로 확인할 수 있다.

 

3) legacy system assessment

i) Quality

- Low quality: 유지보수하는데 너무 많은 비용이 드는 경우

- High quality: 안정적이기에 유지보수에 비용이 많이 들지 않는 경우

 

ii) Business value

- 기대할 수 있는 경제적 가치

 

(1) Low Business value and Low quality

- 유지보수할 때 비용도 많이 들지만 비지니스적 가치가 높지 않다.

- 해당 업무를 다른 업무로 흡수시키거나 대체시키는 등의 과정이 필요하다.

 

(2) High bussiness value and High quality

- 유지보수 비용도 얼마들지 않지만 비즈니스적 가치가 높다.

- 이를 최우선적으로 수정하는 것이 중요하다. 하지만 이는 대부분 바꾸지 않고 그대로 사용하는 경우가 많다.

 

(3) Low business value and High quality

- 비즈니스적 가치가 높지 않지만 유지보수 비용이 들지 얼마 안든다.

- 보수적인 회사라면 대체로 유지할 것이다.

- 경제적인 여건이 좋지 않아 개선이 필요하면 날릴 가능성이 높다.

- 외부에서 솔루션을 가져온다면 COTS를 가져와 대체하는 경우도 있다.

 

(4) High business value and Low quality

- 비즈니스적 가치는 높지만 유지보수 비용이 많이 든다.

- Re-engineering: 소프트웨어를 조금 개선하려는 시도

- replace: 교체를 할 수도 있다.

- 새로운 시스템을 만들어서 기존 시스템을 바꾸는 프로젝트가 많이 존재한다.

 

4) Business value assessment

- 어떻게 비즈니스 가치를 측정할 것인가.

- 매니저들, 비즈니스 고객, 시스템을 사용하는 사람들에게 비즈니스적 가치를 전해들어 이를 판단한다.

 

5) Issues in business value assessment

(1) 시스템을 사용하는 사람의 수와 사용 빈도

- 적은 사람들이 사용하거나 별로 사용되지 않는 시스템인 경우에는 이를 통해 얻을 수 있는 비즈니스적 가치가 낮다고 판단할 수 있다.

 

(2) 비즈니스 프로세스

- 시스템이 구성하고 있는 비즈니스 프로세스가 그렇게 효율적이지 않다면 비즈니스적 가치가 낮다고 판단할 수 있다.

- 비즈니스 프로세스가 효율적이라면 비즈니스적 가치가 높다.

 

(3) 시스템 안정성

- 시스템을 신뢰할 수 있는지, 안정적인지 확인한다.

- 시스템이 불안정하다면 비즈니스 프로세스가 망가질 여지가 있고 이는 비즈니스를 망가트릴 수 있으니 비즈니스적 가치는 매우 낮게된다. 이는 무조건 개선해야한다.

 

(4) 시스템 아웃풋

- 시스템이 아웃풋을 많이 만드는 경우에는 이에 대한 비즈니스에서 쓰이는 소프트웨어는 가치가 높다.

 

6) System quality assessment

(1) Business process assessment

- 비즈니스 프로세스 관점

- 레거시 시스템이 필요한지 아닌지는 레거시 시스템이 실현(지원)하는 비즈니스 프로세스가 의미있는지 판단하고자 한다.

- 레거시 시스템이 구현하는 비즈니스 프로세스의 모델이 정의되어있는지 혹은 모델을 따르고 있는지 등 확인

- 회사의 비즈니스 파트를 모두 확인해서 레거시 시스템이 구현한 프로세스와 비슷한 유사 프로세스가 존재하는지 확인하고, 있다면 이를 통일화하는 것이 중요하다.

- 비즈니스 프로세스의 변형되는 부분이 있는지 확인

- 다른 프로세스와의 관계

- 레거시 시스템이 비즈니스 시스템을 제대로 지원하는지 확인

 

ex) travel ordering system: 과거에는 여행가고자하는 사람이 문의 전화 -> 직원이 예약 // 지금은 웹베이스이기에 여행가고자하는 사람이 직접 예약 // 더 최근에는 웹 컨텐츠를 보여주어서 직접 예약 

- 과거에는 직원이 예약관련 소프트웨어를 사용

- 현재는 여행을 가고자하는 고객이 직접 예약관련 소프트웨어를 사용 -> 직원이 예약하는 시스템은 없어져도 된다.

 

(2)Factors used in environment assessment

(2-1) Suppler stability

- 공급자가 안정적인가

- 하드웨어, 소프트웨어 등 외부에서 조달할 수 있는데 공급자가 없어질 수 있다. 이는 불안해지는 요소이다.

 

(2-2) failure rate

- 시스템의 유지보수 비용이 크다 작다를 정하는 요인

- 에러 발생률

 

(2-3) Age

- 오래됐다는 이유만으로도 위험 요소는 크다.

 

(2-4) Perfomance

- 요구한 성능을 맞출 수 없는 경우에는 개선을 하거나 새로운 시스템으로 바꿔야한다.

 

(2-5) Support requirements

- 필요할 때 연락을 하면 응대가 가능한지, 얼마나 빠르게 응대가 되는지 

- 외국 지사에 있는 경우에는 어려울 수 있다.

 

(2-6) Maintenance costs

- 라이센스 비용

- 비싼 소프트웨어인 경우에는 살 때 100원을 주고 샀으면 통상 매년 40~50원 정도 더 든다. 이는 업데이트, 패치가 됐을 때마다 라이센스 비용을 지불하는 경우가 있다.

- 이에 따라 성능이 조금 떨어지더라도 하드웨어를 늘리면되기에 오픈소스 소프트웨어로 바꾸는 경우가 존재한다.

- 소프트웨어가 오래됐고, 기술지원이 제한된 고객에게만 한다면 공급자는 라이센스 비용을 올릴 수도 있다.

 

(2-7) Interoperability

- 하드웨어적으로, 소프트웨어적으로 다른 컴퓨터와의 연결이 얼마나 수월한가.

- TCP/IP가 활성화되어있는데, 회사마다 본인 고유의 통신 방식이 존재했다. 최근에는 금융권과 같이 보수적인 회사에서만 고유의 통신 방식을 사용한다. 호환이 불가능해 고립을 방지하기 위해 이를 고려해야한다.

 

(3) Factors used application assessment

(3-1) Understandability

- 소스코드는 있는데, 이를 이해할 수 없는가. 하지만 소스코드라도 존재한다면 어쨋든 살아남을 수 있다.

 

(3-2) Personnel skills

- 도저히 언어의 개발환경이나 언어를 이해할 수 있는 사람이 없는가.

- 소프트웨어를 운영할 수 있는 사람이 있는가.

- 소프트웨어 기능 추가를 할 수 있는가 등등

 

(3-3) Documentation

- 객체지향 이전의 소프트웨어라면 구조도 엉망이고 변수명 등과 같은 것들을 이해할 수 없다. 이에 따라 문서가 존재해야한다. 하지만 이전에는 문서를 남기는 경우가 그렇게 많지 않을 가능성이 높다. 

- 워드 프로세서의 개념이 없을 때 만들어진 소프트웨어가 많다. 따라서 문서를 남기기위해선 수기로 작성해야하기에 쉽지 않았고, 이에 따라 문서가 없는 경우가 많았다.

 

(3-4) Data

- 과거에는 데이터베이스는 셀만큼의 컴퓨터 성능도 안됐다. 따라서 과거의 데이터는 중복도 많고, 구조화도 되지 않은 경우가 존재할 수 있다. 데이터의 측면에서도 이를 유지하는게 가능한지 확인해야한다.

 

(3-5) Performance

- 성능이 낮은 경우에도 요구사항을 충족하면 괜찮지만 수요가 올라가서 성능을 올려야할 때 이를 개선하는 것이 불가능하다면 대안을 찾아야한다.

 

(3-6) Progamming language

- 실제 사장된 프로그래밍 언어가 매우 많다. 이를 계속 가지고 있을 것인지 확인해야한다.

 

(3-7) Configuration management

- 소프트웨어를 통합하기 위해 진행하는 컨피귤레이션이 제대로 이루어지고 있는지 확인할 필요가 있다.

 

(3-8) Test data

- 코드를 수정한다면 기존의 test data를 수정해야할수도 있다. 

 

7) System measurement

- 새롭게 사용할건지, 개선할 건지 따지기 전에 이 소프트웨어에 변화를 줬을 때 발생할 수 있는 것들을 정량적으로 측정하는 것이다.

- 손대는 시스템이 얼마나 중요한지 chage requests를 통해 본다. 누군가가 수정을 요청한다. 이 요청이 많아지면 시스템의 퀄리티 혹은 비즈니스 프로세스가 좋지 않은 것이다. 반면 수정요청이 없다면 소프트웨어도 괜찮고, 비즈니스 프로세스도 괜찮다는 것이다. 

- 다른 소프트웨어와의 인터페이스, 얼마나 다른 것들과 연결되어있는지는 중요할 수 있다. 이를 건드리는 것은 부담스러울 수 있다. 이를 덜어내기 위해 앞쪽에 관문을 세우고 뒤에는 모두 갈아엎는 패턴을 사용할 수 있다.

- 데이터의 사이즈, 데이터를 얼마나 사용하고 다루고 있는지, 이를 많이 사용하면 위험할 수 있다.

- 새로운 레거시 시스템은 하드웨어와 하드웨어에서 돌아가는 로직 이외에도 데이터에서 큰 비용이 들어갈 수 있다. 우리가 기존의 시스템을 바꿀 때 데이터의 형태가 바뀌었는데 데이터를 버릴 수 없는 경우에는 이에 맞춰 모두 바꿔야한다. 이를 바꾸는 데에는 매우 많은 시간이 소요된다. 그래서 래거시 시스템을 새롭게 바꾸거나 개선할 때는 데이터도 매우 중요하다.

 

- 대부분 레거시 시스템이 있고, 이를 버리거나 개선하거나 바꾸는 결정을 내려야할 때가 존재한다. 이를 논리적으로 정하기 위해 측정할 수 있는 요인을 정해 이 요인에 의해 버리거나 개선하는 등의 결정을 하는 것이 그나마 합리적인 판단이기에 이를 배운다.

 

---

3. Software maintenance

1) Software maintenance란?

- 유지보수의 의미로 이는 고유명사로서 활용될 정도로 굉장히 중요한 단어이다.

- 실제 회사에서는 팀 단위로 존재한다.

- 협의의 의미: 필요한 이유에 대해 프로그램을 수정하는 행위

- 대대적인 큰 변화가 아닌 마이너한 변화를 의미한다.

- Major changes는 새로운 릴리즈를 의미한다. 이는 마이너 변화이다. 따라서 시스템 아키텍쳐를 바꾸는 등의 대대적인 변화는 유지보수에서 수행하지 않는다.

- 기존의 컴포넌트를 일부 수정하거나 디버그하는 것 외에 새로운 기능이 들어갈 수 있지만 이 떄문에 소프트웨어 전체에 변화가 발생하지는 않는다.

 

2) types of maintenance

(1) Fault repairs

- 테스트에서 걸러내지 못한 프로그램 버그를 수정하는 것

 

(2) Environmental adaptation

- 현재 동작하는 소프트웨어가 새로운 운영체제/하드웨어 위에서 돌아갈 때 이에 맞춰 돌아가게끔 하는 것

 

(3) Functionality addition and modification

- 새로운 기능이 설계/디자인 시에 반영되지 못해서 나중에 추가/수정/삭제하는 것

 

Maintenance effort distribution

- 절대적인 기준은 없지만 일반적으로 위와 같은 비중으로 구성되어있다. 

- 설계 시에 새로운 기능을 추가하는 경우가 제일 많다.

- 설계를 잘하더라도 기능을 수정해야하고, 테스트를 잘해도 에러가 발생할 수밖에 없다.

 

3) Maintenance costs

(1) Maintenance costs란?

- 유지보수는 일반적이며 개발비용보다 2배에서 100배이상 드는 경우가 많다고 얘기하기도 한다. 이를 반드시 인지하는 것이 중요하다.

- 위의 변화는 기술적인 요인에 의해서도 발생하고, 이와 관련되지 않은 요인에 의해서도 바뀔 수 있다. ex) 법규, 비즈니스 환경 등

- 새로운 기능을 수정하고 추가하는 것이 매우 많은 비중을 차지하고 있으니 기능 추가가 된다면 성능 저하나 소프트웨어 구조의 문제가 발생할수도 있다. 이에 따라 개발보다 유지보수 비용이 더 많이 발생할수도 있다.

- 한번 만든 소프트웨어가 시간이 지남에 따라 레거시 시스템이 될 수도 있다.

 

(2) 유지보수 비용과 관련된 다음과 같은 딜레마가 있을 수 있다.

i) 회사는 통상 새로운 소프트웨어를 개발하는 것에 조금 더 가치를 둔다. 이때 유지보수팀은 우대받지는 못한다. 이에 따라 보상도 적다. 이는 유지보수를 하기 힘들게 만드는 경우도 있다. 이게 조직 문화로 고착하면 유지보수의 평가 절하가 발생할 수 있다. 실력이 좋으면 개발팀, 좋지 않으면 유지보수팀으로 배정받을수도 있다. 이는 성능 저하나 비즈니스에 영향을 주거나 비용 증가 등 소프트웨어가 점점 안좋은 방향으로 발전하게하는 원인이 된다. 

ii) 유지보수팀은 개발한 소프트웨어를 이해해야한다. 

iii) 프로그램이 나이를 먹으면 구조도 이상해지고 성능도 나빠질 수 있다. 

 

4) Maintenance prediction

(1) Maintenance prediction

- 유지보수 비용이 들수밖에 없는데 제한된 자원을 가지고 유지보수할 수 있기위해 유지보수를 체계적으로 접근해 이를 예측해본다.

- 시스템에서 어느 부분이 가장 많은 문제를 야기할지 예측

- 가장 많은 비용을 요구할 부분이 어떤 것인지 예측

- 소프트웨어 유지보수 기간에 꾸준히 해서 미리 예측할수도 있고, 유지보수한 경험을 가지고 소프트웨어 설계 시에 이를 고려해 유지보수 시행착오를 조금 더 줄일 수 있는 여지가 있다.

- 소프트웨어의 변화를 야기한다는 것은 무언가가 추가된다는 것이다. 이에 따라 성능은 저하되고 유지보수해야할 사항은 더 많아질 수밖에 없다. 이에 따라 유지보수해야하는 양이 많아지고, 대상도 많아질수밖에 없다. 이에 따라 계획적으로 작업을 해야한다.

 

- 릴리즈된 소프트웨어를 보며 스스로 질문하고 이에 대한 답변을 찾아본다.

- 소프트웨어를 유지보수하며 가장 문제시될만한 구성요소는 무엇이 있을까? 혹은 가장 많은 비용을 지불하는 구성요소를 찾는다.

- 구성요소에 대해 전주기적인/연단위/월단위 등의 실질적인 비용을 찾는다. 이를 고려해 유지보수비용이 더 많이 든다면 상용 소프트웨어를 구매해서 사용할수도 있다. 

- 만약 소프트웨어에 손을 대고 시스템에 손을 대는 변화가 있다면 어떤 변화를 반영할 것인지, 변화뿐만아니라 변화로 인해 발생할 변화를 예의주시해서 발견해야한다.

- 유지보수의 타겟이되는 것을 찾고, 비용, 변경 시 수정사항 및 영향을 받는 것 등등을 토대로 유지보수를 예측한다.

 

(2) Change prediction

- 어디선가 변화가 발생하고 변화가 얼마나 발생했는지에 따라서 maintenance를 얼마나할지 정해야한다.

- 유지보수를 할 때 비용이 가장 많이 들어갈 것을 찾는다. 혹은 변화를 일으킬만한 부분을 찾는다.

- 기본적으로 변화가 발생한다는 것은 운영체제 변경, 실패 뿐만 아니라 비즈니스 프로세스 변경 및 추가 등에 의해 발생할 수 있다. 변화에 대해 예의주시해야할 대상은 소프트웨어가 투입된 비즈니스를 봐야한다.

- 소프트웨어가 비즈니스를 하지만 내규, 법적 조치 등을 행해야한다. 이는 누구나 반드시 지켜야하는 부분이다. 규정, 법령, 사회적 인식 등에 따라 소프트웨어를 바꿔야할 수도 있다.

- 결국 소프트웨어는 외부와 인터페이스를 해야하기에 이에 따라 많이 바뀌기도 한다. 소프트웨어가 가지고 있는 다른 것들과의 상관관계이다. 이를 살펴보고 자세히 대응해볼 필요가 있다. 

- 위의 요인들이 소프트웨어의 변화를 야기한다. 소프트웨어는 당연히 도구적 관점에서 비즈니스 프로세스나 환경에 쓰이기에 소프트웨어의 변화가 필요하다는 것은 비즈니스 프로세스나 환경의 변화가 있다는 것을 의미하기도 한다.

 

 

5) Complexity metrics

(1) Complexity metrics

- 소프트웨어의 복잡도도 유지보수에 영향을 미친다. 소프트웨어의 복잡도가 높다면 성능 개선이 어렵다. 

- control structures, data structures, object method and module size 등 복잡도의 대상이 될 수 있다.

- 유지보수 측면에서 성능을 조금 올리는 것보단 간결하고, 명확하게 짜는 것이 중요할 수 있다.

 

(2) Process metrics

- 유지보수 프로세스가 제대로 돌아가고 있는지에 대해 확인할 필요가 있다.

- 유지보수를 잘 하고 있는지 보기 위함이다.

- change requests가 얼마나 있는지, impact analysis의 분석 시간이 얼마나 걸리는지, 변화를 구현하는 시간이 얼마나 걸리는지, 실제 유지보수 비용이 비싸고 중요도가 높은 것에 투자하고 있는지, 처리되지 않고 쌓여있는 change requests가 얼마나 있는지 등을 확인해야한다. 더불어 30%가 70%의 문제를 야기하는 경우가 존재하기에 문제를 일으키는 몇몇 요인을 제거하면 대부분의 문제가 해결되는 경우가 있어 체계적으로 접근해야한다.

- maintenance도 제한된 상황 속에서 해야한다는 것을 고려해 진행해야한다.

 

6) Software re-engineering

(1) Software re-engineering

- 소프트웨어를 개선하는 행위

- Agile 이전부터 있던 단어로서 최근에는 re-engineering보단 refactor를 더 많이 사용한다. 그러나 refactor를 많이 쓰는 것은 agile이기에 이를 구분해서 얘기를 하기도 한다.

- re-engineering은 주로 구조를 다시 짜는 경우가 많다. 대부분의 경우에 함수는 건드리지 않고, 소프트웨어의 골격을 다시 잡거나하는 경우가 많다. 물론 함수를 일부 수정하는 경우가 있지만 골격을 중심으로 수정하는 것이 포인트이다.

- 하위 시스템 중 일부를 수정하되, 마이너하게 수정하면서 디자인 골격을 바꾸는 경우가 많다. 혹은 re-documented하는 경우도 존재한다. 설계서가 하나도 남지 않는 경우에 리 도큐먼트를 한다.

- 이에 따라 리스크가 줄어들고, 새롭게 프로그램을 짜는 것보단 비용을 줄일 수 있다.

 

The re-engineering process

- 소스 코드가 없다면 소스코드를 새롭게 만들어야한다. 소스코드와 관련된 내용은 여러가지 의미를 담고 있다. 첫번째로는 소스코드를 본다. 두번째로는 소스코드를 새롭게 만든다. 세번째로는 소스코드를 새로운 언어로 바꾼다. 

- 확장성을 넓히거나, 인터페이스를 조정하는 등 구조를 바꾸고, 재사용가능하게 모듈화하고 내부작업을 한다.

- 원래 있던 데이터를 필요하다면 새로운 데이터 형태에 맞춰서 중복성을 제거하거나 익명화를 해서 데이터에 대한 리엔지니어링을 한다.

- 문서가 없다면 만들어진 결과물을 가지고 거꾸로 설계서를 만드는 과정이 수반된다.

- 자동화는 그렇게 많지 않다.

 

(2) Re-engineering approaches

- 큰 의미는 없다.

- 자동화는 제한된 기술로 사용할 수 있다. 분석하는 툴은 많다.

- 대부분 사람이 보고 수동으로 하는 경우가 많다.

 

(3) Re-engineering cost factors

- 소프트웨어의 품질, 자동화된 툴 확인, 데이터 영역도 건드려야하는지 판단, 이를 할 수 있는 사람이 있는지 등을 판단해야한다.

- reengineering을 통해 기존 소프트웨어에 손을 대긴하지만 리스크가 최소화된 상태에서 개선을 도모한다.

 

(4) Refactoring

- Agile에서 언급한 리팩토링의 의미이지만 최근에는 크게 구분하는 것이 의미 없긴하다.

- 리팩토링에서는 프로그램을 수정한다. TDD에서 통과한 코드를 수정한다. 

 

(5) Refactoring과 Re-engineering

- 리엔지니어링: 시스템이 릴리즈되고 유지보수단계에 들어갔을 때 진행하는 단계

- 리팩토링: 개발 프로세스가 연속적으로 이어지는 개발 흐름의 하나의 단계

 

cf) 개발할 때 안좋은 습관

- 중복된 코드: 이는 함수로 만들어야한다.

- 함수가 긴 것: 이해도 안되고, 불필요한 동작이 있을 수 있으니 이를 잘게 쪼개는 것이 중요하다. 

- 스위치: 최신 언어 중에는 스위치가 없는 경우가 있다. 이를 조건문으로 바꾼 경우에 중복된 경우가 발생할 수 있기 때문이다.

- 데이터의 중복성: 데이터가 여기저기 등장하는 경우

- 너무 많은 고민을 해서 나중에 쓸 코드를 미리 적어놓은 것