[소프트웨어공학] 9장 Software Evolution

소프트웨어공학의 기저에는 plan-based, top down, waterfall이 자리 잡고 있지만 에이자일 이나 plan drive 방법에 역시 적용이 가능함

 

주요의제

• Evolution processes – 소프트웨어가 출시되고 끊임없이 발전/개선 됨
• Legacy systems – 누군가 만들어 놓은 오래된 시스템이 아직도 사용되고 있는 것들이 있음 그런 것들에 대한 이해가 필요함
• Software maintenance – 어떠한 작업들이 출시된 이후에 이루어지는지 알아봄

 

Software change

>Software change is inevitable

-> 소프트웨어가 출시가 되고 끝이 아님 -> 결국 우리가 놓쳤던 실수들이 들어오게 되거나 아니면 출시이후에 생긴 문제들이 생김

-> 비즈니스 환경의 변화에 따라 달라진 요구사항에 따라 새로운 요구가 들어옴

-> 테스트 과정에서 걸러내지 못한 에러들에 대한 수리가 필요함

-> 하드웨어가 변화하면 그에 따른 소프트웨어의 변화도 생기게 된다.

-> 새로운 하드웨어가 등장하며 새로운 기능들이 등장하고 그러한 기능들을 사용하기 위한 소프트웨어가 나와야 한다.

-> 기능성이나 신뢰성에 대한 향상이 요구됨

ex. 후쿠시마 원전이 그 당시에는 요구들에 만족되게 설계되었지만 변화한 자연환경에 적응하지 못하고 문제를 일으킨다.

>>위와 같은 다양한 이유들에 의해 소프트웨어는 변화할 수밖에 없음

>A key problem for all organizations is implementing and managing change to their existing software systems. -> 이후에 이러한 변화들을 반영하는 과정은 필연적이고 이러한 것들을 적용해야한다.

 

evolution의 중요성

>기업은 소프트웨어 시스템에 막대한 투자를 하고 있습니다. 이들은 중요한 비즈니스 자산입니다. -> 넥슨이나 쿠팡 등 다양한 회사에서 사용됨, but 이러한 회사들이 순수소프트웨어 회사는 아님

>본 자산의 비즈니스 가치를 유지하려면 해당 자산을 변경 및 업데이트해야 합니다.

>대기업 소프트웨어 예산의 대부분은 새로운 소프트웨어 개발보다는 기존 소프트웨어를 바꾸고 발전시키는 데 주력하고 있습니다. -> 수정사항이 발생했을 때 기존의 것들을 처음부터 하기에는 소요가 너무 크기에 곧바로 소프트웨어를 수정하기 시작함(에이자일 기법), 현재 소프트웨어를 갈아엎는 것에도 굉장히 큰 부담이 있음.

 

 

spiral model of development and evolution

->가장 중요한 것들을 모아서 relase에 넣음 -> 명세서를 작성하고 -> 구현을 함-> 시장에 배포하기 전에 검증을 함 -> 시장에 배포

>>위와 같은 순서를 배포모델에 수정사항에 따라 반복함

 

Evolution and servicing(소프트웨어 생애주기)

소프트웨어 개발 -> 소프트웨어 발전(릴리즈들이 늘어남 -> 새로운 기능이 추가됨, 서비스, 버그패치) -> 소프트웨어 서비싱(더 이상 새로운 기능 추가x, 버리기로 결정 or 더 이상 하드웨어가 지탱을 못함, 서비스만 함, 버그수정) -> 소프트웨어 리타이어

 

>Evolution – 서비싱과의 차이는 새로운 기능이 추가됨, operation을 하면서 버그패치 등이 이루어짐

>Servicing – 이제 더 이상 새로운 기능 추가는 없음, 버그 수정, 그러나 이 시스템은 서서히 소멸되거나 이 그대로 감

>Phase-out – 더 이상 이런 프로그램이 필요 없어지기 때문에 단종 or 운영이 중지됨. -> 새로운 시스템으로 갈아탐

 

Evolution processes(필연적 발생)

>Software evolution processes depend on(영향을 주는 것)

-The type of software being maintained -> 소프트웨어가 어떤 형태로 되어있는지

-The development processes used -> waterfall 같은 방식인지 에이자일 같은 방식인지(어떤 개발방법론으로 만들었는지)

