소프트웨어 유지보수

Software maintenance
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

소프트웨어 엔지니어링에서 소프트웨어 유지보수는 결함 수정, 성능 향상 또는 기타 [1][2]속성을 개선하기 위해 소프트웨어 제품을 배포한 후 수정하는 것입니다.

유지보수에 대한 일반적인 인식은 단순히 결함을 수리하는 것에 불과하다는 것입니다.그러나 한 연구에 따르면 유지관리 작업의 80% 이상이 수정되지 않은 [3]작업에 사용됩니다.이러한 인식은 사용자가 실제로 시스템의 [citation needed]기능이 향상되었다는 문제 보고서를 제출함으로써 지속됩니다.최근 연구에 따르면 버그 수정 비율은 21%[4]에 가깝습니다.

역사

Meir M은 소프트웨어 유지보수 및 시스템 진화에 대해 최초로 설명했습니다. 1969년 리먼.20년에 걸친 그의 연구는 리먼의 법칙을 공식화하는데 기여했다(Lehman 1997).그의 연구결과는 유지보수는 진화적 발전이며 유지보수의 결정은 시간이 지남에 따라 시스템(및 소프트웨어)에 어떤 일이 일어나는지 이해함으로써 도움이 된다는 결론을 내렸습니다.리먼은 시간이 지남에 따라 시스템이 계속 진화하고 있음을 입증했다.코드 리팩터링과 같은 작업을 수행하여 복잡성을 줄이지 않는 한 이러한 작업은 진화하면서 더욱 복잡해집니다.1970년대 후반, Lientz와 Swanson의 유명하고 널리 인용된 조사 연구는 유지 보수에 지출되는 수명 주기 비용의 매우 높은 부분을 폭로했습니다.

조사 결과 유지 보수 작업의 약 75%가 처음 두 가지 유형으로 나타났으며 오류 수정은 약 21%를 소비했습니다.많은 후속 연구들이 유사한 문제 규모를 시사한다.연구에 따르면 새로운 요구사항 데이터 수집 및 분석에서 최종 사용자의 기여가 매우 중요한 것으로 나타났습니다.이것이 소프트웨어의 진화 및 유지 보수 중에 발생하는 문제의 주요 원인입니다.소프트웨어 유지보수는 전체 라이프 사이클 비용의 대부분을 소비하고 소프트웨어를 신속하고 안정적으로 변경할 수 없기 때문에 비즈니스 기회가 상실됩니다.[5] [6] [7]

소프트웨어 유지보수의 중요성

소프트웨어 유지보수의 주요 문제는 관리상의 문제와 기술상의 문제입니다.주요 관리 문제는 고객의 우선순위에 따른 조정, 인력 배치, 유지보수를 수행하는 조직, 비용 예측입니다.주요 기술적 문제는 제한된 이해, 영향 분석, 테스트, 유지보수성 측정입니다.

소프트웨어 유지보수는 오류 수정, 기능 확장, 오래된 기능 삭제 및 최적화를 포함하는 매우 광범위한 작업입니다.변경이 불가피하기 때문에 평가, 제어 및 수정을 위한 메커니즘을 개발해야 합니다.

따라서 소프트웨어를 실행한 후 변경하는 작업은 유지보수 작업으로 간주됩니다.그 목적은 시간이 지남에 따라 소프트웨어의 가치를 보존하는 것입니다.고객 기반을 확장하고, 추가 요건을 충족하며, 사용하기 쉽고, 효율적이며, 새로운 기술을 채택함으로써 가치를 높일 수 있습니다.유지보수는 20년,[citation needed] 개발기간은 1~2년입니다.[citation needed]

소프트웨어 유지보수 계획

소프트웨어의 중요한 부분은 유지보수입니다.소프트웨어 개발 중에 정확한 유지보수 계획을 수립해야 합니다.사용자가 변경을 요구하거나 문제를 보고하는 방법을 지정해야 합니다.예산에는 자원 및 비용 견적이 포함되어야 하며, 모든 새로운 시스템 기능과 품질 목표를 개발하기 위한 새로운 의사결정이 제시되어야 합니다.개발 프로세스 후 5년 이상(또는 수십 년) 지속될 수 있는 소프트웨어 유지보수는 소프트웨어 유지보수의 범위, 배포/도입 후 프로세스의 맞춤화, 유지보수를 제공할 사용자 지정 및 라이프 사이클 비용의 견적을 처리할 수 있는 효과적인 계획이 필요합니다.

소프트웨어 유지보수 프로세스

