<BACEB7CF442DBCD2C7C1C6AEBFFEBEEE20C7B0C1FA20B9D720C5D7BDBAC6AE20C7A5C1D85F30372E31322E31372E687770>

Transcription

1 부록 D 소프트웨어 품질 및테스트표준

2 1. ISO/IEC 개요 범위 준수사항 참조표준 품질접근방법과관련성 제품품질과그생명주기 메트릭 소프트웨어제품메트릭(Metric) 소프트웨어품질특성 기능성(Functionality) 신뢰성(Reliability) 사용성(Usability) 효율성(Efficiency) 유지보수성(Maintainability) 이식성(Portability) 사용품질특성 ISO/IEC 9126 용어정의 ISO/IEC 적용범위 정의 품질요구사항 제품설명서 시험을위한지침 선행조건시험 시험활동 테스트기록 테스트보고서 추후테스트 ISO/IEC 용어정의 57

3 부속서 A: 다른규격에서정의된용어 부속서 B: 제품설명서의예 해설서 ISO/IEC 개요 평가프로세스 개발자를위한프로세스 (Process for Developers) 획득자를위한프로세스 (Process for Acquirers) 평가자를위한프로세스 (Process for Evaluators) 평가를위한지원 계획과관리(Planning and Management) 평가모듈(Evaluation Modules) 소프트웨어품질특성과메트릭 평가프로세스 평가요구사항설정 평가목적설정 평가될제품의타입을식별 품질모델을명세 평가명세화 메트릭선택 메트릭을위한등급레벨성립 평가를위한범주성립 평가설계 평가실행 프로세스지원 IEEE 범위 단위테스트활동 72

4 5. IEEE 개요 검증 확인 소프트웨어검증및확인계획가이드 생명주기에따른검증및확인활동 84

5 부록 표준 본장에서는 ISO/IEC 9126, ISO/IEC 12119, ISO/IEC 14598, IEEE 1008, 그리고 IEEE 1012 등다섯개의테스트표준(Testing Standard) 에대하여살펴본다. 1. ISO/IEC 개요 본절에서는 ISO/IEC 9126 에대해설명한다. 오늘날컴퓨터는점차 다양한응용분야에서광범위하게사용되고있으며, 정확한작동은기업성 공이나인간안전과깊은관련을갖는다. 그러므로, 고품질의소프트웨어 제품을개발하거나선정하는일이매우중요하다. 소프트웨어품질에대한 포괄적인명세및평가작업은적절한품질을확보하기위한주요요인이 다. 이러한작업은소프트웨어의사용목적을고려하여적합한품질특성을 정의함으로써달성된다. 소프트웨어제품은이미검증되었거나널리인정 된메트릭을사용하여관련된모든특성에따라평가되어야한다. 본표준은이러한요구를지원하기위해개발되었으며, 여섯가지품질 특성을정의하고, 소프트웨어제품평가프로세스모델을설명하고있다 범위 본표준의범위(Scope) 에서는소프트웨어품질을여섯가지특성 (characteristics) 으로구분하고, 이를다시부특성 (sub-characteristics) 로세분화한품질모델을명세한다. 이러한부특성은소프트웨어가컴퓨터 - 1 -

6 시스템의일부로사용될때외부로나타나며, 내부적인소프트웨어속성들 의결과이다. 최종사용자를위한소프트웨어품질특성의결합된결과는 사용품질(QIU: Quality In Use) 로정의된다. 정의된특성은펌웨어(firmware) 에수록된컴퓨터프로그램과데이터 를포함하여모든종류의소프트웨어에적용할수있다. 특성과부특성은 소프트웨어품질에대한일관성있는용어를제공한다. 또한특성과부특 성은소프트웨어에대한품질요구사항을명세하기위해서, 또는기능성, 신뢰성, 사용성, 효율성, 유지보수성, 그리고이식성과같은소프트웨어능 력사이의균형을맞추기위한기본틀을제공한다. 프로그래밍환경의재 사용성과같은오직개발자만이관심을갖는소프트웨어속성은본표준의 범위를벗어난다. 구매, 요구명세, 개발, 사용, 평가, 지원, 유지보수, 품질보증및소프트 웨어감사등과관련된사람들이서로다른관점에서소프트웨어제품품 질을명세하고평가할수있도록한다. 본표준에서정의된품질모델의 사용예는다음과같다. 요구사항정의의완전성확인 소프트웨어요구사항확인 소프트웨어설계목적확인 시험목적확인 완성된소프트웨어제품의사용자인수기준확인 본표준은다음사항을제공하기위해 로세스심사에관한표준) 와함께사용될수있다. ISO/IEC 15504( 소프트웨어프 고객-공급자프로세스에서소프트웨어제품품질을정의하기위한 기본틀 지원프로세스에서검토, 검증및확인을위한지원, 그리고정량 - 2 -

7 적품질평가를위한기본틀 관리프로세스에서조직품질목표를설정하기위한지원 본표준은다음사항을제공하기위해 명주기에관한표준) 과함께사용될수있다. ISO/IEC 12207( 소프트웨어생 주요생명주기프로세스내에서소프트웨어품질요구사항을정의 하기위한기본틀 생명주기프로세스를지원하는데있어서검토, 검증및확인을위 한지원 본표준은다음사항을제공하기위해 품질목표를설정하기위한지원 설계검토, 검증및확인을위한지원 ISO 9001 과함께사용될수있다 준수사항 본항에서는본표준의준수사항 (Constraint) 에대하여살펴본다. 본 표준을준수하는소프트웨어품질에대한모든명세서는다음과같은사항 에대한적절한기준을식별하기위해 1.1.5절 4) 에정의된품질모델을사 용할것을권고한다 절에있는특성및부특성을위한내부메트릭에대한기준 1.1.7절에있는특성및부특성을위한외부메트릭에대한기준 1.1.8절에있는사용품질메트릭에대한기준 기준설정이나비교를위한어떠한메트릭도 1.1.6절 4) 의요구사항을 충족할것을권고한다

8 1.4. 참조표준 본표준의참조표준(Reference Standard) 은다음과같다. ISO 9001 (1994) Model for quality assurance in design, development, production, installation and servicing. ISO/IEC (1995) Information Technology - Software life-cycle processes. ISO/IEC PDTR (1996) Information Technology - Software Process Assessment. ISO/IEC DIS (1996) Information Technology - Software product evaluation - Part 1: General overview 품질접근방법과관련성 본다. 본항에서는소프트웨어에대한품질접근방법과관련성에대해살펴 제품품질과그생명주기 품질은소프트웨어생명주기와함께변화한다. 즉, 생명주기의초기에 요구한제품품질이실제로인도된제품품질과다르다. 품질판정도또한 여러관점에서반영된다. 생명주기의각단계에서품질을적절히관리하기 위해서는이러한품질의다양한관점과생명주기에따른품질변화에대한 정의가필수적이다. 다음은생명주기의서로다른단계에서바라본다양한 제품품질관점들이다. 목표품질(GQ: Goal Quality) 은실제사용자의요구를반영하는필요 충분한품질이다. ISO 8402 는품질을, 명시된요구와내재된요구를만족 시키는능력이라고정의하고있다. 그러나, 사용자가명시한요구사항이 - 4 -

9 항상실제사용자의요구를반영하는것은아니다. 왜냐하면사용자는자 신의실제요구사항들을잘모를수있으며, 명시된후에도요구사항이바 뀔수있기때문이다. 따라서, GQ는설계초기에완벽히정의될수없는 개념적인개체이다. 하지만개발자는이목표를염두에두고이에가까이 가도록노력해야한다. 사용자의요구사항과잠재적인어떤문제점을좀 더명확히이해하기위해서는고찰된특정사용시나리오를문서화해두는 것이유용할수있다. GQ란반드시완전한품질을의미하는게아니라필 요충분한품질을말한다. GQ 에대한일부요구사항은사용품질(QIU) 로 측정할수있으며, QIU에대한요구사항은가능한한품질요구명세서에 포함시켜야한다. 요구제품품질(RPQ: Required Product Quality) 은품질요구명세 서에실질적으로기술된품질이다. RPQ는초기확인을위한목표로사용 되어야한다. ISO/IEC 9126에정의된모든품질특성에대한품질요구사 항은품질요구명세서에명시되야한다. 최적의요구사항뿐만아니라최 소한의요구사항도명시되어사용자나개발자모두불필요한비용이나스 케줄지연등을피해야한다. 설계품질(DQ: Design Quality) 은소프트웨어설계의핵심부분이나 중추적인부분, 예를들어, 소프트웨어구조, 프로그램구조및사용자인 터페이스설계전략등에나타나는품질이다. DQ는설계원칙과전략을 반영한다. 소프트웨어품질의상세한내용은코드구현이나시험과정에서 개선될수있지만, DQ에의해나타나는소프트웨어제품품질의근본적인 속성은바뀌지않는다. 예상제품품질(EPQ: Estimated Product Quality) 은개발각단계에 서최종소프트웨어제품의품질에대한예상또는예측품질로서 DQ를 기반으로한다. 제품품질은개발도중에 ISO/IEC 9126에서정의된각품 질특성에대해예상하거나기대할수있다. 이러한예상을위해 DQ와 - 5 -

10 EPQ 간의상관관계를나타낼수있는기법이개발되어야한다. 인도제품품질(DPQ: Delivered Product Quality) 은전형적으로모 의실험데이터를가지고, 모의환경에서시험된인도된제품의품질이다. 시험도중에, 대부분의결함이발견되고제거되어야한다. 그러나, 일부결 함은시험단계이후에도남아있을수있다. 소프트웨어구조나소프트웨어 에대한기본적인설계관점은변경하기어렵기때문에기본적인설계는 통상적으로시험과정에서바뀌지않고유지된다. 사용품질은소프트웨어를포함하고있는시스템에대한사용자관점 의품질이며, 소프트웨어자체의성질보다는그소프트웨어를사용한결과 의관점에서측정된다. 참고 - " 사용자" 는최종사용자와유지보수자모두를말하며, 그들의 요구사항은다를것이다. 사용자환경에서의품질은개발자환경에서의품질과다를수있다. 왜 냐하면, 일부기능은사용자가볼수없거나혹은사용자가사용하지않을 수있기때문이다. 사용자는실제로사용도중에자신에게보이는소프트 웨어속성만을평가한다. 때로는요구분석단계에서사용자가명세한소프 트웨어속성들이바람직하지않을경우도있다

11 가. 품질접근방안 < 그림1> 품질생명주기 소프트웨어제품품질을달성하기위해소프트웨어제품을평가하는 것은소프트웨어개발생명주기의한과정이다. 그림 8.1 에서와같이, 소프 트웨어제품품질은내부속성을측정함으로써, 혹은외부속성에의해평 가될수있다. 그목적은제품이특정한사용에서요구한효과를내도록 하자는것이다. 프로세스품질(ISO/IEC 12207에정의된모든생명주기프로세스의품 질) 은제품품질의개선을가져오고, 제품품질은사용품질의개선을가 져온다. 그러므로, 프로세스를평가하고개선하는것이제품품질을개선 하는한방법이며, 제품품질을평가하고개선하는일이사용품질을개선 하는한방법이다. 적절한품질평가프로세스는개발동안에품질측정을지원하는데필 요하다. < 그림2> 와같이, 소프트웨어의적절한내부속성은요구된외부 행위를성취하기위한선결과제이며, 적절한외부행위는사용품질을성 취하기위한선결과제이다

12 < 그림2> 서로다른품질관점간의관련성 소프트웨어제품품질에대한요구사항은일반적으로개발자, 유지보수 자, 구매자및최종사용자의요구를충족시키기위한내부품질, 외부품질 및사용품질에대한기준을포함한다. 나. 평가항목 항목들은직접측정방법이나혹은그결과를측정하여간접적으로평 가할수있다. 예를들어, 프로세스는그제품을측정하고평가함으로써판 정할수있고, 제품은사용자의작업성능을측정해봄으로써평가할수 있다. 소프트웨어는단독으로수행되는것이아니라인터페이스, 하드웨어, 사용자및작업흐름등을포함하는다른소프트웨어제품으로구성된, 보 다큰시스템의일부로서수행된다. 인도된소프트웨어제품은선정된외 부메트릭수준에서평가된다. 이러한메트릭은그환경과의상호작용을 나타내며운영중에있는소프트웨어를관찰함으로써판정된다. 외부품질 ( 제품이명시되거나내재된요구를만족하는정도) 는운영환경에서사용 품질을평가함으로써측정할수있다. 이러한것은일반적으로좀더특정 한소프트웨어특성을측정함으로써이루어지며, 개발과정의초기에서도 가능하다. 초기개발단계에서는자원이나프로세스만이측정가능하다. 중간제 품( 명세서, 원시코드, 등) 이나오기시작하면, 선정된내부메트릭수준으 로이러한것들을평가할수있다. 이러한메트릭은외부메트릭의값을 - 8 -

