slide1
Download
Skip this Video
Download Presentation
유지 보수 (Software Maintenance)

Loading in 2 Seconds...

play fullscreen
1 / 28

유지 보수 (Software Maintenance) - PowerPoint PPT Presentation


  • 255 Views
  • Uploaded on

유지 보수 (Software Maintenance). - Software Engineering -. 강의 개요. 소 개 유지보수의 특성 소프트웨어 형상 관리 소프트웨어 척도 유지보수 방법 및 도구. 유지 보수. 소프트웨어가 인수 설치된 후 일어나는 모든 작업 소프트웨어가 유용하게 활용되는 기간 소프트웨어 유형에 따라 비용이 많이 들 수 있다 < 예 > 분 류 주문 1 주문 2 패키지 1 패키지 2

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' 유지 보수 (Software Maintenance)' - jin-booker


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

유지 보수

(Software Maintenance)

- Software Engineering -

slide2

강의 개요

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

유지 보수

  • 소프트웨어가 인수 설치된 후 일어나는 모든 작업
  • 소프트웨어가 유용하게 활용되는 기간
  • 소프트웨어 유형에 따라 비용이 많이 들 수 있다

<예>

분 류 주문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

slide4

유지 보수가 어려운 이유

  • 소프트웨어의 특성
    • invisibility
    • complexity
    • changeability
  • old code
  • 관리의 부재
slide5

유지 보수의 종류

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

유지 보수 작업의 특성

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

유지 보수 작업 과정

1) 소프트웨어의 이해

  • 문서, 코드 reading
  • 프로그램의 구조 파악
  • domain knowledge 습득
  • 변수와의 관계, 서브루틴 사이의 관계 파악
  • 코드 안에 숨겨진 의미(semantic) 파악
  • 분석도구(call graph, cross-reference table 등), 디버깅 도구(tracer) 사용

2) 변경 요구분석

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

3) 변경 및 효과 예측

  • code change
  • change effect 분석
slide8

유지 보수 작업 과정

4) 리그레션 테스트(regression test)

  • 변경 부분과 그에 의하여 영향이 있는 부분만 테스트
  • 각 작업이 포괄적이며 단발로 시행

---> 다양한 기술이 필요

유지보수비용곡선

개발비용곡선

분석 설계 구현 테스트

slide9

유지 보수 비용

  • 개발 30 %
  • 유지보수 70 % 50% 기능개선

25% 개작

21% 정정

4 % 예방

  • 유지보수 단계의 생산성
    • 개발단계의 생산성의 1/40
slide10

유지보수 비용 예측

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의 유지보수 작업을 위한 노력 조정수치

slide11

유지 보수의 문제점

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

소프트웨어 형상관리

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

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

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

관리적 측면

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

형상관리 변경 절차

① 변경 요청서 작성

  • 사용자 또는 프로그래머

변 경 요 청 서

요구자:___________ 날짜:_________ 소프트웨어_________________

변경내용:

_________________________________________________________

_________________________________________________________

_________________________________________________________

유지보수 형태: 변경에 의해 영향받는 범위:

1. 정정 □ ___________________________________________

2. 개작 □ ___________________________________________

3. 개선 □ ___________________________________________

문제의 심각정도: 변경요청 이유

1. 피할 수 있음 □ _________________________________________

2. 가벼움 □ __________________________________________

3. 가동중지 □ __________________________________________

완료기일:____________(날짜기입) 또는

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

slide15

형상관리 변경 절차

② 분석가에 의하여 review

  • 문제가 아닌 것
  • 교육을 통하여 해결할 수 있는 것
  • 그 외의 것은 형상관리 위원회 소집

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

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

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

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

slide16

형상관리 기술적 측면

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

UNIX

makefile

시스템 구축

논리적 시스템 구조

물리적

구조로의 전환

화일 1

화일 2”

화일 2

화일 2’

예: 형상관리 기술적 측면

slide18

소프트웨어 척도

  • Preventive maintenance

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

  • 품질
    • 유지보수성(maintainability)
    • 신뢰성(reliability)
    • 전환성(portability)
  • De Marco, We cannot control what we can not measure.
  • 척도(metric)
    • product metric(프로그램의 크기, 복잡도, 자료의 크기, 기능성, 신뢰성, 전환성, 일관성, 유지보수성)
    • process metric(개발에 걸리는 시간, 비용, 진척 상황)
slide19

소프트웨어 품질 척도

  • 정량적인 평가
    • 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
slide20

복잡도 측정

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

a

R1

R5

R2

c

b

d

R3

R4

e

V(G) = 5

f

slide21

Halstead의 Software Science

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

N = n1 log2 n1 + n2llog2n2

  • 프로그램의 부피

V = N log2 ( n1 + n2 )

slide22

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

slide23

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

slide24

Halstead 척도의 예

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

유지 보수 방법

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

유지 보수 방법

  • 소프트웨어의 수정

1) 유지보수 요구분석

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

2) 유지보수 설계

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

3) 유지보수 프로그래밍

    • 조금씩 점증적으로 변경
    • 변경 내용을 반드시 문서로 기록
    • 유지보수 용이성이 저하되지 않도록 수정

4) 유지보수 시험

    • 수정된 모듈을 unit test
    • 영향을 미치는 모듈은 다시 시험
slide27

유지 보수 도구

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

유지 보수 도구

  • 버전관리를 위한 도구
    • 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
ad