품질

- 높은 수준의 SW 품질을 달성하려면 광봄위한 활동이 필요함

테스트

- 품질을 보장하는 가장 일반적인 방법

- 결함을 줄이고 방지하는 것이 제한적인 이유

    - 제품 주기에서 테스트가 너무 늦게 수행됨 - 코드가 개발 단기에 생성 X

    - 테스트는 좁은 차원만 다룸 - 신뢰성 외에 유지보수성, 확장성 등에 향상 X

    - 테스트는 코드 품질만 향상 시킴 - 관련 문서 등 확인 X

#리뷰

- 테스트를 보완하고 개발 초기에 검토할 수 있어 오류를 조기에 발견

- 제품이 변경돠거나 예상치 못한 조건에서 작동하는 데 필요한 품질 확인 가능

 -유지보수성, 재사용성 등과 같은 비기능 품질 요구 사항을 검증하는데 적합

 

품질 보증

- 계획된 품질 수준을 가지고 있음을 보장하는 활동

- 품질 보증 활동

    - 개발사와 협력하여 SW 개발의 적절한 표준과 절차를 정의

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

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

품질 관리

- 품질 계획, 품질 관리, 품질 보증, 검증 및 여러 가지 품질 관련 프로세스를 포함

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

 - 품질을 높이기 위한 활동

    - 측정 : 측정할 수 있는 품질 지표

    - 프로세스 평가 및 개선 : 프로세스 향상을 위한 프로세스 품질 평가 및 개선

 

품질에 대한 다양한 관점

- 관점에 따라 다른 정의 - 사람들마다 달라 명확하지 않음

- 품질에 대한 정의에 따라 품질 관리 활동이 달라짐

품질 관점 1 : 고객 만족

- 사용자 만족도는 제품의 전반적 요소를 기반으로 하며 품질은 그 중 하나

- 사용자가 만족한다고 해서 품질이 높지는 않음 - 다른 품질 요소 무시

품질 관점 2 : 요구 적합성

- 모호하지 않음

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

- 일정 수준 이상의 고급이라는 의미가 없음

    - 요구 사항을 만족하면 좋은 품질이 된다는 것처럼 보일 수 있음

품질 관점 3 : 제품 품질

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

    - 예 ) 카메라의 품질을 결정하는 세 속성 (해상도, 광 감도, 프레임 속도)

 

소프트웨어 품질

- IEEE 정의

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

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

# 요구사항 = 기능 요구 + 품질 요구 사항

 

품질 모델

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

    - 업그레이드, 플렛폼 전환, 단순 운용

소프트웨어의 품질 특성 

- 3가치 차원 존재

- 품질 요소 : 사용자에 의한 외부 관점

- 품질 기준 : 개발자 측면의 내부 관점

- 메트릭 차원 : 품질을 제어 (품질을 측정 가능)

ISO/IEC 9126 품질 모델

- SW가 가질 수 있는 여러 가지 품질 특성을 정의

- ISO에서는 여섯 가지의 품질 특성을 정의

- ISO와 IEEE에서는 품질 속성의 계층을 다르게 정의

SW품질 속성

- 신뢰성 : SW 요구 기능을 명시된 조건 하에 실행하여 정확하고 일관된 결과를 생성하는 능력

- 강인성 : SW요구 기능을 어렵거나 예외적인 환경에서 수행할 능력

- 효율성 : SW요구 기능을 최소의 시간과 자원을 사용하여 원하는 결과를 생성하는 능력

- 상효운용성: SW가 다른 SW와 정보를 교환하는 능력

- 유지보수성: SW가 수리 및 진화될 수 있는 성질

- 테스트 가능성 : SW에 요구된 또는 적용될 수 있는 모든 형식의 평가

    ex) 인스펙션, 동료 검토, 화이트/블랙 박스 테스팅 등

- 이식성: SW가 여러 운영 환경 및 플렛폼에서 실행괼 수 있도록 변형이 가능한 성질

- 재사용성 : SW가 확장이나 커스텀화 없이 유사한 또는 다른 배경에서 사용될 수 있는 성질

- 모듈성 : SW가 모듈 컴포넌트의 통합이나 조정을 쉽게 만드는 성질

SW유형과 품질

SW유형에 따른 품질 특성 및 중요도의 차이

SW유형에 따라 품질에 대한 요구는 매우 다를 수 있다.

품질 관리

- SW프로세스와 품질 표준의지속적인 개선을 목표

- SW 제품이나 아이템이 정해진 요구에 적합하다는 것을 보장하는 데 필요한 계획적이도 체계적인 활동

품질 관리 기능 3가지

품질 보증 조직 - 개발 조직과 별도 조직

- 관리적 활동

개발 조직의 표준화 방법론을 잘 따르도록 하는 것

- 기술적 활동

방법론을 잘 정의하는 것

프로세스와 표준을 정의

- SW품질 보증을 위한 프레임워크를 개발하고 정의할 책임

- 프레임워크 요소

    - SW개발, 품질관리 프로세스 및 방법론 정의

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

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

프로세스와 방법론 정의

- 프로세스 각 단계에 사용될 품질 보증 프로세스를 정의

- 전통적인 프로세스의 품질 보증

 

품질 보증 활동

- 품질 계획

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

    - 목적

    - 관리

    - 표준과 관례

    - 리뷰와 감리

    - 형상 관리

    - 프로세스, 방법론, 도구, 기술

    - 메트릭, 지표

- 품질 제어

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

품질 보증 제어

- 계획이 정확하게 실행되고 있는지 확인하는 것

- 개발자가 품질보증 활동을 수행하도록 도와주는 것