13 예측하는데사용할수있다. 또한, 내부메트릭은외부메트릭에대한필 수적인선결과제로써그자체로측정될수있다. 또다른구분으로는소프트웨어제품에대한평가와그제품이실행되 는시스템에대한평가로나누어볼수있다. 예를들어시스템의신뢰성 은어떤원인( 하드웨어, 소프트웨어, 사람실수등) 으로인한모든문제를 관찰해봄으로써판단할수있다. 반면에, 소프트웨어제품의신뢰성은단 지소프트웨어내부에있는결함( 요구분석, 설계혹은구현으로부터나온) 으로인한고장예를관찰해봄으로써판정할수있다. 또한, 시스템의경 계는평가목적이나사용자에따라다르게판단될수있다. 참고 - 예를들어, 컴퓨터를기반으로하는비행제어시스템을장착한 항공기의사용자를승객이라한다면, 그에따른시스템에는비행승무원, 항공기및비행제어시스템내의하드웨어와소프트웨어등이포함되지만, 비행승무원을사용자로본다면, 그에따른시스템에는단지항공기와비 행제어시스템만이포함된다. 다. 품질모델 소프트웨어품질은정의된품질모델을사용하여평가해야한다. [ 그림 8-3] 과같이, 품질모델은소프트웨어제품이나중간제품의품질목표를 설정할경우에사용해야한다. ISO/IEC 9126의이부분은품질과관련된 문제점에대한점검표(checklist) 로서사용가능한품질모델( 특정한경우 에는더적절한품질분류방법이있을수있지만) 을제시한다

14 < 그림3> 소프트웨어제품품질 소프트웨어품질속성은여섯가지특성( 기능성, 신뢰성, 사용성, 효율 성, 유지보수성및이식성) 으로구분되며, 이러한특성들은다시부특성들 로세분된다. 부특성은내부메트릭이나외부메트릭에의해측정가능하 다. 프로그램크기와같은기본적인내부메트릭은보통그하나만으로소 프트웨어품질메트릭으로사용되는것이아니라메트릭을생성하기위해 다른측정과함께사용되는소프트웨어측정치이다. 사용품질은사용자관점의품질을말하며, 효율성, 생산성, 안전성그 리고만족도등네가지특성을포함한다. 그림 8.4 와같이, 사용품질의 달성은관련된소프트웨어제품의품질부특성에대한외부측정의기준치 도달여부에달려있으며, 외부측정은다시관련된내부측정의연관기준 치도달여부에달려있다. 측정은보통세단계모두에서필요하다. 왜냐 하면, 내부측정의기준치만족이외부측정의기준치달성여부를확인하 는데일반적으로충분하지않으며, 부특성에대한외부측정의기준치만 족이사용품질에대한기준치만족여부를확인하는데보통충분하지않 기때문이다

15 < 그림4> 사용품질 대형소프트웨어제품의모든부분에대해내부적이나외부적으로모든 부특성을측정한다는것은실질적으로불가능하다. 또한사용자작업의모 든가능한시나리오에대해사용품질을측정하는것도통상적으로현실적 이지않다. 평가요구를위해서로다른측정유형간에할당되는자원도 사업목적과제품이나설계프로세스의속성에따라다르다 메트릭 소프트웨어제품메트릭 (Metric) 가. 속성및특성 어떤내부속성의수준은일부외부측정의수준에영향을미친다고알 려져있다. 따라서대부분의특성에는외부적인측면과내부적인측면의 양면성이있다. 예를들어, 신뢰성에대해서는그소프트웨어를시험하면 서주어진실행시간동안에결함의횟수를관찰함으로써외부적으로측정 할수있으며, 내부적으로는고장허용수준을평가하기위해상세한명세 서와원시코드를조사해볼수있다. 내부속성을외부속성에대한표시

16 자라고말한다. 그림 8.5 와같이, 하나의특성이여러개의속성에의해영 향을받는것과마찬가지로하나의속성이여러개의특성에영향을줄수 있다. 본모델에서전체적인품질속성은특성과부특성으로이루어진계 층적인나무구조형태로구분되어있다. 이구조의최상층은품질특성들 로이루어지며최하층은소프트웨어품질속성들로구성되어있다. 일부 속성은한개이상의부특성에관련이있기때문에이계층구조는완벽한 것은아니다. 참고 - 내부속성과외부측정간의상관관계는완벽한것이아니며, 어 떤내부속성이연관된외부측정에끼치는영향은경험에의해결정되며 소프트웨어가사용되는특정환경에따라달라질것이다. 마찬가지로, 외부성질( 적합성, 정확성, 결함허용성이나시간반응성과 같은) 은나타나는품질에영향을줄수있다. 사용상의고장( 예를들어, 사 용자가작업을마칠수없다) 은외부품질( 적합성혹은운영성) 및고쳐야 할연관된내부속성으로추적해볼수있다. 나. 내부메트릭 내부메트릭은설계나코딩도중에실행할수없는소프트웨어제품( 명 세서나원시코드와같은) 에적용할수있다. 소프트웨어제품을개발할 경우에그중간제품에대해서는모의실험행위로부터추출가능한본질적 인성질을측정하는내부메트릭을이용하여평가해야한다. 이러한내부 메트릭의주된목적은요구된외부품질이성취되었는가를확인하는것이 며그예는 ISO/IEC 에나와있다. 내부메트릭은사용자, 평가자, 시험자및개발자가소프트웨어제품품질을평가할수있도록도와주며 그소프트웨어제품을만들기전에미리품질문제점들을지적해준다

17 < 그림5> 품질특성, 부특성및속성 내부메트릭은중간제품이나인도된소프트웨어제품의정적인성질을 분석함으로써내부속성을측정하거나외부속성을보여준다. 내부메트릭 의측정은예를들어원시코드명령문, 제어그래프및상태전이표현등 에나타나는소프트웨어구성요소들의개수나빈도수를사용한다. 참고 - 문서들에대해서도내부메트릭을사용하여평가할수있다. 다. 외부메트릭 외부메트릭은실행가능한소프트웨어나시스템을시험, 운영, 관찰함 으로써소프트웨어를구성하는시스템형태에대한측정을위하여사용되 는메트릭이다. 소프트웨어제품을구매하거나사용하기전에, 특정한조 직이나기술적환경에서제품의사용, 개발및관리와관련된기업목적을 토대로메트릭을사용하여평가해야한다. 이러한것들이주로외부메트 릭이며그예는 ISO/IEC 를따른다. 외부메트릭은사용자, 평가

18 자, 시험자및개발자가시험수행이나운영중에소프트웨어제품품질을 평가할수있도록도와준다. 라. 외부와내부메트릭간의관계 소프트웨어품질요구사항이정의되면, 품질요구사항을표현하는소프 트웨어품질특성이나부특성이열거된다. 그다음은, 그소프트웨어가사 용자요구를만족하는지를확인하는품질기준을정량화하기위해적절한 외부메트릭및수용가능한범위가명시된다. 그다음은, 요구된외부품 질과사용품질이결국에는성취될수있도록계획하고개발도중에중간 제품에그품질을구축할수있도록소프트웨어에대한내부품질속성이 정의되고명시된다. 내부품질특성의정량화를위해적절한내부메트릭 및수용가능한범위를명시하여개발도중에중간제품이내부품질명세 를만족하는지를검증하는데사용될수있도록한다. 목표하는외부메트릭과밀접한관계를가지는내부메트릭의사용을 권장하며, 외부메트릭의값을예측하는데도사용할수있다. 그러나내부 메트릭과외부메트릭간에강한관련성을제공하는이론적모델을설계한 다는것은어려운문제이다. 마. 사용품질메트릭 사용품질메트릭은제품이사용될경우에정해진목표를달성하기위 하여효율성, 생산성및만족도측면에서어느정도특정사용자의요구를 충족하는가를측정한다. 사용품질을평가하는일은특정사용자작업시 나리오내에서소프트웨어품질을확인하는것이다. 사용품질은소프트웨어를포함하고있는시스템의품질을사용자관

19 점에서본것이며, 소프트웨어자체의성질보다는그소프트웨어를사용한 결과의관점에서측정한다. 사용품질은사용자를위한소프트웨어품질 특성의복합적인효과이다. 사용품질과다른소프트웨어품질특성과의 관련성은사용자유형에따라다르다. 최종사용자에있어서사용품질은기능성, 신뢰성, 사용성및효율 성의결과이다. 소프트웨어유지보수담당자에있어서사용품질은유지보수성의 결과이다. 소프트웨어전이담당자에게는사용품질은이식성의결과이다. 바. 메트릭과측정기준의선정 메트릭선정의기반은제품에대한기업목표와평가자의요구에따라 다를것이다. ISO/IEC 9126의이부분에서의모델은다음예와같은다양 한평가요구사항을지원한다. 사용자나사용자의기업단위에서는사용품질에대한메트릭을 사용하여소프트웨어제품의적합성을평가한다. 구매자는기능성, 신뢰성, 사용성및효율성에대한외부측정기 준값이나사용품질기준값을고려하여소프트웨어제품을평가 한다. 유지보수자는유지보수성에대한메트릭을사용하여소프트웨어 제품을평가한다. 서로다른환경에서소프트웨어설치를담당한사람은이식성에 대한메트릭을사용하여소프트웨어제품을평가한다. 개발자는모든품질특성에대한내부측정을사용한기준값에 대비하여소프트웨어제품을평가한다. 참고- ISO/IEC 은메트릭선정을위한지침과소프트웨어 제품평가를위한측정기준을제공한다

20 사. 제품간의비교를위한측정요구사항 제품간이나기준값간의신뢰성있는비교를하기위해서는엄격한메 트릭이필요하다. 측정절차는소프트웨어품질특성 ( 혹은부특성) 에대 해기준을설정하고비교를할수있도록충분한정확성을가지고측정해 야한다. 점검표에의한자료와전문가의견등은서로다른속성을가진 제품을비교할경우에는신뢰성이낮을수있다. 측정도구나사람의실수 로인한측정오류의허용치도있어야한다. 비교를위해사용되는메트릭은신뢰성있는비교를수행하는데사용 할수있기위해타당해야하며정확해야한다. 이는측정이객관적이며, 간격또는보다나은측정범위를사용한경험적이며, 재생성할수있어야 함을요구한다. 객관적이기위해서, 제품의속성에따라적용될수치나범주에대 해문서로작성된합의절차가있어야한다. 경험적이기위해서, 자료들은관찰이나혹은타당한설문조사에 의해수집되어야하며, 간격, 비율, 또는절대치범주로측정되어 야한다. 재생성할수있기위해서, 측정절차는서로다른사람이상이한 경우에소프트웨어제품에대해동일한측정을시행한결과가동 일하게( 적절한오차한계내에서) 나와야한다. 내부메트릭은또한예언적인타당성을가져야한다. 즉이들은일부 원하는외부측정과상관관계가있어야한다. 예를들어, 특정소프트웨어 의속성에대한내부측정은그소프트웨어가사용될경우에측정가능한 일부품질측면과상관관계가있어야한다. 측정으로주어지는값이통상 적인기대치와일치되는것이중요하다. 예를들어, 측정에서제품의품질

21 이높은것으로나왔다면, 이는특정사용자요구사항에따라만족하는제 품이나와야한다 소프트웨어품질특성 본항에서는소프트웨어품질특성 (Software Quality Characteristics) 에대하여살펴본다. 앞서언급한품질모델은소프트웨어제품의품질속 성을여섯가지특성( 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성) 으로구분하고있다. 이들은다시그아래에부특성들로세분된다. 부특성 들은내부혹은외부메트릭으로측정할수있다. 또한순수한외부메트 릭이있다. 각품질특성과그품질특성에영향을미치는소프트웨어부특성에대 해서는정의된다. 측정가능한내부속성에의해각특성과부특성에대한 그소프트웨어능력이결정된다. 내부메트릭의예는 ISO/IEC 에 나와있다. 특성과부특성은그소프트웨어를포함하고있는시스템이제공 하는능력정도에의해외부적으로측정될수있다. 외부메트릭의예는 ISO/IEC 에나와있다. 참고 - ISO/IEC 9126의이부분에있는일부특성은의존성 (dependability) 과연관이있다. 의존성특성은모든유형의시스템에대 해 IEC 50(191) 에정의되어있으며, ISO/IEC 9126의이부분에있는용 어가 IEC 50(191) 에정의되어있고, 이정의는폭넓은호환성이있다 기능성 (Functionality) 소프트웨어가특정조건에서사용될때, 명시된요구와내재된요구를

22 만족하는기능에대한소프트웨어제품의능력. 참고- 다른특성들은주로소프트웨어가언제, 그리고어떻게동작하는 가에초점을두는반면, 이특성은요구를충족하기위해서소프트웨어가 무엇을하는가에관심을둔다. 특성의명시된요구와내재된요구에대해서는품질정의부분에기술 된참고를적용한다. 사용자에의해운영되는시스템에대해서기능성, 신뢰성, 사용성, 그리 고효율성의복합적인사항은사용품질에의해외부적으로측정될수있 다. 가. 적합성 (Suitability) 지정된작업과사용자목적에따라적절한기능들을제공하는소프트 웨어제품의능력. 참고 적합성의예로는구성요소가되는부기능, 테이블용량등으로부터나 오는작업위주의복합기능이있다. 적합성은 ISO 에있는작업을위한적합성에대응된다. 적합성은운영성에영향을준다. 나. 정확성 (Accuracy) 올바른혹은합의된결과를제공할수있는소프트웨어제품의능력. 참고

