[소프트웨어공학] 품질

소프트웨어 시스템의 품질 <- 프로세스 품질에 영향을 많이 받는다. 

 

1. 소개

프로세스의 성숙도가 높아짐에 따라 품질을 높이는 활동도 많이 도입된다. 

품질을 높이는 활동은 다음과 같은 순서대로 도입된다. 

 

테스트 - 리뷰 - 품질 보증 - 품질 관리 - 결함 방지 

 

->수준 놓은 조직일수록, 이 모든 활동을 포함함 

 

1. 테스트 

- 제품 주기에서 테스트는 굉장히 늦게 수행. 

- 테스트는 좁은 차워만 다룸.

- 테스트는 코드 품질만 향상시킴

 

2. 리뷰

- 테스트를 보완함. 

- 개발 초기에 검토할 수 있어 오류를 조기에 발견함

 

3. 품질보증

- 소프트웨어 제품이 계획된 품질 수준을 가지고 있음을 경영진 및 기타 프로젝트 이해 관계자에게 보장하는 활동

 

- 개발자와 협력 -> 소프트웨어 개발의 적절한 표준과 절차를 정의

- 검토 및 감사를 통해 업무를 모니터링하여 확인

- 품질 목표를 향한 진행 상황에 대해 상급 관리자 및 기타 이해 관계자에게 피드백을 제공

 

4. 품질 관리

- 프로젝트 품질 목표 달성을 위해 공학 및 관리 기술 적용

 

-품질 계획, 품질 제어, 품질 보증, 검증 및 여러 가지 품질 관련 프로세스를 모두 포함함!

- 품질 목표를 설정하고 목표 달성을 위한 프로젝트 실행을 관리 및 통제하기 위한 모든 활동

-> 측정: 프로세스 및 제품의 품질을 측정

-> 프로세스 평가 및 개선: 제품의 품질을 개선하기 위해 프로세슷 품질을 새선

 

품질 개념

품질

-> 관점에 따라 다르게 정의될 수 있음 

-> 정의에 따라 품질 관리 활동이 달라짐. 

 

가장 일반적인 품질의 정의 - 고객 만족, 요구 적합성, 제품 품질

 

사용자 관점: 품질 = 고객 만족

- 제품의 전반적 요소를 기반으로 함. 품질은 그 중 하나

-> 다양한 사용자 그룹 동시 만족 어려움

-> 만족에 큰 영향을 미치는 요소가 부족한 품질을 보상하면 만족할 수 

 

품질 = 요구 적합성

- 요구 사항에 대한 적합성을 품질로 정의

- 가장 대표적인 정의임. 

- 모호하지 않음

- 지정된 요구 사항과 디자인을 준수하는 제품이 높은 품질의 제품이다. 

- 일정 수준 이상이라는 의미가 아님. 일반 생황에서의 '품질'과 다른 의미.

-> 명품 시계나 일반 시계나 시계로서 작동한다는 점에서 모두 요구사항을 만족함. 더

 

- 단지 요구 사항만 맞추면 좋은 품질

- 좋은 제품 기능을 쉽게 파악할 수는 없음. 그러나 제품 수명 주기 중 생산, 구현 단계를 보다 쉽게 관리, 제어 가능

 

-> 품질 목표를 정의하기도 쉽고, 진행 상황 측정, 제어도 용이

 

품질 = 제품 품질

- 여러 속성의 집합.  -> 이들이 품질을 결정 

- 디지털 카메라의 품질은 여러 속성(해상도, 광 감도, 프레임 속도 등)에 의해 결정이 되는 것처럼. 

- 각 속성마다 가중치를 부여해 제품의 품질을 결정 가능 

 

소프트웨어 품질

프로젝트의 시간(비용), 기능과 함께 프로젝트 관리의 3가지 제약요소임 (완전 앞에서 다뤘던 내용) 

 

시간(비용)은 정의된 것 없이 이해 관계자간에 합의하면 되는 것. 

기능도 논쟁의 여지가 없음. 무엇이 기능인지 아닌지? 다툴 필요가 없음 

그러나 품질의 정의에 대해 논쟁이 생길 수 있음 -> 이해 관계자들간에 합의가 필요 

 

IEEE에서 정의한 품질

