소프트웨어 유지보수
28 소프트웨어 유지보수<o:p></o:p>
소프트웨어는 사람들의 의식이나 행동방법과 직결되는 시스템이기 때문에 이를 잘 유지보수하지 않으면 그 생명력을 잃게 되는 측 사용할 수 없게 되는 특성이 있다. 따라서 유지보수는 초기의 개발보다 더 중요한 일이며, 소요되는 노력과 비용도 더 많이 든다. 따라서 어떻게 하면 우지보수를 적게 하는 소프트웨어를 개발하느냐 하는 일이 중요하다. 유지보수와 관련된 업무는 개발당시 얼마나 충실하게 개발되었느냐 하는데 따라 크게 좌우되는 경우가 많다. 따라서 유지보수를 줄이려면 완벽한 수순과 방법에 따라 개발하여야 할 것 이며, 환경변화에 잘 적응할 수 있도록 유연하게 개발해야 한다.<o:p></o:p>
<o:p> </o:p>
소프트웨어 유지보수 정의<o:p></o:p>
l 개발이 완료후 사용자에게 인도된 사용중에 있는 소프트웨어를 환경적응, 오류수정, 성능향상 등을 위하여 계속하여 수정, 보완하고 이러한 작업을 통하여 소프트웨어의 수명을 연장시켜주는 작업
<o:p> </o:p>
소프트웨어 유지보수의 필요성<o:p></o:p>
l 유지보수 비용이 전체 비용의 70~80%를 차지
l 소프트웨어 인력이 신규 프로젝트보다 유지보수 업무에 투입되는 낭비적 요소 발생
l 유지보수의 비효율성으로 인해 패키지 소프트웨어의 도입이 확산
l 프로젝트보다 기존 소프트웨어 개선에 더 많은 인력과 비용 소요
l 소프트웨어 기능의 복잡화에 따른 난해함으로 문서화 등의 관리업무가 증가
<o:p> </o:p>
소프트웨어 유지보수 형태<o:p></o:p>
분류기준<o:p></o:p> | 유지보수의 형태<o:p></o:p> |
시간에 의한 분로 | - 계획보수 - 예방보수 - 응급보수 - 지연보수 |
대상에 의한 분류 | - 데이터/프로그램 보수 - 문서화 보수 - 시스템 보수 |
사유에 의한 분류 | - 수리보수 - 적응보수 - 완전화보수 |
<o:p> </o:p>
소프트웨어 유지보수 용이성과 향상<o:p></o:p>
1. 유지보수 용이성<o:p></o:p>
소프트웨어 유지보수 난이도를 나타내는 특성
가) 이용 용이성 : 프로그램이 얼마나 이해하기 쉬운가를 나타내는 특성
나) 수정 용이성 : 프로그램을 수정하는데 얼마나 용이한가를 나타내는 특성
다) 시험 용이성 : 프로그램의 정확성을 나타내는 과정이 얼마나 용이한가를 나타내는 특성
2. 유지보수 용이성의 향상<o:p></o:p>
가) 분석활동(Analysis Activities) : 고객의 요구와 제약사항을 결정하며 목표 제품으 타당성을 밝힘
나) 표준 및 지침(Standard and Guidelines) : 여러형태의 표준 및 지침은 소프트웨어의 유지보수가 용이하도록 하기 위하여 제정
다) 설계활동(Design Activities) : 명확성, 모듈성, 변경용이성을 강조하여 활용함
라) 구현활동(Implementation Activities) : 표준 구조와 단순 코딩 스타일이 채택되어 져야 함.
마) 보조문서(Supporting Documents) : 유지보수 활동에 필요한 지침서와 테스트 설명서가 필요함.
<o:p> </o:p>
소프트웨어 유지보수 비용<o:p></o:p>
1. 유지보수 비용 요소<o:p></o:p>
부분<o:p></o:p> | 비용 요소<o:p></o:p> |
관리적인 요소 | - 시스템에 대한 이해 - 유지보수 담당자 - 소프트웨어 생명주기 - 새로운 환경에 대한 종속도 |
기술적 요소 | - 모듈의 독립성 - 프로그램 언어 - 프로그램 스타일 - 신뢰성 - 문서화 |
무형의 요소 | - 사용자의 불만 - 품질의 저하 - 개발의 지연 |
<o:p> </o:p>
2. 유비보수 비용 예측 방법<o:p></o:p>
가) BL(Belady와 Lehman) 방법
소프트웨어 개발시에 얼마나 열심히 공학기법에 의하여 노력을 경주 하였는가에 따라 유지보수 비용의 증감이 관계되어 진다.
M = P+exp(C-D)
M : 유지보수를 위한 노력(인원)
P : 생산성적 노력
C : 설계의 비구조성이나 문서정리의 미흡함을 통한 복잡도
D : 소프트웨어의 인식정도
<o:p> </o:p>
나) COCOMO 방법
M = ACT X DE X EAF
M : 유비보수를 위한 노력(인원)
ACT : 개발조직이 수행하는 전체 프로젝트 규모에서 유지보수 작업이 차지하는 연평균 비율
DE : 개발 때 필요한 노력(인원)
EAF : 실험적 상수
<o:p> </o:p>
소프트웨어 유지보수 프로세스<o:p></o:p>
1. 유지보수 순서<o:p></o:p>
소프트웨어 이해 à 유지보수 요구사항 분석 à 소프트웨어 설계 à 소스코드 수정 à 단계별 테스트 à 유지보수 결과 검토
2. 유지보수 추진 단계<o:p></o:p>
단계<o:p></o:p> | 주요활동<o:p></o:p> | 활동주체<o:p></o:p> |
요청 | MRF(Modification Request Form) 작성 CR(Change Request) 작성 | 사용자 |
분석 | 유지보수의 유형 분류, 심각성 판단 유지보수의 내용 분석, 영향도 분석 유지보수 우선순위 결정 | 분석가 |
승인 | 분석 내용에 따라 유지보수 여부 승인 유지보수 실행에 대한 승인 | 유지보수 관리 위원회 |
실행 | 유지보수 대상에 대한 유지보수 실행 소프트웨어 변경 보고서(SCR) 작성 관련문서 변경 | 유지보수 담당자 |
3. 유지보수 발생 요인 분석<o:p></o:p>
측면 | 발생요인 |
소프트웨어의 유기적 측면 | - 소프트웨어 시스템에 대한 사용자 참여 및 만족도 미흡 - 개발된 시스템의 문서화, 유연성, 신뢰성 저하 |
개발 환경적 측면 | - 유지보수보다는 신규 프로젝트 치중 - 표준화된 방법론 및 개발 도구 적용의 부재 - 분석 설계 시 유지보수성 및 재 사용성 요인 반영의 미흡 |
<o:p> </o:p>
소프트웨어 유지보소의 문제점과 해결방향<o:p></o:p>
1. 유지보수의 문제점<o:p></o:p>
- 사람의 생각자체가 판이하게 다르듯이 프로그램의 구성이나 기법 자체가 프로그래머의 특성에 따라 다르므로 문서화가 정확하게 되어 있지 않으면 소스코드의 이해에 막대한 지장을 초래함.
- 개발시점에서의 프로그래머의 생각을 파악하기가 용이하지 못함.
- 모든 프로그램은 미리 수정을 에측하거나 기능 확장을 염두로 작성되기 어렵다.
- 유지보수 작업은 인기 있는 작업이 아니므로 그 생산성이 떨어진다.
2. 유지보수의 문제점 해결 방향<o:p></o:p>
- 표준화된 개발방법론 및 개발 도구 적용
- 소프트웨어 재공학 도구 활용(분석, 재구조화, 역공학)
- 유지보수 요인에 대한 예방활동 실시
- 변경관리, 형상관리 등 적절한 프로젝트 관리기법 도입