23 이것은계산된값이필요한정밀도를가지는예상데이터를포함한다. 다. 상호운영성 (Interoperability) 하나이상의명세된시스템과상호작용할수있는소프트웨어제품의능력. 참고 상호운영성은대체성(Replaceability) 과혼동될수있으므로이를피하기위해서호환성(Compatibility) 대신에사용되었다. 라. 보안성 (Security) 권한이없는사람혹은시스템은정보를읽거나변경하지못하게하고, 권한이있는사람혹은시스템은정보에대한접근이거부되지않도록정보를보호하는소프트웨어제품의능력. 참고 이것은전송중인데이터에도적용된다. 안전성(Safety) 은소프트웨어에만관련된것이아니라전체시스템에관련되기때문에사용품질의부특성으로정의된다. 마. 준수성 (Compliance) 응용과관련된표준, 관례또는법적규제및유사한규정을준수하는 소프트웨어제품의능력 신뢰성 (Reliability) 소프트웨어가명세된조건에서사용될때, 성능수준을유지할수있는

24 소프트웨어제품의능력. 참고 소프트웨어는해지거나낡지않는다. 신뢰성의한계는요구사항, 설계 및결함에원인을제공한다. 이러한결함으로인한고장은사용경과 시간보다는소프트웨어제품의사용방법과선정된프로그램선택사 항에따라달라질수있다. ISO/IEC DIS :1994 에서는신뢰성의정의를 " 요구된기능을 수행하는기능적단위의능력" 으로하고있다. 이문서에서, 기능성은 단지소프트웨어품질특성중의하나일뿐이다. 그러므로기능성의정 의를 " 요구된기능을수행하는 " 대신에 " 성능수준을유지하 는 " 으로확장한것이다. 가. 성숙성 (Maturity) 능력. 소프트웨어내의결함으로인한고장을피해가는소프트웨어제품의 나. 결함허용성 (Fault Tolerance) 명세된인터페이스의위반혹은소프트웨어결함이발생했을때명세된성능수준을유지할수있는소프트웨어제품의능력. 참고 성능의명세된수준은고장안정능력(fail safe capability) 을포함한다. 다. 복구성 (Recoverability) 고장발생시명세된성능수준을다시유지하고직접적으로영향받은데이터를복구하는소프트웨어제품의능력. 참고

25 소프트웨어제품은고장난후에때때로복구성으로판정될수있는 일정시간동안작동이멈출수있다. 가용성(Availability) 이란명시된사용환경에서특정시점에요구되는 기능을수행할수있는소프트웨어제품의능력이다. 외부적으로가용성 은소프트웨어제품이정상작동하는전체시간의비율로써판정된다. 그러므로가용성은성숙성( 고장율), 결함허용성, 복구성( 각고장의작 동중지시간) 등의복합체라할수있다. 준수성 (Compliance) 능력. 신뢰성과관련된표준, 관례또는규제를준수하는소프트웨어제품의 사용성 (Usability) 명시된조건에서사용될경우, 사용자에의해이해되고, 학습되고, 사용 되고선호될수있는소프트웨어제품의능력. 참고 기능성, 신뢰성, 효율성등의몇몇특징들은사용성에영향을줄수있 지만 ISO/IEC 9126 의목적상사용성으로써분류되지않는다. 사용자에는소프트웨어사용에영향을받거나의존하는운영자, 최종 사용자, 그리고간접사용자등이포함된다. 사용성은사용준비나결 과평가등소프트웨어가영향을줄수있는모든사용자환경에대처 해야한다. 가. 이해성 (Understandability) 소프트웨어가적합한지, 그리고특정작업과사용조건에서어떻게사 용될수있는지를사용자가이해할수있도록하는소프트웨어제품의능 력

26 참고 이것은소프트웨어의문서가중요하다. 나. 학습성 (Learnability) 사용자가그응용을학습할수있도록하는소프트웨어제품의능력. 참고 학습을위한적합성에대응하는내부속성들은 어있다. ISO 에정의되 다. 운영성 (Operability) 사용자가소프트웨어제품을운영하고제어할수있도록하는소프트 웨어제품의능력. 참고 적합성, 변경성, 적응성, 설치성등의특징들은운영성에영향을미칠 수있다. ISO 에정의된바와같이제어성, 결함허용성, 사용자기대부 합성이운영성에대응된다. 사용자에의해운영되는시스템에대해서기능성, 신뢰성, 사용성, 그리 고효율성등의복합체는사용품질에의해외부적으로측정될수있 다. 라. 선호도 (Attractiveness) 사용자에의해선호되는소프트웨어제품의능력. 참고 이것은사용자가그소프트웨어에좀더호감을가질수있도록만드 는것이다. 예를들면색깔의사용이나그래픽설계등을말한다. 마. 준수성 (Compliance)

27 사용성과관련된표준, 관례, 유형안내및규제를준수하는소프트웨 어제품의능력 효율성 (Efficiency) 명시된조건에서사용되는자원의양에따라요구된성능을제공하는 소프트웨어제품의능력. 참고 자원은다른소프트웨어제품, 하드웨어장비, 재료( 예, 인쇄용지, 디스 켓) 등을포함한다. 사용자에의해운영되는시스템에대해서기능성, 신뢰성, 운영성, 그리 고효율성등의복합체는사용품질에의해외부적으로측정될수있 다. 가. 시간반응성 (Time Behaviour) 명시된조건에서그기능을수행할때적절한반응및처리시간과처리 율을제공하는소프트웨어제품의능력. 나. 자원활용성 (Resource Utilization) 명시된조건에서소프트웨어가그기능을수행할때적절한양과종류 의자원을사용하는소프트웨어제품의능력. 다. 준수성 (Compliance) 효율성과관련된표준및관례를준수하는소프트웨어제품의능력 유지보수성 (Maintainability)

28 소프트웨어제품이변경되는능력. 변경에는환경과요구사항및기능 적명세에따른소프트웨어의수정, 개선, 혹은개작(adaptation) 등이포 함된다. 가. 분석성 (Analyzability) 소프트웨어의결함이나고장의원인혹은변경될부분들의식별에대 한진단을가능하게하는소프트웨어제품의능력. 나. 변경성 (Changeability) 변경명세가구현될수있도록하는소프트웨어제품의능력. 참고 구현은코딩, 설계, 문서화등의변경을포함한다. 소프트웨어가최종사용자에의해변경된다면변경성은운영성에영향 을미칠수있다. 다. 안정성 (Stability) 능력. 소프트웨어변경으로인한예상치않은결과를최소화하는소프트웨어 라. 시험성 (Testability) 변경된소프트웨어가확인될수있는소프트웨어제품의능력. 마. 준수성 (Compliance) 유지보수성과관련된표준및관례를준수하는소프트웨어능력 이식성 (Portability)

29 한환경에서다른환경으로전이될수있는소프트웨어제품의능력. 참고 환경은조직, 하드웨어혹은소프트웨어환경을말한다. 가. 적응성 (Adaptability) 소프트웨어에서원래목적으로제공되는것이외의다른명세된환경 으로변경될수있는소프트웨어제품의능력. 참고 적응성은내부용량( 예, 화면영역, 테이블, 트랜잭션크기, 보고서형식 등) 의확장성을포함한다. 소프트웨어가최종사용자에의해개작된다면적응성은 ISO 에 정의된바와같이개별화를위한적합성에대응되며, 운영성에영향을 줄수있다. 나. 설치성 (Installability) 명세된환경에설치될수있는소프트웨어제품의능력. 참고 소프트웨어가최종사용자에의해설치된다면설치성은적합성과운영성에영향을줄수있다. 다. 공존성 (Co-existence) 공통자원을공유하는공동환경에서다른독립적인소프트웨어와공존 할수있는소프트웨어제품의능력. 라. 대체성 (Replaceability) 동일한환경에서동일한목적으로다른지정된소프트웨어제품을대

30 신하여사용될수있는소프트웨어제품의능력. 참고 대체성은사용자가소프트웨어제품을새로운버전으로업그레이드할때중요하다. 대체성은상호운영성과의혼동을피하기위해호환성을대신하여사용될수있다. 대체성은설치성과적합성두가지모두의속성을포함한다. 마. 준수성 (Compliance) 이식성과관련된표준및관례를준수하는소프트웨어제품의능력 사용품질특성 본항에서는본표준의사용품질특성 (Quality in Use Characteristics) 에대하여살펴본다. 특정사용자에의해사용되는제품 이지정된사용과관련하여유효성, 생산성, 안전성, 만족도등의명시된 목표를달성하기위해사용자요구를충족하는정도. 참고 사용품질은소프트웨어를포함하고있는시스템의품질을사용자관점 에서본것이며, 소프트웨어자체의성질보다는그소프트웨어를사용 한결과에의해측정된다. 사용품질에대한메트릭의예는 ISO/IEC 에나와있다. 사용성은 ISO 에서 ISO/IEC 9126의이부분에서정의된사용 품질과유사하게정의되어있다. 사용품질은모든품질특성에의해 영향을받을수있으며, 따라서 ISO/IEC 에서이해성, 학습성, 운영성및호감성의관점에서정의된사용성보다더넓은의미를갖는 다

31 가. 유효성 (Effectiveness) 명시된조건하에서사용자가정해진목표를달성할수있게해주는소 프트웨어제품의정확성과완벽성정도. 나. 생산성 (Productivity) 소프트웨어제품이명시된조건하에서사용될경우에유효성과관련하 여시스템이나사용자가소비하는자원의정도. 참고 - 관련되는자원에는시간, 노력, 재료, 혹은재정비용등이 있다. 다. 안전성 (Safety) 소프트웨어제품이명시된조건하에서 험을수용가능한수준으로제한하는정도. 참고 - 이정의는 ISO 8402 에기반한다. ( 사람에대한) 상해나피해의위 라. 만족도 (Satisfaction) 지정된조건하에서소프트웨어제품이사용자를만족시키는정도. 참고 - 만족도에대한신뢰성있는데이터를수집하기위해설문지를사용할수있다 ISO/IEC 9126용어정의 1) 구매자 (Acquirer) 공급자로부터시스템, 소프트웨어제품, 또는소프트웨어서비스를구 매혹은조달하는조직

32 2) 속성 (Attribute) 한개체의측정가능한물리적혹은추상적성질 참고 - 속성은내부적또는외부적일수있다. 3) 개발자 (Developer) 소프트웨어생명주기동안개발활동( 요구분석, 설계, 시험에서인수 까지) 을수행하는조직 4) 직접측정 (Direct Measure) 다른속성의측정에의존하지않는속성의측정 5) 평가모듈 (Evaluation Module) 키지 특정소프트웨어품질특성및부특성에대한평가기술을모아놓은패 6) 외부측정 (External Measure) 해당제품을일부분으로하는시스템의행태를측정함으로써유추되는 간접적인제품측정 참고 시스템에는모든관련된하드웨어, 소프트웨어( 주문형소프트웨어또는 기성형소프트웨어) 및사용자등이포함된다. 해당프로그램을실행하는컴퓨터시스템이운영되는동안에고장횟 수를누적하므로, 시험기간동안발견되는고장횟수는그프로그램에 존재하는결함의개수에대한외부측정이된다. 부측정은설계의궁극적목적에보다가까운품질속성을평가하는 데사용되어질수있다. 7) 외부품질 (External Quality) 제품이지정된조건하에서사용될경우에, 명시된요구와내재된요구 를충족하는정도

33 8) 실패 (Failure) 필요한기능을수행하는동안예상치못한기능종료혹은미리지정된 내에서의수행불능 9) 결함 (Fault) 컴퓨터프로그램내부의부정확한절차, 처리혹은데이터정의 참고 - 이정의는 10) 내재된요구 (Implied Needs) IEEE 에서인용하였다. 명시되지는않았지만해당개체가특정조건에서사용될경우의실질 적인요구 참고 - 내재된요구는문서화되지않을수있지만실재로필요한요구이 다. 11) 표시자 (Indicator) 다른측정을예상하거나예측하는데사용가능한측정 참고 예상된측정은동일한또는서로다른소프트웨어의품질특성에대한 측정이될수있다. 표시자는소프트웨어품질속성과생산프로세스의속성, 양쪽모두를 예측하는데사용될수있다. 이들은속성에대한간접측정이다. 12) 간접측정 (Indirect Measure) 하나이상의다른속성으로부터유추가능한속성측정 참고 측정이소프트웨어속성뿐만아니라컴퓨팅환경의속성에의해서도 영향을받으므로, ( 사용자입력에대한응답시간과같은) 컴퓨팅시스 템속성에대한외부측정은소프트웨어속성에대한간접측정이된 다. 13) 중간소프트웨어제품 (Intermediate Software Product)

