1.1 품질에 관한 대중적인 관점

품질에 관한 일반적인 관점은 무형의 특성을 가지고 있다는 것이다.
품질에 대해서 거론되고, 느끼고, 심판할 수는 있지만 그 무게를 잰다거나 측정할 수 없다.
품질이란 것을 보기 전까지는 알 수 없다.
또한 품질을 바라보는 관점이 품질은 고급스럽고, 우수하며, 맛이 좋다라고 보는 것이다.
비싸고 정교하며 보다 복잡한 제품들이 높은 수준의 품질을 가지고 있다고 생각한다.
결과적으로 비싼 제품이 품질이 높다고들 생각하는 것이다.

1.2 품질을 바라보는 전문가의 관점

산업에서는 대중적인 관점에서 어긋난 품질의 개념과 막연함은 품질 개선에 전혀 도움을 주지 않는다.
Grosby (1979)는 품질을 '요구사항의 준수'라 정의하였고, Juran과 Gryna (1970)는 '사용목적의 적합성'이라 정의하였다.

'요구사항의 준수'는 요구사항이 오해 없이 명백하게 정의되어야 함을 내포하고 있다. 그런 다음 개발이나 생산 단계에서 그러한 요구사항들의 준수를 확인하기위해 규칙적으로 측정하는 활동들이 행해진다. 요구사항을 준수하지 않는 것은 곳 결함이며, '품질의 부재'라고 할 수 있다.
예를 들어, 리무진이 리무진의 모든 요구사항을 만족한다면, 이 차는 Quality Car라고 할 수 있다.
만약 티코가 티코의 모든 요구사항을 만족한다면, 이 티코 역시 Quality Car라고 할 수 있다.
그러나 리무진과 티코는 매우 다른 스타일, 성능, 경제성을 가지고 있다. 하지만 이 두 차가 각기 자신만의 표준을 준수하고 있다면 이 두 차 모두 Quality Car라고 할 수 있는 것이다.

'사용목적의 적합성'이란 정의는 어떤 제품이나 서비스가 고객의 사용 목적에 적합한가를 포함하고 있는 고객의 요구사항과 기대를 고려한다. 다른 고객들이 각자 다른 방법으로 제품을 사용하기 때문에 제품은 사용목적의 적합성의 다양한 요소를 지니고 있다. Juran은 이러한 요소들 각자가 품질 특성이며 이러한 특성들은 사용목적의 적합성의 매개변수로 구분되어질 수 있다고 하였다. 가장 중요한 두 매개변수가 바로 '디자인의 품질'과 '적합성의 품질'이다.
디자인의 품질은 제품의 등급이나 모델로 잘 알려져 있다. 이는 곧 구매력의 범위와 관련되어 있다. 등급의 차이는 의도되고 디자인된 차이점의 결과로써 차를 다시한번 예로 들자면, 모든 자동차는 사용자에게 운송이라는 서비스를 제공해주지만 이러한 차의 모델에 따라 크기, 안락함, 성능, 스타일, 경제성, 그리고 상태가 다르다.
반대로 적합성의 품질은 제품이 디자인을 준수하는 정도이다.
다시 말해, 디자인의 품질은 요구사항과 명세의 결정으로 여겨질 수 있고, 적합성의 품질은 요구사항의 준수라고 할 수 있다.

이런면에서 '요구사항의 준수'나 '사용목적의 적합성'은 비슷한 정의를 가지나, 다른 점이 있다면 사용목적의 적합성이란 개념은 소비자의 요구사항과 기대를 위한 보다 더 확실한 역할을 함축하고 있다는 것이다.

1.3 소프트웨어 품질이란?

상품 품질의 관점으로 보자면 '버그'가 없다라고 할 수 있다. 이 말인 즉슨, 만약 소프트웨어가 너무 많은 기능적 결함을 가지고 있다면 기본적인 기능조차 만족하는 요구사항을 만족할 수 없으므로, 품질이란 '요구사항의 준수'라고 할 수 있다.
이러한 정의는 결함율(예를 들어, 소스코드 백만줄 당 결함의 수 또는 단위), 신뢰성(예를 들어, 작업 n시간 당 실패 갯수, 실패한 평균 시간 또는 특정 시간 동안 실패하지 않을 확률)으로 표현할 수 있다.

