Transcript 10_Maintenance-KNU

소프트웨어 공학
Lecture #10: 유지 보수
안병익
[email protected]
강의 블로그 Mobilecom.tistory.com
학습 목표

유지보수의 특성

소프트웨어 형상 관리

소프트웨어 척도

유지보수 방법 및 도구
2
유지 보수



소프트웨어가 인수 설치된 후 일어나는 모든 작업
소프트웨어가 유용하게 활용되는 기간
소프트웨어 유형에 따라 비용이 많이 들 수 있다
<예>
분 류
개발 man-month
비용(100만원)
유지 man-month
보수
배달 및 설치
중앙유지보수작업
현장 서비스
비용(100만원)
비율
3
주문1
580
1,160
주문2
725
1,450
0
70
0
140
1:0.1
패키지1 패키지2
580
725
1,160
1,450
0 3,982
4,146
365
87
383
0 2,233
2,775
730 12,604 14,608
1:0.5 1:10.8
1:9.4
유지 보수가 어려운 이유

소프트웨어의 특성



invisibility
complexity
changeability

old code

관리의 부재
4
유지 보수의 종류

정정(corrective maintenance)


개작(adaptive maintenance)


새로운 기능의 추가
예방(preventive maintenance)


5
새로운 자료나 운영체제, 하드웨어 환경으로 이식
기능 개선(perfective maintenance)


발견된 오류의 원인을 찾아 문제해결. A/S의 개념
유지보수성, 신뢰성 향상
구조 변경
10.1 유지 보수 작업의 특성

유지보수 작업


방대한 분량과의 싸움
변경에 대한 관리

유지 보수 작업 과정

유지 보수 비용

유지 보수의 문제점
6
유지 보수 작업 과정
1) 소프트웨어의 이해






문서, 코드 reading
프로그램의 구조 파악
domain knowledge 습득
변수와의 관계, 서브루틴 사이의 관계 파악
코드 안에 숨겨진 의미(semantic) 파악
분석도구(call graph, cross-reference table 등), 디버깅 도구(tracer)
사용
2) 변경 요구분석


변경이 불가피한 이유와 요구를 이해
기능 향상의 경우는 새로운 기능의 분석
3) 변경 및 효과 예측


7
code change
change effect 분석
유지 보수 작업 과정
4) 리그레션 테스트(regression test)


8
변경 부분과 그에 의하여 영향이 있는 부분만 테스트
각 작업이 포괄적이며 단발로 시행
---> 다양한 기술이 필요
유지 보수 비용

개발
유지보수

유지보수 단계의 생산성


9
30 %
70 %
개발단계의 생산성의 1/40
50% 기능개선
25% 개작
21% 정정
4 % 예방
유지보수 비용 예측
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)


12
소프트웨어를 이루는 부품의 baseline(변경 통제 시점)을 정하고 변경을
철저히 통제하는 것
형상 관리 항목

분석서

설계서

프로그램(원시코드, 목적코드, 명령어 화일, 자료 화일, 테스트 화일)

사용자 지침서
관리적 측면

형상 관리를 위한 조직

분석가: 사용자와 상의하여 무엇이 문제이며 어떤 기능향상 및 개작이
필요한가를 정한다.

프로그래머: 분석가와 협동하여 문제의 원인을 찾아내고 변경의 형태와
내용을 알아낸다. 실제 프로그램의 수정을 담당한다.

13
프로그램 사서: 문서와 코드에 대한 변경을 계속 보관하고 관리한다.
형상관리 변경 절차
① 변경 요청서 작성

14
사용자 또는 프로그래머
변 경 요 청 서
요구자:___________ 날짜:_________ 소프트웨어_________________
변경내용:
_________________________________________________________
_________________________________________________________
_________________________________________________________
유지보수 형태:
변경에 의해 영향받는 범위:
1. 정정
□ ___________________________________________
2. 개작
□ ___________________________________________
3. 개선
□ ___________________________________________
문제의 심각정도:
변경요청 이유
1. 피할 수 있음 □ _________________________________________
2. 가벼움
□ __________________________________________
3. 가동중지 □ __________________________________________
완료기일:____________(날짜기입) 또는
1. 즉시 □
2. 수일내 □
3. 다음 버젼 □
4. 기간없음 □
형상관리 변경 절차
② 분석가에 의하여 review

문제가 아닌 것

교육을 통하여 해결할 수 있는 것

그 외의 것은 형상관리 위원회 소집
③ 제안된 변경을 검토하여 수정 작업의 범위와 필요한 시간을 추정하
고 이에 필요한 인원과 비용을 예측 제기된 변경을 이행할 것인지 결
정 가결된 변경 요청에 대하여 우선순위를 정하고 제약 사항을 고려
한 후 변경을 담당할 형상 관리 팀에게 넘겨짐
④ 시험 시스템을 수정하여 변경 효과를 점검
⑤ 변경 위원회의 설치 승인을 받은 후 새 버전을 설치
⑥ 관계되는 문서를 수정하고 변경 보고서 작성
15
형상관리 기술적 측면