34 소프트웨어개발프로세스에서다른단계의입력으로사용되는소프트 웨어개발프로세스중의제품 참고 - 어떤경우에는중간제품이또한최종제품이될수도있다. 14) 내부측정 (Internal Measure) 제품자체에대한직접혹은간접측정 참고 코드라인수, 복잡도, 워크스루(walkthrough) 에서발견되는결함의개 수및포그지수(fog index) 등은모두제품자체에대한내부측정들 이다. 15) 내부품질 (Internal Quality) 제품이지정된조건에서사용될경우에, 명시된요구와내재된요구를 충족할수있는능력을결정하는제품속성의총체 참고 본표준에서 외부품질 과대비되는의미로사용되는 내부품질 이라 는용어는 ISO 8402 에서의 품질 과근본적으로같은의미이다. ISO/IEC 9126 에서 특성 이라는용어는보다특정한의미로사용되므 로, 속성 이라는용어가 특성 과같은의미로사용되었다. 16) 유지보수자 (Maintainer) 유지보수활동을수행하는조직 17) 측정하다(Measure ( 동사)) 측정을수행하다. 18) 측정치(Measure ( 명사)) 측정을통해개체의속성에배정되는수치나범주 19) 측정 (Measurement) 개체의속성에등급값( 수치나범주일수있음) 을배정하기위한메트

35 릭의사용 참고 범주를사용할경우에, 측정은정성적(qualitative) 일수있다. 예를들 어, 원시프로그램언어(ADA, C, COBOL 등) 와같은소프트웨어제품 의일부중요한속성은정량적인범주이다. 20) 메트릭 정의된측정방법및측정등급 참고 메트릭은내부혹은외부, 또는직접혹은간접적일수있다. 메트릭은정성적인자료의분류방법을포함한다. 21) 품질 (Quality) 명시된요구와내재된요구를충족할수있는능력을가진개체특성들 의총체 참고 계약의경우나혹은핵안전성분야와같은통제된환경에서는요구가 명세되어야하며, 정의해야한다 반면에다른환경에서는내재된요구들을구분하고 (ISO 8402:1994, 참고 1). ISO/IEC 에서관련된개체는소프트웨어제품이다. 22) 품질평가 (Quality Evaluation) 조사 한개체가명세된요구사항을충족시킬수있는정도에대한체계적인 참고 요구사항은제품이계약하에어떤특정사용자를위해개발될경우처 럼, 공식적으로명시될수도있고, 또는소비자소프트웨어와같이불 특정사용자들을위해개발될경우처럼개발조직이명세할수도있으 며, 혹은사용자가비교나선정을목적으로제품을평가하는경우처럼 그요구사항이보다일반적일수도있다

36 23) 품질모델 (Quality Model) 품질요구사항을명세하고품질을평가하는기준을제공하는특성집합 과그들간의상호관계 24) 사용품질 (Quality In Use) 특정사용자에의해사용되는제품이지정된사용의경우에유효성, 작 업효율, 만족도등과관련하여명시된목표를달성하기위해사용자요구 를충족하는정도 25) 판정 (Rating) 측정된값을적절한판정등급으로결정하는활동. 특정품질특성을 갖는소프트웨어와관련된판정등급을결정하기위해사용된다. 26) 판정등급 (Rating Level) 측정범주를구분하기위해사용되는순차적인범주상의지점 참고 판정등급은명시되거나내재된요구에따라소프트웨어를분류( 판정) 할 수있게한다. 적절한판정등급은사용자, 관리자및개발자등과같이품질을보는 관점과연관될수있다. 27) 범위 (Scale) 정의된성질을갖는값들의집합 참고 범위에대한예는다음과같다. 일련의구분에해당되는명목적범위 순서화된일련의범위점(Scale Point) 에해당되는순서적범위 같은간격의범위점을갖는순서적범위에해당되는간격범위 (Interval Scale) 같은간격의범위점뿐만아니라절대값 0 을갖는비율범위

37 명목적또는순서적범위를사용하는메트릭은정성적자료를생성하 고, 간격범위와비율범위를사용하는메트릭은정량적자료를생성한 다. 28) 소프트웨어 (Software) 부분 정보처리시스템의모든프로그램, 절차, 규칙및관련문서혹은그일 참고 소프트웨어는기록되는매체에독립적인지적생산물이다. 29) 소프트웨어제품 (Software Product) 컴퓨터프로그램, 절차, 또는관련문서및데이터의집합 참고 제품에는중간제품과개발자나유지보수자와같은사용자를위해만 들어진제품도포함된다. 30) 공급자 (Supplier) 계약조건하에시스템, 소프트웨어제품또는소프트웨어서비스의공급 에대해구매자와계약을맺는조직 31) 시스템 (System) 명시된요구나목적을충족시키는능력을제공하는하나이상의프로 세스, 하드웨어, 소프트웨어, 장비및사람으로구성되는결합체 32) 사용자 (User) 특정기능을수행하기위해소프트웨어제품을사용하는개인 참고 사용자에는운영담당자, 소프트웨어결과수령자, 또는소프트웨어개 발자및유지보수자등이포함될수있다. 33) 확인 (Validation) 지정된목적의사용을위해특정요구사항을충족하는객관적증거에

38 대한검사및규정에의한확인. 참고 설계및개발단계에서확인은사용자요구에대한부합성을판단하기위해제품을검사하는프로세스를말한다. 확인은일반적으로정의된운영조건하에서최종제품을대상으로수행된다. 확인은그이전단계에서도필요할수있다. " 확인된(Validated)" 이란단어는상응되는상태를나타내기위해사용된다. 사용목적이다양하다면다중확인이수행될수있다. 34) 검증 (Verification) 명세된요구사항을충족시키는객관적증거에대한조사및규정에의한확인 참고 설계및개발과정에서검증은특정활동의결과가그활동에대해명시된요구사항에적합한가를판단하기위해조사하는프로세스를말한다. " 검증된(Verified)" 이란용어는상응되는상태를가리키기위해사용된다

39 2. ISO/IEC 적용범위 본항에서는 ISO/IEC12119 의적용범위(Scope) 에대하여살펴본다. 이규격은소프트웨어패키지들에적용할수있다. 예를들면문서처리기, 스프레드시트, 데이터베이스프로그램, 그래픽패키지, 기술적또는과학적 인기능들을위한프로그램, 그리고유틸리티프로그램들에적용될수있 다. 이규격은 소프트웨어패키지들에대한요구사항( 품질요구사항) 이러한요구사항들에대해소프트웨어패키지를시험하는방법에 관한지침( 시험을위한지침, 특히제 3 자시험에대한지침) 을수립하고있다. 이규격은단지제공되고인도된상태의소프트웨어패키지만을다룬 다. 이규격은( 각활동과, 예를들어명세서와같은중간산출물을포함한) 소프트웨어패키지의생산공정을취급하지않는다. 공급자의품질시스템 (Quality System) 은이규격의범위밖이다. 주 - 일부소프트웨어 ( 예, 안전성이중요한소프트웨어 ) 는추가적인요 구사항을필요로한다. 규격의사용자 이규격의사용자는다음과같은사람들이될수있다. 공급자가 소프트웨어패키지에대한요구사항을명세화할때

40 제품설명형식을설계할때 자신의제품을심사할때 적합성을선언할때 [ISO/IEC Guide 22] 적합성인증서나마크를신청할때 [ISO/IEC Guide 23] 국제, 지역, 국내인증기관에서제3자인증체계를수립하려고할때 [ISO/IEC Guide 16, 28, 44] 시험지침을따라야하는시험소에서적합성인증서나마크를위한시 험을할때 [ISO/IEC Guide 25]; 인정기관이인증기관과시험소를인정할때 [ISO/IEC Guide 40, 58]; 시험소심사원이시험소의능력을심사할때 [ISO/IEC Guide 58]; 구매자가 자신들의요구사항과이규격에서기술된요구사항을비교할때 의도하는업무요구와기존제품의제품설명서의정보를비교할때 인증된제품을찾을때 요구사항이충족될때다른방법으로체크할때 보다나은제품에서이익을얻고자하는사용자 정의 이규격에서는다음과같은정의(Definition) 가사용된다. 참조하기편 하도록다른규격들에서사용되고있는정의들은부속서 다. 1) 기능 A에수록되어있 사용자나프로그램이업무의일부또는전부를수행할수있도록하는 프로그램내의알고리즘구현. 참고1. 기능은반드시사용자에의해호출될수있어야만하는것 은아니다 ( 예, 백업이나저장의자동화). 참고 2. 여기기능의개념은 ISO :1978( 고장, 결점, 유지보

41 수그리고신뢰성의정의) 에서사용된것보다더좁은의미이지 만, ISO 와 ISO 에서정의된것보다는더넓은의 미를갖는다. 2) 요구사항문서 소프트웨어패키지가만족시켜야할권고사항이나요구사항또는규제 사항을포함하고있는문서. 참고- 그룹( 시장부문이나기술협회또는사용자협회), 법률또는 공고에서나온기술또는인간공학규격, 요구사항목록( 또는모 델요구사항명세서) 등이그예이다. 3) 제품설명서 소프트웨어패키지의속성을설명하는문서로서, 이의주된목적은잠 재적인구매자가제품구입에앞서스스로그제품이합당한지 (suitability) 평가할수있도록도움을주는데있다. 참고- 이용어는 ISO/IEC :1990 의 " 시스템설명서" 라는용 어보다는더자세하다. 제품설명서의목적은 ISO 9127 의 " 표지정 보" 의제품설명서를포함하고있다. 라다른목적으로사용된다. 4) 사용자문서 제품설명서는명세서가아니 인쇄또는비인쇄형태의사용가능한전체문서들의집합으로, 제품의 적용을위해제공되며, 또한그자체가제품의중요한부분이다. 5) 패키지문서 패키지제품설명서및사용자문서. 6) 시험사례 시험자를위해문서화된지침으로서, 한기능이나여러기능의조합이 어떻게시험되어야하는가를명세한다. 하나의시험사례는다음과같은

42 주제에대해세부적인정보를포함한다 시험목적 시험될기능들 시험환경과여타조건들( 구성의상세내용및예비작업) 시험데이터 절차 시스템의예측되는행동 7) 유지보수 소프트웨어패키지수정과관련된시스템유지보수의한부분 품질요구사항 본표준의품질요구사항 (Quality Requirements) 은다음과같다. 세부조항 (1) 부터 (3) 까지는 각소프트웨어패키지가제품설명서와사용자문서를가지고있어 야한다는요구사항 제품설명서에대한요구사항. 특히제품설명서가명시된정보를 포함시켜야하며각문장은시험가능하고정확해야한다는요구사 항이있다 사용자문서에대한요구사항 소프트웨어패키지내에포함된프로그램이나데이터가있을경우 그에대한요구사항 참고1 사용자문서, 프로그램과데이터에대한요구사항은많은일반적 요구사항( 제품설명서에서약속하고있는것과는다른것) 을담고있으 나사용자가바랄수있는모든속성을포함하지는않는다. 참고 2 특정속성, 예를들어사용자문서와프로그램메시지의 " 이해가

43 능성" 과 " 개괄용의성" 등은명백히사용자관점에서요구된다. 그러나 명쾌하고반복적인결과를얻을수있는시험이어렵기때문에, 이러한 속성들은현재로서는단지권고로서규정될뿐이다. 참고 3 세부조항 (1) 부터 (3) 까지는 ISO/IEC 9126에나오는특성과같 은순서로배열되어있다. 어떤소프트웨어패키지가 (1) 부터 (3) 까지의모든요구사항에따 른다면, 이는이규격에적합한것이다. 권고("-- 하는것이바람직하다 " 는 단어형식을써서지시하고있는) 들은선택사항이다. 참고4 - 어떤제품이 (1) 부터 (3) 까지의요구사항에제품이적합한지 여부를증명하기는매우어렵거나불가능할수도있다 제품설명서 각소프트웨어패키지는제품설명서를갖고있어야한다. 제품설명서는제품을정의한다. 이는제품의패키지문서화의일부분이 다. 이는사용자문서와프로그램, 그리고데이터에대해정보가있을경우 이를제공한다. 제품설명서의주목적은첫째, 사용자나잠재적구매자가그제품이합 당한지를스스로평가할수있도록하기위함이다. 여기까지는판매정보 이기도하다. 둘째, 시험을위한토대로사용하기위함이다. 셋째, 제품설명 서는그제품에관심을갖는사람들에게이용가능해야한다. 가. 내용에관한일반적인요구사항 제품설명서는잠재적구매자가제품을구입하기앞서스스로이의합 당함을평가할수있도록충분히이해할수있고, 완전하며개괄하기쉬운 것이바람직하다

44 제품설명서는내부불일치성이없어야한다. 용어는모든곳에서동일 한의미를지녀야한다. 제품설명서의문장은시험가능하고정확해야한다. 참고- 이요구사항은만일제기된외적인요구사항문서들이있다면그것 의설명문까지해당된다. 다음의세부조항 2) 부터 8) 까지는제품설명서에꼭포함해야하거나포 함하도록권고되는것을명시한다. 여기에는제품에대한추가적인문장을 포함할수있다. 나. 식별과지시 1) 제품설명서의식별 제품설명서는유일한문서식별을포함해야한다. 제품설명서는예를 들면 " 기능설명서", " 제품정보", " 제품서" 와같이 " 제품설명서 " 와다르 게불릴수있다. 2) 제품의식별 제품설명서는제품을식별해야한다. 제품식별은최소한제품이름과 버전또는날짜를갖고있어야한다. 3) 공급자 제품설명서는최소한한공급자의이름과주소를담고있어야한다. 주 - 이름과주소는반드시인쇄될필요는없다딜러의고무도장으로도충 분하다. 4) 업무 (work task) 한다. 제품설명서는제품을가지고수행될수있는의도된작업을식별해야

