15 maintenance(2010).ppt [호환 모드]€¦ · lecture15 유지보수...

LECTURE

1515유지보수유지보수유지보수유지보수

유지보수 작업에 충분한 일정을 주지 않는다유지보수 작업에 충분한 일정을 주지 않는다.

많은 버그가 테스트를 통과한다.

오래된 코드는 유지보수하기 어렵다.

최은만, CSE 4039 소프트웨어 공학

프로젝트

Death March Project or Doing Well Poject?

최은만, CSE 4039 소프트웨어 공학 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수 배달 및 설치 0 0 3,982 4,146

중앙유지보수작업 70 365 87 383

현장 서비스 0 0 2,233 2,775

비용(100만원) 140 730 12 604 14 608비용(100만원) 140 730 12,604 14,608

비율 1:0.1 1:0.5 1:10.8 1:9.4


소프트웨어의소프트웨어의 유지유지 보수가보수가 어려운어려운 이유이유

1. 소프트웨어의 특성1. 소프트웨어의 특성

비가시성(invisibility)

복잡성(complexity)복잡성(complexity)

변경용이성(changeability)

2 old code2. old code

3. 관리의 부재


유지유지 보수의보수의 종류종류

정정(corrective maintenance)정정(co ect ve a te a ce)

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

개작(adaptive maintenance)개작(adaptive maintenance)

새로운 자료나 운영체제, 하드웨어 환경으로 이식

기능 개선(perfective maintenance)기능 개선(perfective maintenance)

새로운 기능의 추가

예방(preventive maintenance)예방(preventive maintenance)

유지보수성, 신뢰성 향상

구조 변경구 변경


유지유지 보수보수 작업의작업의 특성특성

유지보수 작업

방대한 분량과의 싸움

변경에 대한 관리

유지 보수 작업 과정

유지 보수 비용

유지 보수의 문제점


유지유지 보수보수 작업작업 과정과정

1) 소프트웨어의 이해문서, 코드 reading

프로그램의 구조 파악

domain knowledge 습득g 득

변수와의 관계, 서브루틴 사이의 관계 파악

코드 안에 숨겨진 의미(semantic) 파악

분석도구(call graph cross-reference table 등) 디버깅 도구분석도구(call graph, cross reference table 등), 디버깅 도구(tracer) 사용

2) 변경 요구분석변경이 불가피한 이유와 요구를 이해변경이 불가피한 이유와 요구를 이해

기능 향상의 경우는 새로운 기능의 분석

3) 변경 및 효과 예측d hcode change

change effect 분석


유지유지 보수보수 작업작업 과정과정

4) 리그레션 테스트(regression test)변경 부분과 그에 의하여 영향이 있는 부분만 테스트

각 작업이 포괄적이며 단발로 시행---> 다양한 기술이 필요> 다양한 기술이 필요

유지보수비용곡선유지보수비용곡선

개발비용곡선


분석 설계 구현 테스트8

유지유지 보수보수 비용비용

개발 30 %

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

25% 개작

21% 정정

4 % 예방

유지보수 단계의 생산성

개발단계의 생산성의 1/40


유지보수유지보수 비용비용 예측예측

1) Belady와 Lehman

M = p + Ke^(c-d)

M : 유지보수를 위한 노력,

P : 분석 평가 설계변경 코딩 등 실제 생산성 있는 노력P : 분석, 평가, 설계변경, 코딩 등 실제 생산성 있는 노력,

K : 통계에 의한 상수

c : 설계의 비구조성이나 문서의 미흡함을 나타내는 복잡도

d : 소프트웨어와의 친숙성d : 소프트웨어와의 친숙성

2) COCOMO 방법M = ACT X DE X EAT

M 유지보수를 위한 노력M : 유지보수를 위한 노력

ACT : 개발조직이 수행하는 전체 프로젝트 규모에서 유지보수

작업이 차지하는 연평균 비율(annual change traffic)

DE : 개발할 때 필요했던 노력

EAT : COCOMO의 유지보수 작업을 위한 노력 조정수치


유지유지 보수의보수의 문제점문제점

