소프트웨어 공학 Lecture #10: 유지보수

Presentation on theme: "소프트웨어 공학 Lecture #10: 유지보수"— Presentation transcript:

1 소프트웨어 공학 Lecture #10: 유지보수
최은만 저 6차 개정판 1

2 학습 목표 유지보수의 소개 유지보구 작업 과정 소프트웨어 형상 관리 역공학 리엔지니어링 유지보수 도구

3 유지 보수 소프트웨어가 인수 설치된 후 일어나는 모든 작업 소프트웨어가 유용하게 활용되는 기간
소프트웨어는 환경과 비즈니스 요구에 따라 진화함 유지보수에 드는 노력

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

5 유지보수의 소개 정의 결함을 고치거나 성능을 높이거나 새로운 기능을 추가하거나 변경된 환경에 적응시키기 위하여 배포 후 수정하는 작업 변경의 이유 버그 제거 운영 환경의 변화 – 하드웨어, 플랫폼, 시스템 형상의 변화 정부 정책, 규례의 변화 비즈니스 절차의 변화 미래 문제를 배제하기 위한 변경

6 Lehman의 법칙 시스템의 타입 지속적인 변경의 원칙 엔트로피, 복잡도 증가의 법칙 자기 통제의 법칙 안정성 유지의 법칙
S 타입 – 완벽히 정희할 수 없는 타입(체스 게임) 지속적인 변경의 원칙 엔트로피, 복잡도 증가의 법칙 자기 통제의 법칙 안정성 유지의 법칙 친근성 유지의 법칙 지속적 성장의 법칙 품질 저하의 법칙 피드백 시스템의 법칙

7 유지 보수의 종류 교정형 유지보수(corrective maintenance)
발견된 오류의 원인을 찾아 계획적으로 문제해결 적응형 유지보수(adaptive maintenance) 새로운 자료나 운영체제, 하드웨어 환경으로 이식 완전형 유지보수(perfective maintenance) 성능이나 유지보수성을 개선하기 위한 변경 응급형 유지보수(emergency maintenance) 응급처치하기 위한 무계획적 유지보수

8 10.2 유지 보수 작업 과정 1) 프로그램 이해 2) 변경 파악과 분석 3) 형상 변경 관리 4) 변경 구현, 테스팅 설치
문서, 코드 reading 프로그램의 구조 파악 domain knowledge 습득 변수와의 관계, 서브루틴 사이의 관계 파악 코드 안에 숨겨진 의미(semantic) 파악 분석도구(call graph, cross-reference table 등), 디버깅 도구(tracer) 사용 2) 변경 파악과 분석 변경이 불가피한 이유와 요구를 이해 변경의 영향과 소요 비용, 리스크 분석 3) 형상 변경 관리 변경의 이해 당사자에게 알리고 피드백 4) 변경 구현, 테스팅 설치 code change change effect 분석

9 유지 보수 작업 과정 통합적이고 이해 중심적 개발은 코딩 중심의 작업, 유지보수는 이해 중심의 작업
각 작업이 포괄적이며 단발로 시행 ---> 다양한 기술이 필요

10 유지 보수 프로세스 모델 즉시 수정 모델 반복적 개선 모델 재사용 중심 모델

11 유지보수 프로세스 모델의 비교

12 프로그램 이해 원시코드로부터 설계나 명세를 추출하여 멘탈 모델로 표현하는 작업 개발 프로세스와 반대로 추상성을 추구하는 방향
상향식 이해 모델 상향식(bottom-up) 묶음화(chunking)

13 변경 파악과 분석 변경 요구를 기초로 어떤 부분을 변경할지 찾아냄 다른 변경 방법(COTS)도 찾아냄 변경 분석
변경 효과 분석 변경을 구현하고 테스트하는 데 드는 비용, 시간의 예측 리스크 파악 객체지향 소프트웨어 변경 효과 – 클래스 사이의 의존관계로 파악 클래스 B가 A의 서브클래스이면 B는 A에 의존관계 클래스 B가 A의 집합이면 B는 A에 의존관계 클래스 B가 A를 사용하면 B는 A에 의존관계 클래스 B가 A와 다른 클래스 사이의 연관을 위한 클래스이면 B는 A에 의존관계

14 10.3 형상관리 형상 관리(Configuration Management)
개발 주기 동안 생성된 문서를 관리하고 소프트웨어 시스템과 컴포넌트의 상태를 추적하는 작업 문서와 결과물에 대한 변경이 잘 조정되지 않는다면 불일치 발생 클래스 변경 후 의존 클래스를 업데이트 하여야 하드웨어에 적용되었던 전통적 원리를 소프트웨어 개발에 적용