- 시스템, 구성 요소, 프로세스가 지정된 요구 사항을 충족시키는 정도

- 시스템, 구성 요소, 프로세스가 고객 또는 사용자 요구나 기대를 충족시키는 정도 

=> 요구 사항 준수, 사용자 만족도

=> 품질을 결정하는 두 가지 요소, 프로세스 + 프로덕트를 명시적으로 포함함 

 

-> 요구사항에는 기능 요구 뿐만 아니라 품질요구 사항을 포함. (사용성, 유지보수성 등) 

 

 

2. 품질 모델

품질을 구성하는 여러 속성이 존재함. 모든 속성에 집중하는 건 불가능. 

어느 속성에 관심을 둘것인지?

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

 

 

 

 

소프트웨어 품질의 특성 -> 3가지 차원이 존재 

-> 품질 요소, 품질 기준, 메트릭 

품질 요소 

: 사용자에 의한 외부 관점을 나타냄

 

품질 기준

: 개발자 측면의 내부 관점을 나타냄

 

메트릭

: 품질을 제어하기 위함. 품질 기준별 측정 방법, 스케일 등을 정의하여 측정할 수 있게 함. 

 

여러 품질 모델이 존재함 

그 중 ISO 9126, IEEE 1061 모델.

-> 주특성(품질 요소)는 일치함. 그러나 부특성(품질 기준)은 차이가 존재함!

 

 

품질 속성 

• 신뢰성: 요구된 기능을 명시된 조건 하에 실행 - 정확, 일관성 있는 결과
• 강인성: 요구된 기능을 어렵거나 예외적인 상황에서 수행 능력
• 효율성: 요구된 기능을 최소의 시간과 자원을 사용하여 원하는 결과 생성
• 상호운용성: 다른 소프트웨어와 정보를 교환하는 능력
• 유지보수성: 수리 및 진화될 수 있는 성질 
• 테스트가능성: 요구된 또는 적용될 수 있는 모든 형식의 평가를 허용하는 성질
  • 인스펙션, 동료검토, 화이트박스, 블랙박스 테스팅 등
• 이식성: 여러 운영 환경 및 플랫폼에서 실행될 수 있도록 변형 가능한
• 재사용성: 확장, 커스텀화 없이 유사한 또는 다른 배경에서 사용할 수 있는
• 모듈성: 소프트웨어가 모듈 컴포넌트의 통합이나, 조정을 쉽게 만드는 

 

3. 품질 관리

: 소프트웨어 제품이나 아이템이 정해진 요구에 적합하다는 것을 보장하는 데 필요한 계획적이고 체계적인 활동

 

목표: 소프트웨어 프로세스와 품질 표준의 지속적인 개선 

 

다양한 작업 -> 미치는 영향이 크다. 

 

품질 관리 기능 - 크게 세 가지

프로세스와 표준 정의 / 품질 보증 / 프로세스 개선 

"프레임워크 정의하고, 관리 하고, 개선 하고" 

 

프로세스와 표준 정의 <프레임워크>

- 소프트웨어 개발, 품질 관리 프로세스, 방법론 정의 

- 품질보증 활동을 수행하기 위한 표준, 절차, 가이드라인 정의 

- 품질 측정을 위한 품질 메트릭, 지표 정의 

 

품질 보증 <관리>

- 품질 계획, 품질 제어 활동 

- 품질 계획: 목적, 표준, 인스펙션, 형상관리, 메트릭 등

- 품질 제어: 교육, 품질 데이터 수집

- 리뷰 

 

프로세스 개선 <개선>

- 메트릭, 데이터 수집 방법 정의

- 프로세스 측정을 위한 데이터 수집

- 개선 조치 제안 

 

 

누가? - 품질 보증 조직이 

품질 보증 조직 

- 품질 보증은 sw 개발 조직과 별도로 수행 <- 객관적인 시각으로 평가, 관리 

- 기술적 활동, 관리적 활동이 모두 존재 

- 관리적 활동: 개발 조직의 표준화 방법론을 잘 따르도록

- 기술적 활동: 방법론을 잘 정의하는 것 

 

프로세스와 표준을 정의 

- 소프트웨어 개발 및 품질 관리에 대한 프로세스 및 방법론 정의

- 개발 주기 동안 품질보증 작업을 수행할 표준, 절차, 가이드라인 정의 

