CH2. 소프트웨어 품질

CH2. 소프트웨어 품질

2.1 소프트웨어 품질의 중요성

2.2 소프트웨어 품질 요소

2.3 소프트웨어 품질 모델 및 표준

2.4 소프트웨어 품질 관리

 

 소프트웨어 품질이란 구체적으로 무엇을 의미하고, 어떤 품질 요소가 있으며, 이들을 정량적으로 관리하는 방법에 대해 살펴본다.

---

2.1 소프트웨어 품질의 중요성

 사람마다 제품을 선택하는 기준은 다른다. 따라서 사용자가 만족하는 소프트웨어를 개발하는 것 또한 어려움이 따른다. 그럼에도 소프트웨어 공학의 목표는 높은 품질의 소프트웨어를 만들어내는 것이다. 이는 즉, 소프트웨어 개발과 관련된 모든 이해 관계자 Stakeholder의 만족도를 높이는 것으로 해석할 수 있다.

 

 소프트웨어의 품질은 눈으로 확인하기 어렵고, 절대적 평가가 힘들며, 시간이 지날 수록 품질의 수준이 점점 높아지고 다양한 관련자들을 고려해야하기 때문이다.

 

 따라서 (1) 이해 관계자들의 요구사항을 명확히 식별하고, (2) 요구사항과 관련된 품질 요소를 정의하고, (3) 이를 정량적으로 평가할 수 있는 척도와 절차가 필요하다.

 

소프트웨어 품질의 정의

프레스만 (R. Pressman) : 명시적인 기능 및 성능 요구사항, 명시적으로 문서화 된 개발 표준, 개발된 소프트웨어에서 기대되는 묵시적인 특성에 대한 적합성

 

소프트웨어 품질이 중요한 이유

소프트웨어의 품질 요소는 매우 다양하다. 서로 다른 이해관계자들의 만족을 모두 채우기 어렵기 때문에 대상 소프트웨어의 특성을 고려한 적절한 품질 목표 설정이 필요하다.

2.2 소프트웨어 품질 요소

 소프트웨어 품질은 요구에 대한 적합성이다. 즉, 모든 이해관계자의 기대치를 최대한 만족시켜야한다는 의미이다. 그렇다면 각각의 이해관계자가 가지는 기대는 무엇일까?

 

위 표에서 나타난 각각의 이해관계자들이 기대하는 품질 요소는 사용자 관점의 외적 요소와 개발자 관점의 내적 요소로 분류할 수 있다.

 

외적 품질 요소 : 사용자 관점에서 보여지는 품질 요소

• 정확성 : 사용자 요구사항대로 동작하는 소프트웨어
  • 요구사항 명세서 내용을 하나씩 테스트하여 기대 결과를 생성하는지 여부로 판단.
  • 척도 : Correctness(P) = 1 - (테스트 실패 기능 수 / 사용자의 전체 요구사항 개수)
• 신뢰성 : 사용자가 자신이 수행하던 업무를 소프트웨어에 의존하여 전적으로 수행할 수 있는 정도.
  • 소프트웨어를 사용하는 동안 나타나는 고장 발생 정도로 판단.
  • 소프트웨어 고장의 빈도수와 그 치명도.
  • 척도 : MTBF (Mean Time Between Failure) 고장 간 평균 시간.
    • e.g., 공군 전투기 소프트웨어 신뢰성 : MTBF = 10,000H | 10,000 시간 내에 고장이 한 번도 없어야 함.
• 견고성 : 신뢰성보다 더 엄격한 품질 요소. 명세에 없는 조건에서도 소프트웨어가 합리적으로 동작해야 함.
  • 위험한 임무를 수행해야하는 시스템에서 특히 중요. 틀린 정보에서도 합리적 응답 제공.
  • 척도 : 예외 처리 능력, 시스템 과부하 대응 능력, 스트레스 테스트 결과.
    • 스트레스 테스트 : 소프트웨어를 극한 상황이나 고부하 상태로 운영하며 테스트.