고객 요구사항은 설문 조사를 통하여 '만족', '불만족'을 %로 표현할 수 있는데 IBM은 이를 CUPRIMDSO (Capability[functionality], usability, performance, reliability, installability, maintainability, documentation/information, service, and overall)의 레벨로써 측정하고, HP는 FURPS(functionality, usability, relability, performance, and serviceability)로 측정한다.

전반적인 고객의 만족도와 다양한 품질 특성(Quality Attributes)를 상승시키기 위해서는 품질 특성이 계획(Planning) 및 디자인 단계에서 고려되어야 한다. 하지만 품질 특성이 서로 다른 품질 특성에 영향을 끼칠 수 있다. 예를 들어, 소프트웨어의 높은 기능적 복잡도는 유지보수성을 달성하기 어렵게 만든다. 소프트웨어의 유형이나 고객에 따라 다른 품질 속성의 가중치가 부여된다. 예를들어 복잡한 네트워크나 실시간 처리를 다루는 고객은 성능이나 신뢰성에 가장 높은 가중치를 줄 수 있지만, 독립 시스템이나 간단한 작업을 다루는 고객의 경우 편의성이나 설치, 그리고 문서화에 가장 높은 가중치를 줄 수 있다. 그러므로 다양한 고객이 사용하는 소프트웨어의 다양한 품질 속성을 위한 목표를 설정하기 위해서 고객의 요구사항을 만족하기란 쉽지 않다.
모든 소프트웨어의 결함의 15% 이상이 요구사항의 오류로부터 비롯된다. 개발 프로세스는 요구사항 품질이 저품질의 소프트웨어를 생산한다고 생각하지 않는다.

또다른 소프트웨어 품질을 바라보는 관점은, 프로세스 품질과 최종 산출물 품질이다. 고객의 요구사항으로부터 소프트웨어 상품의 완성까지 개발 프로세스는 복잡하고 종종 몇 개의 단계를 포함하고 각각 피드백을 할 수 있다. 각 단계에서 중간 산출물이 다음 단계를 위해 생산되며, 다음 단계에서 이러한 중간 산출물을 받는다. 이 때, 중간 산출물은 각각 최종 산출물의 품질에 영향을 줄 수 있는 품질 속성을 갖는다.

흥미롭게도 우리가 외부 고객, 그리고 개발 절차의 다음 단계를 위한 내부 고객까지 포함한 품질의 정의로 고객의 개념을 확장시키면, 프로세스 품질 역시 이 정의에 적용될 수 있다. 만약 개발 프로세스의 각 단계에서 다음 단계의 고객을 위한 요구사항을 만족한다면 최종 산출물 역시 특정 요구사항들을 만족할 것이라고 생각하지만 이는 현실을 너무 단순화한 것이다. 왜냐하면 개발 프로세스의 각 단계에서 매우 다양한 요소들이 존재하며, 이는 각 단계들의 요구사항을 만족하는 능력에 영향을 줄 것이다. 개발 중에 품질을 향상시키기위해서는 개발 프로세스 모델이 필요하며, 우리는 그러한 프로세스 안에서 일정한 방법이나 접근법등을 선택하고 배치할 필요가 있다. 또한 적절한 도구와 기술들을 사용해야 한다. 우리는 개발 프로세스와 그에 속하는 단계의 특성들과 매개변수들의 측정이 필요할 뿐만 아니라, 개발 프로세스가 상품의 품질 목표들을 향해 제어되고 이동하고 있다는 확신을 심어주기 위한 측정지표(metrics)과 모델이 필요하다.

1.4 전체 품질 관리(TQM: Total Quality Management)

