소프트웨어 유지 관리 개요

소프트웨어 유지 관리는 현재 SDLC의 일부로 널리 받아 들여지고 있습니다. 소프트웨어 제품 배송 후 수행되는 모든 수정 및 업데이트를 나타냅니다. 수정이 필요한 이유에는 여러 가지가 있으며 그중 일부는 아래에 간략하게 설명되어 있습니다.

Market Conditions -과세와 같이 시간이 지남에 따라 변경되는 정책과 부기 유지 방법과 같은 새로 도입 된 제약은 수정의 필요성을 유발할 수 있습니다.
Client Requirements -시간이 지남에 따라 고객은 소프트웨어의 새로운 기능을 요청할 수 있습니다.
Host Modifications -대상 호스트의 하드웨어 및 / 또는 플랫폼 (예 : 운영 체제)이 변경되면 적응성을 유지하기 위해 소프트웨어를 변경해야합니다.
Organization Changes -조직력 저하, 타 기업 인수, 신규 사업 진출 등 고객 측의 업무 수준 변화가있을 경우 원본 소프트웨어 수정이 필요할 수 있습니다.

유지 관리 유형

소프트웨어 수명 동안 유지 관리 유형은 특성에 따라 다를 수 있습니다. 일부 사용자가 발견 한 버그로 일상적인 유지 관리 작업 일 수도 있고 유지 관리 규모 또는 특성에 따라 그 자체로 큰 이벤트 일 수 있습니다. 다음은 특성에 따른 몇 가지 유지 관리 유형입니다.

Corrective Maintenance -여기에는 사용자가 발견하거나 사용자 오류 보고서로 결론을 내린 문제를 수정하거나 수정하기 위해 수행 된 수정 및 업데이트가 포함됩니다.
Adaptive Maintenance -여기에는 소프트웨어 제품을 최신 상태로 유지하고 끊임없이 변화하는 기술 및 비즈니스 환경의 세계에 맞추기 위해 적용된 수정 및 업데이트가 포함됩니다.
Perfective Maintenance-여기에는 소프트웨어를 장기간 사용할 수 있도록하기위한 수정 및 업데이트가 포함됩니다. 여기에는 소프트웨어를 개선하고 안정성과 성능을 개선하기위한 새로운 기능, 새로운 사용자 요구 사항이 포함됩니다.
Preventive Maintenance-여기에는 소프트웨어의 향후 문제를 방지하기위한 수정 및 업데이트가 포함됩니다. 현재로서는 중요하지 않지만 향후 심각한 문제를 야기 할 수있는 문제에 대처하는 것을 목표로합니다.

유지 보수 비용

보고서에 따르면 유지 관리 비용이 높습니다. 소프트웨어 유지 관리 평가에 대한 연구에 따르면 유지 관리 비용이 전체 소프트웨어 프로세스주기 비용의 67 %에 달하는 것으로 나타났습니다.

평균적으로 소프트웨어 유지 관리 비용은 모든 SDLC 단계의 50 % 이상입니다. 유지 관리 비용이 높아지는 요인은 다음과 같습니다.

유지 관리 비용에 영향을 미치는 실제 요인

모든 소프트웨어의 표준 연령은 최대 10 ~ 15 년으로 간주됩니다.
메모리와 저장 용량이 적은 느린 컴퓨터에서 작동하도록 의도 된 오래된 소프트웨어는 최신 하드웨어에서 새로 출시되는 향상된 소프트웨어에 대해 도전 할 수 없습니다.
기술이 발전함에 따라 오래된 소프트웨어를 유지하는 데 비용이 많이 듭니다.
대부분의 유지 보수 엔지니어는 초보자이며 시행 착오 방법을 사용하여 문제를 수정합니다.
종종 변경은 소프트웨어의 원래 구조를 쉽게 손상시켜 후속 변경을 어렵게 만들 수 있습니다.
변경 사항은 종종 문서화되지 않은 채로 남겨져 향후 더 많은 충돌을 일으킬 수 있습니다.

유지 관리 비용에 영향을 미치는 소프트웨어 최종 요소

소프트웨어 프로그램의 구조
프로그래밍 언어
외부 환경에 의존
직원 신뢰성 및 가용성

유지 보수 활동

IEEE는 순차적 유지 관리 프로세스 활동을위한 프레임 워크를 제공합니다. 반복적으로 사용할 수 있으며 사용자 지정 항목 및 프로세스를 포함 할 수 있도록 확장 할 수 있습니다.

