[소프트웨어공학] - 품질

1. 품질 높이는 방법

소프트웨어 품질을 높이기 위해서는 테스트, 리뷰, 품질 보증(QA)과 같은 활동들이 필요하다.
 

1.1. 테스트

테스트는 소프트웨어 동작을 실행하여 오류를 발견하고 코드 품질을 향상시키는 활동이다. 하지만 이러한 테스트에는 다음과 같은 한계가 존재한다.

• 제품 주기에서 비교적 늦은 시점에 수행됨
• 좁은 차원의 품질만 검증 가능함
• 주로 코드 품질 향상에 집중됨

따라서 테스트만으로 전체 소프트웨어 품질을 완전히 보장하기는 어렵다.

1.2. 리뷰

리뷰는 테스트를 보완하기 위한 활동으로, 개발 초기 단계에서 설계나 문서를 검토하여 오류를 조기에 발견할 수 있다는 장점이 있다.
 
즉, 실제 실행 이전에 발견할 수 있으므로 수정 비용을 줄이는 데 도움이 된다.

1.3. 품질 보증

품질 보증은 개발자와 협력하여 소프트웨어 개발에 필요한 표준과 절차를 정의하고, 이를 지속적으로 관리하는 활동이다. 품질 보증에서는 다음과 같은 활동을 수행한다.

• 소프트웨어 개발 표준과 절차 정의
• 검토 및 감사를 통한 업무 모니터링
• 품질 목표 달성 여부에 대한 피드백 제공

이를 통해 프로젝트 전반의 품질 수준을 지속적으로 유지하고 개선할 수 있다.
 
소프트웨어 품질 역시 앞서 정리한 프로세스처럼 체계적인 관리가 필요하다. 이를 품질 관리라고하며, 품질 계획, 품질 관리, 품질 포증, 검증 등 다양한 품질 관련 프로세스를 포함한다.
 
품질 관리는 품질 목표를 설정하고, 목표 달성을 위해 프로젝트의 수행 과정을 지속적으로 관리하고 통제하는 모든 행동을 의미한다. 대표적인 활동은 다음과 같다.

• 측정을 통한 품질 수준 확인
• 프로세스 평가 및 개선
• 품질 기준 준수 여부 검토
• 품질 목표 달성을 위한 지속적인 관리

---

2. 품질

그렇다면 소프트웨어에서의 품질의 개념은 무엇일까?
 
품질에 대해서는 다양한 관점이 존재한다. 따라서 관점에 따라 품질의 정의도 달라질 수 있으며, 품질을 어떻게 정의하느냐에 따라 품질 관리 활동 역시 달라진다.
 
그중 고객 만족은 제품의 전반적인 요소들을 기반으로 결정되며, 품질은 이러한 고객 만족을 구성하는 중요한 요소 중 하나라고 볼 수 있다.

2.1. 소프트웨어 품질

소프트웨어에서의 품질은 시스템, 구성 요소, 프로세스가 지정된 요구 사항을 충족하는지를 의미한다. 또한 사용자의 요구상항과 기대를 만족시키는 정도 역시 소프트웨어 품질을 판단하는 중요한 기준이 된다.

2.2. 품질 모델

소프트웨어 품질은 어떤 관점에서 시스템을 바라보느냐에 따라 중요하게 여겨지는 품질 속성이 달라진다. 대표적으로 다음과 같은 품질 모델이 존재한다.

• 프로덕트 개정: 소프트웨어를 수정하고 개선하는 관점의 품질 속성이다.
  • 유지 보수성, 융통성, 테스트용이성
• 프로덕트 전환: 소프트웨어를 다른 환경으로 이전하거나 재사용하는 관점의 품질 속성이다.
  • 이식성, 재사용성, 상호운용성
• 프로덕트 운용: 실제 소프트웨어를 운영하는 과정에서 중요한 품질 속성이다.
  • 정확성, 신뢰성, 효율성, 통합성, 사용성

품질 모델을 정의하는 대표적인 표준으로는 ISO/IEC 9126이 있다. ISO/IEC 9126은 소프트웨어가 가져야 하는 여러 품질 특성을 정의한 국제 표준이다.
 
ISO에서는 소프트웨어 품질을 여섯 가지 품질 특성으로 구분하여 정의한다. 또한 IEEE에서도 소프트웨어 품질 모델을 정의하고 있는데, ISO와는 품질 속성을 분류하는 계층 구조와 관점에서 차이가 존재한다.

 

