Chap 12. 품질

윤희빈·2026년 7월 23일

소프트웨어공학 수업

컴퓨터공학과/소프트웨어공학

목록 보기

11/23

1. 소개: 품질을 높이는 활동

1.1 품질 활동 수준

테스트

제품주기에서 테스트가 너무 늦게 수행되는 경향
테스트는 좁은 차원만 다루고, 주로 코드 품질만 향상시키기 쉬움

리뷰

테스트를 보완하며 개발 초기에 검토 가능 → 오류를 조기에 발견

품질보증(QA)

개발자와 협력해 표준/절차 정의
검토/감사로 업무 모니터링 및 확인
품질 목표 진행 상황을 관리자/이해관계자에게 피드백

품질관리

품질관리: 품질 계획·품질 관리·품질 보증·검증 등 “품질 관련 프로세스 전반”
품질 목표를 설정하고 달성하도록 프로젝트를 관리/통제하는 활동
- 측정, 프로세스 평가 및 개선 포함

1.2 품질 개념

품질에 대하여 어떻게 정의하느냐에 따라서 품질 관리 활동이 달리잔다.

고객 만족

사용자 만족도는 제품 전반 요소 기반이며 품질은 그중 하나

제품 A가 제품 B보다 사용자 요구를 더 많이 충족시킨다면 A가 더 품질이 높다고 볼 수 있다.

단, 다양한 사용자 그룹의 요구를 동시에 충족시키지 못할 수도 있다.

요구 적합성

모호하지 않음
지정된 요구 사항과 디자인을 준수하는 제품이 높은 품질의 제품
일정 수준 이상의 고급이라는 의미가 없음
- 롤렉스와 일반 시계 모두 요구 사항에 적합한다.

제품 품질

여러 속성의 집합이 품질을 결정

디지털 카메라의 품질을 결정하는 3가지 속성 (해상도, 광 감도, 프레임 속도)
이걸 모두 만족할 것이냐, 어느 속성에 중점을 두고 만족할 것이냐

1. 소프트웨어 품질

품질

시스템, 구성요소, 프로세스가 지정된 요구사항을 충족시키는 정도
시스템, 구성요소, 프로세스가 고객/사용자 요구나 기대를 충족시키는 정도

→ “프로세스의 품질이 곧 소프트웨어의 품질이다!”

2. 품질 모델

소프트웨어에 대한 작업 관점이 어디 있느냐에 따라 품질 속성의 관심이 달라짐

품질 특성의 3가지 차원

품질 요소(factor): 사용자 관점(외부)
품질 기준(criteria): 개발자 관점(내부)
메트릭(metric) 차원: 품질을 제어/측정

ISO/IEC 9126

소프트웨어가 가질 수 있는 품질 특성 정의
ISO는 6가지 품질 특성 정의(IEEE/ISO는 계층 정의가 다를 수 있음)

“우리는 iso/iec 25010의 품질 표준 9개를 외워라!
위의 사진의 것은 교재의 내용일 뿐…”

제품 품질 모델: 개발자 관점
품질 사용 모델: 사용자 관점

사용성 → 상호작용성, 이식성→ 유연성, +안전성

기능적합성: 제품 또는 시스템이 특정 조건에서 사용될 때 명시적, 암시적 요구사항을 충족하는 기능을 제공하는 정도

성능효율성: 명시된 조건에서 사용되는 자원의 양에 대한 성능의 정도

호환성: 제품, 시스템 또는 구성요소가 동일한 하드웨어 또는 소프트웨어 환경을 공유하면서 다른 제품, 시스템 또는 구성요소와 정보를 교환하거나 필요한 기능을 수행할 수 있는 정도

상호작용성: 명시된 사용 환경에서 제품이 사용자에 의해 유효성, 효율성 및 만족의 목적을 달성하는 정도

신뢰성: 시스템, 제품 또는 구성요소가 지정된 기간 동안 지정된 조건에서 지정된 기능을 수행하는 정도

보안: 제품 또는 시스템이 권한 유형 및 레벨에 따라 적합한 데이터 접근 수준을 갖도록 정보 및 데이터를 보호하는 정도

유지보수성: 시스템을 개선 및 수정하거나, 환경 및 요구사항의 변화에 적응시키기 위해 제품이나 시스템을 수정할 수 있는 효과와 효율성의 정도

유연성: 시스템, 제품 또는 구성요소를 다른 하드웨어, 소프트웨어, 운영체제 및 새로운 사용 환경으로 이식할 때의 효과성과 효율성 정도

안전성: 제품 또는 시스템이 사람, 재산, 환경에 해를 끼칠 수 있는 위험을 허용 가능한 수준으로 줄이고, 사용 중 사고나 손상을 유발하지 않도록 하는 정도

효과성: 설정된 목표와 제약조건을 얼마나 효과적으로 달성하게 하는지

효율성: 자원을 얼마나 효율적으로 사용할 수 있는지

