[요구공학] [소프트웨어 품질 속성] Maintainability

소프트웨어 품질 속성과 품질 시나리오, 그리고 기능적 적합성(Functional Suitability), 성능 효율성(Performance Efficiency), 호환성(Compatibility), 사용성(Usability), 신뢰성(Reliability), 보안(Security)에 대해 앞선 글에서 알아보았습니다.

[요구공학] 소프트웨어 품질 속성과 품질 시나리오

 

이번에는 소프트웨어 품질 속성 중 하나인 유지 관리성(Maintainability)에 대해 조금 더 자세히 알아보고, 품질 시나리오 예를 알아보고자 합니다.

 

 

목차

 

유지 관리성(Maintainability)

유지 관리성(Maintainability)은 시스템이 시간이 지나면서 발생할 수 있는 다양한 변경 요구에 효과적으로 대응할 수 있는 능력을 나타냅니다. 이 특성은 시스템의 장기적인 성공과 지속 가능성에 중요하며, 개발 및 유지보수 비용을 낮추는 데 기여합니다.

 

각 하위 특성의 설명과 중요성은 다음과 같습니다.

 

모듈성(Modularity)

모듈성(Modularity)은 시스템이 개별적으로 분리된 구성 요소로 설계되어 한 구성 요소의 변경이 다른 구성 요소에 미치는 영향을 최소화하는 정도를 나타냅니다.

 

중요성

모듈성(Modularity)이 높은 시스템은 각 모듈을 독립적으로 개발하고 테스트할 수 있기 때문에 오류 발생 시 그 영향을 제한하고, 필요한 부분만 수정할 수 있어 유지보수 비용과 복잡성이 감소합니다.

 

QAS 예시

• Category: 유지 관리성
• Source: 개발팀
• Stimulus: 시스템 기능의 변경 요청
• Environment: 개발 및 운영 환경
• Artifacts: 서비스 지향 아키텍처(SOA), 마이크로서비스
• Response: 시스템은 개별 서비스를 독립적으로 업데이트하거나 수정할 수 있어야 함
• Response Measure: 단일 서비스의 변경이 시스템의 다른 부분에 영향을 미치지 않아야 하며, 개별 업데이트의 배포 시간은 2시간 이내로 제한됨

 

개발 및 운영 환경에서, 개발팀이 시스템 기능의 변경을 요청할 때, 서비스 지향 아키텍처(SOA) 및 마이크로서비스를 활용하여 시스템은 각 개별 서비스를 독립적으로 업데이트하거나 수정할 수 있다. 이 과정에서 단일 서비스의 변경이 시스템의 다른 부분에 영향을 미치지 않으며, 개별 업데이트의 배포 시간은 2시간 이내로 제한된다.

 

 

재사용성(Reusability)

재사용성(Reusability)은 시스템의 구성 요소나 코드를 다른 프로젝트나 시스템에서 재사용할 수 있는 정도입니다.

 

중요성

재사용성(Reusability)이 높은 시스템은 재사용 가능한 컴포넌트를 활용하면 개발 시간과 비용을 절약하고, 검증된 구성 요소의 재사용을 통해 시스템의 전반적인 신뢰성을 높일 수 있습니다.

 

QAS 예시

• Category: 유지 관리성
• Source: 개발팀
• Stimulus: 코드 또는 구성 요소의 재사용
• Environment: 소프트웨어 개발 환경
• Artifacts: 코드 라이브러리, 공통 서비스 모듈
• Response: 개발자들은 기존의 검증된 모듈을 새로운 시스템 또는 업데이트에 적용할 수 있어야 함
• Response Measure: 재사용된 컴포넌트로 인해 개발 시간 및 비용이 최소 30% 절감됨

 

소프트웨어 개발 환경에서, 개발팀이 코드 또는 구성 요소의 재사용을 요청할 때, 코드 라이브러리와 공통 서비스 모듈을 활용하여 개발자들은 기존의 검증된 모듈을 새로운 시스템 또는 업데이트에 적용할 수 있다. 이 과정에서 재사용된 컴포넌트로 인해 개발 시간 및 비용이 최소 30% 절감되어야 합니다.

 

 

분석 가능성(Analysability)