소프트웨어에 대한 변경이 수시로 일어나며 이를 문서에 반영하지웨어에 대한 변경이 수시 일어나며 이를 문서에 반영하지

않는 경우 이를 추적하는 것은 거의 불가능하다.

다른 사람이 작성한 프로그램을 이해하는 일은 쉽지않다. 문서화되다른 사람이 작성한 램을 이해하는 일은 쉽지않다 문서화되

어 있지 않거나 주석도 달지 않았다면 문제는 매우 심각하다.

소프트웨어가 변경을 가정하여 설계되는 경우가 드물다. 웨어가 변경 가정하여 설계되 경우가 물다

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

를 하지 못한다. 하지 못 다

유지보수를 위한 적극적인 도구를 사용하지 못한다.

프로그램 이해를 위하여 테스트나 디버깅 도구를 사용하는데 그친프로그램 이해를 위하여 테스트나 디버깅 도구를 사용하는데 그친

다.


소프트웨어소프트웨어 형상관리형상관리

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

---> 소프트웨어 형상 관리

형상 관리(Configuration Management)g g

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

경을 철저히 통제하는 것

형상 관리 항목형상 관리 항목

분석서

설계서설계서

프로그램(원시코드, 목적코드, 명령어 화일, 자료 화일, 테스트 화일)

사용자 지침서


관리적관리적 측면측면

형상 관리를 위한 조직형상 관리를 위한 직

분석가: 사용자와 상의하여 무엇이 문제이며 어떤 기능향상 및 개작

이 필요한가를 정한다.

프로그래머: 분석가와 협동하여 문제의 원인을 찾아내고 변경의 형

태와 내용을 알아낸다. 실제 프로그램의 수정을 담당한다.

프로그램 사서: 문서와 코드에 대한 변경을 계속 보관하고 관리한다.


형상관리형상관리 변경변경 절차절차

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

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

1. 즉시 □ 2. 수일내 □ 3. 다음 버젼 □ 4. 기간없음 □


형상관리형상관리 변경변경 절차절차

② 분석가에 의하여 review② 분석가에 의하여 ev ew

문제가 아닌 것

교육을 통하여 해결할 수 있는 것

그 외의 것은 형상관리 위원회 소집

③ 제안된 변경을 검토하여 수정 작업의 범위와 필요한 시간을 추정하③

고 이에 필요한 인원과 비용을 예측 제기된 변경을 이행할 것인지

결정 가결된 변경 요청에 대하여 우선순위를 정하고 제약 사항을 고

려한 후 변경을 담당할 형상 관리 팀에게 넘겨짐

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

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

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


형상관리형상관리 기술적기술적 측면측면

어떤 방법으로 시스템에 관련된 모든 변경을 추적하여 시스템의 현어떤 방법 시 템에 관련된 든 변경을 추적하여 시 템의 현

재 상태를 항상 알 수 있게 할 것인가?

개발 단계에도 적용 가능개발 단계에 적용 가능

형상 관리 항목을 정하고 모든 변경은 공식적인 합의에 의하여 실시

가동 중인 소프트웨어의 변경은 신중을 기해야 함가동 중인 소프트웨어의 변경은 신중을 기해야 함

조금씩 점증적으로 변경하고 검증

부분적으로 변경된 대규모 시스템부분적으로 변경된 대규모 시스템

object의 구성이 문제

버전 관리 시스템버전 관리 시스템


소프트웨어소프트웨어 척도척도

Preventive maintenance eve t ve a te a ce

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

품질품질

유지보수성(maintainability)

신뢰성(reliability)신뢰성(reliability)

전환성(portability)

De Marco We cannot control what we can not measureDe Marco, We cannot control what we can not measure.

척도(metric)

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

성, 전환성, 일관성, 유지보수성)

process metric(개발에 걸리는 시간, 비용, 진척 상황)


소프트웨어소프트웨어 품질품질 척도척도

정량적인 평가

GQM Paradigm[Basili]

− Goal Identification : Evaluate effectiveness of coding

standardstandard

− Questions : Who is using standard?

What is coder productivity?p y

What is code quality?

− Metrics : code size, effort, errors, …..

