소프트웨어 공학 11(유지보수)

유지보수(maintenance)

• 개발 후에 이루어지는 소프트웨어의 변경 작업
• 소프트웨어가 유용하게 활용되는 기간
• 소프트웨어는 환경과 비즈니스 요구에 따라 진화함
• 유지보수에 드는 노력

 

레거시(legacy) 시스템

• 옛날 시스템
• 대체하려면 비용이 많이 든다.
• 지식, 경험, 지능이 녹아 있음
• 여러가지 이유로 수정 후 배포하는 작업
  • 버그 제거
  • 운영 환경의 변화
  • 정부 정책, 규례의 변화
  • 비즈니스 절차의 변화
  • 미래 문제를 배제하기 위하여 변경

 

유지보수 유형

• 수정형 유지보수(corrective maintenance)
  • 발견된 결함을 고치기 위하여 소프트웨어 제품을 수정
  • 테스트에서 발견 못한 오류를 실 사용 도중 발견해 report가 왔을때 수정

 

• 적응형 유지보수(adaptive maintenance)
  • 변경된 환경에서도 계속 사용할 수 있도록 소프트웨어를 이식하거나 변경
  • 새로운 운영체제/하드웨어 환경으로 이식
    • os가 바뀜에 따라 유지보수

 

• 완전형 유지보수(perfective maintenance)
  • 구조개선을 통해 성능 및 유지보수성을 개선하기 위하여 실시하는 유형

 

• 예방형 유지보수(preventive maintenance)
  • 오류 발생을 방지하기 위해 수행하는 유지보수

 

• 응급형 유지보수 (emergency maintenance)
  • 응급처치하기 위한 무계획적 유지보수

 

Lehman의 법칙

• 계속 변화해야 함(보다 쓰기 편하게 해줘야 함)
• 복잡도 증가(유지보수를 해도)

 

유지보수작업과정

1 현재 프로그램의 이해

• 프로그램 로직을 추적하거나 요구, 설계 등에 대한 이해가 필요

2 변경 파악과 분석

• 필요한 변경을 파악하고 그 영향도와 소요 비용, 변경에 의한 리 스크를 분석

3 변경 영향 파악

• 이해당사자들에게 알리고 피드백을 얻음

4 변경 구현, 테스트, 설치

• 시스템을 수정하고 확인 후 설치

 

유지 보수 프로세스 모델

#### 즉시 수정 모델

 

반복적 개선 모델

• 운영체제/ 환경변화
• 성능 개선 및 기능 추가
• 관련 프로세스 모델
  • 진화 모델

 

 

재사용 중심 모델

• 컴포넌트 저장소
  • 더 좋은 컴포넌트로 대체

 

변경 파악과 분석

• 클래스간의 관계에서 파악
• 변경 요구를 기초로 어떤 부분을 변경할지 찾아냄

 

객체지향 소프트웨어

• 상속

class A extends B{
    ...
}

• 포함
  • data 파트에 존재

class A{
    Data c = new Data();

    ...
}

• 연관(의존)
  • 메서드에 코딩할때 다른 클래스를 사용

class A{
    method foo(Data d){
        d.ride();
        ...
    }
}

형상 관리

• 개발 주기 동안 생성된 문서를 관리하고 소프트웨어 시스템과 컴포넌트의 상태를 추적하는 작업
• 형상
  • SW(소스코드, 문서) + 버전 + @(누가 했는가)

 

베이스 라인

• 기준이 되는 소프트웨어 형상 항목(configuration item)의 집합
• 목적
  • 프로젝트의 중요한 상태 정의
  • 프로덕트가 특정 상태에 이르렀는지를 나타냄
  • 계속되는 개발, 유지보수 작업의 기준
  • 형상 항목에 대한 변경을 제어하는 메커니즘

 

역공학(reverse engineering)

• 유지보수 하려는데 문서가 없는 경우 소스코드로 부터 문서를 만들어내는 작업
  • 추상화된 것으로 만드는 작업
  • 소스코드 -> 설계문서 -> 분석문서(역공학 과정)

 

리엔지니어링(re-engineering) - 재공학

• 시스템 또는 컴포넌트를 재구조화 하는 과정(구조를 바꿈)
• SW가 체계가 없고 가독성이 떨이질때 재구조화

SW공학

• 대규모 고품질 소프트웨어를 체계적으로 개발하기 위한 방법론

 

품질

품질

1. 시스템, 구성 요소, 프로세스가 지정된 요구 사항을 충족시키는 정도
2. 시스템, 구성 요소, 프로세스가 고객 또는 사용자 요구나 기대를 충족시키는 정도

• 사용자 입장에서 만족감 - big q
• 개발자 입장에서의 오류가 없는 것 - small q

 

품질 속성

 

소프트웨어의 품질속성은 세가지 차원이 존재

• 품질 요소(factor) : 사용자에 의한 외부 관점
• 품질 기준(criteria) : 개발자 측면의 내부 관점
  • 사용자 입장의 quality가 좋아야하는데 이러한 부분을 결정하는 부분은 개발자 품질 기준의 어떠한 부분에 해당하는지 매핑
• 메트릭차원 : 품질을 제어
  • 품질 기준의 척도
  • 어떤 척도로 평가되는가

 

