소프트웨어 공학 (software engineering) 유지 보수 (maintenance) 문양세...

소프트웨어 공학 (Software Engineer-ing)

유지 보수 (Maintenance)

문양세강원대학교 IT 대학 컴퓨터과학전공

Software Engineeringby Yang-Sae Moon

많은 소프트웨어는 개발이 끝이 아니라 , 그때부터 시작이다 .

전자레인지의 경우 새로운 기능을 추가할 수 있다고 생각하지 않으나 ,소프트웨어는 주물주물하면 새로운 기능을 넣을 수 있다고 생각한다 .

자동차의 관리와 유사하게 , 소프트웨어의 유지보수도“해당 제품을 값어치 있게 사용하기 위한” 매우 중요한 요소이다 .

We will cover …• 유지 보수의 특성• 소프트웨어 형상 관리• 소프트웨어 척도• 유지 보수 방법 및 도구

유지보수 (Maintenance)In this chapter …


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

소프트웨어가 유용하게 활용되는 기간

소프트웨어가 살아있는 기간

소프트웨어 유형에 따라 비용이 많이 들 수 있다

유지 보수 ?유지보수 (Maintenance)


소프트웨어의 특성• Invisibility• Complexity• Changeability

Old code( 예전 소프트웨어는 기능 , 작동에만 관심이 있었을 뿐 , 설계 , 문서화 , 테스트 등이 체계적으로 이루어지지 않았음 )

관리 부재• 소프트웨어 유지 보수에 대한 개념 부족

( 예 : 국내에선 무상 유지 보수 기간의 비용 무시 , 선진국의 경우 매우 중시 )• 인력 교체에 따른 불가피한 관리 부재

유지보수 (Maintenance)소프트웨어 유지 보수가 어려운 이유


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

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

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

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

유지보수 (Maintenance)유지보수의 종류


유지보수 (Maintenance)유지보수에 드는 노력 분포

통합 테스트 단위 테스트

구현설계명세서요구분석

유지 보수

소프트웨어 생명 주기 전체에서 차지하는 유지보수 노력(Life Cycle 에서의 기간을 이야기하며 , 비용을 이야기하는 것은 아님 )

유지 보수 유형 분포

개작기타정정

기능 보강


We are now …

유지보수의 특성

소프트웨어 형상 관리

소프트웨어 척도

유지보수 방법 및 도구

유지보수 (Maintenance)


소프트웨어의 이해• 문서 , 코드 reading• 프로그램의 구조 파악• Domain knowledge 습득

( 응용 분야에 대한 지식 필요 , 예를 들어 세무 소프트웨어… )• 변수와의 관계 , 서브루틴 사이의 관계 파악• 코드 안에 숨겨진 의미 (semantic) 파악• 분석도구 (call graph, cross-reference table 등 ), 디버깅 도구 (tracer) 사용

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

변경 및 효과 예측• Code change• Change effect 분석 ( 특히 , side effect 에 유의하여야 함 )

유지보수 (Maintenance)유지 보수 작업 과정 (1/2)


리그레션 테스트 (regression test)• 변경 이후에도 여전히 같은 기능을 수행하는지 확인하는 테스트• 변경이 적은 경우 , 변경 부분과 그에 의하여 영향이 있는 부분만 테스트• 변경이 많은 경우 , 예상치 못한 부분을 생각하여 전체를 테스트 결과적으로 , 예전 테스트 케이스 ( 항목 , 절차 , 결과 ) 를 잘 관리해야 함

유지보수 비용 곡선• 개발 주기에는 , 비용이 분석 , 설계 등으로 서서히 증가하다 구현에서 최고점에 이름• 유지보수 주기에는 , 분석 , 이해 등의 초기 단계에 가장 많은 비용이 듦

유지보수 (Maintenance)유지 보수 작업 과정 (2/2)

분석 설계 구현 테스트

유지보수 주기개발 주기


개발 30%

유지보수 70%

유지보수 단계의 생산성• 개발 단계 생산성의 1/40 에 불과• 개발 시 , 한 줄에 2,500 원 유지 보수 시 10 만원• 왜 ?