• 성능 : 소프트웨어의 효율성을 의미.
  • 척도 : 소프트웨어를 수행하기 위해 필요한 메모리의 양, 총 실행 시간 등.
• 사용자 친숙성 : 소프트웨어가 사용하기 편리한가를 나타내는 품질 요소.
  • 편의성 지원 기능이 얼마나 제공되는가로 측정.
  • 척도 : 도움말 말풍선, 스크롤 바, 핫 키 등의 기능 개수.
• 가용성 : 소프트웨어를 언제든지 사용하고 싶을 때 사용
  • 서버, 네트워크, 프로그램 등의 시스템이 정상적으로 사용 가능한 정도
  • 척도 : Usable Time / Operation Time
• 보안성 : 잠재적인 공격이 예측되는 상황에서도 소프트웨어가 올바르게 동작.
  • 척도 : 발견된 취약점 개수, 사고 통계, 보안 취약으로 인한 연간 손실액.
• 안전성 : 소프트웨어 위험성을 회피하고, 위험 상태 발생 시 사용자에게 안내.
  • 소프트웨어 위험성 : 소프트웨어 사고가 발생하기 위한 필요 조건.
  • 척도 : 사고 발생률
• 무결성 : 프로그램이나 데이터에 대한 불법 사용이나 잘못된 접근을 막는 정도
  • 데이터에 대한 적절한 접근 보장, 권한 없는 사용자 접근 금지
  • 무결성을 보장함으로써, 데이터 부정확함과 손실로부터 시스템 보호.
    • e.g., 블록 체인 등
  • 척도 : 무단 접근 시도 수 

각각의 품질 요소는 서로 긍정적으로 작용하기도, 부정적으로 작용하기도 한다.

 

내적 품질 요소 : 개발자 관점 품질 요소

• 검증 가능성 : 소프트웨어가 지닌 속성이 올바르다는 것을 완전히 확인 가능한가. 요구사항을 충족하는지 확인하고 검증할 수 있는 정도.
  • 정형 검증 : 검증 대상을 형식 언어/수학으로 표현하거나 시뮬레이션함으로써 검증 대상이 정확하게 동작한다는 것을 보이는 방법.
    • 척도 : 명세와 구현의 일치성, 귀납적 증명, 정형적 추론.
  • 테스트 : SW의 정확한 동작을 확인하기 위하여 테스트 케이스를 이용해 실행.
    • 척도 : 테스트 커버리지, 자동화 수준.
• 유지보수성 : 사용중인 소프트웨어는 많은 변경과 수정이 발생한다.
  • 척도 : 수정 가능성 = 발견된 오류나 결함을 수정하기 위해 소요하는 시간 (그러나 판단이 어려움.)
  • 유지보수 활동 
    • 수정 유지보수 : 개발된 소프트웨어를 사용하는 동안 오류가 발생하는 경우 취하는 활동
    • 적응 유지보수 : 소프트웨어 운영 조건에 대한 변화를 수용하는 활동
    • 완전 유지보수 : 소프트웨어 가독성 및 이해성을 높이는 재구조화를 목적으로 수행
    • 예방 유지보수 : 소프트웨어가 정확하게 동작할 것인지를 테스트하고 점검. 임무 중심 및 안전 중심 소프트웨어에서 매우 중요한 유지보수 활동.
• 재사용성 : 새로운 소프트웨어를 개발하기 위해 기존 소프트웨어 컴포넌트를 사용하는 정도
  • 척도 : Reusability(P) = LOC(R)/LOC(S)
    • LOC(S) : 전체 개발된 산출물 양, LOC(R) : 재사용으로 개발된 부분의 양
• 이식성 : 얼마나 다양한 하드웨어 플랫폼과 소프트웨어 플랫폼을 지원하는가.
• 가독성(=이해성) : 모든 산출물이 얼마나 쉽게 이해하도록 작성되었는가.
  • 척도 
    • 조직 또는 기관에서 정의하는 표준 가이드라인을 따르고 있는가?
    • 산출물의 내용이 체계적으로 구조화/모듈화 되었는가?
    • 모든 문서에는 페이지 번호, 그림 및 표 번호가 있는가?
    • 직관적이고 의미있는 단어들을 사용하여 표현했는가?