전체 품질 관리란 용어는 원래 1985년 Naval Air Systems Command에서 자신의 품질 향상을 위한 일본식 관리 기법을 표현하기 위해 만들어 졌다. 이 용어는 많은 뜻으로 해석될 수 있으나 일반적으로 품질과 고객의 만족을 관계지음으로써 지속적인 성공을 달성하기위한 관리 스타일이라고 표현한다. 이런 접근법의 기반은 조직의 모든 구성원들이 프로세스와 상품, 그리고 서비스의 향상에 참여하는 문화의 창조라고 할 수 있다.

1980년 이래로, 미국의 많은 회사들이 TQM을 품질에 적용하고 있다. HP의 TQC(Total Quality Control), 모토로라의 Six Sigma Strategy, 그리고 IBM의 Market Driven Quality가 그것들이며, 기타 다른 회사들도 각기 자신들만의 품질에 적용하고 있다. 자세한 사항은 책을 참고하시라.

이러한 다양한 방법론에도 불구하고, TQM 시스템의 핵심 요소는 다음과 같이 요약할 수 있다.

 - 고객 중심: 목표는 전체 고객 만족도를 달성하는 것이다. 고객 중심 요소는 고객의 요구를 연구하고 고객의 요구사항을 수집하며, 고객의 만족도를 측정하고 관리하는 것이다.
 - 프로세스: 목표는 프로세스의 변수를 줄이고 지속적으로 프로세스 향상을 꾀하는 것이다. 이 요소는 비지니스 프로세스와 상품 개발 프로세스를 포함하고 있으며 비지니스 프로세스 향상을 통해 상품 품질이 향상 될 것이다.
 - 품질의 인간적인 측면: 목표는 회사 전체적으로 품질 문화를 창조하는 것이다. 집중 영역으로써 리더쉽, 관리 방침, 전원 동참, 직원 우대, 그리고 다른 사회적, 심리적, 그리고 인간적 요소들이 있다.
 - 측정 및 분석: 목표는 목표 지향 측정 시스템에 의한 모든 품질 매개변수들의 지속적인 향상을 이끌어 내는 것이다.

아래 그림이 이러한 핵심 요소를 설명해 주고 있다.

다양한 조직적 프레임워크들이 TQM 철학을 입증하는 품질의 향상을 위해 제시되고 있다. Plan-Do-Check-Act, Quality Improvement Paradigm/Experience Factory Organization, SEI Capability Maturity Model, Lean Enterprise Management 등이 있으며 자세한 사항은 역시 책을 참고하시길.

간단히 설명하자면, Plan-Do-Check-Act는 단일 프로세스 또는 생산 라인을 최적화하기 위한 피드백 사이클에 기반을 두고 있다. Quality Improvement Paradigm/Experience Factory Organization은 지속적으로 조직의 향상을 꾀하는 것이 목표이다. 그들의 점진적 목표와 그 목표들의 상태를 평가하는데 기반을 두고 있다. SEI의 CMM은 레벨 4에 도달할 때까지 핵심 프로세스영역의 평가에 기반을 둔 단계적 프로세스 향상 모델이다. 이 모델의 목적은 결함 예방, 기술 혁신, 그리고 프로세스 변경 관리를 통해 지속적인 프로세스 향상을 달성하는 것이다. Lean Enterprise Management는 부가가치 활동들과 아닌 활동들의 제거나 축소 상의 상품의 집중 이론에 기반을 두고 있다. 목표는 소프트웨어를 만드는데 필요한 활동들을 최소화하고, 생산자의 요구사항에 맞도록 프로세스를 수정하는 것이다.

1.5 결론

품질의 가장 적합한 정의는 '고객의 요구사항의 준수'이다. 사실상 운영상 품질의 정의는 두가지 수준으로 이루어져 있다. 하나는 고유한 상품 품질(q)와 다른 하나는 고객 만족도(Q)이다.

TQM 철학은 품질과 고객의 만족을 관계지음으로써 지속적인 성공에 목표를 두고 있다. 위에서 언급한 4가지 핵심 요소인 (1) 고객 중심, (2) 프로세스 향상, (3) 품질의 인간적인 측면, (4) 측정 및 분석으로 이루어져 있다.