- 품질 관련 데이터를 모아 데이터베이스 사용하여 분석 관리

- 관리자에게 프로세스 개선을 위한 제안을 하고 수용된 제안이 적절히 실현되고 프로세스에 녹아 들었는지 확인

품질 보증을 위한 검토 작업

결과물 검토 방법

- 인스펙션

    - 공식적 검사 회의(워크스루, 동료 검토는 비공식적)

    - 품질 개선과 비용 절감을 위한 기법으로 사용

    - 오류, 변칙, 표준이나 관례의 부적합 리스트와 체크

    - 인스펙션 과정

        - 기술 스텝들로 구성, 6단계로 수행

        - 모든 인스펙션 과정의 책임과 권한은 주재자에게 주어짐

소프트웨어 측정

- 소프트웨어 속성의 객관적이로 정량적인 평가가 필요

- 측정 방법을 표준화 필요

    ex) 싸이클로매틱 복잡도, 알고리즘 계산 복잡도, 빅 오 표현 등

- 소프트웨어 메트릭

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

        - 프로세스 메트릭

        - 프로젝트 메트릭

        - 프로덕트(품질) 메트릭

품질 측정과 메트릭

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

품질 측정의 가치

- 지표의 정의와 사용

    - 지표 : 상대적 의미가 있는 값의 범위

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

- 유사 프로젝트와 시스템을 정량적으로 비교

- 개선의 정량적인 평가

- 기술의 객관적인 평가

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

전통적인 품질 메트릭 분류

요구 메트릭(R)

- 요구의 비 모호성

    - 각 요구사항은 한가지 의미로한 해석되는 비모호성에 근거

- 요구 완전성 메트릭

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

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

    - f함수가 완벽하게 매핑된다면 SRS는 완벽한 것으로 간주

설계 메트릭(D)

- M0 ~ M7 : 모듈

- 화살표 : 모듈 호출

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

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

    - mdc(M) = d + 1

    - d : M이 가진 다이아몬드 수

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

- 선택 복잡도 (S0)

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

- M0 ~ M7의 S0 = 1

    - 모든 단말 노드

- M1 모듈의 복잡도

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

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

- 모듈 설계 복잡도

 

- 통합 복잡도 메트릭 ( 통합 테스트 케이스 수)

    - S1(M) = S0(M)-n + 1 = 11 - 8 + 1 = 4

        n = 모듈의 수

구현 메트릭(C)

- LOC(Line of code) 메트릭

    - 원시 코드 줄을 세는 것

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

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

 

시스템 메트릭(S)

- 신뢰도 메트릭

MTBF = BTTF + MTTR

MTBF(Mean Time Between Failure) : 고장이 수리되어 가동된 후 고장 발생까지의 평균 시간

BTTF(Mean Time To Failure) : 가동되어 고장 발생까지의 평군 시간(고장 복구되지 않는 경우)

MTTR(Mean TIme To Repair) : 수리 평균 시간

AVAIL(가용성) = MTBF / (MTBF + MTTR) = 시스템이 가동될 확률

 

프로세스 개선

- 엔지니어링 프로세스가 경험에 따라 어떤 차이가 있는지 연구하고 모델을 제시

    - 미 국방성의 CMMI

    - ISO의 SPICE

- 소프트웨어 시스템의 품질은 그것을 개발하는데 사용되는 프로세스의 품질에 좌우됨

 

미 국방성의 CMMI

- 미 국방성 지원으로 카네기멜론 대학의 프로세스 성숙도를 위한 프레임워크

    - CMM_SW : SW 개발 프로세스의 성숙도를 다룸

    - CMMI는 SW, 시스템, 프로덕트를 포함하는 세 분야를 통합 평가하는 모델

CMMI 용도

     - 프로세스 성숙도 평가 기준

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

C(capability) : 능력 : 개발 목표(주어진 기간, 정해진 비용, 고품질 등)를 달성할 수 있는 힘

M(Maturity) : 성숙 : 성숙도가 높은조직 : 책임감이 있는 조직으로서 개발 과정에서 객관적이고 정량적인 근거에 따라 프로세스가 측정되고 지속적인 개선이 이루어지는 조직

M(Model): 모델 : 프로세스를 감사하는 의미로 사용, 기준대로 하고 있는지, 그렇지 않은지를 검사

    CMMI는 '수행 지침'이라는 모델을 제시 

I(integration) : 통합 : 여러 가지 프로세스의 기준을 하나로 통합하겠다는 의미

    소프트웨어 개발 생명주기의 각 단계를 통합한 모델이라는 의미

CMMI 모델 단계

LV1. 초보 단계 : 개발 과정이 무질서 상태

LV2. 관리 단계 : 기본 프로세스 절차를 실행

LV3. 정의 단계 : 조직 표준 절차를 확립하고 절차를 수행

LV4. 계량적 관리 : 프로세스 제품의 정량적 품질 측정, 프로세스 목표와 통제 가능

LV5. 최적화 단계 : 프로세스 평가와 피드백 가능, 지속적으로 프로세스 개선

 

ISO9001

 -SPICE(Software Process Improvement and Capability dEtemination)

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

CMMI와 SPICE

- 차이점은 성숙도 레벨과 심사 영역의 구분

- 성숙도 차이

    - CMMI는 레벨 1부터 5까지 5개의 성숙도 수준

    - SPICE는 레벨 0부터 5까지 6개 수준

- 심사 영역

    - CMMI는 하나의 레벨로 평가하는 일차원적인 구조

    - SPICE는 각 프로세스 영역마다 능력에 대한 평가를 별도로 하는 이차원적 구조