2.3. 품질 특성

소프트웨어 품질의 특성은 다음과 같이 세 가지 차원으로 구분할 수 있다.

• 품질 요소(Factor): 사용자가 인식하는 외부 관점의 품질 특성
• 품질 기준(criteria): 개발자 관점에서 내부 품질을 평가하기 위한 기준
• 메트릭 차원: 품질 요소와 기준을 정량적으로 측정하고 제어하기 위한 척도

2.4. 품질 속성

품질에는 다음과 같이 여러 가지 속성이 존재한다.

• 신뢰성(Reliability): 소프트웨어에 요구된 기능을 명시된 조건 하에서 실행하여 정확하고 일관된 결과를 생성하는 능력
• 강인성(Robustness): 소프트웨어에 예외적이거나 어려운 환경에서도 정상적으로 동작할 수 있는 능력
• 효율성(Efficiency): 소프트웨어에 최소한의 시간과 자원을 사용하여 원하는 결과를 생성하는 능력
• 상호운용성(Interroperablilty): 소프트웨어가 다른 소프트웨어와 정보를 교환하고 함께 동작할 수 있는 능력
• 유지보수성(Maintainability): 소프트웨어를 수정, 개선, 확장하기 쉬운 성질
• 테스트 가능성: 소프트웨어에 대해 다양한 방식의 테스트와 평가를 수행할 수 있는 성질
  • ex) 인스펙션, 동료검토, 화이트박스 테스팅, 블랙박스 테스팅 등
• 이식성(Portability): 소프트웨어가 여러 운영 환경 및 플랫폼에서 실행될 수 있도록 변형이 가능한 성질
• 재사용성(Reusability): 소프트웨어가 큰 수정 없이 유사하거나 다른 환경에서도 다시 사용될 수 있는 성질
• 모듈성(Modularity): 소프트웨어가 독립적인 모듈 단위로 구성하여 통합과 수정이 용이하도록 만드는 성질

---

3. 품질관리

품질 관리는 소프트웨어 제품이나 아니템이 정해진 요구사항에 적합하다는 것을 보장하기 위해 수행하는 계획적이고 체계적인 활동이다. 품질 관리에는 다양한 작업이 포함되며, 이러한 활동들은 소프트웨어의 전반적인 품질 향상에 큰 영향을 미친다.
 
이러한 품질 관리의 기능은 다음과 같다.

• 프로세스와 표준 정의: 소프트웨어 개발과 품질 과닐르 위한 프로세스와 표준을 정의하는 활동
  • 소프트웨어 개발 프로세스와 방법론 정의
  • 품질 보증 활동 수행을 위한 표준 절차 정의
  • 가이드라인 및 프레임워크 정의
• 품질 보증: 품질 목표를 달성하기 위해 품질 관련 활동을 수행하고 관리하는 과정
  
  • 품질 계획 수립(목표, 표준, 인스펙션, 형상 관리, 메트릭 등)
  • 품질 제어 수행(교육, 품질 데이터 수집 등)
  • 리뷰 및 감사
• 프로세스 개선: 현재 프로세스를 측정하고 개선하기 위한 활동
  • 메트릭, 데이터 수집 방법 등 정의,
  • 프로세스 측정을 위한 데이터 수집,
  • 개선 조치 제안,
  • 지표 계산

+) 품질 보증 조직
소프트웨어 품질을 보증하기 위해 품질 보증(QA)을 담당하는 조직이 존재한다. 이러한 품질 보증 조직의 활동은 크게 관리적 활동과 기술적 활동으로 구분할 수 있다.

• 관리적 활동: 개발 조직이 정해진 표준과 방법론, 절차를 올바를게 준수하도록 관리하는 활동
• 기술적 활동: 소프트웨어 품질 향상을 위한 방법론, 표준, 측정 기법 등을 정의하고 개선하는 활동

즉, 관리적 활동은 프로세스 준수 여부에 초점을 두고, 기술적 활동을 품질 향상을 위한 기술적 기준과 방법을 마련하는 데 초점을 둔다.
 
++) 품질 보증 활동
품질을 보증하기 위한 대표적인 활동은 다음 두 가지가 존재한다.

