소프트웨어 품질관리

(1)

Software Engineering

소프트웨어 품질관리

(2)

소프트웨어 품질

•

소프트웨어 품질

–

품질 관리 및 품질 보증은 제품을 만들어내는 조직에서는 필수적인 활동

–

소프트웨어 공학은 고품질의 소프트웨어를 생산하는 것을 그 목표로 함

–

소프트웨어의 품질이란?

•

소프트웨어 품질은 소프트웨어의 유용성(fitness for use)을 얻기 위해 갖추어야 하는 특성들의 집합이며, 소프트웨어가 사용자의 요구사항을 충족시키기 위하여 갖추어야 할 제반 특성을 의미

–

소프트웨어의 품질도 다른 제품들과 마찬가지로 사용자의 입장에서 보아지고 평가되어 야 함

–

소프트웨어의 품질은 개발팀의 목적, 그리고 사용자의 기대 및 요구와 깊은 관계를 가지 고 있음

–

소프트웨어 품질도 공정 과정마다 품질여과(quality filtering)를 할 때 얻어질 수 있음

•

가장 효과적인 품질여과 방법은 각 공정 과정마다 공식기술검토회(formal technical review)를 거치는 것

•

특히 프로젝트 초기에 만들어지는 요구사항 명세서에 대한 공식기술검토회는 매우 중요

–

품질 관리는 누구든지 오류를 범할 수 있다는 것을 인정하는 데에서 출발하였고, 고객의 만족을 증대시키기 위해 끊임없이 개선하는 과정을 중시함으로서 경쟁력 있는 기업체질 을 만들어 옴

–

소프트웨어 품질 보증(SQA: Software Quality Assurance) 활동

•

소프트웨어 개발 전 과정에 걸쳐 적용되는 품질 보호 활동

(3)

소프트웨어 품질보증

•

소프트웨어 품질보증(SQA: Software Quality Assurance)이란?

–

‘당연히 있어야 할 품질과 실현되는 품질을 일치시키는 노력’

–

SQA는 품질 관리가 효과적으로 이루어져 품질이 소정의 수준에 있다는 것을 보증하는 것

–

SQA는 소프트웨어를 개발할 때 과학적인 관리 기법을 적용하여 사용자가 요구하는 품질의 제품을 체계적이며 경제적으로 달성하려는 활동들의 집 합이라 정의할 수 있음

(4)

품질보증 작업

•

품질보증 작업

–

소프트웨어 공정과정인 분석, 설계, 구현, 시험 단계에 적용될 수 있는 방 법과 도구들이 확립되어야 함

–

또한 공정과정의 분리와 각 공정과정의 임무, 입력물, 산출물, 사용도구 등을 정의하여야 함

–

각 공정과정의 결과물에 대한 공식기술 검토가 이루어져야 함

–

다단계 시험전략이 필요

–

소프트웨어 개발이란 문서화 과정이라 볼 수 있으며 각 공정과정마다 문 서는 가장 핵심적인 산출물

–

기록 유지와 보고(record keeping and reporting)가 체계적으로 이루어져 야 함

–

개발 표준의 확립이 필요

–

^체계적인관리를 위해 품질과 진행 과정에 대한 측정이 필요

(5)

1. 소프트웨어 품질 정의

• 품질

–

「사용자(고객) 만족」,「사용하기에 적합함」,「규격에 맞음」

등 다양하게 정의내릴 수 있음

–

품질은 구체적으로 명시되어 있는 기능 및 성능을 만족해야 하고, 직업적(professional)으로 만들어지는 소프트웨어에 기대되는 사 용자의 요구 수준을 만족시키는 것임

–

다구찌, 품질이란?

•

「제품이 출하된 때부터 사회에 끼치는 손실(Quality is the loss imparted from the time a product is shipped) 이라고 함

–

「사용자가 만족할 수 있는 품질의 소프트웨어를 가장 경제적으로 만드는 것」이 소프트웨어 공학 및 품질 관리의 목표로 인식되어 옴

(6)

품질 비용(quality cost)

• 품질 비용

–

「제품이나 서비스의 품질과 관련하여 발생하는 비용」으로 정의

