소프트웨어 공학

Lecture #10: 유지 보수

안 병 익biahn99@gmail.com

강의 블로그 Mobilecom.tistory.com

학습 목표

2

유지보수의 특성

소프트웨어 형상 관리

소프트웨어 척도

유지보수 방법 및 도구

유지 보수

소프트웨어가 인수 설치된 후 일어나는 모든 작업소프트웨어가 유용하게 활용되는 기간소프트웨어 유형에 따라 비용이 많이 들 수 있다 < 예 >

분 류 주문 1 주문 2 패키지 1 패키지 2개발 man-month 580 725 580

725 비용 (100 만원 ) 1,160 1,450 1,160

1,450유지 man-month 보수 배달 및 설치 0 0 3,982 4,146 중앙유지보수작업 70 365 87 383 현장 서비스 0 0 2,233 2,775 비용 (100 만원 ) 140 730 12,604

14,608비율 1:0.1 1:0.5 1:10.8 1:9.4

3

유지 보수가 어려운 이유

소프트웨어의 특성 invisibility complexity changeability

old code관리의 부재

4

유지 보수의 종류

정정 (corrective maintenance) 발견된 오류의 원인을 찾아 문제해결 . A/S 의 개념

개작 (adaptive maintenance) 새로운 자료나 운영체제 , 하드웨어 환경으로 이식

기능 개선 (perfective maintenance) 새로운 기능의 추가

예방 (preventive maintenance) 유지보수성 , 신뢰성 향상 구조 변경

5

10.1 유지 보수 작업의 특성

유지보수 작업 방대한 분량과의 싸움 변경에 대한 관리

유지 보수 작업 과정

유지 보수 비용

유지 보수의 문제점

6

유지 보수 작업 과정

1) 소프트웨어의 이해 문서 , 코드 reading 프로그램의 구조 파악 domain knowledge 습득 변수와의 관계 , 서브루틴 사이의 관계 파악 코드 안에 숨겨진 의미 (semantic) 파악 분석도구 (call graph, cross-reference table 등 ), 디버깅 도구

(tracer) 사용2) 변경 요구분석

변경이 불가피한 이유와 요구를 이해 기능 향상의 경우는 새로운 기능의 분석

3) 변경 및 효과 예측 code change change effect 분석

7

유지 보수 작업 과정

4) 리그레션 테스트 (regression test) 변경 부분과 그에 의하여 영향이 있는 부분만 테스트 각 작업이 포괄적이며 단발로 시행 ---> 다양한 기술이 필요

8

유지 보수 비용

개발 30 %유지보수 70 % 50% 기능개선

25% 개작21% 정정4 % 예방

유지보수 단계의 생산성 개발단계의 생산성의 1/40

9

유지보수 비용 예측

1) Belady 와 Lehman M = p + Ke^(c-d)

M : 유지보수를 위한 노력 , P : 분석 , 평가 , 설계변경 , 코딩 등 실제 생산성 있는 노력 , K : 통계에 의한 상수 c : 설계의 비구조성이나 문서의 미흡함을 나타내는 복잡도 d : 소프트웨어와의 친숙성

2) COCOMO 방법M = ACT X DE X EAT M : 유지보수를 위한 노력 ACT : 개발조직이 수행하는 전체 프로젝트 규모에서 유지보수 작업이 차지하는 연평균 비율 (annual change traffic) DE : 개발할 때 필요했던 노력 EAT : COCOMO 의 유지보수 작업을 위한 노력 조정수치

10

유지 보수의 문제점

소프트웨어에 대한 변경이 수시로 일어나며 이를 문서에 반영하지 않는 경우 이를 추적하는 것은 거의 불가능하다 .

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

소프트웨어가 변경을 가정하여 설계되는 경우가 드물다 . 관리적인 측면에서 유지보수를 담당하는 프로그래머에게

동기부여를 하지 못한다 . 유지보수를 위한 적극적인 도구를 사용하지 못한다 . 프로그램 이해를 위하여 테스트나 디버깅 도구를 사용하는데 그친

다 .

11

10.2 소프트웨어 형상관리