이 섹션에서는 6가지 소프트웨어 유지보수 프로세스에 대해 다음과 같이 설명합니다.

  1. 구현 프로세스에는 유지보수 계획의 구상 및 작성, 개발 중 확인된 문제 처리 준비, 제품 구성 관리에 대한 후속 조치 등의 소프트웨어 준비 및 이행 작업이 포함됩니다.
  2. 문제 및 수정 분석 프로세스. 응용 프로그램이 유지보수 그룹의 책임이 되면 실행됩니다.메인터넌스 프로그래머는 각 요청을 분석하여 (상황을 재현하여) 확인하고 타당성을 확인하고, 조사하여 해결책을 제안하며, 요청 및 솔루션 제안을 문서화하고, 마지막으로 변경 적용에 필요한 모든 승인을 받아야 합니다.
  3. 수정의 실시 자체를 고려한 프로세스.
  4. 수정이 해결책을 제공하는지 확인하기 위해 요청을 제출한 개인에게 수정 작업을 확인함으로써 수정 프로세스를 수락합니다.
  5. 이행 프로세스(플랫폼 이행 등)는 예외적이며 일상적인 유지보수 태스크의 일부가 아닙니다.기능을 변경하지 않고 소프트웨어를 다른 플랫폼으로 이식해야 하는 경우 이 프로세스가 사용되며 유지 보수 프로젝트 팀이 이 작업에 할당될 수 있습니다.
  6. 마지막으로 매일 발생하지 않는 이벤트이기도 한 마지막 유지보수 프로세스는 소프트웨어 폐기입니다.

유지관리자에게 고유한 프로세스, 액티비티 및 프랙티스가 다수 있습니다.다음은 예를 제시하겠습니다.

  • 이행: 시스템이 개발자에서 유지관리자로 점진적으로 이전되는 제어되고 조정된 일련의 활동.Knowledge Transfer(KT; 지식전송)가 통상적인 핸드오버 중에 발생하는 것이 이상적입니다.
  • 유지관리자가 협의한 SLA(서비스 수준 계약) 및 전문(도메인 고유) 유지보수 계약
  • 변경 요청 및 문제 보고서 헬프 데스크: 유지보수 담당자가 수신한 요청의 우선순위 부여, 문서화 및 라우팅에 사용하는 문제 처리 프로세스

소프트웨어 유지 보수 카테고리

E.B. Swanson은 처음에 수정, 적응 및 [8]완벽의 세 가지 유지관리 범주를 식별했습니다.IEEE 1219 표준은 2010년 6월에 P14764로 [9]대체되었습니다.그 후, 이러한 내용이 갱신되어 ISO/IEC 14764가 제공되고 있습니다.

  • 수정 유지 보수:발견된 문제를 수정하기 위해 납품 후 수행되는 소프트웨어 제품의 사후 수정.자동 버그 수정으로 수정 유지보수를 자동화할 수 있습니다.
  • 적응형 유지보수:소프트웨어 제품을 변경 또는 변경 환경에서 사용할 수 있도록 하기 위해 배포 후 수행되는 소프트웨어 제품 수정.
  • 완벽한 유지보수:성능 또는 유지보수성을 개선하기 위해 납품 후 소프트웨어 제품 수정.
  • 예방적 유지보수:소프트웨어 제품 납품 후 소프트웨어 제품을 수정하여 소프트웨어 제품의 잠재적인 결함을 검출하고 수정한 후 유효한 결함이 되기 전에 수정합니다.

또, 소프트웨어의 총소유 코스트를 삭감하기 위해서 실시하는, 제공 전/릴리스전의 유지보수의 개념도 있습니다.소프트웨어 유지보수 목표를 포함한 코딩 표준 준수 등소프트웨어의 결합 및 응집 관리.소프트웨어 지원 목표 달성(SAE JA1004, JA1005, JA1006)일부 학원은[who?] 설계 문서나 시스템/소프트웨어 이해 훈련, 자원(설계 데이터가 없는 경우 약 1.5~2.0배의 비용)이 부족하기 때문에 지속적인 소프트웨어 유지보수에 대한 비용을 정량화하는 연구를 실시하고 있다.

유지 보수 요소

주요 조정 요소가 유지보수에 미치는 영향(긍정적 영향이 최대인 순서대로 정렬)

유지 보수 요소 플러스 범위
유지보수 전문가 35%
높은 스탭 경험 34%
테이블 기반 변수 및 데이터 33%
기본 코드의 복잡도가 낮음 32%
Y2K 및 특수 검색 엔진 30%
코드 재구성 도구 29%
리엔지니어링 툴 27%
고급 프로그래밍 언어 25%
리버스 엔지니어링 툴 23%
복잡도 분석 도구 20%
결함 추적 도구 20%
Y2K "대량 업데이트" 전문가 20%
자동 변경 관리 도구 18%
초과근무수당 18%
품질 측정 16%
정식 기준 코드 검사 15%
회귀 테스트 라이브러리 15%
뛰어난 응답 시간 12%
연간 10일 이상의 트레이닝 12%
고도의 관리 경험 12%
헬프 데스크 자동화 12%
오류가 발생하기 쉬운 모듈이 없음 10%
온라인 장애 보고 10%
생산성 측정 8%
뛰어난 사용 편의성 7%
사용자 만족도 측정 5%
높은 팀 사기 5%
합 503%