–

예방 비용(prevention cost), 평가 비용(appraisal cost), 및 실패

비용(failure cost) 등 3가지 범주로 구분

–

요구사항 분석, 설계, 체계적인 방법론의 적용 등은 실패 비용을 최소화하기 위한 과정이라 볼 수 있음

–

^{지렛대의 효과}

•

「 1온스를 들여 예방을 하면 치료에 드는 1파운드를 절약할 수 있다 (An ounce of prevention is worth a pound of cure) 」

(7)

요구사항 명세서와 품질

• 요구사항 명세서와 품질

–

일반적으로 품질은 사용자 만족도에 의해 측정

–

요구사항 명세서는 품질을 측정할 수 있는 기초가 되는 문서

–

품질은 요구사항을 얼마나 충족시켰는가에 의해 결정되며, 이를

판정하기 위해 요구사항은 구체적이며 명확하게 기술되어야 함

–

요구사항 명세서는 설계 및 구현을 위해 중요한 문서일 뿐만 아니

라 품질을 평가하는 기준이 됨

–

요구사항 명세서는 품질을 측정하는 기초가 되는 동시에 소프트웨 어 공학이 추구하는 고품질 소프트웨어를 만든다는 단일 목표에 접근할 수 있게 함

(8)

2. 소프트웨어 품질 요소

• 소프트웨어 품질 요소

–

소프트웨어의 유용성 및 사용 목적을 달성하는 데 필요한 성질

–

소프트웨어도 일반적인 제품에서 필요로 하는 품질 요소가 적용될 수 있고, 특히 소프트웨어가 가지고 있는 특성상 특정 품질 요소가 추가될 수 있음

–

일반적으로 품질은 소프트웨어의 운용에서 나타나는 특성, 소프트 웨어의 수정에서 요구되는 특성, 새로운 환경에 대한 적응성의 3 가지 중요한 측면에서 관찰될 수 있음

•

정확성(correctness), 신뢰성(reliability), 효율성(efficiency), 유용성 (usablility), 무결성(integrity), 유연성(flexibility), 시험성(testability), 유지보수성(maintainability), 이식성(portability), 재사용성

(reusability), 상호운영성(interoperability) 등

–

원하는 시스템의 품질, 품질요소의 상대적인 중요성, 품질의 측정 및 검증 방법 등을 요구사항 명세서에 명시할 수 있음

(9)

소프트웨어 품질 요소표

구분 품질요소 정의

정확성(Correctness) 사용자의 요구사항을 만족시키는 정도

신뢰성(Reliability) 기능상의 장애없이 의도한 임무를 수행하여야 하는 요구수준 효율성(Efficiency) 프로그램을 수행하는데 요구되는 자원과 코드량의 최적화 정도 확장성(Expandability) 시스템에 새로운 기능이나 데이터를 추가할 수 있는 능력 사용용이성(Usability) 프로그램을 배우고 작동하는 것을 배우는데 요구되는 노력 운용측면

무결성(Integrity) 허가받지 않은 사람이 소프트웨어나 자료에 접근할 수 없도록 통 제할 수 있는 능력

유지보수성(Maintainability) 프로그램의 오류를 발견하고 수정하는데 요구되는 노력의 정도 수정측면

이식성(Portability) 한 환경에서 다른 환경으로 옮겨 사용하는데 요구되는 노력의 정도

시험성(Testability) 의도한 기능을 수행하는지 검사하는데 요구되는 노력의 정도 재사용성(Reusability) 소프트웨어의 일부분을 다른 시스템에서 재사용할 수 있는 정도 상호운영성(Interoperability) 다른 시스템에 결합시키는데 요구되는 노력을 나타내는 정도 적응측면

유연성(Flexibility) 소프트웨어를 수정하기 위해 요구되는 노력의 정도

(10)

3. 품질 표준

• 품질 표준

–

최근 들어 소프트웨어의 품질 문제가 생산성보다 더 핵심적인 과 제로 떠오르고 있음

–

소프트웨어를 생산하는 조직이 좋은 품질의 제품을 생산하기 위하 여 갖추어야 할 기본사항을 준수하는지에 대한 보증을 소프트웨어 를 구입하는 기관에서 요구하는 경향이 점차 늘어가고 있음