어떤 방법으로 시스템에 관련된 모든 변경을 추적하여 시스템의 현재
상태를 항상 알 수 있게 할 것인가?
개발 단계에도 적용 가능
형상 관리 항목을 정하고 모든 변경은 공식적인 합의에 의하여 실시
가동 중인 소프트웨어의 변경은 신중을 기해야 함


부분적으로 변경된 대규모 시스템


16
조금씩 점증적으로 변경하고 검증
object의 구성이 문제
버전 관리 시스템
예: 형상관리 기술적 측면
UNIX
makefile
시스템 구축
논리적 시스템 구조
물리적
구조로의 전환
화일 1
17
화일 2
화일 2’
화일 2”
10.3 소프트웨어 척도

Preventive maintenance
--> 여러 가지 소프트웨어의 품질 측정 기술이 필요

품질

유지보수성(maintainability)

신뢰성(reliability)

전환성(portability)

De Marco,

척도(metric)

We cannot control what we can not measure.
product metric(프로그램의 크기, 복잡도, 자료의 크기, 기능성, 신뢰성,
전환성, 일관성, 유지보수성)

18
process metric(개발에 걸리는 시간, 비용, 진척 상황)
소프트웨어 품질 척도
 정량적인 평가

GQM Paradigm[Basili]

Goal Identification : Evaluate effectiveness of coding standard

Questions
: Who is using standard?
What is coder productivity?
What is code quality?

Metrics
 품질 특성의 측정
19

indirect metric

product measurement

prediction
: code size, effort, errors, …..
복잡도 측정

McCabe
a
R1
R2
c
b
R3
R5
d
R4
e
V(G) = 5
f

리전의 수: 프로그램의 선택경로와 루프가 많아질수록 증가

복잡도를 반영하는 척도


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) = SAVE
10 CONTINUE
20 CONTINUE
RETURN
END
22
Halstead 척도의 예
연산자
1 End of statement
2 Array subscript
3=
4 IF ( )
5 DO
6,
7 End of program
8 .LT.
9 .GE.
n1=10 GO TO 10
23
개수
7
6
5
2
2
2
1
1
1
1
28 = N1
피연산자
1
X
2
I
3
J
4
N
5
2
6
SAVE
n2=7
1
개수
6
5
4
2
2
2
1
22 = N2
Halstead 척도의 예

최소 부피
L
2
n1

*
n2
N2
프로그래밍에 대한 노력
E
( n1 * N 2 ( N1  N 2 )) * log 2 ( n1  n2 ))
2 * n2

프로그래밍 노력을 객관적인 수치로 나타냄

프로그램의 유사성을 검출하는데 이용


24
연산자의 종류, 연산자의 총 수, 프로그램의 크기,
선언된 변수의 수, 제어구조의 총수
10.4 유지 보수 방법 및 도구


소프트웨어의 이해
원시 코드






외부문서




25
프로그램 주석
변수
구조와 프로시듀어
모듈의 문서
입출력 양식
사용자 지침서
기술문서(분석, 설계, 시험 등)
운용 및 과거 유지보수 관련 문서
참고 자료
유지 보수 방법
 소프트웨어의 수정
1) 유지보수 요구분석
 수정의 목적을 구체적으로 사용자와 함께 도출
 새 기능의 추가: 기능 분석
 기존 기능과 어떻게 연결시킬 것인지 분석
2) 유지보수 설계
 수정될 모듈을 식별
 추가되는 모듈을 어디에 어떤 인터페이스로 연결할 것인지 설계
 수정이 초래할 영향을 파악
3) 유지보수 프로그래밍
 조금씩 점증적으로 변경
 변경 내용을 반드시 문서로 기록
 유지보수 용이성이 저하되지 않도록 수정
4) 유지보수 시험
 수정된 모듈을 unit test
 영향을 미치는 모듈은 다시 시험
26
유지 보수 도구


27
원시코드 이해를 위한 도구

앞뒤 참조표(cross-reference table)

호출 그래프(call graph)

자료 흐름도(data flow graph)

시스템 구조도(system chart)

디버깅 보조기(trap, dump, trace, assertion checking)

동적 분석기
테스트를 위한 도구

comparator

regression tester
유지 보수 도구

버전관리를 위한 도구

SCCS in UNIX
1.1
1.2
1.1
1.3
1.2
1.3
1.2.1
1.2.2
 형상관리를 위한 도구
 #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
28
1.4
2.1
2.1
2.2