• 신뢰성(reliability)
  • 소프트웨어에 요구된 기능을 명시된 조건 하에 실행하여 정확하고 일관성 있는 결과를 생성하는 능력
  • 주어진 입력에 대한 일관된 출력
• 강인성(robustness)
  • 소프트웨어에 요구된 기능을 어렵거나 예외적인 환경에서 수행할 능력
  • 과부하에 잘 견디는가?
  • 관련 테스팅: 스트레스 테스팅 (stress testing)
• 효율성(efficiency)
  • 소프트웨어에 요구된 기능을 최소의 시간과 자원을 사용하여 원하는 결과를 생성하는 능력
    • 시간 효율성 : 빨라야 함
    • 공간 효율성 : 메모리를 적게 사용
• 상호운용성(interoperability)
  • 소프트웨어가 다른 소프트웨어와 정보를 교환하는 능력
  • SW가 외부시스템과 연계할때 그 연계시스템과의 정보 교환 능력
• 유지보수성(maintainability)
  • 소프트웨어가 오류수정 및 진화 (구조개선 등)될 수 있는 성질
  • 재공학을 통해 유지보수가 좋게 만들어야 함
• 테스트가능성
  • 소프트웨어에 요구된 또는 적용될 수 있는 모든 형식의 평가
  • 테스트하기 좋은 SW
  • 인스펙션(정적분석), 화이트박스 테스팅, 블랙박스 테스팅 등
• 이식성(portability)
  • 소프트웨어가 여러 운영 환경 및 플랫폼에서 실행될 수 있도록 변형이 가능한 성질
• 재사용성(reusability)
  • 소프트웨어가 확장이나 커스텀화 없이 유사한 또는 다른 운용환경에서 사용될 수 있는 성질
• 모듈성(modularity)
  • 소프트웨어가 모듈 컴포넌트의 집합체로서 관련 모듈의 통합이나 조정을 쉽게 하는 성질

품질 관리

 

• 소프트웨어 제품이나 아이템이 정해진 요구에 적합하다는 것을 보장하는 데 필요한 계획적이고 체계적인 활동
• 다양한 작업이며 미치는 영향이 크다
• 품질관리기능
  1. 프로세스와 표준의 정의
  2. 품질보증
  3. 프로세스 개선

전통적인 품질 메트릭

• mdc = 자체복잡도 = d + 1(다이아몬드 수)
• S0 = 바로 아래의 자식의 SO + mdc(본인)
  • 위 그림에서 M2의 SO = 4(1 + 1 + 2)
  • M0의 SO = 12(3 + 4 + 3 + 2)

 

구현 및 시스템 메트릭

구현 메트릭

• LOC 메트릭 : 원시코드의 줄을 세는것
• 싸이클로매틱 복잡도 메트릭 : 프로그램을 통과하는 독립된 경로의 개수이며 필 요한 테스트의 횟수

 

시스템 메트릭

 

• 신뢰도 메트릭(용어의 뜻 확인)
  • MTBF = MTTF + MTTR
  • MTBF(Mean Time Between Failure) : 고장 사이의 평균 시간
  • MTTF(Mean Time To Failure) : 고장 까지의 평균시간
  • MTTR(Mean Time To Repair) : 수리 평균시간
• 가용성 메트릭
  • 사용이 필요할 때에 시스템이 바로 운용/접근할 수 있는 정도
  • 가용성
    • $\frac{MTBF}{(MTBF+MTTR)}$
    • 시스템이 죽지 말아야 할 정도
    • 항시 가동하는 정도

CMMi 모델

• 프로세스가 좋아햐 품질이 좋은 소프트웨어를 개발 가능
• 프로세스 성숙도를 위한 프레임 워크
  • 프로세스 개선(진화) 과정(개선의 단계를 보여줌)

 

• initial:
  • 개발 프로세스가 임시방편, 무질서, 영웅적 개인(잘하는 개발자)에 의존, 예측 불가능
• repeatable:
  • 비용, 일정, 기능에 대한 예측과 추적이 가능, 통제관리가 되고있음
  • 개인적 경험보다 과거 데이터에 의존 (과거에 성공 프로젝트를 재현할 수 있는 단계), 개발 프로세스가 안정화
    • 안정화는 되어있지만 비용이 계속 바뀔 수 있음
    • 반복가능한 프로세스가 세팅이 됨
• defined:
  • 프로세스 표준에 따름, 일관성이 중요, 개발팀 조직, 관리조직의 분화, 프로세스 관리팀이 표준화에 따라 관리함
    • 표준 -> 일관성
    • 비용같은 부분이 일관성이 있어짐
• managed:
  • 프로세스/프로덕트 품질에 대한 정량적 평가 가능, 정량적 목표 설정, 정량 목표 도달 가능성 예측, 도달 하지 못할 것을 예측하는 경우 별도의 조치
    • 여러 속성에 대한 정량적 평가 가능
    • 품질이 정량화
• optimizing:
  • 정량적 feedback에 의해 지속적인 프로세스 개선이 가능, 측정 기반 old technology, methodology를 퇴출, 혁신 추구
    • 정량화된 프로세스를 기준으로 자체 개발