• 품질 계획: 프로젝트 초반에 이루어지는 활동으로 특정 프로젝트에 필요한 품질 목표와 절차, 표준 등을 정의하고 품질 계획을 수립하는 과정
• 품질 제어: 프로젝트 전반에 걸쳐 이루어지는 활동으로, 품질 계획이 제대로 수행되고 있는지 모니터링하며 필요에 따라 개선 및 수정 작업을 수행하는 과정

3.1. 품질 보증을 위한 검토작업 - 인스펙션

품질 보증을 하기 위한 검토 작업은 소프트웨어 개발 단계에 따라 다음과 같이 구분할 수 있다.

• 설계 품질
  • 명세와 설계 단계(요구 분석 및 계획, 설계)에 대한 품질을 의미한다.
  • 요구사항 검토, 예비 검토(PDR), 주요 설계 검토(CDR) 등을 통해 수행된다.
• 설치 품질
  • 구현 및 통합 시험 단계에서의 품질을 의미한다.
  • 시험(Test) 및 완료 검토를 통해 품질을 확인한다.
• 운용 품질
  • 소프트웨어 릴리스 이후 운영 단계에서의 품질을 의미한다.
  • 기능 검토와 물리적 검토 등을 통해 이루어진다.

대표적인 방법으로 인스펙션, 워크스루, 동료 검토 등이 존재한다.
 
인스펙션은 품질 보증을 위한 대표적인 검토 활동으로, 품질 향상과 비용 절감을 위한 기법으로 사용된다.
 
인스펙션은 소프트웨어 산출물을 대상으로 일반적인 오류, 변칙 사항, 표준 및 관례 위반 여부 등을 체크리스트 기반으로 검토하는 작업으로, 다음과 같이 진행된다.

1. 계획
2. 사전 교육
3. 준비
4. 인스펙션 회의
5. 수정
6. 후속조치

이때, 수정 단계에서 추가적인 수정 사항이 발견되면 다시 계획 단계로 돌아가 인스펙션 과정을 반복하게 된다.

---

4. 품질 측정

마지막으로 앞서 관리하고 보증한 소프트웨어 품질이 실제로 적절한 수준인지 측정하는 방법에 대해 정리해 보려고 한다. 품질 측정 방법은 다음과 같이 크게 두 가지로 구분할 수 있다.

• 소프트웨어 측정: 소프트웨어 속성과 특성을 객관적이고 정량적으로 평가하는 활동
• 소프트웨어 메트릭: 소프트웨어 품질을 측정하기 위해 사용하는 표준화된 측정 기준 및 방법

4.1. 품질 측정과 메트릭 유용성

품질 측정과 메트릭은 요구분석, 설계, 구현, 문서화 등 소프트웨어 개발 과정에서 만들어지는 산출물을 정량적으로 평가하기 위한 방법이다. 즉, 품질이 좋다/나쁘다를 감으로 판단하는 것이 아닌 수치와 기준을 통해 객관적으로 판단하는 것이다.
 
이때 지표는 상대적인 의미를 가지는 값의 범위를 의미한다. 예를 들면 코드 복잡도가 일정 기준보다 높다면 유지보수성이 낮을 가능성이 있다고 판단할 수 있다.
 
품질 측정과 메트릭은 다음과 같은 점에서 유용하다.

• 중요한 부분에 자원을 집중적으로 투입 가능하다.
• 유사한 프로젝트나 시스템을 정량적으로 비교할 수 있다.
• 개선 결과를 수치로 평가할 수 있다.
• 특정 기술의 효과를 객관적으로 평가할 수 있다.
• 프로세스 개선 효과를 객관적으로 확인할 수 있다.

즉, 품질 측정은 소프트웨어 품질을 개관적으로 관리하기 위한 기준이며, 메트릭은 그 품질을 실제로 측정하기 위한 구체적인 방법으로 볼 수 있다.

4.2. 전통적인 품질 메트릭

전통적인 품질 메트릭은 소프트웨어 개발 산출물을 단계별로 평가하기 위한 측정 기준이다. 대표적으로 다음과 같은 메트릭이 존재한다.

• 요구 메트릭: 요구사항 명세서가 명확하고 완전한지 평가
• 구현 메트릭: 실제 코드의 규모나 복잡도를 평가
• 시스템 메트릭: 완성된 시스템의 신뢰도 등을 평가

4.2.1. 요구 메트릭

요구 메트릭은 요구사항 명세서, 즉 SRS(Software Requirements Specitifcation)의 품질을 평가하기 위한 메트릭이다.
 