15 베이스 라인 베이스 라인 목적 소프트웨어 형상 항목(configuration item)의 집합으로 구성
프로젝트의 중요한 상태 정의 프로덕트가 특정 상태에 이르렀는지를 나타냄 계속되는 개발, 유지보수 작업의 기준 형상 항목에 대한 변경을 제어하는 메커니즘

16 형상관리의 필요성 소수의 개발자가 한 장소에서 일한다면 형상관리는 불필요
시스템을 개발하는 많은 팀과 개발자들이 협력하고 동기화 할 필요 여러 버전을 유지하여야 할 경우 다양한 고객을 만족시키기 위한 제품을 유지하기 위해

17 형상관리 절차 소프트웨어 형상 파악 형상 변경 제어 소프트웨어 형상 감사 소프트웨어 형상 상태 보관

18 형상 파악 고유 식별자 – 고유 번호 예, LIS-Incl-DM 이름
문서 종류 – 요구 분석서, 설계 문서, 원시코드, 테스트 케이스 문서 파일 – 파일 이름과 경로 저자 생성 날짜, 목표 완성일 버전 번호 업데이트 이력 설명 SQA 담당자 – 품질 보증 책임자 SCM 담당자 – 항목 체크한 책임자

19 형상 변경 제어 변경의 이유를 파악 변경 분석 변경 제안 준비 변경 제안의 평가 변경을 추가 소프트웨어의 결함 하드웨어 변경
운영 요구의 변경 고객이나 사용자로부터 개선 요구 예산, 프로젝트 일정, 기간의 변경 변경 분석 변경 제안 준비 변경의 설명, 조직 및 개발자 파악, 변경의 이유, 영향 받는 항목, 소요 노력, 프로젝트 일정에 대한 영향 변경 제안의 평가 변경을 추가

20 형상 감사 베이스라인을 구축하기 위한 메커니즘 정의 형상 항목 검토 형상 항목 확인

21 10.4 역공학 역공학의 정의 프로그램의 추상 수준을 점증적으로 복구해 나가는 과정
대상 시스템을 분석하여 시스템의 컴포넌트와 관계를 찾아내어 같은 수준의 다른 표현이나 더 높은 수준의 표현으로 만드는 작업 프로그램의 추상 수준을 점증적으로 복구해 나가는 과정

22 역공학 작업순서 원시코드에서 소프트웨어 결과물들을 추출하는 것 역공학 도구의 구성

23 역공학의 용도 복원된 다이어그램은 다음 여러 방면에 사용 프로그램 이해 정형적 분석 테스트 케이스 생성 리엔지니어링
소프트웨어의 구조, 기능, 동작 이해 용이 정형적 분석 소프트웨어에 존재할 수 있는 문제를 감지 테스트 케이스 생성 흐름도의 경로 – 경로 테스트 케이스에 도움 리엔지니어링

24 재문서화 의미적으로 같은 추상 수준을 가진 표현을 생성하는 작업 목적 소프트웨어의 이해를 증진시키기 위하여 시스템의 다른 관점
현재 보유한 문서를 개선 새로 수정된 프로그램의 문서화

25 설계 복구 원시코드를 자세히 검토하여 의미 있는 추상성 높은 표현을 찾아내고 추출하는 작업 복구된 설계
원시코드 이해에 도움이 될 수 있음 향후 유지보수 또는 리엔지니어링을 위한 베이스라인으로 사용 유사한 다른 애플리케이션을 위하여 사용될 수도 있음 프로그래밍 언어 구조에 크게 좌우 객체지향 프로그램 – UML 도구에 의하여 자동화 원시코드에 내재된 설계의 의미, 의사결정을 파악 설계로 표현하는 작업 도메인 지식이 필요할 수도 있음

26 10. 5 리엔지니어링 시스템 또는 컴포넌트를 재구조화 하는 과정 목적 소프트웨어 아키텍처 개선 소프트웨어의 복잡도 경감
변경에 대한 적응성 개선 성능, 효율성, 자원 유용성 개선 소프트웨어 시스템의 유지보수 개선

27 리엔지니어링 과정 개선이 필요한 위치 파악 개선 전략을 선택 제안된 개선의 구현 목표를 기준으로 시스템 평가

28 10.6 유지 보수 도구 도구의 사용은 시간과 노력을 대폭 감소시킬 수 있음 역공학 도구 메트릭 측정 도구 성능 측정 도구
정적 분석 도구 변경 효과 분석 도구 형상 관리 도구 리그레션 테스팅 도구

29 Questions?