45 5) 요구사항문서에적합성 제품설명서는제품이따르고있는요구사항문서들을참고할수있는 데이경우관련된간행물(editions) 은식별되어야한다. 6) 요구되는시스템 제품을사용할때요구되는시스템( 하드웨어, 소프트웨어그리고이의 구성) 은제조업자이름과모든구성부분의형태식별자를포함하여명시되 어야한다. 예를들면다음과같다. 코프로세서를포함하는프로세스유닛 주메모리크기 주변( 보조) 저장의유형과크기 확장카드 입출력장비 네트워크환경 시스템소프트웨어와기타소프트웨어 예를들면, 다른업무, 다른범위값또는다른효율성요구사항을위해 다른요구되는시스템이명시될수있다. 이전에하드웨어나소프트웨어제품이식별되어있다면, "( 또는, 상호운영 이가능하다면, 또다른... )" 이라는문장이제품설명서에나타날수있 다. 과거에제품의버전이식별되어있다면 " 또는상호운영가능한갱신 된버전" 이라는설명이들어있을수있다. " 버전 X부터최소한버전Y 까 지" 라는설명이있을수있지만, " 버전 X 부터" 라는설명은있어서는안된 다. 주 - " 버전 X 부터" 라는설명은소프트웨어패키지가운영에실패할수있 는버전 X+3 의등장에의하여후에잘못된것으로될수있다. 7) 다른제품과의인터페이스

46 만일제품설명서가다른제품을참조한다면, 그인터페이스또는제품이 식별되어야한다. 8) 인도될항목 제공되는제품의모든물리적구성부분, 특히모든인쇄된문서와모 든데이터미디어는식별되어야한다. 예를들면, 원시프로그램, 목적모듈, 또는실행모듈과같이공급되는 프로그램의형태가설명되어야한다. 주 - 미디어포맷( 예를들어디스켓포맷) 을표시할필요는없다. 요구되 는시스템에의해가능한포맷이결정되기때문이다. 9) 설치 제품설명서에는제품의설치가사용자에의해수행될수있는지그여 부가언급되어야한다. 10) 지원 한다. 제품설명서에는제품운영을위한지원이제공되고있는지언급되어야 11) 유지보수 제품설명서에는유지보수의제공여부가언급되어야한다. 유지보수가 제공된다면, 무엇이정확히포함되는지를언급해야한다. 다. 기능성에대한설명 1) 기능의개괄 제품설명서는제품이갖고있는사용자가호출가능한기능, 필요한데 이터, 그리고제공되는설비에대한전반적인개괄을제공해야한다. 각언급된기능( 특히선택사항이나변형) 에대해그것이

47 제품의부분인지 제품설명서에서완전히설명된제품확장부분인지 제품설명서에서참조된제품확장의부분인지 보증이안된추가( 보충) 부분인지 명백히설명되어야한다. 참고 - 사용자가호출가능한모든기능이언급될필요는없고, 모든기능 에대해그것이어떻게호출되는지에대해상세한내용을제시할필요는 없다. 2) 범위값 만일제품사용이제품의특정범위값에의하여제한받는다면이러한 값들은제공되어야한다. 예를들면다음과같다. 최소또는최대값 키의길이 파일내레코드의최대수 탐색기준의최대수 최소샘플크기 고정된범위값을제공할수없는경우( 예를들어, 이값들이어플리케 이션(application) 의형태나입력데이터에의존할때) 에는그한계가언급 되어야한다. 허용될수있는값의조합이제공될수있으며사용자문서 내에보다상세한정보가참조될수있어야한다. 3) 보안 제품설명서는우연이든의도적이든프로그램과데이터에권한이없는 접근을방어할수있는수단에대한정보를포함하는것이바람직하다. 라. 신뢰성에대한설명

48 참고 제품설명서는데이터저장절차에대한정보를포함해야한다. 충분하다. - 예를들어, 운영체제에의해백업이가능하다고언급하는것으로 제품의기능적능력을보장하는추가적인제품속성이설명되는것이바람 직하다. 예를들면, 다음과같은것이있다. 입력이적절한지여부의체크 사용자잘못으로인해빚어지는중대한결과의방어 에러복구 마. 사용성에대한설명 1) 사용자인터페이스 명령라인, 메뉴, 윈도우, 기능키, 도움말기능같이사용자인터페이스 유형은이름이붙여져야한다. 2) 요구되는지식 제품을적용하는데요구되는특정지식은명시되어야한다. 예를들면 다음과같은것이있다. 기술적영역에대한지식 운영체계에대한지식 특정훈련에의해획득될수있는지식 제품설명서에쓰여진것이외의언어에대한지식( 에러메시지와 비주얼데이터를포함하여) 사용자문서및사용자인터페이스에서 사용된언어는소프트웨어패키지자체와제품설명서에서참조한 다른제품에서사용되어야한다. 참고 - 이요구사항은 ISO/IEC 9127:1988, 6.1.7의요구사항을넘어서 는것이다. 그규격에서는언어에관한언급은선택적사항이다

49 사용자필요에따른개조 (adaptation) 만일제품이사용자에의해개조될수있다면, 개조를위한도구와그 사용에대한조건이식별되어야한다. 예를들면다음과같다. 매개변수의변경 연산알고리즘의변경 기능키에대한할당 3) 저작권침해에대한방지 저작권침해에대한기술적인보호가사용성을해칠수있다면, 이보 호조치는언급되어야한다. 예를들면다음과같다. 복사에대한기술적보호 프로그램된사용만료기간 복사(copy) 에대해지불을하라는대화식경고(reminder) 4) 사용효율성및사용자만족 있다. 제품설명서는사용효율성및사용자만족에관한데이터를포함할수 주 - 그와같은데이터는 ISO 의지침을따를수있다. 바. 효율성에대한설명제품설명서는명시된조건( 예를들어시스템구성과로드프로파일 ) 하에서주어진기능의반응시간및처리율등과같은제품의시간적행위에대한데이터를포함할수있다. 사. 유지보수성에대한설명 제품설명서는유지보수성에관한설명을포함할수있다

50 아. 이식성에대한설명 제품설명서는이식성에관한설명을포함할수있다. 1) 사용자문서 완전성 사용자문서는제품사용에필요한정보를담고있어야한다. 제품설명 서에서언급한모든기능과프로그램내에서사용자가호출가능한모든 기능은사용자문서에서완전하게기술되어있어야한다. 한다. 제품설명서에서주어진모든범위값은사용자문서에서도반복되어야 만일설치가사용자에의해수행될수있다면, 사용자문서는필요한모 든정보를담고있는설치매뉴얼을포함해야한다. 설치매뉴얼은설치시 파일의최소/ 최대크기를말해주는것이바람직하다. 만일유지보수가사용자에의해수행될수있다면, 사용자문서는관련 된유지보수유형에대해필요한모든정보를담고있는프로그램유지보 수매뉴얼을포함해야한다. 정확성 사용자문서내의모든정보는정확해야한다. 또한사용자문서의표현은 모호하지않고에러가없어야한다. 일관성 사용자문서의문서들은스스로, 상호간, 또한제품설명서와불일치하지 않아야한다. 각용어는모든곳에서같은의미를지니는것이바람직하다. 이해성 사용자문서는언급된업무를일상적으로수행하는사용자들에게이해 될수있어야바람직하다. 예를들어, 적절한용어선택, 그래픽형태제시,

51 상세한설명사용, 유용한정보를참조함으로써가능하다. 개괄용의성 하다. 사용자문서는관계성을쉽게알수있도록개괄하기쉬운것이바람직 모든문서는목차와색인을갖추는것이바람직하다. 만일어떤문서가인쇄된형태로제공되지않는다면, 있는절차가설명되어야바람직하다. 이를인쇄할수 2) 프로그램및데이터 기능성 설치 만일설치가사용자에의해수행될수있다면, 프로그램을설치매뉴얼 에있는정보를따름으로써성공적으로프로그램을설치할수있다. 제품 설명서에제시된요구되는사항은시스템의각각에프로그램을설치하기 에충분해야한다. 설치에이어, 제공된시험사례를사용하거나대응되는메시지로자체 시험을하는방식으로프로그램이제대로기능할수있는지의여부를알 수있어야한다. 기능의존재 사용자문서에언급된모든기능은관련설비, 속성및데이터와함께, 그리고주어진범위값내에서, 사용자문서에서주어진형태로실행될수 있어야한다. 참고 - 제품설명서에서언급된모든기능은사용자문서에서도있어야 하기때문에, 그기능들이실행될수있어야한다는것은당연하다

52 정확성 프로그램과데이터는제품설명서및사용자문서에있는모든문장에 대응되어야한다. 기능들은업무에정확히실행되어야한다. 특히, 프로그 램과데이터는제품설명서에의해참조된요구사항문서내의모든요구사 항에따라야만한다. 일관성 프로그램과데이터는그자체내에, 그리고제품설명서및사용자문서 와불일치가없어야한다. 각각의용어는모든곳에서동일한의미를지니 는것이바람직하다. 프로그램운영통제와사용자에의한프로그램행위( 예를들어메시지, 입력스크린포맷, 인쇄된보고서) 는균일하게구조화되는것이바람직하 다. 신뢰성 하드웨어, 요구되는소프트웨어와그제품에속하는프로그램으로이루 어진시스템은사용자가이를통제할수없는상태에빠지지않아야하며, 데이터의훼손이나손실이일어나지않아야한다. 이요구는다음과같은경우에도충족되어야한다. - 처리능력이명시된한계까지올라간경우 - 명시된한계이상으로처리능력을끌어올리려는시도가가해지는경우 - 사용자에의해서또는제품설명서에나열된프로그램의다른곳으로부터잘못된입력이주어진경우 - 사용자문서화내의명확한지침을어긴경우

53 어떠한프로그램도감지할수없는하드웨어와운영체계인터럽션 ( 예 를들어시스템운영리셋을위한키나키의조합) 의가능성만은제외한 다. 프로그램은입력구문조건을어기는것을인식해야한다. 프로그램이 입력에대하여에러또는정의되지않은것으로인식하는경우, 프로그램 은이것을허용가능한입력으로서처리해서는안된다. 사용성 사용성에관해서는, 이규격에근거해합의하는당사자는 ISO 9241 리즈의가장최신판을적용할가능성을조사할것을권고한다. 시 참고 - 특히 ISO 9241 시리즈의 part 10과 13 을고려하는것이좋다. 이해가능성 프로그램의질문, 메시지그리고결과는이해할수있어야바람직하다. 예를들면다음과같다 용어의적절한선택에의해그래픽제시에의해배경정보의제공에의해도움말기능의설명에의해 에러메시지는 ( 예를들어사용자문서에있는항목을참조함으로써 ) 사 용에러에상응하는원인의설명또는시정방법을설명하는상세한정보 를제공해야한다. 개괄용의성 각각의데이터매체는제품식별을지녀야하며, 만일매체가하나이

54 상일때에는구별되는숫자나문장이있어야한다. 사용자를위해프로그램으로작업을할때어떤기능이실행되고있는 지를항상알수있어야한다. 프로그램은쉽게눈으로볼수있거나읽기쉬운형태로정보를사용자 에게제공하는것이바람직하다. 사용자는정보의적절한코딩및그룹화 에의해안내받는것이바람직하다. 필요하다면, 프로그램은사용자에게 경고를하는것이바람직하다. 프로그램으로부터의메시지는사용자가유형에의해쉽게구별할수 있도록설계되는것이바람직하다. 예를들면다음과같다. - 승인(acknowledgement) 프로그램으로부터의질의 경고 에러메시지 입력스크린포맷, 보고서, 기타입출력은명백하고개괄하기쉽게설 계되는것이바람직하다. 이를위해서는다음과같은것이있다. - 문자필드는왼쪽정렬된다. - 숫자필드는오른쪽정렬된다. - 테이블내의소수점이나콤마는같은수직선상에정렬된다. - 필드제한을알수있어야한다. - 필드의사용은필수적이며, 따라서그렇게알수있어야한다. - 입력실패는식별된입력스크린포맷내에서강조되어야한다

55 - 시각적이거나청각적인표시로써사용자의관심을스크린의내용변 화로이끌어야한다. 운영가능성 심각한결과를초래하는기능의실행은취소가능하거나, 프로그램이 그명령을실행하기전에결과에대해분명한경고를하고확인을요청하 도록해야한다. 특히, 데이터삭제및덮어쓰기, 장기적인프로세스수행 을인터럽트하는경우는심각한결과를빚게된다. 만일문서화하고있는문장이대화에제시되면, 예를들어전개된목차 테이블을선택하거나키워드에기반한탐색기능에의해서, 사용자가직접 그문장의하위항목을접근할수있는것이바람직하다. 효율성 아무것도요구되는것은없다. 서술하였다면이를따라야한다. 그러나제품설명서에서효율성에대해 유지보수성 아무것도요구되는것은없다. 그러나제품설명서에서유지보수성에대 해서술하였다면이를따라야한다. 이식성 아무것도요구되는것은없다. 서술하였다면이를따라야한다. 그러나제품설명서에서이식성에대해 2.4. 시험을위한지침 본항에서는시험을위한지침(Instructions for Testing) 에대하여살