문제 이해 , 수정 , 테스트 등이 특정 부분에 집중적으로 발생하며 ,오류의 발생은 시점을 예측할 수도 없고 , 따라서 계획할 수도 없다 .

유지보수 (Maintenance)유지 보수 비용

50% 기능 개선25% 개작21% 정정4% 예방


Belady & Lehman

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

COCOMO 방법

• M: 유지보수를 위한 노력• ACT: 개발조직이 수행하는 전체 프로젝트 규모에서 유지보수 작업이 차지하는

연평균 비율 (annual change traffic)• DE: 개발할 때 필요했던 노력• EAT: COCOMO 의 유지보수 작업을 위한 노력 조정수치

유지보수 (Maintenance)유지 보수 비용 예측 - 생략

( )c dM p Ke

M ACT DE EAT


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

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

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

관리적인 측면에서 유지보수를 담당하는 프로그래머에게 동기부여를 하지 못한다 . ( 유지보수 담당자는 사이드에 있다는 사회적 통념 )

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

유지보수 (Maintenance)유지 보수의 문제점


We are now …







변경에 대한 철저한 관리가 필요 소프트웨어 형상 관리

형상 관리 (Configuration Management)• 소프트웨어를 이루는 부품의 Baseline( 변경 통제 시점 ) 을 정하고 변경을 철저히

통제함

형상 관리 항목• 분석서• 설계서• 프로그램 ( 원시코드 , 목적코드 , 명령어 파일 , 자료 파일 , 테스트 파일 )• 사용자 지침서

유지보수 (Maintenance)소프트웨어 형상 관리


형상 관리를 위한 조직

분석가 : 사용자와 상의하여 무엇이 문제이며 어떤 기능 향상 및 개작이 필요한가를 정한다 . 주로 정책 결정을 내릴 수 있는 고급 엔지니어 / 관리자가 수행

프로그래머 : 분석가와 협동하여 문제의 원인을 찾아내고 변경의 형태와 내용을 알아낸다 . 실제 프로그램의 수정을 담당한다 . 소프트웨어 프로그래머가 수행

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

유지보수 (Maintenance)관리적 측면의 형상 관리


변경 요청서 (CR: Change Request) 작성 : 사용자 또는 프로그래머가 작성

유지보수 (Maintenance)형상 관리에 따른 소프트웨어 변경 절차 (1/2)

변 경 요 청 서

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


분석가에 의하여 리뷰 (review)• 문제가 아닌 것 (바른 결과인데… 이를 오류로 인식하는 경우… )• 교육을 통하여 해결할 수 있는 것 ( 사용법을 잘 모르는 경우… )• 그 외의 것은 형상관리 위원회 소집

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

형상 관리 팀에게 넘겨짐

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

변경 위원회의 설치 승인을 받은 후 새 버전을 설치 잘 동작하지 않으면 원복 ( 원상복구 )

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

유지보수 (Maintenance)형상 관리에 따른 소프트웨어 변경 절차 (2/2)


어떤 방법으로 시스템에 관련된 모든 변경을 추적하여 시스템의 현재 상태를 항상 알 수 있게 할 것인가 ? 소프트웨어도 복잡 , 조직도 복잡 ,… 시간이 지나면 왜 그렇게 고쳤는지도 알 수 없는 경우가 많음

개발 단계에도 적용 가능 체계적인 버전 관리

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

가동 중인 소프트웨어의 변경은 신중을 기해야 함• 조금씩 점증적으로 변경하고 반드시 검증• 변경 후 오류 발생 시 , 원상복구를 위하여 항시 대비책을 마련해야 함

유지보수 (Maintenance)형상 관리의 기술적 측면 (1/2)



시스템 구축UNIX

makefile

논리적 시스템 구조

물리적구조로의 전환

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

부분적으로 변경되는 대규모 시스템• 모듈 별로 관리하고 , 모듈 별로 변경하고 , 모듈 별로 컴파일하고 ,

모듈 별로 적용하고…• 대규모 시스템의 경우 버전 관리 시스템 사용이 필요함

SCCS(Source Code Control System), RCS, CVS, …

형상 관리의 기술적 측면 (2/2)


We are now …







소프트웨어 품질에 대한 측정 기술이 필요