분석 가능성(Analysability) 은 시스템의 결함이나 실패 원인을 진단하거나 예정된 변경의 영향을 평가하기 위해 시스템을 분석할 수 있는 정도입니다.

 

중요성

분석 가능성(Analysability)은 시스템의 문제를 신속하게 식별하고 해결하는 데 도움을 주어, 유지보수 팀이 효과적으로 대응할 수 있도록 합니다.

 

QAS 예시

• Category: 유지 관리성
• Source: 테스트 팀
• Stimulus: 시스템 결함 진단 및 영향 평가
• Environment: 테스트 및 프로덕션 환경
• Artifacts: 테스트 도구, 로그 파일, 디버깅 도구
• Response: 시스템은 발생한 결함을 식별하고, 그 원인을 효과적으로 진단할 수 있어야 함
• Response Measure: 결함 식별 및 진단에 걸리는 시간은 발생 후 24시간 이내로 제한됨

 

테스트 및 프로덕션 환경에서, 테스트 팀이 시스템 결함 진단 및 영향 평가를 시행할 때, 테스트 도구, 로그 파일, 디버깅 도구를 활용하여 시스템은 발생한 결함을 식별하고, 그 원인을 효과적으로 진단할 수 있다. 이 과정에서 결함 식별 및 진단에 걸리는 시간은 발생 후 24시간 이내로 제한되어야 합니다.

 

 

수정 가능성(Modifiability)

수정 가능성(Modifiability)은 시스템의 요구 사항 변경, 기능 추가 또는 결함 수정을 효율적으로 수행할 수 있는 능력입니다.

 

중요성

수정 가능성(Modifiability)은 유연하고 수정이 용이한 시스템은 시장 변화나 사용자 요구에 빠르게 대응할 수 있으며, 장기적으로 시스템의 가치를 유지하고 비용을 절감합니다.

 

QAS 예시

• Category: 유지 관리성
• Source: 개발팀
• Stimulus: 사용자 인터페이스 변경 요청
• Environment: 소프트웨어 개발 및 배포 환경
• Artifacts: 소스 코드, 개발 도구
• Response: 시스템은 사용자 인터페이스의 변경 요청을 신속하고 효과적으로 구현할 수 있어야 함
• Response Measure: 사용자 인터페이스 변경은 개발 시작 후 48시간 이내에 완료되며, 기존 기능성에 영향을 미치지 않음

 

소프트웨어 개발 및 배포 환경에서, 개발팀이 사용자 인터페이스 변경을 요청할 때, 시스템은 소스 코드와 개발 도구를 사용하여 이 변경 요청을 신속하고 효과적으로 구현합니다. 사용자 인터페이스의 변경은 개발 시작 후 48시간 이내에 완료되며, 이 과정에서 기존의 기능성에는 영향을 미치지 않습니다. 

 

 

테스트 가능성(Testability)

테스트 가능성(Testability)은 시스템, 제품 또는 구성 요소가 얼마나 쉽게 테스트할 수 있는지, 즉 테스트 기준을 설정하고 이를 충족하는지 검증할 수 있는 정도입니다.

 

중요성

테스트 가능성(Testability)이 높은 시스템은 개발 초기 단계에서 결함을 식별하고 수정하기 쉽게 만들어, 전반적인 개발 과정에서 품질을 향상시키고 위험을 줄일 수 있습니다.

 

QAS 예시

• Category: 유지 관리성
• Source: 품질 보증 팀
• Stimulus: 새로운 기능 통합 테스트
• Environment: 개발 및 테스트 환경
• Artifacts: 테스트 케이스, 테스트 자동화 도구
• Response: 시스템은 새로 통합된 기능에 대해 쉽고 명확하게 테스트할 수 있어야 함
• Response Measure: 새 기능에 대한 테스트 커버리지는 90% 이상이며, 테스트 완료 시간은 기능 통합 후 24시간 이내

 

개발 및 테스트 환경에서, 품질 보증 팀이 새로운 기능의 통합 테스트를 진행할 때, 테스트 케이스와 테스트 자동화 도구를 사용하여 시스템은 이 새 기능을 쉽고 명확하게 테스트할 수 있습니다. 이 과정에서 새 기능에 대한 테스트 커버리지는 90% 이상이며, 기능 통합 후 24시간 이내에 테스트가 완료됩니다.