요구사항은 개발의 출발점이기 때문에, 요구사항이 모호하거나 빠져 있으면 이후 설계, 구현, 테스트 과정 전체에 문제가 발생할 수 있다.
 
요구 메트릭에서 중요한 기준은 다음과 같다.

• 요구의 비모호성
  • 요구사항이 여러 의미로 해석되지 않고 명확하게 작성되어 있는지를 평가한다.
  • ex) "시트템은 빠르게 응답해야 한다"는 요구사항 모호, "시스템은 사용자의 요청에 대해 평균 2초 이내에 응답해야 한다"는 요구사항 명확
• 요구 완전성 메트릭
  • 요구 명세서가 시스템의 가능한 상태와 외부 자극을 충분히 포함하고 있는지를 평가
  • SRS가 시스템의 모든 가능한 상태와 모든 가능한 외부자극을 포함해야 한다. 즉, 시스템이 어떤 상황에서 어떤 입력을 받았을 때 어떻게 반응해야하는지 빠짐없이 정의되어야 한다.
  • 다음과 같은 f 함수가 완벽하게 매핑된다면 해당 SRS는 완벽한 것으로 간주한다.
    • f(state, stimulus) > (state, response)

4.2.2. 설계 메트릭과 모듈 설계 복잡도

설계 메트릭은 다음 그림을 통해 정리해 보려고 한다.

그림에 대해서 설명하면 다음과 같다.

• M0 ~ M7: 모듈
• 화살표: 모듈 호출 관계
• 다이아몬드 화살표: 조건 분기 호출
• mdc(M): 모듈 설계 복잡도
  • mdc(M) = d + 1
  • d: M이 가진 다이아몬드의 수
• S0: 선택 복잡도
  
  • S0(leaf) = 1, 각 단말 노드는 하나의 서브트리
  • S0(M) = ∑ S0​(child)  + mdc(M)

따라서 위의 그림에서 M4~M7의 S0 = 1이며, 모두 단말 노드에 해당한다.
 
이때, M1의 모듈 복잡도는 다음과 같이 표현할 수 있다.

• S0(M1) = S0(M4) + S0(M5) + mdc(M1) = 1 + 1 + 1 = 3

4.2.3. 구현 메트릭

구현 메트릭은 실제 작성된 코드의 품질을 평가하기 위한 메트릭이다. 대표적인 구현 메트릭은 다음과 같다.

• LOC(Line of Code)메트릭
  • 원시 코드의 줄 수를 세는 방식으로 코드의 규모를 간단하게 파악할 수 있다는 장점이 있다.
  • 코드 줄 수가 많다고 무조건 품질이 낮거나 기능이 많은 것이 아니므로 단독으로 품질 판단 요소로 이용하기에는 한계가 있다.
• 싸이클로매틱 복잡도 메트릭
  • 프로그램을 통과하는 독립적인 경로의 개수를 측정하는 케트릭이다.
  • 조건이나 반복문이 많아질수록 코드의 가능한 실행 경로가 늘어나고, 그만큼 테스트해야 할 경우의 수도 증가한다.
  • 따라서 복잡도가 높다는 것은 코드가 복잡하고 테스트하기 어려울 가능성이 높다는 의미가 된다.

4.2.4. 시스템 메트릭

시스템 메트릭은 완성된 시스템 품질을 평가하기 위한 메트릭이다.
 
대표적으로는 신뢰도 메트릭이 존재한다. 이 신뢰도 메트릭에서는 다음과 같은 개념이 중요하다.

• MTBF(Mean Time Beteween Failure): 고장 사이의 평균 시간
• MTTF(Mean Time To Failure): 고장까지의 평균 시간
• MTTR(Mean Time To Repair): 수리 평균 시간

위 세 요소에 대한 관계는 다음과 같이 표현된다.

• MTBF = MTTF +  MTTR

즉, 시스템이 고장 없이 동작하는 시간과 고장이 발생한 후 복구하는 시간을 함께 고려하여 시스템의 신뢰도를 측정한다.
 
MTBF가 클수록 시스템이 고장 없이 오래 동작한다는 의미이므로 신뢰도가 높다고 볼 수 있다. 반대로 MTTR이 크면 고장 복구에 오랜 시간이 걸린다는 뜻으로, 운영 품질이 낮아질 수 있다.