변경에 대한 철저한 관리가 필요

---> 소프트웨어 형상 관리형상 관리 (Configuration Management)

소프트웨어를 이루는 부품의 baseline( 변경 통제 시점 ) 을 정하고 변경을 철저히 통제하는 것

형상 관리 항목 분석서 설계서 프로그램 ( 원시코드 , 목적코드 , 명령어 화일 , 자료 화일 , 테스트

화일 ) 사용자 지침서

12

관리적 측면

형상 관리를 위한 조직 분석가 : 사용자와 상의하여 무엇이 문제이며 어떤 기능향상 및 개작이

필요한가를 정한다 . 프로그래머 : 분석가와 협동하여 문제의 원인을 찾아내고 변경의 형태와

내용을 알아낸다 . 실제 프로그램의 수정을 담당한다 . 프로그램 사서 : 문서와 코드에 대한 변경을 계속 보관하고 관리한다 .

13

형상관리 변경 절차

① 변경 요청서 작성 사용자 또는 프로그래머

변 경 요 청 서 요구자 :___________ 날짜 :_________ 소프트웨어 _________________ 변경내용 : _________________________________________________________ _________________________________________________________ _________________________________________________________ 유지보수 형태 : 변경에 의해 영향받는 범위 : 1. 정정 □ ___________________________________________ 2. 개작 □ ___________________________________________ 3. 개선 □ ___________________________________________ 문제의 심각정도 : 변경요청 이유 1. 피할 수 있음 □ _________________________________________ 2. 가벼움 □ __________________________________________ 3. 가동중지 □ __________________________________________ 완료기일 :____________( 날짜기입 ) 또는 1. 즉시 □ 2. 수일내 □ 3. 다음 버젼 □ 4. 기간없음 □

14

형상관리 변경 절차

② 분석가에 의하여 review 문제가 아닌 것 교육을 통하여 해결할 수 있는 것 그 외의 것은 형상관리 위원회 소집

③ 제안된 변경을 검토하여 수정 작업의 범위와 필요한 시간을 추정하고 이에 필요한 인원과 비용을 예측 제기된 변경을 이행할 것인지 결정 가결된 변경 요청에 대하여 우선순위를 정하고 제약 사항을 고려한 후 변경을 담당할 형상 관리 팀에게 넘겨짐

④ 시험 시스템을 수정하여 변경 효과를 점검

⑤ 변경 위원회의 설치 승인을 받은 후 새 버전을 설치

⑥ 관계되는 문서를 수정하고 변경 보고서 작성

15

형상관리 기술적 측면

어떤 방법으로 시스템에 관련된 모든 변경을 추적하여 시스템의 현재 상태를 항상 알 수 있게 할 것인가 ?

개발 단계에도 적용 가능형상 관리 항목을 정하고 모든 변경은 공식적인 합의에 의하여 실시가동 중인 소프트웨어의 변경은 신중을 기해야 함

조금씩 점증적으로 변경하고 검증부분적으로 변경된 대규모 시스템

object 의 구성이 문제 버전 관리 시스템

16

예 : 형상관리 기술적 측면

시스템 구축 UNIXmakefile

논리적 시스템 구조물리적구조로의 전환

화일 1 화일 2 화일 2’ 화일 2”

17

10.3 소프트웨어 척도

Preventive maintenance --> 여러 가지 소프트웨어의 품질 측정 기술이 필요품질

유지보수성 (maintainability) 신뢰성 (reliability) 전환성 (portability)

De Marco, We cannot control what we can not mea-sure.

척도 (metric) product metric( 프로그램의 크기 , 복잡도 , 자료의 크기 , 기능성 ,

신뢰성 , 전환성 , 일관성 , 유지보수성 ) process metric( 개발에 걸리는 시간 , 비용 , 진척 상황 )

18

소프트웨어 품질 척도

정량적인 평가GQM Paradigm[Basili]

- Goal Identification : Evaluate effectiveness of coding standard

- Questions : Who is using standard? What is coder productivity? What is code quality?- Metrics : code size, effort, errors, …..