JCreator

 [ Metrics and Models in Software Quality Engineering ]

- 머릿말 -

시대별로 바라본 소프트웨어 공학의 관점은..

1960년대 이전 : 기능의 관점
1970년대 : 스케줄의 관점
1980년대 : 비용의 관점
1990년대 이후 : 품질과 효율성의 관점

1990년도부터 품질은 소프트웨어 개발 프로세스의 핵심으로 자리잡았으며 소프트웨어 벤더의 관점에서 품질은 시장에 성공적으로 경쟁하기 위해서 더이상 경쟁력이 아닌 필수 조건이 되가고 있다.
"Quality is no longer an advantage factor in the marketplace; it has become a necessary condition if a company is to compete successfully"

이 책의 구성은...

챕터 1: 소프트웨어 품질이란?
품질과 소프트웨어 품질의 정의에 대해 다루고, 이런 정의를 통해 바라본 소비자의 역할.
품질 속성과 이들의 관계. TQM (Total Quality  Management)와 품질의 소비자 관점에 대해서 다룸

챕터 2: 소프트웨어 개발 프로세스 모델
소프트웨어 산업에서 사용되고 있는 다양한 개발 프로세스 모델의 검토.
간략하게나마 소프트웨어 성숙 평가의 두가지 방법에 대해 서술. - SEI (Software Engineering Institute) 프로세스 능력 성숙도 모델인 CMM과 SPR (Software Productivity Research, Inc.)의 SPR 평가 방법

챕터 3: 측정 이론의 기본(Fundamental of Measurement Theory)
실제 소프트웨어 측정에 상당히 중요한 측정이론의 기본적인 사항에 대해 고찰
운용상의 정의 개념과 그 중요성이 예제와 함께 표현 - 측정의 수준, 약간의 기본 측정, 그리고 6 시그마의 개념
측정 품질, 신뢰성, 그리고 검증성, 마지막으로 측정 오류의 발생과 관련된 두 가지 주요 기준에 대해 알아보고 그들의 중요성이 표현.
관측적 데이터를 기반으로한 인과관계 설립에 필요한 기준에 대한 상관관계와 주장들에 대한 논의 또한 제공

챕터 4: 소프트웨어 품질 메트릭스의 개요
최종 산출물, 진행 중, 그리고 유지보수 3가지 소프트웨어 생명주기와 관련된 메트릭스의 분류를 위한 품질 메트릭스의 예제들을 표현
몇몇 대규모 소프트웨어 회사들에 대한 메트릭스 프로그램의 서술 및 소프트웨어 공학 데이터의 수집에 관한 논의

챕터 5: 소프트웨어 개발의 7개의 기본 품질 도구의 적용
소프트웨어 개발상에서 Ishikawa의 7가지 기본 도구로 알려진 품질 제어를 위한 기본 통계 도구 어플리케이션의 소개
소프트웨어 환경상에서 제어 차트를 적용함에 따른 잠재력과 도전과제들.
추가로 브레인 스토밍과 복잡한 인과관계의 표현-관계 다이어그램-을 위한 정량적 도구의 논의

챕터 6: 결함 제거의 유효성(실효성)
상위 5개의 챕터에 모델과 메트릭스에 관한 소프트웨어 개발의 품질 역학을 서술
두 가지 형태의 모델(품질 경영모델과 소프트웨어 신뢰성 및 추정 모델)을 통해, 소프트웨어 개발의 품질이 계획되고, 지냉되며 관리되고, 목표화
품질 계획에 있어서 결함 제거 유효성 및 그 측정, 그리고 역할의 중심 개념을 고찰

챕터 7: Rayleigh 모델
Rayleigh 모델을 설명하고 신뢰성과 예측 모델로서의 구현에 대해 서술.

챕터 8: 지수 분포와 신뢰성 성장 모델
지수분포와 주요 소프트웨어 신뢰성 성장 모델에 대해 논의
개발이 완료되어 소프트웨어가 소비자에게 전달되기 전에 Rayleigh와 같은 모델들은 품질 예측을 위해 사용
이 모델들은 역시 현장에서 실패 패턴 또는 결함 발생 패턴의 모델링을 위한 유지보수 계획에 사용