56 펴본다. (1) 부터 (5) 까지의지침(instruction) 은품질요구사항에대해제 품이어떻게시험되어야하는가를명시하고있다. 이지침에는모든적합 한제품에서요구되는특성에대한시험과제품설명서에서약속한특성에 대한시험을포함한다. 이지침에는문서검사에의한시험과프로그램및 데이터의블랙박스시험을포함한다. 이지침들은기능시험( 블랙박스시험) 을기술한다. 구조적시험은원 시코드를이용해야하기때문에포함되지않는다. 제품이필요한시스템내의제품만이시험된다. 컴퓨터작업장에서의 인간공학적평가는이규격에서는고려되지않는다. 참고1. 이지침들은인증체계에따르는제 3자시험을일차적인목적 으로한다. 생산하는동안에는구조시험을하는것이더경제적이고효과 적일것이다. 참고 2. 조항 4는소프트웨어패키지에대한요구사항을담고있지않 다. 어떤소프트웨어패키지는조항 4에따른시험을받지않고서도인정 된다. 그러므로그시험은비적합성의존재를발견하지못할수도있다. 참고 3. 요구되는시스템이제품설명서에의해결정되기때문에, 요구 되는시스템과제품의어떠한비적합성도제품의비적합성으로취급된다. 참고 4. 인증체계는선택적인권고사항에대한시험을실시할수있다. 참고 5. 인간공학적평가에대한지침은 ISO 에있다 선행조건시험 가. 제품항목의존재 소프트웨어패키지를시험하기위해서는제품설명서에서식별된요구

57 사항문서들과아울러인도된모든항목이존재해야한다. 나. 시스템구성물의존재 소프트웨어패키지를시험하기위해서는제품설명서에서명명된모든 컴퓨터시스템의구성부분이이용될수있어야한다. 다. 훈련 만일제품설명서에훈련이언급되어있으면, 시험자는훈련자료와훈 련프로그램을이용해야한다 시험활동 제품설명서, 사용자문서, 소프트웨어패키지의부분으로서인도되는프 로그램과어떠한데이터도 조항 조항 4 의요구사항에따라서시험되는것이바람직하다. 4 의권고에따라서시험되는것이바람직하다. 시험대상은조항 함한다( 완벽성, 일관성등). 4의요구사항으로부터도출되며그모든것을포 만일제품설명서에다른제품이언급되어있다면, 이다른제품은 시험대상제품의제품설명서의내용만을위해서시험될필요가 있다. 제품설명서, 사용자문서, 제품의기능과데이터에있는세부사항은 다음과같은경우시험자의판단에따라반드시시험될필요는없 을수있다. 규정된업무의적절성에무시할정도로작은영향을미치거나 원칙적으로는시험될수있지만비용에서타당하지못할때 시험되지않은세부사항은시험기록과시험보고서에언급되어야한 다. 이것들을시험하지않은이유를시험기록에문서로남겨야한다

58 가. 제품설명서 조항 4의요구사항을충족하고있는가시험되어야하며조항 4의권고 를충족하고있는가도시험되는것이바람직하다. 나. 사용자문서 조항 4에있는요구사항을충족하고있는가시험되어야하며조항 4의 권고를충족하고있는가도시험되는것이바람직하다. 다. 프로그램과데이터 조항 4에있는요구사항를충족하고있는가시험되어야하며조항 4의 권고를충족하고있는가도시험되는것이바람직하다. 한다. 제품설명서에명명된모든컴퓨터시스템에서프로그램은시험되어야 만일몇개의프로그램변형( 상이) 이있다면, 그각각은시험되어야한 다. 제품설명서와사용자문서에따라, 여러변형( 상이) 에서동일한기능은 하나의변형에서각각시험될수도있다. 프로그램및이와함께공급되는데이터는제품설명서사용자문서에 근거하여구성된시험사례를이용하여시험되어야한다. 추가적인자료 ( 예를들어원시코드) 는제품설명서와사용자문서의주장을테스트함에 있어서필요하지않는한굳이고려될필요는없다. 테스트사례는방법론적으로그리고체계적으로구성되어야한다. 만일사용자문서에서예가주어진다면테스트사례로서이용되어야하 지만, 테스트는이예들에한정되어서는안된다. 소프트웨어패키지의공급자에의해서제공된테스트사례는이용될

59 수있지만, 테스트는이사례들에한정되어서는안된다. 1) 설치 만일제품설명서에따라사용자에의해설치가수행될수있다면, 설치 매뉴얼에서술되어있는데로프로그램이설치될수있고또성공적으로설 치되는가테스트되어야한다. 그렇지않으면설치된프로그램의하드웨어와소프트웨어환경이고려 중인컴퓨터시스템을위한제품설명서의서술과상응하는지확인되어야 한다. 2) 프로그램실행 테스트사례는제품설명서와사용자문서에서기술된모든기능을포괄 해야한다. 그리고업무를위해대표되는기능의조합을고려해야한다. 프로그램은범위값( 제품설명서와사용자문서에따라) 이적용되는요구 시스템에서모든범위값에대해테스트되어야한다. 사용자문서에서금지한다고명백하게반대하고있거나선언하고있는 입력과명령절차는테스트에서사용되어야한다 테스트기록 각테스트에대한기록은반복적인테스트를허용할수있도록다음과 같은충분한정보를갖추어야한다 [ISO/IEC Guide 25]. 테스트계획이나테스트사례를포함한테스트명세 테스트하는동안발생한고장을포함하여테스트사례와관련된 모든결과 테스트에참가한사람들의식별 테스트보고서

60 테스트의대상과결과는 ( 테스트기록에기록된데로) 테스트보고서에 요약되어야한다. 테스트보고서는다음과같은구조를갖춰야한다. 제품식별 테스트에이용된컴퓨터시스템( 하드웨어, 구성 ) 사용된문서( 식별도함께) 소프트웨어그리고그 제품설명서, 사용자문서, 프로그램과데이터의테스트의결과 요구와일치하지않는것의목록 권고와일치하지않는것의목록또는준수되지않은권고의목 록, 또는제품이권고를테스트하지않았다는설명문 테스트가완료된날짜 테스트보고서의결과는각제목에상응하는설명을담고있어야 한다. 제품을권고에대한적합성테스트를하지않았다는설명과더불 어, 테스트보고서는권고에부적합한목록도제공할수있다. 테스트보고서의식별( 테스트한연구소, 제품식별, 테스트보고서 의데이터) 과보고서페이지의총숫자가테스트보고서의각페이 지에존재해야한다. 테스트보고서는테스트한연구소의문서화된동의가없이는그 전체가복제( 재생) 될수없다는설명 [ISO/IEC Guide 25] 테스트보고서는 을따르는것이바람직하다. ISO/IEC Guide 25의테스트보고서를위한규정 추후테스트이미테스트를받은제품이다시테스트될때에는, ( 이전의테스트를

61 고려하여 ) 문서그리고기능과데이터의변경된부분모두는새로운제품 처럼테스트되어야한다. 변경된부분에의해서또는요구되는시스템의변화에의해서 ( 시험자 의전문적지식에의하면) 영향을받을것으로예견되는변경되지않은부 분은새로운제품처럼테스트되어야한다. 여타모든부분은최소한샘플로테스트되어야한다 ISO/IEC 용어정의 부속서 A: 다른규격에서정의된용어 이규격에서사용된일부용어는참조를쉽게하기위해서다른규격에 서정의되어있는것을인용하고있다. 공표당시, 지시된판들은유효하였 고이로부터인용된정의는사용되고있었거나고려되고있었다. 가. A.1 일반용어 1) A.1.1 소프트웨어: 정보처리시스템의프로그램, 절차, 규정그리 고관련된문서. [ISO/IEC :1993] 2) A.1.2 소프트웨어패키지: 일반적인( 범용) 애플리케이션또는기 능을위해서몇몇사용자에게제공된완비되고문서화된프로그램 집합. [ISO/IEC :1990] 3) A.1.3 시스템소프트웨어: 애플리케이션소프트웨어의실행을지 원하는애플리케이션에독립적인소프트웨어. [ISO/IEC :1990] 4) A.1.4 유틸리티루틴, 유틸리티프로그램: 컴퓨터사용자와서비스 직원에게일반적이고빈번하게요구되는루틴( 컴퓨터프로그램)

62 [ISO/IEC :1989] 5) A.1.5 기능단위: 규정된목적을수행할수있는하드웨어나소프 트웨어, 또는이둘의개체. [ISO/IEC :1993] 6) A.1.6 ( 컴퓨터) 프로그램: 특정프로그래밍언어의규칙에따르고 어떤기능, 과업, 또는문제를해결하는데필요한선언문과설명 문또는지침으로구성된구문적단위. [ISO/IEC :1993] 7) A.1.7 인터페이스: 기능적특성, 공통의물리적상호연결특성, 신 호특성, 그리고여타다른특성에의해서정의된두기능단위 사이의공유된범위. [ISO/IEC :1984] 8) A.1.8 사용자인터페이스: 사람인사용자와컴퓨터시스템의하드 웨어나소프트웨어구성물사이에정보가전달될수있게하는인 터페이스. [ANSI/IEEE Std ] 9) A.1.9 구성: 정보처리시스템의하드웨어와소프트웨어가조직되 고상호연결되는방식. [ISO/IEC :1993] 나. A.2 제품의특성 1) A.2.1 기능성: 일련의기능존재와이들의명세된특성과관련된 일련의속성들의집합. 기능이다. [ISO/IEC 9126:1991] 명시적또는묵시적필요를만족하는것이 2) A.2.2 신뢰성: 명시된기간동안명시된조건에서소프트웨어의 성능수준을유지하는능력과관련된속성들의집합. [ISO/IEC 9126:1991] 3) A.2.3 사용성: 사용자( 실제사용자나묵시적인사용자) 가사용을 위해요구하는노력과그러한사용에대한개개인의판단과관련 된속성들의집합. [ISO/IEC 9126:1991] 4) A.2.4 효율성: 명시된조건하에서소프트웨어성능수준과사용된 자원의양사이에관계된속성들의집합. [ISO/IEC 9126:1991] 5) A.2.5 유지보수성: 규정된수정을수행하기위하여필요한노력과

63 관련된속성들의집합. [ISO/IEC 9126:1991] 6) A.2.6 이식성: 소프트웨어가다른환경으로이전되는능력과관련 된속성들의집합. [ISO/IEC 9126:1991] 다. A.3 데이터 1) A.3.1 데이터: 의사소통, 해석, 또는처리에적합하도록형식화된 방식으로정보를재해석할수있는표현. [ISO/IEC :1993] 2) A.3.2 데이터매체: 데이터가내부또는표면에기록될수있고 그로부터데이터가복원될수있는물질. [ISO/IEC :1993] 라. A.4 테스트 1) A.4.1 테스트: 규정된절차에따라주어진제품, 공정, 또는서비 스의한개이상의특성을결정하는기술적인작업 (operation). [ISO/IEC Guide 2:1991] 2) A.4.2 테스트데이터: 점검문제를위해사용되는데이터. [ISO :1986] 3) A.4.3 점검문제: 기능단위가올바로작동되는판단하기위하여 사용되는문제로알려진해결책을가지고있는문제. [ISO :1986] 4) A.4.4 테스트방법: 테스트를수행하기위한규정된기술적인절 차. [ISO/IEC Guide 2:1991] 5) A.4.5 테스트계획, 시스템테스트, 평가계획: 시스템의테스트와 평가를위한세부요구사항, 기준, 일반적방법론, 책임, 일반계획 을수립한계획. [ISO :1990] 6) A.4.6 테스트보고서: 테스트결과및테스트와관련된관련정보 를포함한문서. [ISO :1990]

64 마. A.5 기타용어 1) A.5.1 프로그램유지보수매뉴얼: 프로그램의유지보수에필요한 모든정보를제공하는문서. [ISO :1990] 2) A.5.2 시스템유지보수: 결함을고치거나, 성능을개선하거나또는 시스템을변환된환경이나요구사항에맞추기위한시스템의수 정. [ISO :1990] 3) A.5.3 업무(work task): 작업시스템의의도된결과. [ISO 6385] 4) A.5.4 작업시스템(work system): 작업시스템은사람과작업도 구로구성되어작업장에서, 작업환경안에서, 그리고업무에의해 부여된조건하에서업무를수행하기위해작업공정에서함께기능 을수행하여작업을수행함. [ISO 1395:1981] 부속서 B: 제품설명서의예 다음의예는모든제품설명서에서제시되어야할정보를보여주기위 하여이규격에따라서단지가상의소프트웨어패키지를설명한다. 제품설명서 작업불꽃버전 2.6 작업불꽃 - 화면보호기와암호보호 프로그램작업불꽃은당신이컴퓨터에작업을하고있지않을때적색-녹색- 청색의색깔을띤화면위로 - 대단히근사한불꽃을펼쳐보이면서작업중인화면을보호해준다. 암호를걸어놓으면, 당신의부재중누군가당신의컴퓨터를조작하면당신은이에대한통고를받게된다. 작업불꽃은기억장치에설치가된다. 이프로그램은일정시간동안아무런키가눌려지지않거나마우스가움직여지지않으면언제든자동으로활성화된다. 그시간은조정할수있다. 이것은당신이아무키를누르거나마우스를움직이자마자실행을멈춘다. 그러나당신이암호를정해놓으면, 작업불꽃은암호가입력될때까지중단되지않고대기할것이다

