유지보수

💎 개요

💍 유지보수

• 소프트웨어가 인수되어 설치된 후 일어나는 작업

• 전체예산의 70% 정도가 유지보수에 사용됨

• 주의 : 개발에서 비용이 가장 많이 드는 단계는 어디냐 ? 유지보수가 제외되기 때문에 구현단계가 가장 비용이 많이 든다. 단위테스트+구현 = 구현단계

💍 유지보수의동기

• 교정형 유지보수(수정) : 테스트 단계에서 발견되지 않은 오류가 시스템이 인수되어 사용될 때 발견되는 경우

• 적응형 유지보수 : 소프트웨어의 운영 환경의 변화에 따라 변경되는 경우

• 개선형 유지보수 :
  1) 시스템에 새로운 기능을 추가하는 형태의 유지보수(완전 유지보수) : 미처 생각치 못했던 요구사항의 발생, 사용자 인터페이스 향상, 성능 개선
  2) 미래에 발생할 수 있는 결함을 방지하기 위해 논리구조, 성능, 유지보수성을 개선하는 유형(예방 유지보수)

💎 유지보수란?

💍 리먼의 원리 (소프트웨어의 변화 원리)

• S/W는 계속 변경됨

• 복잡도가 계속 증가

• 대규모 S/W의 유지보수에는 일정한 특성이 있음

• 대규모 S/W는 안정화 상태인 경우가 많음

• 진화 시 이전 버전과 친근성 유지 경향

• S/W의 기능은 계획 증가함

• S/W가 운영환경에 적응하지 못하면 품질이 저하됨

• S/W는 피드백을 통해 진화해 나감

💍 개발작업과 유지보수 작업의 차이

💍 유지보수의 접근 방법

• 형상관리가 잘됐는지 여부에 따라 달라짐
  cf) 형상관리 : 소프트웨어의 변경 과정을 잘 보관하는 작업, 대상 시스템을 이루는 모든 요소에 대해 문서화

• 형상관리가 잘 된 경우 : 이떄의 테스트는 regression test

• 형상관리가 잘 안된 경우 : 소프트웨어를 이해하기 위한 자료는 원시코드 뿐이다. 역공학을 이용한다.

💍 유지보수에 영향을 주는 요소

• 사용자 : 불편, 오류의 개선을 위한 변경 요청

• 환경 : 운용 환경, 조직 환경

• 유지보수 프로세스 : 변경 요청, 이해 및 변경, 변경 효과 분석, 리그레션 테스팅

• 소프트웨어 제품 : 지속적인 사용과 변경

• 유지 보수 인력 : 관련된 사람

💍 유지보수 작업의 문제점과 한계

• S/W에 대한 변경이 수시로 발생 : 문서에 반영하지 않는 경우, 이를 추적하는 것은 거의 불가능(추적성)

• 다른 사람이 작성한 프로그램을 이해하는 일은 쉽지 않음 : 문서화 되어있지 않거나 주석도 달지 않았다면 문제는 매우 심각

• 변경을 가정하여 설계되는 경우가 드묾

• 관리적인 측면에서 유지보수를 담당하는 프로그래머에게 동기 부여를 하지 못함

• 유지보수를 위한 적극적인 도구를 사용하지 못함 :
  프로그램 이해를 위하여 테스트나 디버깅 도구를 사용하는데 그침

💎 유지보수 작업 단계와 모델

💍 유지보수 작업 단계

• 소프트웨어의 개발 : 사용자의 요구를 이해 -> 분석 -> 설계 -> 구현

• 유지보수
  1) 현재 시스템이 처한 상황과 제약에서 출발하여 개선 요구를 이해한다.
  2) 변경 영향 분석 : 변경이나 추가에 의해 시스템이 어떻게 영향을 받는지를 조사하는 작업
  3) 유지보수의 단계 : 프로그램 이해 -> 변경 요구 분석 -> 변경 영향 분석 -> 리그레션 테스트

💍 변경 요구 분석

• 소프트웨어 변경이 불가피한 이유와 요구를 분석하는 과정

• 방법
  1) 오류를 잡기위한 교정형 유지보수 : 어떤 부분이 잘못 됐는지 추적
  2) 변화된 운영환경 때문에 변경이 필요한 적응형 유지보수 : 새로운 환경을 철저히 연구하고 조사
  3) 기능 향상을 위한 변경이 필요한 개선형 유지보수 : 새로운 기능의 요구를 정확하게 분석하고 이해

💍 변경 영향 분석

• 소프트웨어를 실제로 변경하기 전에 변경으로인한 효과를 점검하는 과정 : 코드 수정으로 다른 부분이 영향을 받는지 확인하고 연쇄적으로 고쳐야 하는지 점검, 변경으로 인해 영향을 받는 문서는 무엇이며, 어떤 부분인지 확인

• 변경 영향 분석 시의 주의점
  1) 하나의 요구를 충족하기 위해 여러 곳을 변경할 수 있음 -> 이런 경우 변경이 필요한 부분을 모두 찾아야함
  2) 변경 요구를 수용하기 위해 또 다른 변경 방법이 있는지 알아봐야함
  3) 문제의 근본 원인을 제거하기 위해 하나의 컴포넌트만 수정하기는 어려움
  4) 결함을 발견하고 수정하는 여러 방안을 검토한 후 각 방안의 유지보수 비용을 고려
  5) 변경 영향 분석에 추가하여 변경과 관련된 리스크를 파악하고 리스크를 해결했다는 것을 확인할 수 있는 층정방법도 정의돼야 함

💍 리그레션 테스트

• 소프트웨어를 변경한 후에도 여전히 같은 기능을 한다는 것을 확인하기 위한 테스트

• 변경에 의해 영향을 받는 부분만 다시 테스트하는데, 어떤 부분을 재시험해야 하는지 알아내기 어려운 경우가 많음

• 모든 테스트 케이스가 보관되어야 하는 이유

💍 유지보수 작업 모델

💍 즉시 수정 모델

• 임시방편적인 유지보수 작업 모델

• 문제가 일어날 것에 대비하여 기다리다가 가능하면 빨리 문제를 해결하는 방식

• 장기적인 효과를 자세히 분석하지 않고 바로 수정하며 문서 수정은 최소화됨

💍 반복적인 개선 모델

• 소프트웨어 개발 생명주기 동안 반복적으로 변경이 일어나 시스템이 계속 개선된다는 전제에 바탕을 둔 모델

• 자주 사용되는 환경 : 요구가 완전히 이해되지 않고 전체 시스템을 구축할 수 없는 환경

• 즉시 수정 모델을 체계화한 것 : 즉시 수정모델은 버그의 수정이 아니라, 수정이 더 많은 문제를 일으킬 수 있기 때문

💍 재사용 중심 모델

• 재사용의 개념
  1) 재사용 후보가 될 만한 시스템의 부품을 파악
  2) 시스템의 부품을 이해
  3) 시스템의 부품을 새로운 요구에 맞추어 변경
  4) 변경된 부품을 새 시스템에 통함

• 재사용 중심 모델은 재사용 컴포넌트를 위한 저장소가 필요