• 생산성 : 소프트웨어 개발 과정이 얼마나 효율적인가.
  • 척도 : 주어진 시간 내에 얼마만큼의 성과를 내고 있는가. LOC (Lines Of Codes)나 기능 점수 활용.
• 상호 운용성 : 서로 다른 소프트웨어들이 협업을 수행할 수 있는 능력.
  • IoT 기술을 근간으로 하는 스마트 시티 환경에서 매우 중요함.
• 적시성 : 소프트웨어를 적시에 사용자에게 배포할 수 있는 능력. 계획된 스케쥴에 맞추어 개발이 완료되었는가.
• 가시성 : 소프트웨어 개발 과정의 각 단계에서 소프트웨어 개발 상태 정보가 모두 문서화된다면 가시성이 제공된다고 볼 수 있음. 문서화.
• 기타 품질 요소 : 적응성, 무결성, 회복성, 변경성, 추적성 등.

프로세스 품질

 지금까지 소프트웨어 품질을 구분하는 기준으로 내적 품질 요소와 외적 품질 요소를 살펴보았다. 품질을 구분하는 또 다른 요소는 제품 품질과 프로세스 품질이다. 제품 품질이란 소프트웨어 제품 그 자체의 품질에 해당하는 것으로 내적 품질과 외적 품질을 모두 포함한다.

 

 프로세스 품질이란 개발 과정에서 수행되는 엔지니어들의 활동이 얼마나 적합했나를 의미한다.

 

• 프로세스 모델 적합성 : 어떤 프로세스 모델 (폭포수 모델, 애자일 등)을 적용했나.
• 개발 방법론 적합성 : 객체지향 방법, 구조적 방법론, 정보 공학 방법론 등.
• 도구 적합성 : 개발도구가 개발 환경에 적합한지, 팀 기반 개발을 충분히 지원할 수 있는지.
• 표준 준수성 : 선택한 표준이 적절한지, 선택한 표준을 준수하여 프로젝트가 진행되고 있는지.
• 프로젝트 데이터 관리 수준 : 프로젝트 진행과 관련된 상세 데이터가 정보 저장소에 저장되어 프로젝트 내에서 혹은 추후 신규 프로젝트의 예측 활동에서 활용할 수 있는지.

 

2.3 소프트웨어 품질 모델 및 표준

 지금까지 다양한 품질 요소의 정의와 개념에 대하여 살펴보았다. 그렇다면 이 품질 요소들을 어떻게 관리해야할까? 소프트웨어 품질 모델은 이러한 품질 요소드를 적용하는데 가이드라인이 되어준다. 대표적으로 ISO 25010 품질 모델에 대해 알아보겠다.

 

ISO 25010 품질 모델

 ISO 25010 품질 모델은 ISO 9126의 업데이트 버전으로, 현재 표준으로 쓰이는 모델이다. 이 표준에서는 내적 품질과 외적 품질에 대한 개념을 재정의 했다. 외적 품질은 블랙 박스 방식으로 측정되는 제품의 품질 특성을 나타내며, 내적 품질은 소프트웨어의 내부 구조를 기반으로 한 화이트 박스 방식으로 측정되는 제품의 품질 특성을 의미한다.

 

ISO 25010 표준에서는 ISO 9126에서는 정의하지 않는 Quaility-in-Use (사용 품질) 모델을 제시하였다. 이는 모델은 해당 품질 요소가 소프트웨어의 실제 운영 환경에서 활용될 수 있는 품질 특성을 포함하고 있다.

2.4 소프트웨어 품질 관리

 그렇다면 이러한 소프트웨어 품질 목표를 어떻게 달성해야할까? 목표 달성을 위해서는 품질을 정량적으로 평가할 필요가 있다. 따라서 이번 절에서는 정량적 품질 개선과 예측적 품질 관리에 대해 알아보겠다.

 

