9.1 소 개 9.2 유지보수의 특성 9.3 소프트웨어 형상 관리 9.4 소프트웨어 척도 9.5 유지보수 방법 및 도구 9.1 소 개 9.2 유지보수의 특성 9.3 소프트웨어 형상 관리 9.4 소프트웨어 척도 9.5 유지보수 방법 및 도구

9.1 유지 보수 소프트웨어가 인수 설치된 후 일어나는 모든 작업 소프트웨어가 유용하게 활용되는 기간 소프트웨어 유형에 따라 비용이 많이 들 수 있다 <예> 분 류 주문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

유지 보수가 어려운 이유 소프트웨어의 특성 old code 관리의 부재 invisibility complexity changeability old code 관리의 부재

유지 보수의 종류 정정(corrective maintenance) 개작(adaptive maintenance) 발견된 오류의 원인을 찾아 문제해결. A/S의 개념 개작(adaptive maintenance) 새로운 자료나 운영체제, 하드웨어 환경으로 이식 기능 개선(perfective maintenance) 새로운 기능의 추가 예방(preventive maintenance) 유지보수성, 신뢰성 향상 구조 변경

9.2 유지 보수 작업의 특성 유지보수 작업 유지 보수 작업 과정 유지 보수 비용 유지 보수의 문제점 방대한 분량과의 싸움 변경에 대한 관리 유지 보수 작업 과정 유지 보수 비용 유지 보수의 문제점

유지 보수 작업 과정 1) 소프트웨어의 이해 2) 변경 요구분석 3) 변경 및 효과 예측 문서, 코드 reading 프로그램의 구조 파악 domain knowledge 습득 변수와의 관계, 서브루틴 사이의 관계 파악 코드 안에 숨겨진 의미(semantic) 파악 분석도구(call graph, cross-reference table 등), 디버깅 도구(tracer) 사용 2) 변경 요구분석 변경이 불가피한 이유와 요구를 이해 기능 향상의 경우는 새로운 기능의 분석 3) 변경 및 효과 예측 code change change effect 분석

유지 보수 작업 과정 4) 리그레션 테스트(regression test) 유지보수비용곡선 개발비용곡선 분석 설계 구현 테스트 변경 부분과 그에 의하여 영향이 있는 부분만 테스트 각 작업이 포괄적이며 단발로 시행 ---> 다양한 기술이 필요 유지보수비용곡선 개발비용곡선 분석 설계 구현 테스트

유지 보수 비용 개발 30 % 유지보수 70 % 50% 기능개선 25% 개작 21% 정정 4 % 예방 유지보수 단계의 생산성 개발 30 % 유지보수 70 % 50% 기능개선 25% 개작 21% 정정 4 % 예방 유지보수 단계의 생산성 개발단계의 생산성의 1/40

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

유지 보수의 문제점 소프트웨어에 대한 변경이 수시로 일어나며 이를 문서에 반영하지 않는 경우 이를 추적하는 것은 거의 불가능하다. 다른 사람이 작성한 프로그램을 이해하는 일은 쉽지않다. 문서화되어 있지 않거나 주석도 달지 않았다면 문제는 매우 심각하다. 소프트웨어가 변경을 가정하여 설계되는 경우가 드물다. 관리적인 측면에서 유지보수를 담당하는 프로그래머에게 동기부여를 하지 못한다. 유지보수를 위한 적극적인 도구를 사용하지 못한다. 프로그램 이해를 위하여 테스트나 디버깅 도구를 사용하는데 그친다.

9.3 소프트웨어 형상관리 변경에 대한 철저한 관리가 필요 형상 관리(Configuration Management) ---> 소프트웨어 형상 관리 형상 관리(Configuration Management) 소프트웨어를 이루는 부품의 baseline(변경 통제 시점)을 정하고 변경을 철저히 통제하는 것 형상 관리 항목 분석서 설계서 프로그램(원시코드, 목적코드, 명령어 화일, 자료 화일, 테스트 화일) 사용자 지침서

관리적 측면 형상 관리를 위한 조직 분석가: 사용자와 상의하여 무엇이 문제이며 어떤 기능향상 및 개작이 필요한가를 정한다. 분석가: 사용자와 상의하여 무엇이 문제이며 어떤 기능향상 및 개작이 필요한가를 정한다. 프로그래머: 분석가와 협동하여 문제의 원인을 찾아내고 변경의 형태와 내용을 알아낸다. 실제 프로그램의 수정을 담당한다. 프로그램 사서: 문서와 코드에 대한 변경을 계속 보관하고 관리한다.

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