( 여기에서의 ) 품질이란 ?• 유지보수성 (maintainability)• 신뢰성 (reliability)• 이동성 (portability)

De Marco said… “We cannot control what we cannot measure.”

척도 (metric)• Product metric ( 프로그램 크기 , 복잡도 , 자료 크기 , 기능성 , 신뢰성 , 일관성 , …)• Process metric ( 개발 기간 , 개발 비용 , 진척 상황 )

유지보수 (Maintenance)소프트웨어 척도의 개념


McCabe 에 의해 제안• ( 제 6 장에서 소개한 ) 프로그램 제어 (논리 ) 흐름도를 기초로 복잡도를 측정• 복잡도를 제어 흐름도의 영역 (region) 개수로 표현

영역의 수 : 프로그램의 선택경로와 루프가 많아질수록 증가복잡도를 반영하는 척도 :원시코드에 포함된 오류의 수 ∝ 사이클로매틱 개수 실험 결과임모듈의 크기를 정하는 척도로 사용할 수도 있음

유지보수 (Maintenance)복잡도 측정 – 생략

a

b

e

c d

f

R1R2

R3 R4

R5

V(G) = 5


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

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

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

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

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

Vocabulary n = n1 + n2

프로그램의 길이 N ( N1 + N2) N = n1 log2 n1 + n2 log2n2

프로그램의 부피V = N log2 ( n1 + n2 )

유지보수 (Maintenance)Halstead 의 Software Science (1/2) – 생략


유지보수 (Maintenance)Halstead 의 Software Science (2/2) – 생략

최소 부피

프로그래밍에 대한 노력

프로그래밍 노력을 객관적인 수치로 나타냄프로그램의 유사성을 검출하는데 이용 ( 숙제 copy 검사 )연산자의 종류 , 연산자의 총 수 , 프로그램의 크기 선언된 변수의 수 , 제어구조의 총수

1 2 1 2 2 1 22

( * ( )*log ( ))2*

n N N N n nEn

21 2

2 *nLn N


SUBROUTINE SORT(X,N)DIMENSION X(N)IF (N.LT.2) RETURNDO 20 I = 2,NDO 10 J = 1,JIF (X(I) .GE. X(J)) GO TO 10

SAVE = X(I)X(I) = X(J)X(J) = SAVE

10 CONTINUE20 CONTINUE

RETURNEND

유지보수 (Maintenance)Halstead 척도 예제 (1/2) – 생략

Fortran Program 소스


유지보수 (Maintenance)Halstead 척도 예제 (2/2) – 생략

Fortran Program 분석

연산자 갯수 피연산자 갯수 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 2 7 End of program 1 n2=7 1 1 8 .LT. 1 22 = N2 9 .GE. 1

n1=10 GO TO 10 1 28 = N1

프로그램 부피 = 204 ( 어셈블리로 짤 경우의 부피 = 328)


We are now …







소프트웨어의 이해 무엇인지를 알아야 고칠 수 있겠죠 ?

원시 코드 (source code) 분석• 프로그램 주석 (comment)• 변수 (variable)• 구조와 프로시저 (structure & procedure) • 모듈의 문서• 입출력 양식

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

유지보수 (Maintenance)유지보수 관련 필요사항


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

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

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

4) 유지보수 시험• 수정된 모듈을 단위 테스트 (unit test)• 영향을 미치는 모듈은 다시 시험

이전의 시험 도구 및 결과를 잘 보관하여야 함

유지보수 (Maintenance)소프트웨어의 수정


유지보수 (Maintenance)유지보수 도구 (1/2)

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

테스트를 위한 도구• comparator• regression tester ( 이전 시험과의 결과 비교… )


유지보수 (Maintenance)유지보수 도구 (2/2)

버전 관리 도구 (SCCS(Source Code Control System) in UNIX)

형상 관리 도구 (make and Makefile in UNIX)

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

#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


유지보수 (Maintenance)Makefile 예제 화면 (1/3)

Makefile 예제 : main.mk



Makefile 의 실행 ($ make [-f makefile])



복잡한 형태의 Makefile 예제


Homework #5Homework

소프트웨어 공학 (software engineering) 유지 보수 (maintenance) 문양세...

Documents