- 품질 측정과 평가를 위한 품질 메트릭, 지표 정의 

 

프로세스마다 품질 보증 활동이 다르다. 

전통적인 프로세스에서 필요한 품질 보증 활동은 다음과 같다. 

(전통적인 프로세스: 요구 분석 - 설계 - 구현 - 테스트 - 유지보수)

 

품질 보증 활동

-> 계획하고, 제어하고 

 

1. 품질 계획

: 프로젝트 초반에 이루어지는 활동. 특정 프로젝트에 대한 품질 계획을 작성. 

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

2. 품질 제어 

: 프로젝트 전반에 걸쳐. 품질 계획의 실행을 모니터링하고 현실적으로 수정이 필요하면 품질 계획을 수정 

-계획이 정확하게 실행 중? 개발자가 품질 보증 활동을 수행하도록 도와주는 것.

-품질 관련 데이터 모아 DB 사용해 관리.

-관리자에게 프로세스 개선 제안 

 

 

인스펙션

품질 보증 작업 -> 결과물에 대해 살펴본다는 것 

 

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

 

인스펙션

-> 품질 개선과 비용 절감을 위한 기법 

 

 

4. 품질 측정

소프트웨어 측정

: 소프트웨어 속성의 객관적이고 정량적인 평가 

 

소프트웨어 메트릭

- 표준화된 소프트웨어 측정 방법

- 프로세스 메트릭 

- 프로젝트 메트릭

- 프로덕트 메트릭 - 품질 메트릭, 크기 메트릭 

 

 

품질 측정의 유용성

품질 측정

: 요구분석, 설계, 구현, 문서화가 포함된 소프트웨어의 정량적인 평가 

 

정량적인 평가를 왜 하는지?

- 지표의 정의와 사용 -> 상대적의미가 존재 - 문제가 되는 부분을 지적 가능

- 중요한 부분에 자원을 투입

- 유사 프로젝트와 정량적 비교

- 개선의 정량적인 평가 

- 기술의 객관적인 평가 

- 프로세스 개선의 객관적인 평가 

 

-> 소프트웨어를 수준별로 평가할 수 있다. 

 

전통적인 품질 메트릭 

요구 메트릭(R), 설계 메트릭(D), 코드 메트릭(C), 시스템 메트릭(S)

-> 이들로 요구 명세, 설계, 코드, 시스템의 품질 측면을 측정 

 

요구 메트릭

요구의 비모호성 메트릭- 소프트웨어 요구 명세서에 기술된 각 요구 사항이 여러 사지로 해석되지 않고 한 가지 의미로만 해석된다. 

-> 여러 사람이 요구 명세를 검토 

-> 모드 고유한 한 가지 방법으로만 해석하는 요구의 비율

 

요구 완전성 메트릭 - 요구 명세서에 기술된 시스템의 상태와 시스템에 대한 외부자극이 완전하다는 가정에 근거. 

SRS - > 시스템의 모든 가능한 상태와 모든 가능한 외부자극을 포함. 

시스템 -> 상태 변환 머신으로 보고 -> 상태과 자극을 상태와 생성된 반응으로 매핑. 

 

어떤 상태에서 어떤 자극을 주니 -> 어떤 상태로 어떤 반응과 함께 변화됨

 

이 매핑함수 f가 완벽 매핑? SRS 완벽

 

 

설계 메트릭

 

 

M0~M7: module

화살표: 모듈 호출 

다이아몬드 화살표: 분기 호출

 

모듈 설계 복잡도, mdc(M)

: 모듈을 서브루틴 모듈로 통합하기 위해 필요한 통합 테스트 횟수 

 

mdc(M) = d + 1

 

d: M이 가진 다이아몬드의 수. 

다이아몬드: 이진 조건의 분기 

 

다이아몬드 -> 선택적 호출

다이아몬드 하나 아래 A B 모듈이 있다면 

1. A를 호출하고 선택적으로 B를 호출하는 경우 - (A-B), (A-) 2번

2. A나 B를 선택적으로 호출 - (A-), (B-) 2번

3. A를 선택적으로 호출하고 B를 호출 - (A-B), (-B) 번 

-> 다이아몬드 1개에 2번의 테스트 필요 

 