–

따라서 제품이나 서비스의 개발과정과 효과성을 공급자(개발자)나 구매자(고객)와는 다른 독립적인 제 3자가 보증하는 인증제도가 전 세계적으로 받아들여지고 있음

–

KS(Korean Industrial Standards) 마크도 그 대표적인 예

(11)

ISO

• ISO(International Standards Organization)

–

^{국제 표준화기구}

–

제품이나 서비스의 요구사항을 보완할 수 있도록 '기업의 경영 체 계에 대한 국제 표준'을 설정하고, 품질시스템 표준인 ISO 9000 시리즈를 개발해놓고 있음

–

ISO 9000 시리즈

•

이전의 생산자 중심 제품 검사 또는 공장의 불량품을 조사해 온 품질 체계를 구매자 중심으로 바꾸어, 기업이 품질 시스템을 제대로 구축하 고 있는가에 초점을 맞추고 있음

•

기업의 제품 또는 서비스의 품질에 요구되는 공정 단계 중 수행되는 종합적인 활동에 의해 평가

–

ISO는 품질시스템 구축에 대한 적합성 검사를 위한 가이드를 제시 함

(12)

품질시스템

• 품질 시스템

–

^{ISO 9001}

•

외부품질 보증목적에 사용될 수 있는 품질시스템(Quality System) 요 구사항에 관한 3가지 규격 중 하나

•

설계, 개발, 생산, 설치 및 서비스분야에 적용되는 품질기준 지침을 제 공

–

ISO에서 정의하는 품질 시스템이란?

•

품질 관리를 기업이나 공장에 적용하여 제품의 품질을 보장하기 위한 조직의 구성과 그 조직의 책임, 업무 분장, 절차, 업무의 과정, 업무 및 작업진행을 위한 자원 및 재정을 통틀어 말함

–

ISO 9001 품질 시스템

•

설계, 개발, 생산, 설치 및 서비스에 있어서의 품질 보증 모델

–

ISO 9000-3

•

소프트웨어 품질 보증을 위한 지침, 특히 사용자(구매자)의 요구사항 명세서에 따라 소프트웨어가 개발되어야 하는 가이드라인을 제공

12

(13)

4. 검토 기법

• 검토 기법

–

현재의 상황을 파악하고 일이 계획대로 진행되는지를 알기 위해 검토 기법을 이용하는 것이 바람직

–

또한 이정표(milestone)를 만들어 프로젝트 진행에 대한 정기적인 검토와 관리를 하는 것이 최선의 방법

–

기술적인 검토(formal technical review)는

•

소프트웨어 문서에 대하여 여러 사람들이 객관적인 눈으로 바라보아 총체적인 관점을 반영할 수 있다는 장점을 가지고 있음

–

기술 검토는 소프트웨어 개발과정에서 나타나는 결함을 초기에 발 견하여 여과(filtering)하기 위해 수행함

(14)

4.1 공식기술검토회

•

공식기술검토(Formal Technical Review)

–

공식기술검토는 산출물의 오류를 발견하기 위한 공식적인 활동

–

공식기술검토는 소프트웨어 개발 실무자들이 수행하는 소프트웨어 품질보증 활동

–

공식기술검토회의 목적

•

산출물에 대한 기능, 논리에 대한 오류를 발견하고, 설계 및 구현 과정에서 요구사 항과 일치하는지 검증하고, 소프트웨어가 미리 정하여진 기준에 맞추어 개발되고 있는지 점검하는 것

–

공식기술검토회를 통하여 오류를 초기에 걸러내는 것이 프로젝트를 관리하기 수월하게 하여 주며 높은 품질의 소프트웨어를 만들 수 있는 길임

–

공식기술검토회는 문서와 밀접한 관계를 가진 적은 수의 사람들이 모여 수행 하는 것이 바람직

–

검토가 이루어지기 전 검토에 대한 준비가 이루어져야 하며, 문서가 미리 배포 되어 검토에 참여하는 사람은 문서를 미리 읽고 문제점이나 의문점을 준비하 여야 함