챕터 9: 품질 경영 모델들
전체 개발 주기를 관장하는 몇몇 품질 경영모델에 대한 서술
In-Process 메트릭스와 모델들이 보여지고 다뤄지는 것을 지원하는 보고서
In-Process 메트릭스와 In-Process 품질 상태-노력/결과 모델-을 해석하기위한 프레임워크 표현

챕터 10: 소프트웨어 테스팅을 위한 In-Process 메트릭스
소프트웨어 테스팅을 위한 메트릭스에 집중
벤더에 의해 개발된 소프트웨어를 평가하는 수락 테스팅을 위한 후보 메트릭스와 어떻게 당신의 상품이 출하할만큼 충분하게 좋은지 알수 있는 중요한 질문에 대해 논의

챕터 11: 복잡도 메트릭스와 모델들
소프트웨어 공학ㅇ에서 메트릭스와 모델의 세번째 타입에 대한 논의
품질 경영 모델과 신뢰성 및 예측 모델들이 프로젝트 경영과 품질 경영을 위한 반면, 복잡도 메트릭스와 모델들의 목적은 소프트웨어 엔지니어들이 그들의 디자인과 소프트웨어의 구현이 향상될 수 있게 함

챕터 12: 메트릭스와 객체 지향 프로젝트에서 얻은 가르침
디자인과 복잡도 메트릭스, 생산성 메트릭스, 품질과 품질 경영 메트릭스, 그리고 객체지향 프로젝트의 구현 및 배포와 구현에서 배운 가르침을 다룸

챕터 13: 가용성 메트릭스
시스템 가용성과 단전(outage) 메트릭스의 논의 및 가용성, 신뢰성, 그리고 기존 결함율 측정 사이의 관계에 대한 탐색
가용성 메트릭스와 소비자 만족 측정들은 4번째 소비자 지향 메트릭스와 모델 형식이다.

챕터 14: 소비자 만족의 측정과 분석
소비자 만족 데이터 수집 및 측정, 그리고 이를 분석하기 위한 테크닉과 모델들을 논의
챕터 3부터 이 챕터까지 메트릭스와 모델의 전체적인 범위를 관장

챕터 15: In-Process 품질 평가 수행
좋은 프로젝트 품질 경영의 통합된 요소로써 in-process 품질 평가 수행을 설명
품질 평가들은 이전 챕터와 정량적인 정보들과 같이 정량적인 지표를 기반

챕터 16: 소프트웨어 프로젝트 평가 수행
소프트웨어 프로젝트 평가 방법에 대한 제안
프로젝트 수준과 실무자의 관점으로부터의 논의에 집중

챕터 17: 소프트웨어 프로세스 향상의 규칙들
소프트웨어 프로세스 향상 전문가를 위한 실제적인 조언
챕터 2의 프로세스 성숙도와 관련

챕터 18: 기능 점수 매트릭스를 소프트웨어 프로세스 향상 측정에 이용
소프트웨어 프로세스 향상의 6단계에 대한 논의
경험에 의한 데이터의 상당 부분을 기반으로 프로세스 향상의 비용과 효과를 측정
비용, 스케줄, 생산성, 그리고 품질에 관한 정량적인 분석 결과를 제공
기능 점수 매트릭스의 가치를 분명하게 표현
마찬가지로 챕터 2의 프로세스 성숙도와 관련

챕터 19: 결론
일반적인 소프트웨어 측정과 특정 소프트웨어 품질 메트릭스와 모델들의 관찰 결과를 제공
소프트웨어 공학 측정의 미래에 대한 관점 제공

부록: 프로젝트 평가 설문지의 실제 예제 제공
챕터 16에서 논의된 메소드와 테크닉에 대하여 독자들이 그들의 프로젝트 평가 활동을 위한 설문지 커스터마이징 가능

JCreator