이러한 활동은 다음 각 단계와 함께 진행됩니다.

Identification & Tracing-수정 또는 유지 보수 요구 사항 식별과 관련된 활동을 포함합니다. 사용자가 생성하거나 시스템 자체가 로그 또는 오류 메시지를 통해보고 할 수 있으며 여기에서 유지 보수 유형도 분류됩니다.
Analysis-변경 사항이 안전 및 보안 영향을 포함하여 시스템에 미치는 영향을 분석합니다. 영향이 심할 경우 대체 솔루션을 찾습니다. 그런 다음 필요한 수정 세트가 요구 사항 사양으로 구체화됩니다. 수정 / 유지 보수 비용이 분석되고 추정이 완료됩니다.
Design-교체 또는 수정이 필요한 새로운 모듈은 이전 단계에서 설정 한 요구 사항 사양에 따라 설계되었습니다. 검증 및 검증을 위해 테스트 케이스가 생성됩니다.
Implementation -새로운 모듈은 디자인 단계에서 생성 된 구조화 된 디자인의 도움으로 코딩되며 모든 프로그래머는 병렬로 단위 테스트를 수행해야합니다.
System Testing-새로 생성 된 모듈 간의 통합 테스트를 수행합니다. 통합 테스트는 새로운 모듈과 시스템간에 수행됩니다. 마지막으로 시스템은 회귀 테스트 절차에 따라 전체적으로 테스트됩니다.
Acceptance Testing-시스템 내부 테스트 후 사용자의 도움을 받아 합격 여부를 테스트합니다. 이 상태에서 사용자가 몇 가지 문제를 불만을 제기하면 다음 반복에서 해결하거나 해결해야합니다.
Delivery-수락 테스트 후 시스템은 소규모 업데이트 패키지 또는 시스템의 새로 설치를 통해 조직 전체에 배포됩니다. 최종 테스트는 소프트웨어가 제공된 후 클라이언트 측에서 수행됩니다.

필요한 경우 사용 설명서의 하드 카피와 함께 교육 시설이 제공됩니다.
Maintenance management-구성 관리는 시스템 유지 관리의 필수 부분입니다. 버전, 반 버전 또는 패치 관리를 제어하기 위해 버전 제어 도구를 사용합니다.

소프트웨어 리엔지니어링

기능에 영향을주지 않고 현재 시장에 유지하기 위해 소프트웨어를 업데이트해야하는 경우 소프트웨어 리엔지니어링이라고합니다. 소프트웨어 디자인을 변경하고 프로그램을 다시 작성하는 철저한 프로세스입니다.

레거시 소프트웨어는 시장에서 사용 가능한 최신 기술로 계속 조정할 수 없습니다. 하드웨어가 노후화되면 소프트웨어 업데이트가 골칫거리가됩니다. 소프트웨어가 시간이 지남에 따라 오래 되어도 기능은 그렇지 않습니다.

예를 들어, 처음에는 Unix가 어셈블리 언어로 개발되었습니다. 언어 C가 등장했을 때 어셈블리 언어로 작업하는 것이 어려웠 기 때문에 Unix는 C로 다시 엔지니어링되었습니다.

이 외에도 프로그래머는 소프트웨어의 일부 부분에서 다른 부분보다 더 많은 유지 관리가 필요하고 리엔지니어링도 필요하다는 사실을 알아 차립니다.

재 설계 프로세스

Decide리엔지니어링 할 것. 전체 소프트웨어입니까, 아니면 일부입니까?
Perform 기존 소프트웨어의 사양을 얻기 위해 리버스 엔지니어링.
Restructure Program필요한 경우. 예를 들어, 기능 지향 프로그램을 객체 지향 프로그램으로 변경합니다.
Re-structure data 필요에 따라.
Apply Forward engineering 재 설계된 소프트웨어를 얻기위한 개념.

소프트웨어 리엔지니어링에 사용되는 중요한 용어는 거의 없습니다.

리버스 엔지니어링

기존 시스템을 철저히 분석하고 이해하여 시스템 사양을 달성하는 과정입니다. 이 프로세스는 역 SDLC 모델로 볼 수 있습니다. 즉, 더 낮은 추상화 수준을 분석하여 더 높은 추상화 수준을 얻으려고합니다.