만약 호출 조건이 이진 조건이 아니라 N개의 조건이라면 N-1개의 이진 조건으로 대체 

-> mdc = N-1 +1 = N 

 

 

설계 복잡도(s0)

: 구조도에서 모듈 M을 루트로 할 때 서브트리 개수 

 

s0(leaf) = 1. 각 단말 노드는 하나의 서브트리 

s0(M) = sigma(i=1~n) S0(Mi) + mdc(M)

 

자식노드들의 s0 다 더하고 본인의 mdc 값 

 

일반식

s0(M) = Ndm + Nadb

 

Ndm: 모듈의 개수

Nadm: 선택적 모듈을 호출하는 분기의수 

 

통합 복잡도 메트릭

- 계층적 모듈 구조나 구조도 모듈을 통합하기 위해 필요한 통합 테스트케이스 최소 개수 

 

s1(M) = s0(M) - n + 1 

n: 모듈의 개수 

 

이 값만큼의 통합 테스트가 필요하다. 

 

 

 

구현 메트릭

LOC 메트릭

: 원시코드의 줄을 세는 것 

싸이클로매틱 복잡도 메트릭

프로그램을 통과하는 독립된 경로의 개수 - 필요한 테스트 횟수 

 

 

 

시스템 메트릭

신뢰도 메트릭

- MTBF = MTTF + MTTR

 

MTBF : 고장 사이의 평균 시간. mean time between failure

MTTF : 고장까지의 평균 시간. mean time to failure

MTTR : 수리 평균 시간. mean tiem to repair

 

5. 프로세스 개선

엔저니어링 프로세스가 경험에 따라 어떤 차이가 있는지?

이를 연구하고 모델을 제시한 두 가지

 

미 국방성 - CMU SEI의 CMMi

ISO의 SPICE

 

 

CMMi

프로세스 성숙도를 위한 프레임워크 

- CMM-SW: 소프트웨어 개발 프로세스의 성숙도를 다룸

- CMMi: 소프트웨어, 시스템, 프로덕트를 포함하는 세 분야를 통합 평가하는 모델 

 

어디에 쓰나?

- 어떤 점이 부족, 강한지 발견하여 성숙도 평가 기준

- 능력을 스스로 평가하고 프로세스 개선의 방향을 설정 

 

5가지 레벨이 있음 

위로 갈수록 생산성이 좋은 조직. 아래는 리스크가 많은 조직 

1 initial 초보 - 개인, 혼자하는 수준, 아무것도 ㄴ

2 managed 관리 - 프로젝트 관리를 함

3 defined 정의 - 개발 프로세스사 온전히 지켜짐 

4 quanitatively managed 계량적 관리 -  정량적으로 측정이 가능함. 품질 

5 opimizing 최적  - 정략적인 측정을 토대로 새로운 방법을 적용하여 개선해 나감 

 

ISO 9001 - SPICE

Software precess improvement and capability dEtermination

소프트웨어 프로세스 평가를 위한 국제 표준 

- 분야별로 6단계로 나눔

0 Incomplete 미완성

1 Preformed 실행

2 Managed 관리

3 Estabilishd 확립

4 Predicatable 예측

6 Optimizing 최적 

 

- 고객-공급자 프로세스 / 엔지니어링 프로세스 / 지원 프로세스 / 관리 프로세스 / 조직 프로세스 

 

목적

- 개발기관 스스로 평가하여 프로세스 개선

- 기관에서 정한 조건 만족하는지 스스로 평가 

- 계약을 맺기 위해 프로세스 평가 

 

프로세스 영역

고객-공급자 프로세스: 발주, 공급자 선정, 고객인수, 요구사항 도출, 운영

엔지니어링 프로세스: 시스템 개발

지원 프로세스: 문서화, 형상관리, 품질 보증, 검토 등

관리 프로세스: 프로젝트 관리, 품질관리, 위험 관리 등

조직 프로세스: 프로세스 정의, 심사, 개선 인력관리 등

 

CMMI vs. SPICE

차이점

- 성숙도 레벨

(1~5 5레벨 / 0~5 6레벨) 

- 심사 영역의 구분 

(하나의 레벨로 평가, 일차원적 / 각 프로세스 영역마다 능역에 대한 평가를 별도로, 이차원적 구조)