만족도: 사용자가 소프트웨어 사용에 대해 얼마나 만족하는지, 즉 얼마나 유용하고 요구를 잘 충족시키며 신뢰할 수 있는지, 또한 사용이 얼마나 즐겁고 안전한지

위험 회피성: 소프트웨어가 예측 가능하고 잠재적인 위험을 최소화하는지, 경제적 위험과 SW 사용으로 인한 건강, 안전 위험을 줄이고 환경에 미치는 위험을 줄이는지

맥락 포괄성: 다른 상황이나 환경에서 얼마나 대응할 수 있는지, 다른 상황과 맥락에 얼마나 적응할 수있고 유연하게 확장이나 변경할 수 있는지

소프트웨어의 유형과 품질

소프트웨어 유형에 따른 품질 특성 중요도 차이

어떤 소프트웨어를 만드는냐에 따라 상대적으로 중요한게 다를 수 있다.
차등을 두어야지, 제한된 자원 안에서 품질을 지킬 수 있다.

3 품질 관리(Quality Management)

정의

소프트웨어 제품/아이템이 정해진 요구에 적합함을 보장하기 위한 계획적·체계적 활동
다양한 작업이며 미치는 영향이 크다

기능

품질 관리 기능 3가지
1. 프로세스와 표준의 정의
2. 품질 보증
3. 프로세스 개선

> 성능을 잘 추적해라.
기능만 추적하는게 아니라 성능도 확인해봐야한다.
내 시스템으로 얼만큼의 고객이 어떤 시간 간격으로 접근하는가 → 알맞은 방법을 적용
품질 데이터가 수집될 수 있도록 체계까지 갖추어야 한다.
>

3.1 품질 관리 조직

관리적 활동: 개발 조직이 표준화 방법론을 잘 따르도록 함
기술적 활동: 방법론 자체를 잘 정의

QA팀이 긴밀하게 움직인다.
기술문서: 사용자 메뉴얼, 설계 문서 등등..
조직이 견고한 곳은 기술문서작성자(Technical Writer)가 존재한다.

3.2 프로세스와 표준 정의 내용

개발/품질관리 프로세스 및 방법론 정의
개발 주기 동안 수행할 표준·절차·가이드라인 정의
품질 측정/평가를 위한 메트릭·지표 정의

프로세스와 방법론을 정의

위 과정을 건너뛰고 바이브코딩하면 애자일 프로세스의 철학을 반영할 수 없다. 어디서 어떻게 잘못된것인지 알 수 없기 때문. 전통적이라고해서 나쁘지 않다. 모든 과정을 반드시 거쳐라.

품질 관리 표준과 절차의 정의

메트릭 정의

3.3 품질 관리 활동

품질 계획: 프로젝트 초반, 해당 프로젝트의 품질 계획 작성
품질 제어: 프로젝트 전반, 계획 실행 모니터링 및 필요 시 계획 수정

품질계획

각 프로젝트 초기에 이루어짐.

목적
관리
표준과 관례
리뷰와 감리
형상관리
프로세스, 방법론, 도구 기술
메트릭, 지표

품질보증 계획(IEEE730)

sk 브로드밴드 독거노인 서비스를 감리할 사람은 수업 이후 요청할 것.

품질 보증 계획 (IEEE 730)

품질 제어

계획이 정확히 실행되는지 확인 + 개발자가 QA 활동 수행하도록 지원
품질 데이터 수집/DB로 관리, 프로세스 개선 제안 및 반영 여부 확인

3.4 인스펙션(Inspection)

품질 보증 작업은 주로 결과물의 리뷰로 이루어진다.

테스트나 품질 측정 작업도 품질을 위하여 중요한 작업이지만 상당한 시간과 노력은 결과물의 검토나 검사에 할애된다.

결과물을 리뷰하는 방법: 인스펙션, 워크스루, 동료 검토

품질 보증을 위한 검토 작업
품질 개선과 비용 절감을 위한 기법으로 사용
공통 오류/변칙/표준 부적합을 체크리스트로 점검하는 작업(비용 절감/품질 개선)

인스펙션 관정

모든 인스펙션 과정의 책임과 권한은 인스펙션 주재자 (moderator)에게 있다.

4. 품질 측정(Measurement)

4.1 측정 기본 개념

소프트웨어 측정: 소프트웨어 속성의 객관적·정량적 평가
소프트웨어 메트릭: 표준화된 측정 방법

측정/메트릭의 유용성

요구분석, 설계, 구현, 문서화까지 정량 평가
중요한 부분에 자원 투입, 유사 프로젝트 비교, 개선 효과/기술/프로세스 개선을 객관적으로 평가

4.2 품질 메트릭

아래는 전통적인 품질 척도의 일부를 나타낸 것이다.

전통적인 품질 메트릭

메트릭은 요구 메트릭(R), 설계 메트릭(D), 코드 메트릭(C), 시스템 메트릭(S)로 분류한다.