–

일반적으로 일주일이나 열흘 전에 문서를 보내 충분한 검토가 이루어질 수 있 도록 하는 것이 바람직

–

일반적으로 참여 인원은 3-5 명이 적당

–

검토회 시간도 2시간을 넘기지 않는 것이 바람직하다고 알려져 있음

(15)

검토 지침

• 검토 지침

–

산출자를 검토하지 말고 산출물을 검토하라.

–

검토를 위한 시간과 자원을 할당하여 일정을 세우고 이를 유지하 라.

–

검토의 목적은 문제의 발견임을 잊지 말고 논쟁과 반박을 삼가라.

–

참가자의 수룰 제한하고 사전준비를 하도록 하라.

–

칠판 등을 이용하여 검토자의 의견을 기록하라.

(16)

5. 소프트웨어 측정

• 소프트웨어 측정

–

소프트웨어를 측정하는 일은 소프트웨어 공학에서 다루어야 하는 매우 중요한 부분 중의 하나임

–

개발에 소요되는 자원, 기간, 품질 등의 측정 없이 여러 기법, 도구, 방법론 등에 대한 평가를 내릴 수 없음

–

또한 측정 없이 프로젝트의 상태를 파악할 수 없고 프로젝트가 어 디로 가고 있는지 알 수 없음

–

올바른 측정은 산출물의 품질, 인력의 생산성, 도구의 효과 등을 객관적으로 평가할 수 있는 기준을 제공

(17)

소프트웨어 척도

•

소프트웨어 척도(metrices)

–

소프트웨어의 생산성, 품질, 사업의 특성 등에 관한 자료를 수치로 표시하는 것

–

소프트웨어는 눈에 보이지 않아 특성상 이를 측정하는 것과 그 결과를 척도로 나타내는 것이 대단히 어려운 일임

–

소프트웨어 공학의 발전이 느린 이유중의 하나는 이와 같은 공학적인 방식을 잘 활용하지 못하 는데 있음

–

불행히도 아직도 많은 소프트웨어 관리자 및 개발자들이 소프트웨어 척도를 활용하고 그 실용 성을 느낄 수 있는 단계에 와 있지 못함

–

소프트웨어의 직접적인 측정 방법

•

줄 수에 의한 척도

– 모든 소프트웨어에 적용할 수 있는 장점

– 프로그래밍 언어에 종속적이며 초기 산정시 정확히 계산하기 어려우며, 잘 설계된 프로그램의 경우 오히려 생산성이 떨어지는 등 문제점

•

기능에 의한 척도

– 프로그램 언어에 독립적이며 초기 산정시 계산하기 쉽다는 장점

– 객관성을 띄고 있지 못할 가능성이 높고 물리적인 의미가 없다는 문제점

–

소프트웨어 척도에는 여러 정의가 있을 수 있고 측정의 결과를 나타내는 것 뿐만이 아니라 이 를 뒷바침하는 이론과 모델이 필요

–

소프트웨어의 품질을 측정하는 방법 중에 품질 항목을 세분화하여 계량적으로 수치화하는 방 법이 있음

–

응용 분야에 따라 품질 항목이 차지하는 중요도에 따라 상대적인 우선 순위를 정하여 이를 적 용하는 것이 바람직

(18)

요약

•

품질 문제는 개발의 생산성과 거의 동등하게 중요시되고 있다.

•

품질 향상의 필요성과 전 세계적인 경쟁에 능동적으로 대처하기 위해 소프트웨어 개발 회사들은 품질 향상을 위해 다양한 기법들을 도입하고 있다.

•

효과적인 소프트웨어 품질 관리를 위해서는 품질의 평가보다는 품질 향 상에 더 중점을 두는 오프라인 품질 관리기법(off-line Quality Control) 을 많이 사용하여야 한다.

•

품질은 개발자에 의해 평가되기 보다는 고객에 의해 평가된다.

•

높은 품질의 제품을 지속적으로 만들기 위해서는 기존에 시행해 왔던 방법에서 탈피하여 체계적인 공학이론들을 습득하고 이를 실제로 적용 하는 훈련이 요구된다.