65 당신은가장좋아하는구성을하여 작업불꽃이자동으로활성화되기전에기다리는시간을조정할수있다(1부터 999 분까지, 아니면즉시). 동시에일어나는불꽃의수를조정할수있다(1부터 19 까지). 이를위해작업불꽃은명령라인대화나윈도우대화를할것이다( 당신의운영체계가시스템날짜와시간을조정하는방식으로 ). 당신은패스워드도같은방식으로정의할수있다(6부터 45 문자까지). 그러므로작업불꽃이임의의문자에의해작동이멈추거나아니면암호를입력했는데작동이멈추지않는다면, 예를들어전원을껐다가켜는식으로누구인가작업불꽃을가로채서암호없이또는다른암호로작업불꽃을재시작해놓은것이다. 운영체계에의해서이프로그램과그구성을백업복사할수있다. 암호는저장되지않는다. 몇가지기술적세부사항 : 작업불꽃은최소한 1MB 주기억장치와최소한 720 KB의 90 mm (3.5 in) 또는 130 mm(5.25 in) 의디스켓드라이브를갖춘 Quince Hardcore 119xi 개인용컴퓨터( 그리고이와호환되는컴퓨터) 에서실행된다. 하드디스크를필요로하지않는다. 작업불꽃은직렬또는병렬 Mini-Rat 마우스( 또는이와호환되는모든마우스) 를지원하지만, 마우스를요구하지는않는다. 작업불꽃은 B.I.T.S 1.01 또는 Gnome 3.0( 또는이둘과호환되는모든운영체계) 하에서실행된다. 작업불꽃을주문할때에는 B.I.T.S 의상이( 변형) 을위한것인지아니면 Gnome 의상이( 변형) 을위한것인지작업불꽃을 90mm (3.5 in) 디스켓으로원하는지 130mm(5.25 in) 디스켓으로원하는지여부를본사에연락하기바란다. ( 제품의) 꾸러미는디스켓에담긴프로그램( 로드모듈) 과설치안내를포함하고있는문서화된소책자로구성되어있다

66 다음사항에주목하기바란다. 작업불꽃을설치하거나사용할때어떠한특별한지식을필요로하지않는다. 프로그램메시지와문서는영어로쓰여있다. 작업불꽃은 ISO/IEC 12119: 1994 정보기술 - 소프트웨어패키지 - 품질요구사항과테스트를완전히준수하고있다. 제품의운영이나유지보수에지원을하지는않는다. 작업불꽃을구할수있는곳 : PyroManiac Klaus P Schmidt Ltd 33 Bell Street Bergheim, SU Telephone (022) 해설서 ISO/IEC JTC1의소프트웨어공학표준화위원회에서는 1991년소프 트웨어제품의품질평가를위한 ISO/IEC 9126 을발간하였다. 이표준은 불특정한소프트웨어의개발과정에서나오는중간산출물과최종제품의 평가를위해서개발되어실제산업현장에서적용하기에여러가지어려움 이존재하였다. 따라서, 위원회에서는일반적으로많이사용되면서도평가 가용이한패키지소프트웨어의품질평가와품질을테스트할수있는기준 을개발하게되었다. 따라서본표준에서는 ISO 9126에서정의된모든품 질특성이소프트웨어패키지에는적용되지않고있다. 본표준이가지는특성중에하나는 ISO 9126에서정의한품질특성을

67 사용하고있지만특이하게테스트를위한내용을포함하고있다는것이다. 경우에따라서는본표준에서정의한품질에대한테스트가부족할수있 으나, 이는개정중에있는 ISO 9126 시리즈의일부를보완적으로사용하 면해결될수있는간단한문제이다. 본표준은대규모구매를하는집단을중심으로구매인증을위한기준 으로유럽에서사용되기시작하였다. 또한본표준에따른적용결과및 방법은여러곳에서실험되고연구되어발표되고있다. 현재본표준의적 용성은대단히높은편이며, 개정중에있는 ISO 9126이완성되어도본 표준의골격에는영향이없을것이다. 또한본표준에따른품질평가의 경험이없이는 성이있다. ISO 9126에따른품질평가는어렵다는데본표준의중요

68 3. ISO/IEC 개요 ISO/IEC 은소프트웨어제품평가프로세스 (software product evaluation processes) 의개요와평가에대한안내지침및요구사항을제 공한다 평가프로세스 국제표준인 ISO/IEC 14598은세가지다른상황에서의평가프로세스 (Evaluation Process) 에대한안내지침과요구사항을제공한다. 개발 (development) ISO/IEC ; 획득 (acquisition) ISO/IEC ; 독립평가 (independent evaluation) ISO/IEC 개발자를위한프로세스 (Process for Developers) ISO/IEC 은새로운제품을개발또는기존에있는제품을향상시키기위해서계획하는조직과기술직원을통하여제품평가를수행하려는조직에서사용될수있다. ISO/IEC 은생명주기동안에개발된중간제품을측정(measure) 함으로써, 최종제품의품질을예측할수있는척도(indicator) 를제공한다 획득자를위한프로세스 (Process for Acquirers)

69 ISO/IEC 는기존소프트웨어제품또는미리개발된소프트웨어제품을획득또는재사용하기위하여계획하는조직에서사용될수있다. ISO/IEC 는여러후보제품에서특정제품에대하여승인을결정하기위한목적또는한제품을선택하기위한목적으로적용될수있다 평가자를위한프로세스 (Process for Evaluators) ISO/IEC 는소프트웨어제품의독립적인평가(independent assessment) 를수행하는평가자에의해서사용될수있다. 이러한평가는 개발자, 획득자, 또는다른동료의요청에의해서수행될수있다 평가를위한지원 본항에서는 ISO/IEC 에서평가를위한지원(Support for Evaluation) 에대하여살펴본다. 그림 8.6 과같이, 각평가프로세스표준 은 ISO/IEC 계획과관리(Planning and Management) 그리고 ISO/IEC 평가모듈의문서화(Documentation of evaluation modules) 와연결(conjunction) 하여사용될수있다. < 그림6> 평가프로세스와평가지원표준의관계 계획과관리 (Planning and Management) ISO/IEC 계획과관리는소프트웨어제품평가에대한기능을지원하기위해필요한요구사항과안내지침을포함하고있다. ISO/IEC 에서의지원(support) 은소프트웨어평가프로세스그리고개발, 회득, 표준화, 통제, 조직내평가전문가의피드백(feedback) 등

70 을포함하여관련된활동(activity) 의계획과관리에연관되어있다. ISO/IEC 의이부분은정량적인 (quantitative) 평가계획을만드는매니저에의해서사용될수있다 평가모듈 (Evaluation Modules) ISO/IEC 은평가모듈을문서화하기위한안내지침을제공한다. 평가모듈은품질모델의명세서(specification), 모델의계획된어플리케이션에대한관련된데이터와정보그리고실제어플리케이션에대한정보를포함한다. ISO/IEC 14598의이부분은새로운평가모듈을생산하는조직에의해서사용될수있다 소프트웨어품질특성과메트릭 ISO/IEC 14598의각부분은소프트웨어품질특성과메트릭 (Software Quality Characteristics and Metrics) 을기술하고있는 ISO/IEC 9126 의부분과연결(conjunction) 하여사용될수있다. 품질특성과부특성 (Quality Characteristics and

71 Subcharacteristics) - ISO/IEC 외부메트릭 (External Metrics) ISO/IEC 내부메트릭 (Internal Metrics) ISO/IEC [ 그림 8-7] 과같이, ISO/IEC 은품질특성, 연관된품질부특성 그리고 ISO/IEC 9126 품질모델의상위세레벨사이의관계를정의한다. ISO/IEC 그리고 ISO/IEC 은각메트릭에일치하는품질 특성과품질부특성의관계를식별한다. < 그림7> ISO/IEC 9126 소프트웨어품질특성과메트릭 3.5. 평가프로세스 소프트웨어품질을평가하기위하여, 우선평가요구사항을설정하고, 명세하고, 설계하고, 마지막으로평가를수행해야한다. ISO/IEC 14598의 이부분은평가프로세스 (Evaluation Process) 의개요를설명하고있다. ISO/IEC 의다른부분은이프로세스가다른환경에적용될수있 는방법에대하여설명하고있다

72 3.6. 평가요구사항설정 평가목적설정 소프트웨어품질평가의목적은고객의필요를만족하는소프트웨어의 개발과획득모두를직접적으로지원하는것이다. 궁극적인목표는제품이 요구되는품질을제공한다는것을보증하는것이다 평가될제품의타입을식별 평가될중간소프트웨어제품또는최종소프트웨어제품의타입은생 명주기에있는단계와평가목적에의존적일것이다. 이단계의목적은소 프트웨어제품이사용자에의해실제사용될때상태를만족하고요구를 적용하는것이다. 요구사항 운영 (Opera tion) 실세계 요구 사용중인품질 (Quality in Use) 외부메트릭 결정사용과피드백 (determine) 명세 시스템행위 외부품질요구사항들 결정확인 (Validatio n) (determine) 지시 (indicates) 외부품질 (External quality) 시스템통합과테스트 외부메트릭 요구사항 지시 (indicates) 소프트웨어속성 내부품질요구사항들 내부품질 (Internal quality) 내부메트릭 검증 (Verification)

73 품질모델을명세 < 그림8> 소프트웨어생명주기에서의품질 소프트웨어평가의첫번째단계는품질모델을사용함으로써관련된 품질특성을선택하는것이다. 소프트웨어평가를위한품질모델은일반 적으로특성과부특성의계층적트리구조로구분된소프트웨어품질속성 의총합으로표현된다 평가명세화 메트릭선택 메트릭은소프트웨어제품측정을쉽고경제적으로만들수있고측정 결과를사용하기쉽기때문에매우중요하다. 많은소프트웨어측정이편 리하려면몇몇종류의도구로구성하고평가모듈로써패키지되어야할 것이다 (ISO/IEC ). 평가의두가지넓은의미는수정할문제를식별하기위한것과양자택 일되는제품이나요구사항에대응하는제품의품질을비교하기위한것이 다 메트릭을위한등급레벨성립 양적인특징은품질메트릭을사용함으로써측정될수있다. 측정된결 과는양과맵핑된다. 이런값은그자체가레벨의만족도를보이지는않는 다. 이러한목적때문에양은요구사항의다른만족도에대응하는범위로

74 분할한다. < 그림9> 메트릭을위한등급레벨(rating level) 평가를위한범주성립 소프트웨어품질요구사항명세는적절하게잘정의된품질모델을사 용함으로써정의될수있다. 이런목적을위해다른모델을사용해야하는 특별한이유가없다면 ISO/IEC 의품질모델과정의를사용한다. 제품의품질을평가하기위해다른특징의평가결과를요약할필요가있 다 평가설계 평가설계 (Design the evaluation) 단계는평가계획을생산하는것을의미한다. 평가계획은평가방법과평가자의행동이스케줄을설명한다 (ISO/IEC , ISO/IEC 혹은 ISO/IEC ). 평가계획은측정계획과일치해야한다 (ISO/IEC )

75 3.9. 평가실행 가. 측정 측정을위해서, 선택된메트릭은소프트웨어제품에적용한다. 결과는 메트릭척도의값이다. 나. 범주를비교 등급단계에서, 측정된값은이미결정된범주와비교된다. 다. 결과평가 평가는소프트웨어평가프로세스의마지막단계이다. 이단계에서등 급레벨의집합이도출된다 프로세스지원 프로세스지원활동은다음과같은정보를수집함으로써평가를지원 한다. 수집된정보는메트릭을개발하고평가하며, 평가프로세스를표준 화하고, 메트릭과측정을위한데이터로사용된다. ISO/IEC 는 소프트웨어제품평가를위한지원프로세스의요구사항과지침을포함한 다

76 4. IEEE 범위 본하에서는 IEEE1008 의적용가능한범위(Scope) 에대하여살펴본 다. IEEE1008 은소프트웨어단위테스트에대한표준이다. 소프트웨어단 위테스트는테스트계획의성과, 테스트집합획득, 소프트웨어단위의요 구사항에대한테스트단위의측정을포함한절차이다. 측정은단위요구 사항문서에명세함으로서단위를실행하거나측정에요구한동작과단위 의실질적인동작을비교하기위해견본데이터를사용한다. 본표준에서는체계적이고문서화된단위테스트를위하여조직화된 접근을정의한다. 이접근방법에서테스트의완벽성을결정하기위하여 단위디자인과단위구현정보가사용된다. 또한본표준에서는단계, 활 동, 지침을체계적으로구성된단위테스트절차를설명한다. 일반적으로단위테스트계획은전체테스트계획에서수행된다. 전체 테스트계획절차와본표준의범위와는적합하지않지만, 일반적인단위 테스트계획활동을다룬다 단위테스트활동 본항에서는단위테스트활동(Unit Testing Activities) 에대하여설명한다. 가. 테스트계획수행단계 일반적인접근방법, 자원, 스케줄계획