요구의 비모호성:검토인이 요구에 대하여 동일한 의미적 해석을 하는 요구의 개수 → 즉, 검토인이 한명이 아니라 여러명이라는 뜻.
요구의 완전성: 인풋이 들어오면 아웃풋이 나올 수 있는 조합의 수가 있는데, 그걸 모두 명시를 했는가? →물론 고려안해도 되는 조합은 있지만 그래도 100%면 좋다.
요구의 일관성: 상충되지 말아야한다. → 모호하지 않아야 한다. 동일한 것에 대해 동일해야 한다.
팬 인 : 팬 인이 높다는 것은 부하가 넘쳐서 과부하로 고장날 수 있고, 책임이 과하다는 의미, 변경이 되면 많은 모듈에 영향을 줌 → 분리를 해야하는지 고려해봐야함.
팬 아웃 : 다른 모듈을 호출하는 개수.

(1) 요구 메트릭(R)

비모호성(unambiguity)
요구 완전성 메트릭: SRS가 시스템의 가능한 상태/외부자극을 포함한다는 가정 기반
SRS: 시스템의 모든 가능한 상태와 모든 가능한 외부자극을 포함
f함수가 완벽하게 매핑된다면 SRS는 완벽한 것으로 간주 $f(state, stimulus) -> (state, response)$

(2) 설계 메트릭

M0-M7: 모듈
화살표: 모듈 호출
다이아모든 화살표: 분기 호출
$F_{in}$ : 이 모듈을 호출하는 모듈의 수
$F_{out}$ : 이 모듈이 호출하는모듈의 수

팬 인과 팬 아웃

팬 인이 높다 ↔ 모듈이 많이 사용된다.

팬 아웃이 높다 ↔ 다른 모듈을 많이 호출한다.

모듈 복잡도 mdc(M)

설계 복잡도를 표시한 구조도

mdc(M) = d+1

d: M이 가진 다이아몬드의 수
다이아몬드: 이진 조건의 분기(조건을 체크)
선택 복잡도 S0
- S0(leaf) = 1, 각 단말 노드는 하나의 서브트리
- S0(M) = $\sum^{n}_{i=1} S0(M_i) + mdc(M)$
- M: $M_i(i=1,2,...,n)$ 모듈들을 호출

리프는 수행 경로가 하나 뿐임 → S0= 1
M1는 하위의 복잡도와 자신의 복잡도를 더해서 3
복잡하면 복잡해질 수록 품질 관리가 어려울 수 있다.

M4~M7의 S0 = 1

모두 단말 노드

M1 모듈복잡도

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

M1은 분기가 없기 때문에 mdc값이 1

모듈 설계 복잡도

S0(M) = $N_{dm}+N_{adb}$

$N_{dm}$ : 모듈의 개수

$N_{adb}$ : 선택적 모듈을 호출하는 분기의 수

(3) 구현 메트릭

LOC(코드 라인 수) 메트릭 : 원시 코드의 줄을 세는 것
싸이클로매틱 복잡도: 프로그램을 통과하는 독립된 경로의 개수이며 필요한 테스트의 횟수

(4) 시스템 메트릭(신뢰도)

MTBF = MTTF + MTTR
MTBF(고장 사이 평균시간), MTTF(고장까지 평균시간), MTTR(수리 평균시간)

5. 프로세스 개선(Process Improvement)

엔지니어링 프로세스가 경험에 따라 어떻게 다른지 연구하고 모델 제시
- 미 국방성: CMMI
- ISO: SPICE
소프트웨어 시스템 품질은 “개발 프로세스 품질”에 좌우

5.1 CMMI

프로세스 성숙도 프레임워크
- CMM-SW: 소프트웨어 개발 프로세스의 성숙도를 다룸
- CMMi는 소프트웨어/시스템/프로덕트를 통합 평가하는 모델
용도: 성숙도 평가 기준, 스스로 역량 평가 및 개선 방향 설정

영웅적 개인 : 매우 위험하다.
프로젝트 관리 단계
정의 단계: 전반적인 조직의 체계가 관리가 되도록 많은 게 정의
4단계 : 조직 프로세스의 성과가 나오고, 계량적으로 프로세스를 관리할 수 있다.
5단계: 지속적인 개선이 일어나면서 최적화. 내가 하는 개선이 어떤 문제와 인과관계가 있는지
코딩만 잘하면 되는게 아니라, 인간관계도 잘해야 한다.

5.2 SPICE(ISO 9001)

Software Process Improvement and Capability dEtermination
소프트웨어 프로세스 평가를 위한 국제 표준

LV 5를 한 기업은 극소수다.

CMMI vs SPICE 차이(요지)

성숙도 레벨
- CMMI: 레벨 1~5 (5단계)
- SPICE: 레벨 0~5 (6단계)
심사 구조
- CMMI: 하나의 레벨로 평가하는 1차원 구조
- SPICE: 프로세스 영역마다 능력 평가(2차원 구조)

윤희빈

비니비니히비니의 정리블로그

이전 포스트

Appendix 03. AI들의 조별과제: Agentic AI

다음 포스트