품질 특성의 측정 indirect metricproduct measurementprediction

19

복잡도 측정

McCabe

리전의 수 : 프로그램의 선택경로와 루프가 많아질수록 증가복잡도를 반영하는 척도

원시코드에 포함된 오류의 수 ∝ 사이클로매틱수 모듈의 크기를 정하는 척도로 사용할 수도 있음

a

b

e

c d

f

R1R2

R3 R4

R5

V(G) = 5

20

Halstead 의 Software Science

원시코드에 표현된 사실로부터 계산되는 여러가지 척도 제안

n1 - 프로그램에서 사용된 연산자 (operator) 의 종류

n2 - 프로그램에서 사용된 피연산자 (operand) 의 종류

N1 - 프로그램에서 사용된 총 연산자의 수

N2 - 프로그램에서 사용된 총 피연산자의 수

프로그램의 길이 N N = n1 log2 n1 + n2 llog2n2

프로그램의 부피

V = N log2 ( n1 + n2 )

21

Halstead 척도의 예

< 예 > SUBROUTINE SORT(X,N) DIMENSION X(N) IF (N.LT.2) RETURN DO 20 I = 2,N

DO 10 J = 1,J IF (X(I) .GE. X(J)) GO TO 10 SAVE = X(I) X(I) = X(J) X(J) = SAVE10 CONTINUE20 CONTINUE

RETURN END

22

Halstead 척도의 예

연산자 개수 피연산자 개수1 End of statement 7 1 X 62 Array subscript 6 2 I 53 = 5 3 J 44 IF ( ) 2 4 N 25 DO 2 5 2 26 , 2 6 SAVE 27 End of program 1 n2=7 1 18 .LT. 1 22 = N2 9 .GE. 1

n1=10 GO TO 10 1 28 = N1

23

Halstead 척도의 예

최소 부피

프로그래밍에 대한 노력

프로그래밍 노력을 객관적인 수치로 나타냄프로그램의 유사성을 검출하는데 이용

연산자의 종류 , 연산자의 총 수 , 프로그램의 크기 , 선언된 변수의 수 , 제어구조의 총수

2

2

1*2Nn

nL

2

2122121

*2))(log*))(*(

nnnNNNnE

24

10.4 유지 보수 방법 및 도구

소프트웨어의 이해원시 코드

프로그램 주석 변수 구조와 프로시듀어 모듈의 문서 입출력 양식

외부문서 사용자 지침서 기술문서 ( 분석 , 설계 , 시험 등 ) 운용 및 과거 유지보수 관련 문서참고 자료

25

유지 보수 방법

소프트웨어의 수정 1) 유지보수 요구분석

수정의 목적을 구체적으로 사용자와 함께 도출 새 기능의 추가 : 기능 분석 기존 기능과 어떻게 연결시킬 것인지 분석

2) 유지보수 설계 수정될 모듈을 식별 추가되는 모듈을 어디에 어떤 인터페이스로 연결할 것인지 설계 수정이 초래할 영향을 파악

3) 유지보수 프로그래밍 조금씩 점증적으로 변경 변경 내용을 반드시 문서로 기록 유지보수 용이성이 저하되지 않도록 수정

4) 유지보수 시험 수정된 모듈을 unit test 영향을 미치는 모듈은 다시 시험

26

유지 보수 도구

원시코드 이해를 위한 도구앞뒤 참조표 (cross-reference table)호출 그래프 (call graph) 자료 흐름도 (data flow graph) 시스템 구조도 (system chart) 디버깅 보조기 (trap, dump, trace, assertion checking) 동적 분석기

테스트를 위한 도구 comparator regression tester

27

유지 보수 도구

버전관리를 위한 도구 SCCS in UNIX

형상관리를 위한 도구

#1: sys: mod1.o mod2.o #2: ld mod1.o mod2.o -o sys #3: mod1.o: mod1.c incl.h #4: cc -c mod1.c #5: mod2.o: mod2.c incl.h #6: cc -c mod2.c

1.1 1.2 1.3 1.4 2.1 2.2

1.1 1.2 1.3 2.1

1.2.1 1.2.2

28