기존 시스템은 이전에 구현 된 설계로, 우리는 아무것도 모릅니다. 그런 다음 디자이너는 코드를보고 리버스 엔지니어링을 수행하고 디자인을 얻으려고합니다. 디자인을 손에 들고 사양을 마무리하려고합니다. 따라서 코드에서 시스템 사양으로 거꾸로 이동합니다.

프로그램 구조 조정

기존 소프트웨어를 재구성하고 재구성하는 과정입니다. 동일한 프로그래밍 언어로 또는 한 프로그래밍 언어에서 다른 언어로 소스 코드를 재배 열하는 것이 전부입니다. 재구성은 소스 코드 재구성과 데이터 재구성 또는 둘 다를 가질 수 있습니다.

재구성은 소프트웨어의 기능에 영향을주지 않지만 안정성과 유지 관리 성을 향상시킵니다. 오류를 매우 자주 일으키는 프로그램 구성 요소는 구조 조정을 통해 변경되거나 업데이트 될 수 있습니다.

구식 하드웨어 플랫폼에 대한 소프트웨어의 의존성은 재구성을 통해 제거 할 수 있습니다.

포워드 엔지니어링

포워드 엔지니어링은 리버스 엔지니어링을 통해 가져온 사양에서 원하는 소프트웨어를 얻는 프로세스입니다. 과거에 이미 수행 된 소프트웨어 엔지니어링이 있었다고 가정합니다.

포워드 엔지니어링은 소프트웨어 엔지니어링 프로세스와 동일하지만 한 가지 차이점 만 있습니다. 항상 리버스 엔지니어링 후에 수행됩니다.

부품 재사용 성

구성 요소는 시스템에서 독립적 인 작업을 실행하는 소프트웨어 프로그램 코드의 일부입니다. 작은 모듈 또는 하위 시스템 자체 일 수 있습니다.

예

웹에서 사용되는 로그인 절차는 구성 요소로 간주 될 수 있으며 소프트웨어의 인쇄 시스템은 소프트웨어의 구성 요소로 볼 수 있습니다.

구성 요소는 기능의 응집력이 높고 결합 속도가 낮습니다. 즉, 독립적으로 작동하고 다른 모듈에 의존하지 않고 작업을 수행 할 수 있습니다.

OOP에서 객체는 해당 관심사에 매우 구체적이며 다른 소프트웨어에서 사용할 가능성이 적습니다.

모듈 식 프로그래밍에서 모듈은 여러 다른 소프트웨어 프로그램에서 사용할 수있는 특정 작업을 수행하도록 코딩됩니다.

소프트웨어 구성 요소의 재사용을 기반으로하며 CBSE (구성 요소 기반 소프트웨어 엔지니어링)로 알려진 완전히 새로운 수직 영역이 있습니다.

다양한 수준에서 재사용이 가능합니다.

Application level -전체 애플리케이션이 새로운 소프트웨어의 하위 시스템으로 사용되는 경우.
Component level -애플리케이션의 하위 시스템이 사용되는 경우.
Modules level -기능 모듈이 재사용되는 곳.

소프트웨어 구성 요소는 서로 다른 구성 요소 간의 통신을 설정하는 데 사용할 수있는 인터페이스를 제공합니다.

재사용 프로세스

요구 사항을 동일하게 유지하고 구성 요소를 조정하거나 구성 요소를 동일하게 유지하고 요구 사항을 수정하는 두 가지 방법을 채택 할 수 있습니다.

Requirement Specification -소프트웨어 제품이 기존 시스템, 사용자 입력 또는 둘 모두의 도움을 받아 준수해야하는 기능 및 비 기능 요구 사항이 지정됩니다.
Design-이것은 또한 소프트웨어 용어로 요구 사항이 정의되는 표준 SDLC 프로세스 단계입니다. 전체 시스템 및 하위 시스템의 기본 아키텍처가 생성됩니다.
Specify Components -소프트웨어 설계를 연구함으로써 설계자는 전체 시스템을 더 작은 구성 요소 또는 하위 시스템으로 분리합니다. 하나의 완전한 소프트웨어 디자인은 함께 작동하는 거대한 구성 요소 모음으로 바뀝니다.
Search Suitable Components -소프트웨어 구성 요소 저장소는 기능 및 의도 된 소프트웨어 요구 사항을 기반으로 일치하는 구성 요소를 검색하기 위해 설계자가 참조합니다.
Incorporate Components -일치하는 모든 구성 요소가 함께 포장되어 완전한 소프트웨어로 형성됩니다.