정량적 품질 개선

 품질을 정랑적으로 평가하는 이유는 점수를 매기는 것의 목적이 아니라 더 좋은 프로그램을 만드는데 목적이 있다. 따라서 서 품질을 개선하기 위한 노력이 지속적으로 이루어진다.

• 준비단계
  • 조직 전체에 품질 관리 활동이 이루어진다는 것을 공식화.
  • 품질 관리 담당자 지정 등 팀 구성과 역할을 정의
  • 품질 관리 활동을 이해 요구되는 적용 표준, 지원 도구, 환경을 구축
• 척도 조정 단계
  • 다양한 품질 요소 중에서 어떤 요소를 측정할 것인가를 결정
  • 요구사항을 바탕으로 적용 대상 품질 요소를 확정
  • 각 품질 요소를 적용할 단계 및 대상물과 정량화 방법 정의
    • 품질 측정 계획서에 포함
• 측정 단계
  • 품질 측정 계획서를 기반으로 데이터 수집 후 정량화 방법에 의해 분석
  • 새로운 데이터가 발견되거나 척도를 분리해야하는 상황이 발생하면, 새로운 척도를 마련하고 적용.
• 평가 단계
  • 측정된 요소들이 올바른지 점검하고, 품질 수준 평가
    • 유사 프로젝트의 품질 요소 수준과 상대적으로 비교하거나, 조직에서 정의한 품질 척도에 근거해 진행
    • 품질 측정 과정, 데이터 수집 시점, 데이터 임의 변경 등을 점검
    • 수집/측정 데이터는 조직 차원의 프로젝트 DB에 저장
• 관리 단계
  • 조직 차원에서 수행하는 품질 관리 및 기술 관리 프로세스
  • 적절한 품질 표준을 선택
  • 품질 관리 활동에 대한 다양한 양식 및 가이드라인 제공, 교육 등을 통해 조직 차원의 품질 관리 활동을 관리·지원

정량적 품질 개선 예시 [프로젝트 : 온라인 쇼핑 플랫폼]

• 요구사항 : 제품 검색 시 2초 이내에 사용자에게 검색 결과 제공
  • 척도 조정 : 품질 요소 = 성능(효율성), 평가 척도 = 검색 속도
  • 측정 : 실제 검색 속도 측정
  • 평가 : 검색 속도가 2초 이내인지 평가

예측적 품질 관리

 그동안 수행해 온 다수의 소프트웨어 프로젝트로부터 프로젝트 데이터베이스를 얻을 수 있다. 프로젝트 데이터베이스는 소프트웨어 개발 과정에서 생성되는 계획, 실행, 유지 관리 등의 모든 데이터를 저장, 관리, 활용할 수 있도록 구성되어있다. 또한 정의된 품질 요소 평가를 위한 데이터도 함께 저장하여 품질 평가에 활용할 수 있다.

 

PMO, Project Management Office의 역할은 전사 차원에서 프로젝트 데이터를 분석하여 조직의 소프트웨어 개발 역량을 위한 활동을 계획해야한다.

 

소프트웨어 품질 요소 이점

소프트웨어의 품질 요소를 알아둔다면 프로젝트의 목표를 설정할 수 있고 평가할 수 있다. 만약 목표가 검색 결과를 빠르게 제공하는 검색 시스템을 개발하는 것이라고 하자. 명확한 품질 평가 척도가 없다면 몇 초 이내를 빠르다고 할 수 있는 지 정의할 수 없을 것이다. 하지만 2초라는 명확한 목표 품질을 제시한다면 2초 이내에 제공 되었으니 빠르다고 판단할 수 있다.

 

이러한 품질 평가 척도는 보고서나 기획서 작성시 신뢰도를 상승시키고, 뚜렷한 목표를 통해 고품질 소프트웨어를 개발할 수 있게 해준다.