형상관리 변경 절차 ② 분석가에 의하여 review 문제가 아닌 것 교육을 통하여 해결할 수 있는 것 그 외의 것은 형상관리 위원회 소집 ③ 제안된 변경을 검토하여 수정 작업의 범위와 필요한 시간을 추정하고 이에 필요한 인원과 비용을 예측 제기된 변경을 이행할 것인지 결정 가결된 변경 요청에 대하여 우선순위를 정하고 제약 사항을 고려한 후 변경을 담당할 형상 관리 팀에게 넘겨짐 ④ 시험 시스템을 수정하여 변경 효과를 점검 ⑤ 변경 위원회의 설치 승인을 받은 후 새 버전을 설치 ⑥ 관계되는 문서를 수정하고 변경 보고서 작성

형상관리 기술적 측면 어떤 방법으로 시스템에 관련된 모든 변경을 추적하여 시스템의 현재 상태를 항상 알 수 있게 할 것인가? 개발 단계에도 적용 가능 형상 관리 항목을 정하고 모든 변경은 공식적인 합의에 의하여 실시 가동 중인 소프트웨어의 변경은 신중을 기해야 함 조금씩 점증적으로 변경하고 검증 부분적으로 변경된 대규모 시스템 object의 구성이 문제 버전 관리 시스템

예: 형상관리 기술적 측면 시스템 구축 UNIX makefile 논리적 시스템 구조 물리적 구조로의 전환 화일 1 화일 2 화일 2’ 화일 2”

9.4 소프트웨어 척도 Preventive maintenance --> 여러 가지 소프트웨어의 품질 측정 기술이 필요 유지보수성(maintainability) 신뢰성(reliability) 전환성(portability) De Marco, We cannot control what we can not measure. 척도(metric) product metric(프로그램의 크기, 복잡도, 자료의 크기, 기능성, 신뢰성, 전환성, 일관성, 유지보수성) 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 : code size, effort, errors, ….. 품질 특성의 측정 indirect metric product measurement prediction

복잡도 측정 McCabe 리전의 수: 프로그램의 선택경로와 루프가 많아질수록 증가 복잡도를 반영하는 척도 원시코드에 포함된 오류의 수 ∝ 사이클로매틱수 모듈의 크기를 정하는 척도로 사용할 수도 있음 a R1 R5 R2 b c d R3 R4 e V(G) = 5 f

Halstead의 Software Science 원시코드에 표현된 사실로부터 계산되는 여러가지 척도 제안 n1 - 프로그램에서 사용된 연산자(operator)의 종류 n2 - 프로그램에서 사용된 피연산자(operand)의 종류 N1 - 프로그램에서 사용된 총 연산자의 수 N2 - 프로그램에서 사용된 총 피연산자의 수 프로그램의 길이 N N = n1 log2 n1 + n2 llog2n2 프로그램의 부피 V = N log2 ( n1 + n2 )

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

Halstead 척도의 예 연산자 개수 피연산자 개수 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

Halstead 척도의 예 최소 부피 프로그래밍에 대한 노력 프로그래밍 노력을 객관적인 수치로 나타냄 프로그램의 유사성을 검출하는데 이용 연산자의 종류, 연산자의 총 수, 프로그램의 크기, 선언된 변수의 수, 제어구조의 총수

9.5 유지 보수 방법 소프트웨어의 이해 원시 코드 외부문서 프로그램 주석 변수 구조와 프로시듀어 모듈의 문서 입출력 양식 사용자 지침서 기술문서(분석, 설계, 시험 등) 운용 및 과거 유지보수 관련 문서 참고 자료

유지 보수 방법 소프트웨어의 수정 1) 유지보수 요구분석 수정의 목적을 구체적으로 사용자와 함께 도출 새 기능의 추가: 기능 분석 기존 기능과 어떻게 연결시킬 것인지 분석 2) 유지보수 설계 수정될 모듈을 식별 추가되는 모듈을 어디에 어떤 인터페이스로 연결할 것인지 설계 수정이 초래할 영향을 파악 3) 유지보수 프로그래밍 조금씩 점증적으로 변경 변경 내용을 반드시 문서로 기록 유지보수 용이성이 저하되지 않도록 수정 4) 유지보수 시험 수정된 모듈을 unit test 영향을 미치는 모듈은 다시 시험

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

유지 보수 도구 버전관리를 위한 도구 형상관리를 위한 도구 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