품질 특성의 측정

i di t t iindirect metric

product measurement

prediction


p

18

복잡도복잡도 측정측정

McCabe

a

R1 R5b c dR2

R3 R4

e

f

V(G) = 5

리전의 수: 프로그램의 선택경로와 루프가 많아질수록 증가

복잡도를 반영하는 척도

원시코드에 포함된 오류의 수 ∝ 사이클로매틱수

모듈의 크기를 정하는 척도로 사용할 수도 있음


HalsteadHalstead의의 Software ScienceSoftware Science

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

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

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

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

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

프로그램의 길이 N

N = n1 log2 n1 + n2 llog2n2

프로그램의 부피

V = N log2 ( n1 + n2 )


Halstead 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 10IF (X(I) .GE. X(J)) GO TO 10

SAVE = X(I)

X(I) = X(J)

X(J) = SAVEX(J) = SAVE

10 CONTINUE

20 CONTINUE

RETURNRETURN

END



연산자 개수 피연산자 개수

1 End of statement 7 1 X 6

2 Array subscript 6 2 I 5

3 = 5 3 J 4

4 IF ( ) 2 4 N 2

5 DO 2 5 2 2

6 , 2 6 SAVE 26 , 2 6 SAVE 2

7 End of program 1 n2=7 1 1

8 .LT. 1 22 = N2

9 GE 19 .GE. 1

n1=10 GO TO 10 1

28 = N1



최소 부피

2

2

1*2

Nn

nL =

프로그래밍에 대한 노력

2122121

*2))(log*))(*( nnNNNnE ++

=

프로그래밍 노력을 객관적인 수치로 나타냄

프로그램의 유사성을 검출하는데 이용

2*2 n

프로그램의 유사성을 검출하는데 이용

연산자의 종류, 연산자의 총 수, 프로그램의 크기,

선언된 변수의 수 제어구조의 총수선언된 변수의 수, 제어구조의 총수


유지유지 보수보수 방법방법

소프트웨어의 이해

원시 코드

프로그램 주석

변수변수

구조와 프로시듀어

모듈의 문서

입출력 양식

외부문서

사용자 지침서사용자 지침서

기술문서(분석, 설계, 시험 등)

운용 및 과거 유지보수 관련 문서

참 자참고 자료


유지유지 보수보수 방법방법

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

수정의 목적을 구체적으로 사용자와 함께 도출

새 기능의 추가: 기능 분석새 기 의 추가 기 석

기존 기능과 어떻게 연결시킬 것인지 분석

2) 유지보수 설계

수정될 모듈을 식별수정될 모듈을 식별

추가되는 모듈을 어디에 어떤 인터페이스로 연결할 것인지 설계

수정이 초래할 영향을 파악

3) 유지보수 프로그래밍3) 유지보수 프로그래밍

조금씩 점증적으로 변경

변경 내용을 반드시 문서로 기록

유지보수 용이성이 저하되지 않도록 수정유지보수 용이성이 저하되지 않도록 수정

4) 유지보수 시험

수정된 모듈을 unit test

영향을 미치는 다시 시험


영향을 미치는 모듈은 다시 시험

25

유지유지 보수보수 도구도구

원시코드 이해를 위한 도구원시 이해를 위한 구

앞뒤 참조표(cross-reference table)

호출 그래프(call graph)g p

자료 흐름도(data flow graph)

시스템 구조도(system chart)

디버깅 보조기(trap, dump, trace, assertion checking)

동적 분석기

테스트를 위한 도구

comparator

regression tester


유지유지 보수보수 도구도구

버전관리를 위한 도구

SCCS in UNIX

1 1 1 2 1 3 1 4 2 1 2 21.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

형상관리를 위한 도구#1: sys: mod1.o mod2.o

#2: ld mod1.o mod2.o -o sys

#3: d1 : d1 i l h#3: mod1.o: mod1.c incl.h

#4: cc -c mod1.c

#5: mod2.o: mod2.c incl.h

#6: cc -c mod2 c


#6: cc c mod2.c

27

15 maintenance(2010).ppt [호환 모드]€¦ · lecture15 유지보수...

Documents