에러가 발생하기 쉬운 모듈뿐만 아니라 다른 많은 요인들로 인해 성능이 저하될 수 있습니다.예를 들어, 매우 복잡한 스파게티 코드는 안전하게 유지하기가 매우 어렵습니다.성능을 저하시키는 매우 일반적인 상황은 장애 추적 소프트웨어, 변경 관리 소프트웨어, 테스트 라이브러리 소프트웨어 등 적절한 유지보수 도구가 없다는 것입니다.다음은 소프트웨어 유지보수에 대한 몇 가지 요인 및 영향 범위를 설명합니다.

주요 조정 요소가 유지보수에 미치는 영향(부정적인 영향이 최대인 순서대로 정렬)

유지 보수 요소 마이너스 범위
오류가 발생하기 쉬운 모듈 -50%
내장된 변수 및 데이터 -45%
스탭의 미숙함 -40%
높은 코드 복잡성 -30%
특수 검색 엔진 Y2K 없음 -28%
수동 변경 제어 방법 -27%
저수준 프로그래밍 언어 -25%
결함 추적 도구 없음 -24%
Y2K "대량 업데이트" 전문가 없음 -22%
사용 편의성 저하 -18%
품질 측정 없음 -18%
유지보수 전문가 없음 -18%
응답 시간 부족 -16%
코드 검사 없음 -15%
회귀 테스트 라이브러리 없음 -15%
헬프 데스크 자동화 없음 -15%
온라인 결함 보고 없음 -12%
관리 미숙 -15%
코드 재구성 도구 없음 -10%
연간 훈련 없음 -10%
리엔지니어링 툴 없음 -10%
리버스 엔지니어링 툴 없음 -10%
복잡도 분석 도구 없음 -10%
생산성 측정 없음 -7%
팀의 사기 저하 -6%
사용자 만족도 측정 없음 -4%
초과근무수당없음 0%
합 -500%

[10]

유지보수의

John Estdale은 [11]2019년 제27회 소프트웨어 품질관리 국제회의의 논문에서 라이브러리, 플랫폼, 툴 등 외부 IT 요인에 대한 구현으로 인해 발생하는 유지보수 요구에 대해 "[12]유지보수 부채"라는 용어를 도입했습니다.애플리케이션 실행은 계속되며 IT부문은 이 이론적 책임을 잊고 다른 곳에서 더 긴급한 요건과 문제에 집중합니다.이러한 부채는 시간이 지남에 따라 누적되어 소프트웨어 자산의 가치를 묵묵히 잠식하고 있습니다.결국 시스템 변경을 피할 수 없는 상황이 발생합니다.

그러면 소유자는 시스템을 더 이상 변경할 수 없다는 것을 알게 됩니다.그것은 말 그대로 유지보수가 불가능하기 때문입니다.즉, 유지보수가 비즈니스 문제를 해결하는 데 시간이 너무 오래 걸리거나 비용이 너무 많이 들 수 있으므로 대체 솔루션을 찾아야 합니다.소프트웨어가 갑자기 0파운드 가치로 추락했다.

Estdale에서는 '유지보수 채무'[12]를 어플리케이션의 현재 구현 상태와 이상적인 구성 요소 간의 갭으로 정의합니다.이는 완전히 유지보수 및 지원되는 외부 컴포넌트의 기능만을 사용하는 것입니다.이 빚은 종종 숨겨지거나 인식되지 않는다.애플리케이션의 전체적인 유지보수성은 다음을 포함한 모든 종류의 컴포넌트를 다른 공급업체로부터 지속적으로 입수할 수 있는지에 따라 달라집니다.

  • 개발 도구: 소스 편집, 구성 관리, 컴파일 및 빌드
  • 테스트 도구: 테스트 선택, 실행/검증/리포트
  • 상기의 실행 플랫폼: 하드웨어, 운영체제 및 기타 서비스
  • 운영 환경 및 모든 스탠바이/디저스터 리커버리 시설(소스 코드 언어의 런타임 지원 환경 포함), 작업 스케줄링, 파일 전송, 리플리케이트 스토리지, 백업 및 아카이브, 싱글 사인온 등의 광범위한 에코시스템
  • 별도로 취득한 패키지(DBMS, 그래픽스, 통신, 미들웨어 등)
  • 소스 코드, 오브젝트 코드 라이브러리 및 기타 호출 불가능한 서비스에서 구입
  • 운영 환경을 공유하거나 해당 애플리케이션과 연동하는 다른 애플리케이션에서 발생하는 모든 요건 발생

