유지 보수 (Software Maintenance)

1. 유지 보수 (Software Maintenance) - Software Engineering -

2. 강의 개요 • 소 개 • 유지보수의 특성 • 소프트웨어 형상 관리 • 소프트웨어 척도 • 유지보수 방법 및 도구

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

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

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

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

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

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

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

10. 유지보수 비용 예측 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의 유지보수 작업을 위한 노력 조정수치

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

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

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

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

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

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

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

18. 소프트웨어 척도 • Preventive maintenance --> 여러 가지 소프트웨어의 품질 측정 기술이 필요 • 품질 • 유지보수성(maintainability) • 신뢰성(reliability) • 전환성(portability) • De Marco, We cannot control what we can not measure. • 척도(metric) • product metric(프로그램의 크기, 복잡도, 자료의 크기, 기능성, 신뢰성, 전환성, 일관성, 유지보수성) • process metric(개발에 걸리는 시간, 비용, 진척 상황)

19. 소프트웨어 품질 척도 • 정량적인 평가 • 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

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

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

22. 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

23. 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

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

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

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

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

28. 유지 보수 도구 • 버전관리를 위한 도구 • SCCS in UNIX 1.2 1.3 1.4 1.1 2.2 2.1 1.2 1.3 2.1 1.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