-The skills and experience of the people involved. - 누가 이런 소프트웨어를 짜고 그 사람의 경험은 어떠한지

>Proposals for change are the driver for system evolution.(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

-> 변화를 도출하는 과정(고민) -> 변화를 검토하고 분석해서 어떻게 변화할지 제안서가 나옴(결정) -> 소프트웨어 개발(발전) -> 새로운 시스템

>>위 과정이 반복됨

 

 

The software evolution process

변화 요정 -> 변화가 반영되었을 때 우리의 시스템은 어떨까(impact analysis) -> 계획을 세움(다음번 release에 대한 planning, 우리가 테스트과정에서 걸러내지 못한 다양한 변화들(fault repair, 시스템의 버그, 보안사항들 수리), 운영체제 변화(platform adaptation), 시스템의 변경이 요구(새로운 경쟁자, 시장 환경, 법규 규정들과 같은 비기능적인 부분에서 나타날 수 있음)) >>따라서 우리가 이러한 것들을 감안을 해서 어떠한 식으로 release를 할지 계획을 세움 -> 계획을 실행(수정을 진행, 우리가 가하는 수정에서 또 다른 수정이 나타날 수 있음) -> 새로운 시스템이 출시됨

>>여기서 끝나지 않고 끊임없이 위 과정들이 반복됨.

 

Change implementation

-> 변화 제안이 옴 -> 요구사항을 분석함(변화에 따라 기존 요구사항이 흔들린 다면 그것 역시 수정을 해야 함) -> 문서화작업(요구사항서, 설계서들을 모두 다시 업데이트함, plan-based, waterfall 사용에 필수적, 에이자일에서는 좀 더 유연해질 수 있음) -> 수정된 명세서에 따라 다시 개발함

 

Change implementation

지금까지는 기술적인 관점 -> 조직적인 관점에서도 생각을 해야 함(주요한 영향이 있음)

소프트웨어 개발과 관리하는 팀이 다를 수 있음

최초 소프트웨어 릴리즈를 개발한 팀과 소프트웨어를 evolution하는 사람이 다를 수 있음

같을 수도 있음 -> 회사 내에서 만들어서 회사 내에서 사용할 경우

다른 경우는 SI업체(삼성 sds, LG cns)에서 만들었을 때 고객에게 남품을 하고 고객 스스로 evolution을 진행하는 경우 or evolution 자체도 고객님께서 회사에게 맡겼는데 그 전담팀 회사 내에서 따로 존재하는 경우가 있을 수 있음(남의 소프트웨어를 이해해야함 -> 이러한 경우 evolution은 plan-based을 선호 할 수 있음, 문서화가 잘되어 있기 때문에)

 

Urgent change requests -> 급박한 변화 요청이 들어옴

-> 변화 요청 -> 소스코드 분석 -> 소스코드 수정 -> 시스템에 변경된 것들 적용

>>이러한 것 과정에서 문서를 업데이트 시키지 않으면 문제가 발생함

 

Agile methods and evolution

>개발과 발전시키는 팀이 같다면 -> 변화된 요구사항이 들어온다면 그것을 받아서 evolution 과정을 진행시키면 됨

>TDD가 같이 이루어짐

>TDD + 에이자일에 더 수월해질 수 있음

 

 

Handover problems

개발, 발전 과정이 다를 수 있음을 생각해봐야함

-> 에이자일 기법을 이용해서 개발을 했는데 발전하는 팀이 plan-based기법을 사용한다면 자연스럽게 발전 팀이 개발팀에게 문서를 요구하지만 충분하지 않음 -> 개발팀의 소스코드들을 받아서 자신 설계서를 만들어야할 수도 있음. >> 문서화가 필요함

-> 위와 반대의 경우라면 발전 팀이 개발팀에게 TDD와 같은 테스트코드를 요구할 수 있음 -> 발전팀이 스스로 테스트코드를 만들어야 할 수도 있음 -> 에이자일에서는 최적화가 필요하나 안 되어있다고 생각하여 추가적으로 해야 할 수 있음

>>개발 팀과 발전 팀의 개발 기법에 따라 위와 같은 고민들이 이루어질 수 있음

 

 

Legacy systems(오래된 시스템, 사용하지 않는 하드웨어, 인공위성, 화성 탐사선 등에는 오래전 CPU/하드웨어를 사용하고 있는 경우가 있음, 소프트웨어 라이브러리가 유지보수 더 이상 유지 보수되지 않을 때, but 아직까지도 작동하고 있는 것들) -> 전통적인 소프트웨어를 어떻게 evolution 시켜야할지

 

The elements of a legacy system

-> 관점의 중심에는 어플리케이션 소프트웨어라고 할 수 있음

>하드웨어가 더 이상 생산이 되지 않을 경우 문제발생

>데이터베이스에서도 더 이상 사용되지 않는 경우 문제 발생

>비즈니스 프로세스에서 의미가 있지만 너무 오래되었다면 문제가 발생 할 수 있음

>소프트웨어는 지속적으로 발전하고 있는데 문서들이 업데이트가 되지 않는 경우 -> 복잡한 문제 발생

 

Legacy system components

>System hardware – 하드웨어 자체가 단종이 되었을 때 문제 발생

>Support software – 하드웨어에서 올라가는 OS, 라이브러리가 단종(회사부도)되는 경우 문제 발생

>Application software – 이 소프트웨어를 만들 때 사용된 언어와 같은 것들이 거의 단종이 되었을 때 문제 발생(언어를 사용하는 개발자를 구하기도 어려움)

>Application data – 데이터베이스 같은 것들이 더 이상 개발되지 않고 단종 되면 문제 발생

>Business processes – 비즈니스 살아있고 이것을 담은 소프트웨어가 계속 돌아가고 있다면 -> 소프트웨어는 지속적으로 업데이트가 된 상태라면 이러한 것들을 버리기가 어려움

>Business policies and rules – 비즈니스 프로세스를 제약하는 법규와 규정과 같은 것들

>>이러 저러한 이유로 기술 지원이 단종 된 시스템들에 대한 처리가 대부분의 회사들이 가지고 있는 문제임

 

 

Legacy system replacement(가장 간단명료함, 하지만 회사에서 절대 일어나진 않음, 위험함)

> 현재 시스템을 버리고 전혀 새로운 것을 만든다면 문서화가 잘 되어있지 않을 테니 여러 예외 처리되지 않은 문제들이 발생할 수 있음

> 잘못 갈아엎으면 업무 자체가 마비될 수 있음

> 비용적인 문제가 크게 작용함

 

Legacy system change(이것 역시 쉽지 않음)

>역시 비용이 많이 듦

>필요한 부분만 적절하게 적용함

>사멸하는 언어들에 대한 개발자를 찾기도 어려움

>예전 소프트웨어 체계적이지 못함

>릴리즈가 출시된 이후에 수정이 이루어지면서 최초에 설계서가 부정확해지는 경우가 많음

>오래된 것이기 때문에 성능저하가 나타날 수 있음(소프트웨어의 이해가 충분히 되지 않은 상태에서의 수정에서 성능저하가 수반될 수 있음)

>데이터 베이스, 파일처리에 대한 이해가 충분하지 않다면 에러나 중복이 발생할 수 있음

 

Legacy system management(그러면 이러한 것들을 어떻게 처리를 할지)

>이 소프트웨어가 왜 필요한지 그 이유에 대해 생각해봄.(비즈니스 프로세스를 다시 볼 필요가 있음) -> 대체가 가능하다면 현재 것을 날려버릴 수 있음

>그렇지 않다면 계속 유지 보수가 필요함(버릴 수 없음 가져가야함, 이것이 최근에 VM에서 돌려서 많이 사용됨)

>re-engineering – 소프트웨어에 손을 대서 개선시킴

>비즈니스 프로세스를 개선하기 위해 하드웨어를 포함하는 전체 시스템을 바꿔봄

>>위에 것들 중에 어떤 것을 하는 것이 좋은지 결정하기 위한 판단이 있음(system quality – 소프트웨어가 얼마나 잘 만들어져 있는지 유지되어있는 기술적인 측면에서 바라보는 것 , business value – 이 시스템을 계속 운영하므로써 얻는 경제적 이점이 무엇인지 알아보는 것)

 

system quality

-낮을수록 비용도 많이 들고 비효율적임

-높으면 안정적 유지보수 비용에 부담이 크지 않음

business value

-경제적 가치 창출 능력

>Low quality, low business value -> 웬만하면 사라짐, 아니면 다른 쪽에 흡수됨.

>High-quality, low-business value -> 애매함, 보수적인 접근을 한다면 유지를 함, 그렇지 않다면 날려버림, 상용 소프트웨어로 대체함

>Low-quality, high-business value -> 돈을 많이 버는 상태, but 유지보수 비용이 많이 들어감, 소프트웨어에 손을 대서 개선점을 찾아봄(re-engineered), 회사 입장에서 더 좋은 소프트웨어를 만들어서 대체하려고 노력함

>High-quality, high business value -> 대부분 보수적 접근을 하기 때문에 현재 상태를 유지하며 사용함

 

Business value assessment

시스템을 사용하는 System end-users, Business customers, Line managers, IT managers, Senior managers. 이와 같은 사람과의 대화를 통해 현재 소프트웨어 사용에 어떠한 의견을 가지고 있는지를 확인하고 이후 변화를 모색함

 

 

business value assessment(비즈니스 가치가 있는지 판단하는 방법 4가지)

>The use of the system – 시스템을 사용하는 사람의 수와 사용빈도를 가지고 판단

-> 적은 사람들이 간헐적으로 사용한다면 이 시스템의 가치가 적다고 판단함

>The business processes that are supported – 소프트웨어를 뒷받침하고 있는 비즈니스 프로세스가 과연 의미가 있는 것인지 없는 것인지 판단함

>System dependability – 시스템의 안정성, 신뢰성을 통해 판단함

-> 시스템이 안정적이지 못하다면 비즈니스 프로세스를 망가지게 할 수 있기 때문에 부정적인 결과를 초래하게 됨.

>The system outputs – 시스템의 결과가 어떤 비즈니스 가치를 가져오는지 판단함

 

System quality assessment(유지보수 비용이 큰지 작은지)

>Business process assessment – 비즈니스 프로세스 관점에서 접근

>Environment assessment – 환경적 요인에서 접근

>Application assessment – 어플리케이션의 퀄리티 관점에서 접근

 

business value assessment

>>관점 지향적 접근 방식을 사용하고 시스템 이해 관계자에게서 답변을 구합니다.

-Legacy system이 구현하고 있는 비즈니스 프로세스가 모델이 정의되어 있는 것인지 또한 그 모델을 따르는 것인지 근본적인 질문을 함

-회사의 비즈니스 파트를 보고 Legacy system이 구현한 프로세스와 비슷한 프로세스가 있는지를 확인함 -> 하나의 목적을 위해서 수행하는 작업이 두 개 이상의 프로세스로 되고 있는지를 봄 -> 이렇다면 통일화시키는 것이 좋음

-비즈니스 프로세스가 변형이 되거나 개선이 되어 적용이 되는 부분이 있는지 확인함

-진짜 이 비즈니스 프로세스가 필요한지 안한지를 판단함, 다른 비즈니스 프로세스들과의 상관관계는 어떻게 되는지 알아볼 필요가 있음

-근본적으로 현재 Legacy system이 비즈니스 프로세스를 제대로 적용하고 지원하고 있는지 질문해볼 필요가 있음

>>ex. travel ordering system - 여행을 가고자 하는 사람들이 문의를 하고 그 문의를 받아서 여행에 대한 예약을 해주는 시스템

-> 예전이라면 여행사를 방문을 해서 창구에 가서 응대하시는 분에게 본인이 원하는 지역과 날짜를 이야기해서 그 직원 분들께서 직접 컴퓨터에 입력함

-> 현재는 web-based system으로 바뀌어 여행사를 가도 window에 설치되어있는 시스템이 아닌 web-based system를 사용하여 웹상으로 정보를 입력함

-> 더욱이 애초에 여행사를 가지 않고 직접 web-based로 order를 함

-> 최근에는 web을 이용하는 것이 아닌 스마트폰 어플을 통해서 접수를 함

-> 서버에 직접 클라이언트 어플리케이션을 하는 시스템들이 등장함

>>결국은 앞쪽에서 사용한 windows에서 직접 돌아가는 시스템들은 제거 되고 이후 등장한 서버부분의 시스템들도 사라졌다.

>>web-based에서는 직원들이 사라지고 사용자가 직접 신청을 함 -> 비즈니스 프로세스가 바뀐 것임 -> 직원이 사용하는 웹기반 예약시스템도 필요가 없어 사라짐

>>Legacy system도 중요하지만 이 시스템이 지원하는 비즈니스 프로세스가 사라졌거나 바뀌었다면 Legacy system 사라지거나 다른 것으로 바뀔 수 있다는 것을 비즈니스 프로세스를 보고 결정을 함

 

Factors used in environment assessment(환경적인 측면)

>Supplier stability – 외부에서 조달해서 사용되는 것들의 공급자가 안정적인지

>Failure rate – 하드웨어 or 소프트웨어가 실패가 얼마나 일어나는지

>Age – 얼마나 오래되었는지, 오래되었다면 위험부담이 커짐

>Performance – 성능이 변화된 사항들을 따라가지 못하는 것

>Support requirements – 지원 요청, 문제가 발생되었을 때 처리가 되는지, 얼마나 빨리 처리가 되는지, 외국 제품의 국내 지사가 사라진다면 처리시간이 길어질 수 있음

>Maintenance costs – 라이센스(사용에 대한 권리, 업데이트 비용)비용이 존재, 유지보수 비용, 비용적인 문제로 오픈소스 소프트웨어로 교체하는 경우도 있음

>Interoperability – 컴퓨터가 운영체제 적으로 소프트웨어적 하드웨어적으로 다른 컴퓨터와의 연결이 수월하지 -> 통신 시스템만 하더라도 이전의 것들은 현재의 것들과 다른 것들도 존재함(호환되지 않음)

 

Factors used in application assessment(어플리케이션 측면)

>Understandability – 이해할 수 있는지

>Documentation – 예전에 것들은 문서화가 잘 이루어져 있지 않기 때문에 이해하기 어려운 측면이 많음

>Data – 과거의 데이터들은 중복도 많고 구조도 이상한 것들이 많음, 유지가 가능할지 생각해 보아야함

>Performance – 성능적인 면에서 수요가 올라감에 따라 성능이 받쳐주지 못한다면 사용에 어려움이 있다.

>Programming language – 지금까지 오면서 사멸된 언어들이 많은데 그러한 언어들을 계속 발전시킬지에 대한 판단이 필요함

>Configuration management – 릴리즈를 할 때 내보내는 것과 버전컨트롤을 하기 위한 방법들을 배웠는데 그러한 것들이 제대로 이루어지고 있는지 볼 필요가 있음.

>Test data – 소프트웨어를 바꾼다면 그것에도 이전 테스트 데이터들이 적용될 수 있는지 판단을 함

>Personnel skills – 도저히 이 언어를 다룰 수 있는 사람이 없다, 도저히 이 언어로 개발환경을 이해할 수 있는 사람이 없다면 날아가게 됨.

>System measurement

-> 측정을 할 때 우리가 가지는 부담이 있음

-> 이 소프트웨어에 변화가 생길 때 있을 수 있는 것들을 정량적으로 측정해본 것

>>number of system change requests – 문제를 지적하는 요청이 많이 온다면 소프트웨어에 문제가 있는 것으로 판단함

>>number of different user interfaces used by the system – 얼마나 많이 다른 것들과 연관이 되어있는지 보고 많은 것은 변화를 주기에 부담스러움(부담을 덜기 위해 앞에서 관문을 세우는 기법이 있었음)

>>volume of data used by the system – 데이터의 사이즈, 데이터를 얼마나 많이 사용하고 있는지, 데이터를 많이 사용하고 다룬다면 변화에 따른 위험도가 높을 수 있음

>>Cleaning up old data is a very expensive and time-consuming process – 의외로 데이터에서 큰 비용이 들 수 있음, 기존의 시스템을 바꾸면서 데이터의 형태가 바뀌어 버렸다 그런데 그 데이터를 버릴 수 없다면 이전의 모든 데이터를 변형된 데이터의 형태로 바꿔줘야 함(하드웨어, 소프트웨어뿐만 아니라 데이터도 중요함)

>>결국은 버리거나 바꾸거나 개선하는 것 중 결정을 내려야함 -> 정답이 있는 것이 아님

 

Software maintenance(유지보수, 협의의 의미도 가짐)

큰 대대적 변화가 아닌 마이너 변화를 가짐(시스템 구조를 바꾸는 큰 변화가 아님)

새로운 기능이 들어갈 수는 있지만 그로인해 시스템 전반적인 구조를 바꾸지는 않음.

 

 

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

>Fault repairs – 버그, 테스트에서 걸러내지 못한 오류를 수정하는 과정

>Environmental adaptation – 현재 동작하는 소프트웨어가 새로운 하드웨어, 운영체제 위에서 돌아가야 한다면 환경에 맞춰서 변화하는 과정

>Functionality addition and modification – 새로운 기능을 추가하거나 기존기능을 바뀌는 과정

>>새로운 릴리즈가 아닌 마이너 변화를 적용하고 시스템의 전체적인 구조를 바꾸지는 않음

 

Maintenance effort distribution -> 위의 3가지는 어떤 비율로 구성될까?

>Fault repairs(24%)

>Environmental adaptation(19%)

>Functionality addition and modification(58%)

>>버그는 발생할 수밖에 없다.

>>당연히 있는 일이라고 생각하고 받아들이는 자세가 필요함

 

Maintenance costs(유지보수 비용, 개발할 때 드는 비용보다 훨씬 많이 들어감)

기술적인 요인

비즈니스의 변화

법규, 규정의 변화

현재 시스템의 추가되는 것들이 많음 -> 이에 따른 성능저하가 일어날 수 있다 -> 소프트웨어 구조에 문제를 줄 수도 있음.

시간이 지남에 따라 비용이 올라갈 수 있음.

 

 

Maintenance costs(유지보수 비용, 딜레마가 존재)

> 회사는 통상 새로운 소프트웨어를 만들어서 릴리즈하는 것에 가치를 더 많이 둠 -> 대기업들이 여러 팀을 구성해서 개발과 유지보수를 진행함에 따라 사람이 달라지면 그에 따른 이해를 하는데 시간이 많이 소요됨.

> 회사는 통상 새로운 소프트웨어를 만들어서 릴리즈하는 것에 가치를 더 많이 두기 때문에 유지보수에는 가치를 많이 두지 않기 때문에 유지보수자에게 보상이 제대로 이루어지지 않을 수 있음. -> 유지보수팀이 평가 절하되는 경우가 있음 -> 소프트웨어에 부정적인 영향을 끼침

> 프로그램이 나이를 먹으면 전체적으로 성능이 낮아지고 그에 따른 유지보수 비용들이 늘어나게 된다.

>>유지보수라는 과정은 당연히 존재할 수밖에 없다고 받아들여야함

>>조직적인 도움도 필요함

 

Maintenance prediction(유지보수 예측)

-> 제한된 자원, 인력, 시간을 가지고 유지보수 비용을 절감 할 수 있을까?

-> 시스템에서 가장 많은 문제를 불러일으키는 부분을 생각해봄

-> 가장 많은 비용을 요구할 것 같은 부분을 예측해봄

>>이러한 과정을 개발, 유지보수 과정에서 지속적으로 해줌으로써 비용을 줄인다.

-> 시스템 성능은 기능이 추가됨에 따라 낮아질 수밖에 없다 -> 이에 따라 유지보수 비용은 증가함

>>계획적인 작업이 필요함.

>>미리 선제적으로 발생할 문제들을 예측해서 수정함

 

유지보수 예측에 대한 질문

>유지보수 비용이 가장 많이 들어갈 곳(시스템의 구성요소)은 어디인가? -> 실제적인 비용을 산출해봄 -> 비용이 너무 많이 들어간다면 현재 시스템에 대한 replace를 선언함

>어떤 변화들을 받아드릴 것인지

 

Change prediction(변화 예측)

> 가장 비용이 많이 나올만한 부분을 찾아보는 것

> 변화가 발생할 수밖에 없는 요인을 생각해봄

> 비즈니스 프로세스가 변경된다면 발생할 수밖에 없는 변화들을 파악해봄

>>변화의 근간에 있는 비즈니스 프로세스를 어떤 식으로 예측해야 소프트웨어의 변화도 예측할 수 있다.

> 법령, 규정 등의 외부적인 요인에 의해서도 변화가 올 수 있음

> 상관관계가 있는 것들을 파악하여 변화를 예측해볼 수 도 있다.

 

Complexity metrics(소프트웨어가 복잡하다면...)

-> 구조와 같은 것들이 복잡하다면 유지보수에 어려움이 생길 수 있다.

-> 모듈의 크기도 고려해야함

 

Process metrics(소프트웨어 프로세스 아님)

-> 이러한 유지보수 과정이 제대로 돌아가고 있는지 판단

-변화요청이 많아지고 쌓이고만 있다면 제대로 처리가 이루어지고 있지 않은 것임

-평균적인 프로세스 시간도 일정해야함

-변화요청 구현 시간도 일정해야함

-처리되지 않은 변화요청도 왜 이렇게 쌓여있는지 판단이 필요함

 

Software re-engineering(소프트웨어를 개선시키는 작업, refactoring – 에이자일에서 많이 사용)

-Restructuring하는 경우가 많음, 설계를 다시 수정을 하고 함수는 잘 수정하지 않음

-일부분에 대해서 마이너하게 수정을 진행함

-다시 문서화를 함

장점

-risk가 줄어듦

-비용이 줄어듦

 

 

re-engineering 과정

-주로 구조를 바꾸는 경우가 많음

>Source code translation – 소스코드를 변환하는 작업

>Reverse engineering - 문서화된 것을 통해서 다시 만듦

>Program structure improvement – 주로 이곳이 많음, 구조를 많이 수정함

>Program modularisation – 중복성을 줄이던지 하는 것이 가능

>Data re-engineering – 필요하다면 데이터의 골격도 수정이 가능

-> 자동화는 아직 많이 사용되지는 않는다.

 

Re-engineering cost factors(비용 요소)

>The quality of the software to be re-engineered. -> 소프트웨어의 품질

>The tool support available for reengineering. -> 자동화된 부분이 있다면 사용

>The extent of the data conversion which is required. -> 데이터 영역도 건드릴 필요가 있다면 수정함

>The availability of expert staff for reengineering. -> 이걸 다룰 수 있는 사람이 있을까?

>>Re-engineering을 통해서 기존의 소프트웨어에 손은 대지만 가능한 risk가 최소화 된 상태에서 변화를 도모한다.

Refactoring(에이자일에서 사용)

-소프트웨어를 수정함

-성능을 개선을 하거나 복잡성이 너무 높은 것들은 낮출 수 있게 수정을 함

 

Refactoring and reengineering

reengineering -> waterfall, plan-based처럼 단계를 거쳐서 릴리즈를 하고 유지보수 단계로 들어간 것을 의미함

Refactoring -> 연속적인 프로세스(에이자일) 스프린트로 나선형으로 개선해 나가는 것

>>둘을 유사하게 사용하기도 함

 

Bad smells(안 좋은 것)

>Duplicate code – 중복된 코드

>Long methods – 함수가 너무 긴 것, 하나의 일을 하는 것으로 잘게 쪼게는 것

>Switch (case) statements – 너무 무자비하게 사용하면 중복성이 발생할 수 있다

>Data clumping – 데이터의 중복성

>Speculative generality – 현재는 사용하지 않는데 나중을 위해 넣은 것

 

Key points

- 소프트웨어 개발과 진화는 나선 모델(spiral model)을 사용하여 표현될 수 있는 통합된 반복 프로세스라고 생각할 수 있습니다.

- custom systems의 경우 소프트웨어 유지 보수 비용이 소프트웨어 개발 비용을 초과하는 경우가 많습니다.

- 소프트웨어 발전 과정은 변경 요청에 의해 추진되며 변경 영향 분석, 릴리스 계획 및 변경 구현이 포함됩니다.

- 기존 시스템(Legacy systems)은 구식 소프트웨어 및 하드웨어 기술을 사용하여 개발된 오래된 소프트웨어 시스템으로 비즈니스에 유용하게 사용됩니다.

- 현대 기술로 대체 시스템을 개발하는 것보다 레거시 시스템(legacy system)을 유지하는 것이 더 저렴하고 덜 위험합니다.

- 레거시 시스템(legacy system)의 비즈니스 가치와 애플리케이션의 품질을 평가하여 시스템의 교체, 변형, 유지 여부를 결정할 수 있도록 합니다.

- 소프트웨어 유지보수에는 버그 수정, 새로운 환경에서 작동하도록 소프트웨어 수정, 신규 또는 변경된 요구사항 구현 등 3가지 유형이 있습니다.

- 소프트웨어 재엔지니어링(Software re-engineering)은 소프트웨어 재구성과 재문서화를 통해 보다 쉽게 이해하고 변경할 수 있도록 합니다.(waterfall, plan-based)

- 기능을 보존하는 프로그램 변경이나 리팩터링(Refactoring)은 예방 정비의 한 형태입니다.

(에이자일)