그리고 물론.

  • 사내 또는 시장에서 관련 스킬을 이용할 수 있습니다.

컴포넌트가 완전히 사라지면 어플리케이션을 재구축할 수 없게 되거나 즉시 유지보수할 수 없게 됩니다.

「 」를 참조해 주세요.

레퍼런스

[13]

  1. ^ "ISO/IEC 14764:2006 Software Engineering — Software Life Cycle Processes — Maintenance". Iso.org. 2011-12-17. Retrieved 2013-12-02.
  2. ^ Soleimani Neysiani, Behzad; Babamir, Seyed Morteza; Aritsugi, Masayoshi (2020-10-01). "Efficient feature extraction model for validation performance improvement of duplicate bug report detection in software bug triage systems". Information and Software Technology. 126: 106344. doi:10.1016/j.infsof.2020.106344. S2CID 219733047.
  3. ^ Pigoski, Thomas M., 1997: 실용적인 소프트웨어 유지보수:소프트웨어 투자를 관리하기 위한 베스트 프랙티스.Wiley Computer Pub.(뉴욕)
  4. ^ Eick, S., Graves, T., Karr, A., Marron, J. 및 Mockus, A. 2001.코드가 붕괴되는가?변경관리데이터에서증거평가소프트웨어 엔지니어링에 관한 IEEE 트랜잭션. 27 (1) 1~12.
  5. ^ Lientz B., Swanson E., 1980: 소프트웨어 유지보수 관리.애디슨 웨슬리, 리딩, 매사추세츠 주
  6. ^ 리먼 M. M., 1980: 프로그램, 라이프 사이클 및 소프트웨어 진화의 법칙IEEE 의사록, 68, 9,1060-1076
  7. ^ 페니 그럽, 암스트롱 ATakang, 2003: 소프트웨어 유지보수:개념과 프랙티스세계 과학 출판사
  8. ^ Lientz, B. P.; Swanson, E. B.; Tompkins, G. E. (June 1978). "E. Burt Swanson, The dimensions of maintenance. Proceedings of the 2nd international conference on Software engineering, San Francisco, 1976, pp 492 — 497". Communications of the ACM. Portal.acm.org. 21 (6): 466–471. doi:10.1145/359511.359522. S2CID 14950091. Retrieved 2013-12-02.
  9. ^ IEEE 표준에 의한 1219-1998 상태
  10. ^ "The Economics Of Software Maintenance In The Twenty First Century" (PDF). Archived from the original (PDF) on 2015-03-19. Retrieved 2013-12-02.
  11. ^ Khan, O; Marchbank, P; Georgiadou, E; Linecar, P; Ross, M; Staples, G (2019). Proc of Software Quality Management XXVII: International Experiences and Initiatives in IT Quality Management. Southampton: Solent University. ISBN 978-1-9996549-2-4.
  12. ^ a b Estdale, John. Delaying Maintenance Can Prove Fatal. in [11]. pp. 95–106.
  13. ^ Pigoski, Thomas. "Chapter 6: Software Maintenance" (PDF). SWEBOK. IEEE. Retrieved 5 November 2012.

추가 정보

  • ISO/IEC 14764 IEEE Std 14764-2006 Software Engineering — Software Life Cycle Processes — Maintenance. 2006. doi:10.1109/IEEESTD.2006.235774. ISBN 0-7381-4960-8.
  • Pigoski, Thomas M. (1996). Practical Software Maintenance. New York: John Wiley & Sons. ISBN 978-0-471-17001-3.
  • Pigoski, Thomas M. Description for Software Evolution and Maintenance (version 0.5). SWEBOK Knowledge Area.
  • April, Alain; Abran, Alain (2008). Software Maintenance Management. New York: Wiley-IEEE. ISBN 978-0-470-14707-8.
  • Gopalaswamy Ramesh; Ramesh Bhattiprolu (2006). Software maintenance : effective practices for geographically distributed environments. New Delhi: Tata McGraw-Hill. ISBN 978-0-07-048345-3.
  • Grubb, Penny; Takang, Armstrong (2003). Software Maintenance. New Jersey: World Scientific Publishing. ISBN 978-981-238-425-6.
  • Lehman, M.M.; Belady, L.A. (1985). Program evolution : processes of software change. London: Academic Press Inc. ISBN 0-12-442441-4.
  • Page-Jones, Meilir (1980). The Practical Guide to Structured Systems Design. New York: Yourdon Press. ISBN 0-917072-17-0.

외부 링크