77 테스트되기위한특징결정 일반적인계획정제 나. 테스트집합획득단계 테스트집합디자인 정의된계획과디자인구현 다. 테스트단위측정단계 테스트절차실행 종결을위한확인 테스트노력과단위평가. [ 그림 8-10] 단위테스트활동 라. 일반적인접근방법, 자원, 스케줄계획

78 일반적으로단위테스트계획은전체테스트계획을하는동안계획문 서를고려하여작성해야한다. 마. 테스트계획입력물 프로젝트계획 소프트웨어요구사항문서 바. 계획지침 단위테스트를위한일반적인접근방법명세 완벽한요구사항명세 종료요구사항명세 자원요구사항명세 일반적인스케줄명세 사. 테스트계획산출물 일반적인단위테스트계획정보( 계획지침 1~5 항목에해당) 단위테스트일반적인자원요구서( 만약계획지침 4항목에산출물이있을경우 ) 아. 테스트를위한특징결정 1) 결정입력물 단위요구사항문서 소프트웨어아키텍처디자인문서( 필요시) 2) 결정지침 기능적요구사항연구 추가적요구사항과연관된절차식별

79 단위상태식별 입력과출력의데이터특성식별 테스트안에포함되기위한요소선택 3) 결정산출물 테스트안에포함되기위한요소의항목( 결정지침의 5항목에해당 ) 일반적인단위테스트계획정보( 결정지침의1~5 항목에해당) 자. 일반적인계획정제 1) 정제입력물 테스트안에포함되어지기위한요소의항목( 결정지침의 5항목 에해당 ) 단위요구사항설명요구서( 결정지침의 1~4 항목에해당) 2) 정제지침 접근방법정제 특별한자원요구사항명세 명확한스케줄명세 3) 정제산출물 명확한단위테스트계획정보 ( 정제지침 1~3 항목에해당) 단위테스트특별한자원요구서( 만약정제지침 2항목의산출물 이있을경우 ) 차. 테스트집합명세 1) 디자인입력물 단위요구사항문서 테스트안에포함되기위한요소의항목 ( 결정지침의 5항목에해 당 )

80 단위테스트계획정보 ( 테스트계획지침의 1,2 항목, 정제지침 1 항목 ) 단위디자인문서 이전테스트로부터테스트명세서( 사용가능시) 2) 디자인지침 테스트집합의아키텍처디자인 명확한테스트절차획득 테스트케이스명세서획득 디자인정보에기반한테스트케이스명세서확대 테스트디자인명세서완성 3) 디자인산출물 단위테스트디자인명세서( 디자인지침 5 항목에해당) 분리된테스트절차명세서( 만약디자인지침 2항목의산출물이 있을경우 ) 분리된테스트케이스명세서( 만약디자인지침 3혹은4항목의산 출물이있을경우 ) 단위디자인강화요구서( 만약디자인지침 4항목의산출물이있 을경우 ) 카. 정제된계획과디자인구현 1) 구현입력물 단위테스트계획정보 단위테스트디자인명세서혹은분리된문서들에테스트케이스 명세서 소프트웨어데이터구조설명서 테스트지원자원 테스트아이템 이전테스트활동으로부터테스트데이터( 사용가능시)

81 이전테스트활동으로부터테스트도구( 사용가능시) 2) 구현지침 테스트데이터검증과획득 특별한자원획득 테스트아이템획득 3) 구현산출물 검증된테스트데이터( 검증지침 1 항목에해당) 테스트지원자원( 검증지침 2 항목에해당) 테스트아이템구성( 검증지침 3 항목에해당) 초기요약정보( 검증지침 3 항목에해당) 4) 테스트절차실행 5) 실행입력물 검증된테스트데이터( 검증지침 1 항목에해당) 테스트지원자원( 검증지침 2 항목에해당) 테스트아이템형상( 검증지침 3 항목에해당) 테스트절차명세서( 검증지침 2 항목에해당, 만약산출물이있 을경우 ) 실패분석결과( 디버깅절차에해당, 만약산출물이있을경우) 6) 실행지침 테스트실행 결과결정 테스트가실패할경우를고려하여테스트실패정보, 분석내용을테스 트요약보고서의결과정리항목에기록한다. 적합한 Case를선택하고 Case 에알맞은행동을수행한다. Case 1: Case 2: Case 3: 테스트명세서혹은테스트데이터실패 테스트절차실행의실패 테스트환경의실패 Case 4: 단위구현의실패 실패했을경우다음의

82 Case 5: 단위디자인의실패 주의 [ 그림 8-11] 과같이, 실행주기와체크지침은테스트지침 3 항목에정의된종료상태가될때까지반복한다. 흐름은 [ 그림 8-12] 와같이표시된다. 실행활동에서제어 < 그림11> 실행활동의제어흐름 < 그림12> 체크활동의제어흐름 7) 실행산출물 테스트결과, 테스트하며발생한사건설명, 실패분석결과, 오류 수정활동, 오류를수정할수없는이유, 자원소비데이터, 절차

83 언어구현을위한추적요약정보를포함한테스트요약보고서의 실행정보( 실행지침 1,2 항목에해당) 수정된테스트명세서( 만약실행지침 2 의산출물이있을경우) 수정된테스트데이터( 만약실행지침 2 의산출물이있을경우) 종료를위한확인 8) 확인입력물 종료요구사항( 테스트계획지침 2, 3 항목에해당) 실행정보( 실행지침 1,2 항목에해당) 테스트명세서( 디자인지침 1~3 항목에해당, 요구시) 소프트웨어데이터구조설명서( 요구시) 9) 확인지침 테스트절차의정상적인종료를위한확인 테스트절차의비정적인종료를위한확인 테스트집합보충 10) 확인산출물 테스트케이스의추가적인활동과종료상태를포함한테스트요 약보고서의확인정보( 확인지침 1~3 항목에해당) 추가되고혹은수정한테스트명세서( 확인지침 3항목의산출물이 있을경우 ) 추가된테스트데이터( 만약지침 3 항목의산출물이있을경우) 타. 테스트노력과단위평가 1) 평가입력물 단위테스트디자인명세서( 디자인지침 5 항목에해당) 실행정보( 실행지침 1,2 항목에해당) 확인정보( 확인지침 1~3 항목에해당) 분리된테스트케이스명세서( 디자인지침 3,4 항목에해당, 만약 산출물이있을경우 )

84 2) 평가지침 테스트상태설명 단위의상태설명 테스트요약보고서완료 테스트생산물의보존보증 3) 평가산출물 완벽한테스트요약보고서( 평가지침 3 항목에해당) 완벽하게저장된테스트생산물의수집물( 평가지침 4항목에해당 )

85 5. IEEE 개요 IEEE 1012 는소프트웨어의검증및확인계획(Software Verification and Validation Plan, SVVP) 에대한표준으로서이를작성하기위해필 요한지침이나정보등을담고있다. 소프트웨어검증및확인은애플리케 이션생명주기의각단계에서소프트웨어를평가하기위해잘정의된접근 방법이다. 소프트웨어검증및확인활동을통해소프트웨어는그품질을 보장하고, 소프트웨어가사용자요구사항에부합되는지를확인할수있다. 또한소프트웨어의검증및확인을통해프로젝트와소프트웨어의상태를 파악할수있는통찰력을가지고소프트웨어를관리할수있으며이로인 해각단계의산출물이나소프트웨어개발프로세스또는지원프로세스를 유연하게적용할수있다. 소프트웨어검증및확인은소프트웨어와생명주기에따른중간산출 물이소프트웨어의기능과품질을위한요구사항에부합되는지를확인하 기위해리뷰(Review), 분석(Analysis), 테스트 (Testing) 기술등을포함 한다. 소프트웨어검증및확인활동은소프트웨어의결점을찾아내고사용 자들이요구하는기능과속성들이소프트웨어에적용되었는지를확인하는 것에목적을둔다. 따라서검증및확인활동들은소프트웨어개발산출물 들에영향을주며그내용은다음과같이구분된다

86 검증 소프트웨어생명주기의모든단계산출물에대한검증으로서검증내 용은다음과같다. 각단계의산출물은이전단계의요구사항과산출물에대해정확성 (Correctness), 완결성(Completeness), 일관성(consistency), 정밀성 (Accuracy) 등을만족시켜야한다. 각단계의산출물은그단계의표준, 관례, 규칙등을만족시켜야한다. 각단계의산출물은다음단계의활동을위한정보를포함해야한다 확인 최종산출물이정의된소프트웨어및시스템요구사항을만족시키는지 에대한확인이다. 검증및확인활동들은일반적으로소프트웨어개발프로세스와지원 프로세스에함께적용하며그중어떤활동은두프로세스사이에서수행 될수있다. 검증및확인활동은계획, 조직, 감독등의관리활동과분석, 평가리뷰, 테스트등의기술활동으로구분된다 소프트웨어검증및확인계획가이드 본항에서는소프트웨어검증및확인계획가이드 (Software Verification and Validation Plan) 에대하여살펴본다. 계획수립과계획 의문서화의목적은확인및검증을위한자원을효과적으로관리하고, 검 증및확인절차를감독하고제어하며, 활동에참여하는사람들의역할과

87 의무를명확하게하는것이다. 소프트웨어검증및확인계획은모든프로젝트에적용될수있는범용 적인계획을프로젝트에맞게수정해야한다. 검증및확인활동의기본적 인목적은전반적인생명주기동안바뀌지않으나어느경우에는계획에 대해중요한수정사항이발생할수있다. 이러한수정사항들은소프트웨어 개발활동이나검증및확인활동에연결되어있다. 따라서계획을수정하 기위한절차도계획안에포함되어야한다. 전반적인프로젝트계획을위 한검증및확인계획은다음과같은세부스텝을포함한다. 1) 검증및확인범위를식별한다. 소프트웨어개발활동들을정의하며이활동은중요도, 복잡성, 이용 가능한자원등의요소를고려한프로젝트에맞게적용될수있다. 2) 전체적인프로젝트의범위에서구체적인목표를설정한다. 설정된목표가상세하고측정및성취가능하여검증및확인활동을 통해만족될수있는목표여야한다. 3) 검증및확인도구와기술을선택하고계획을수립하기위해선행 되는프로젝트입력물을분석한다. 4) 사용될기술및도구를선택한다. 프로젝트를진행할때사용가능한도구나기술들을식별하고각도구 나기술들을선택하기위해필요한정보를수집한다. 수집한정보를기반 으로, 프로젝트의특정한제약사항이나필요에맞게도구와기술을선택한 다. 5) 검증및확인계획을수립한다. 이전단계의결과를리뷰하고, 이를기반으로검증및확인의목적과제 약사항들에맞는상세한활동들을정의한다

88 5.3. 생명주기에따른검증및확인활동 본항에서는생명주기에따른검증및확인활동 (Life-Cycle Verification and Validation) 에대하여살펴본다. 소프트웨어생명주기는 소프트웨어개발프로세스와검증및확인활동들을포함한다. 대부분의 소프트웨어검증및확인계획은생명주기의단계에할당된활동을통해 관리된다. [ 그림 8-13] 는소프트웨어검증및확인계획의전반적인구성 요소를보여준다. 생명주기는 7개의소프트웨어개발및사용단계로구성되어있고각 단계는검증및확인활동을위한입력물을정의하고있으며생명주기의각 단계내에는최소한의검증및확인활동을정의하고해당단계를통해요 구되는검증및확인출력물을정의한다. 또한 IEEE1012표준에서는검증 및확인활동을위해검증및확인의관리를한단계로정의하고있다. 이 활동은생명주기의특정한한단계라기보다여러단계에적용되고함께수 행되는단계이다

89 < 그림13> 검증및확인계획개요

90 검증및확인관리를포함한생명주기에서의검증및확인활동은다음과같다. 1) 검증및확인관리 (Management of V&V) 소프트웨어검증및확인계획을생성 한계선( 기준선) 변경평가 검증및확인리뷰관리 리뷰검증 2) 구상단계의검증및확인 (Concept Phase V&V) 3) 요구사항도출단계의검증및확인 (Requirement Phase V&V) 소프트웨어요구사항추적성분석 소프트웨어요구사항평가 소프트웨어요구사항인터페이스분석 테스트계획생성 시스템테스트 인수테스트 4) 설계단계에서의검증및확인 (Design Phase V&V) 소프트웨어설계추적성분석 소프트웨어설계평가 소프트웨어설계인터페이스분석 테스트계획생성 컴포넌트테스트 통합테스트 테스트설계생성 컴포넌트테스트 통합테스트 시스템테스트 인수테스트 5) 구현단계의검증및확인 (Implementation Phase V&V)

91 소스코드추적성분석 소스코드평가 소스코드인터페이스분석 소스코드문서명가 테스트케이스생성 컴포넌트테스트 통합테스트 시스템테스트 인수테스트 테스트절차생성 컴포넌트테스트 통합테스트 시스템테스트 컴포넌트테스트실행 6) 테스트단계의검증및확인 (Test Phase V&V) 인수테스생성 테스트실행 통합테스트 시스템테스트 인수테스트 7) 설치및검사단계의검증및확인 (Installation and checkout Phase V&V) 설치구성감사 최종검증및확인보고서생성 8) 작동및유지보수단계의검증및확인 (Operation and Maintenance Phase V&V) 소프트웨어검증및확인계획수정 예외처리평가 제안된수정평가

92 단계테스크반복