정보통신단체표준 초안 - TTAtta.or.kr/include/Download.jsp?filename=stnfile/tta.ko... · Web view정보통신단체표준 TTA.KO-11.0019 제정일 : 1999년 12월 8일 소프트웨어

정보통신단체표준TTA.KO-11.0019

제정일 : 1999년 12월 8일

1999년 12월

소프트웨어 프로세스와 품질 - 용어

Software Process and Quality - Vocabulary

한국정보통신기술협회

서 문

1. 표준의 목적

본 표준은 소프트웨어 프로세스와 품질에 관한 용어를 정의함을 목적으로 한다.

2. 참조 권고 및 표준

2.1 국제 표준(권고) : 없음

2.2 국내 권고 : 없음

2.3 기타 : 없음

3. 국제 표준(권고)와의 비교

해당사항 없음

4. 지적 재산권 관련 사항 : 없음

5. 적합 인증 관련 사항 : 없음

6. 표준의 이력

i

판 수 제개정일 제개정판 내역

제1판 1999년 12월 8일 제정

Preface

1. The Purpose of Standard

This standard offers definition of terminology about software process and quality.

2. Reference Recommendations and/or Standards

2.1 International standards : None

2.2 Domestic standards : None

2.3 Other standards : None

3. Relationship to International Standards(Recommendations) : None

4. The statement of Intellectual Property Rights : None

5. The statement of Conformance Testing and Certification : None

6. The history of standard

ii

Edition Issued date Contents

The 1st edition 1999. 12. 8. Established

목 차CONTENTS

1. 개요………………………………………………………………………………… 1 Introduction

2. 표기법…………………………………………………………………………… 1 Notation

3. 용어 정의………………………………………………………………………… 2 Definition

4. 참고자료…………………………………………………………………………… 82 References

iii

1. 개요

오늘날 소프트웨어나 이를 기반으로 하는 정보시스템은 산업이나 서비스 활동에 있어서 이미

필수적인 요소이다. 소프트웨어나 정보시스템이 사용자의 만족을 충족시키기 위해서는 고품질의

소프트웨어가 요구되고 있다. 그러나 고품질의 소프트웨어를 생산하고 관리하는 작업은 매우

어려운 일이며 이에 효과적인 도구, 방법, 기법의 적용이 요구되고 있다. 하지만 아무리 효과적인

도구, 방법, 기법을 적용하여도 기반이 되는 의사소통의 기본단위, 즉 한글 기반의 표준화된

용어가 정의되어 있지 않다면 개발자간, 사용자간의 의사소통의 애매함과 이해도가 떨어져

고품질의 소프트웨어나 정보시스템의 효율적인 생산 및 관리가 이루어질 수 없다.

본 표준은 소프트웨어의 품질에 관한 용어를 정의하여 그 의미를 명확히 하고 소프트웨어의

품질에 관련된 활동을 수행하는 과정에서 의사소통의 모호성을 제거할 수 있도록 정의하는 것을

목적으로 한다.

2. 표기법

한글 용어를 가나다 순으로 나열하였고 이어지는 괄호 안에 대응하는 영어표기를 규정하였다.

하나의 용어가 여러 정의를 가지는 경우에는 (1), (2),…와 같이 번호순으로 나열하였다. 정의를

명확히 할 필요가 있을 때에는 예를 추가하였다. 동일한 뜻을 나타내는 용어가 2 개 이상 있을

시에는 상호참조 하도록 관련 용어를 제시하였다. 다른 용어와의 관계를 보여주기 위해서 아래의

표기법과 같이 상호 참조하도록 명시하였다.

“-와 비교”는 보충하는 용어를 가리킨다.

“-와 대조”는 반대 의미이거나 뜻이 상당히 다른 용어를 가리킨다.

“-와 동의어”는 동의어인 용어를 가리킨다.

“-을 보시오”는 오히려 더 좋거나 상당히 관련된 용어를 가리킨다.

“-도 보시오”는 관련된 용어를 가리킨다.

[주]는 표제어의 대한 세부적인 설명을 가리킨다.

1

4. 용어 정의

4.1 가 매개변수 (dummy parameter) 형식 매개변수(formal parameter)를 보시오.

4.2 가명 (alias) (1) 항목에 대한 부가적인 이름. (2) 레이블의 대안이다. 예를 들면, 레이블과 하나

이상의 가명은 컴퓨터 프로그램에서의 같은 자료 요소를 말하는데 사용할 수 있다.

4.3 가상 기계 (virtual machine) 컴퓨터 및 관련장치에 대한 기능적인 모의 실험.

4.4 가상 기억장치 (virtual memory) 가상 기억장치 (virtual storage)를 보시오.

4.5 가상 기억장치 (virtual storage) 가상주소를 실제주소로 사상해서 컴퓨터 시스템 사용자가

주기억장치의 주소지정을 할 수 있는 기억장치 공간. 가상 기억장치의 크기는 실제 주기억장치의

크기와는 상관없이 컴퓨터 시스템과 사용 가능한 보조기억장치의 양에 의해 제한된다. (ISO)

4.6 가용성 (availability) (1) 사용이 필요할 때 한 소프트웨어가 지정된 시스템 기능을 수행할 수

있는 확률. (2) 총 운영시간에 대한 시스템 가동시간의 비율. (3) 사용이 필요할 때 한 항목이

지정된 기능을 수행할 수 있는 능력. (ANSI/ ASQC A3-1978)

4.7 가용성 모델 (availability model) 가용성을 예상, 판단, 평가할 때 사용하는 모델.

4.8 간접 측정 (indirect measure) 하나 이상의 다른 속성의 측정에서 유도된 속성의 측정. [주]

사용자 입력에 대한 반응 시간과 같은 컴퓨팅 시스템의 속성의 외부 측정은 측정이 컴퓨팅 환경

속성의 영향으로 측정에 영향을 미치므로 소프트웨어 속성에 대한 간접 측정이다.

4.9 감독자 (supervisor) 감독 프로그램을 보시오.

4.10감독자 프로그램 (supervisor program) 일반적으로 운영체제의 일부분인 컴퓨터

프로그램으로서 다른 컴퓨터 프로그램의 실행을 제어하고 자료처리 시스템에서 작업의 흐름을

조정한다. 관리 프로그램, 감독자와 동의어. (ISO)

4.11 감리 (audit) 감사를 보시오.

4.12 감사 (audit) (1) 소프트웨어 요구사항, 명세(서), 기준선, 표준, 절차, 명령어, 코드, 그리고

계약하고 인가한 요구사항을 준수하여 평가하기위한 독립적인 조사활동. (2) 확정된 절차,

명령어, 명세(서), 코드, 표준 또는 달리 적용 가능한 계약하고 인가한 요구사항 그리고 구현의

효율성을 측정하기 위한 충분하고 충실한 조사활동. (ANSI 45.2.10-1973) (4) 요구사항에 적합함을

심사하기 위하여 소프트웨어 제품 또는 프로세스를 독립적으로 심사할 목적으로 자격 있는

사람이 수행함.(ISO) 코드 감리를 보시오.

4.13 감시 (monitoring) 제 3 자 또는 획득자가 수행하는 공급자 활동의 상태 또는 결과의 시험

2

(ISO)

4.14 강 자료형 (strong typing) 각각의 자료객체는 선언하고 부적절한 자료객체에 대한 응용

연산은 배제함으로써 부적합한 자료형의 자료객체의 상호작용을 방지하는 자료형을 요구하는

프로그래밍 언어 기능.

4.15 개념 단계 (concept phase) 소프트웨어 개발 프로젝트의 초기 단계. 사용자의 요구를 문서화

작업을 통해서 기술하고 평가한다. 여기서 문서는 요구사항 명세, 프로젝트 진행 계획, 시스템

정의 문서등에 대한 문서를 지칭한다.(IEEE STD 1012-1986)

4.16 개발 (development) 요구분석, 설계, 코딩, 통합, 시험, 설치와 소프트웨어 제품의 인수를

지원하기 위한 소프트웨어 생명주기 프로세스.(ISO 9000-3:1997)

4.17 개발 기준선 (developmental baseline) 개발 형상을 보시오. (IEEE STD 610.12-1990)

4.18 개발 명세(서) (development specification) 요구사항 명세(서)와 동의어. (DoD usage)

4.19 개발 방법론 (development methodology) 개발 단계를 정의하고 활동, 제품, 검증절차, 각

단계의 종결기준 등을 상세히 기술하는 소프트웨어 개발을 위한 조직적인 접근방법.

4.20 개발 생명 주기 (development life cycle) 소프트웨어 개발 주기 참조. (IEEE STD 610.12-1990)

4.21 개발 시험 (development testing) 시스템이나 형상요소를 개발하는 동안 개발자들에 의해

개발환경에서 수행되는 공식 또는 비공식 시험. 인수 시험; 운영 시험과 비교. 자격 시험 참조. (IEEE STD 610.12-1990)

4.22 개발 주기 (development cycle) 소프트웨어 개발 주기를 보시오.

4.23 개발 형상 (developmental configuration) 컴퓨터 소프트웨어 형상 항목의 개발과정에서

산출되는 문서들. 할당 기준선; 기능 기준선; 제품 기준선과 비교. (IEEE STD 610.12-1990)

[주] 개발 형상은 개발자의 제어하에 있기 때문에 기준선이라 불리지 않음.

4.24 개발자 (developer) 소프트웨어 생명주기 프로세스 동안 개발활동(요구사항 분석, 설계,

인수시험 포함)을 수행하는 조직. (ISO)

4.25 개정(revision) 변경, 에러, 분석, 향상 등으로써 같은 기능적 용량을 이용하여 제어하는 항목. (IEEE STD 1074-195)

4.26 개정 통보 (notice of revision) 개정을 제안하고, 개정 승인 후에 개정되었음을 또는 개정될

것임을 사용자에게 통보. 형상 제어; 공학 변경; 명세 변경 통보도 보시오. (IEEE STD 610.12-1990)

3

4.27 개체 (entity) 개별적으로 표현과 고려를 할 수 있는 것. (ISO 8402: 1994)

[주] - 예를 들면, 개체는 활동, 프로세스, 제품, 조직, 시스템, 인력 또는 그것의 어떤 부합물이라 할

수 있음.

4.28 객관적 증거 (objective evidence) 관찰, 측정, 시험 또는 다른 수단을 통해 얻은 사실을

바탕으로 참을 증명할 수 있는 정보. (ISO 8402: 1994)

4.29 객관화 프로그래밍 (egoless programming) 프로그램 개발에 팀 책임의 개념을 기초로 하는

소프트웨어 개발 접근방법. 이것의 목적은 개인에 의존적인 사고방식을 지양하여 객관적인

평가를 할 수 있게 누구든지 알아볼 수 있도록 프로그래밍을 하는 것.

4.30 객체 지향 설계 (object-oriented design) 시스템이나 구성요소가 객체와 객체 사이의 연관

관계의 관점으로 표현되는 소프트웨어 개발 기술. 데이터 구조 중심 설계; 입력-처리-출력; 모듈

분해; 객체 지향 설계; 신속 시제품화; 나선형 모델; 단계적 정제; 구조적 설계; 트랜잭션 분석; 변환

분석을 보시오. (IEEE STD 610.12-1990)

4.31 검사 (inspection) (1) 저자가 아닌 다른 사람이나 단체가 결함, 개발 표준 위반, 그리고 다른

문제점을 감지하기 위해서 소프트웨어 요구사항, 설계 또는 코드를 자세히 조사하는 공식 평가

기법. (2) 조사나 관찰 또는 측정에 의해서 재료, 공급, 소자, 부품, 장치, 시스템, 프로세스 또는

구조들이 미리 결정한 품질요구와 일치하는지를 결정하는 품질관리 단계. (ANSI N45.2.10-1973)

(3) 제품 또는 서비스의 1 개 이상의 특성을 측정, 조사, 시험, 게이지 등에 의해 규정된 요건과

비교하여 적합 여부를 판정하는 제반 활동.(ISO 8402:1994-1986) 웍스루와 대조. 코드 감리도

보시오.

4.32 검정 (certification) (1) 시스템 또는 컴퓨터 프로그램이 명세화된 요구상황에 맞게 번역되는

것을 보여주는 서면화된 보증. (2) 컴퓨터 프로그램이 안전하다는 것과 민감한 정보를 생산하는

정의된 환경 안에서만 작동되도록 허가하는 것을 문서화한 인가. (3) 운영할 수 있는 인가를 받기

위해서 시스템의 안정성을 나타내는 형식적 증명. (4) 시스템, 소프트웨어 부 시스템, 또는 컴퓨터

프로그램이 운영환경 내에서 명세화 한 요구사항을 만족하는지를 확인하는 과정으로 검정은 보통

실제 조건아래의 현장에서 사용하는 용어로서 소프트웨어 자체뿐만 아니라 그 소프트웨어를

만들기 위한 명세(서)를 평가하는데 사용한다. 검정은 검증(verification)과 확인(validation) 과정을

실제 또는 모형화 한 운영 환경까지 확장한 것.

4.33 검증 (verification) (1) 소프트웨어 개발주기에 있어서 주어진 단계에서 제품이 이전 단계에서

수립한 요구사항을 만족하는가를 결정하는 과정. (2) 프로그램 정확도에 대한 정형적인 증명. (3)

항목, 프로세스, 서비스 또는 문서에 명시한 요구사항을 따르는지를 재검토, 조사, 시험, 검사, 감리

및 문서화하는 행위. (ANSI/ASQC A3-1978) (4) 검사 및 객관적인 증거의 제시로 명시한

요구사항을 만족하였음을 확인하는 것.(ISO)

[주]

4

1 설계 및 개발에서 검증은 명시한 요구사항에 적합한가를 결정하기 위하여 주어진 활동의 결과를

시험하는 프로세스로 생각할 수 있다.

2 <검증된>은 일치된 상태를 지정할 때 사용된다.

확인도 보시오. 정확도 증명도 보시오.

4.34 검증 시스템 (verification system) 자동화 검증 시스템을 보시오.

4.35 검증, 확인 및 시험 (VV&T) 소프트웨어 생명주기 전반에 걸쳐서 오류를 발견하고,

요구사항에 대한 제품의 정확성, 완전성 그리고 일치성 등을 확인하는 작업.

4.36 검증과 확인 (verification and validation) (1) 시스템이나 구성요소에 대한 요구사항이

완전하고 정확한지, 각 개발단계의 제품들이 이전단계에서 부과된 요구사항이나 조건들을

수행하는지, 최종 시스템이나 구성요소가 명세된 요구사항에 부합하는지를 결정하는 프로세스. (IEEE STD 610.12-1990)

4.37 검토 (review) (1) 계획된 결과가 소프트웨어의 요소 또는 프로젝트의 현 상태와 일치하는지

여부를 평가하는 활동. 관리 검토 프로세스, 기술 검토 프로세스와 같은 정형화된 프로세스를

수반한다. (IEEE STD 1028-1988) (2) 논평을 위해 프로젝트 참여자, 관리자, 사용자, 고객 또는

기타 관심있는 참여자를 포함한 제품에 대한 발표 회의. (IEEE STD 1058.1-1987) 설계 검토를

보시오.

4.38 견고성 (robustness) 소프트웨어에 가치 없는 입력이 들어와도 정확하게 수행될 수 있는 정도.

4.39 결점 (defect) 의도한 사용 요구사항을 충족시키지 못한 것 (ISO 8402:1994-1986)

[주] 이 정의는 한가지 이상의 품질 특성이 의도된 사용 요구사항에서 벗어나거나 빠진 것을

포함한다. 결함 (fault) 을 보시오.

4.40 결정점 메트릭 (decision point metric) 내부의 모든 결정점들이 기대한 결과를 보이는

모듈수를 전체 모듈수로 나눈 결과. 결정점이 기대한 결과를 보인다는 것은 결정점의 모든 유효한

경우(조건)에서의 수행과 적어도 하나 이상의 유효하지 않은(예를 들어, 예외사항) 경우에서의

수행에서 올바른 결과를 보이는 것이다. (IEEE 730.1-1989)

4.41 결정표 (decision table) (1) 모든 가능한 문제와 이에 따르는 행위에 대한 우연성을 묘사하는

표. (ISO) (2) 조건의 집합과 이들에 따르는 행위를 배열이나 표의 형태로 표현하는 것. (ANSI)

4.42 결함 (bug) 장애 (fault) 을 보시오.

4.43 결함 파종 (bug seeding) 장애 파종 (fault seeding) 을 보시오.

4.44 결합도 (coupling) 컴퓨터 프로그램에서 모듈간의 상호독립성 메트릭. 응집도(cohesion)와

대조.

5

4.45 경계치 내 시험 자료 (non-external test data) 입력 도매인의 경계치 내에 있는 시험자료.

4.46 경계치 외 시험 자료 (external test data) 입력 도매인의 경계치나 경계치 외에 있는 시험

자료나 출력 도매인의 경계치를 야기하는 시험 자료.

4.47 경로 분석 (path analysis) 프로그램 전체를 통해 가능한 모든 경로를 인지하고, 불완전한

경로를 발견하거나 임의의 경로에 있지 않은 프로그램의 일부를 발견해내는 프로그램 분석.

4.48 경로 식 (path expression) 특별한 프로그램 경로가 실행되기 위해 충족되어야 하는

입력조건을 나타내는 논리식.

4.49 경로 조건 (path condition) 특별한 프로그램 경로를 실행하기 위해 충족시켜야 하는 일련의

조건.

4.50 경영 검토 (management review) 품질 정책과 목표에 관련해서 품질 시스템의 상태와

적합성에 대한 최고 경영자의 공식적 평가.

[주]

1 경영 검토는 품질정책의 검토를 포함할 수 있다.

2 품질감사 결과가 경영검토의 입력중의 하나일 수 있다.

3 "최고경영자"라는 용어는 품질 시스템의 검토를 받는 조직의 경영자를 가리킨다.

4.51 계약(contract) 소프트웨어 제품의 공급, 개발, 생산, 운영, 유지보수 또는 서비스의 공급을

위하여 양자간에 특별히 법이나 조직내의 법과 유사한 형태의 내부합의에 의한 상호 동의.(ISO)

4.52 계약 요구사항(contractual requirement) 소프트웨어 개발, 인도, 지원 범위에 대한 고약과

고객에 보여줄 성능과 요구사항들 (IEEE STD 1074-1995)

4.53 계약 검토 (contract review) 품질 요구사항을 적절히 정의했고 애매모호한 표현이 없으며

문서화 했고 공급자가 실현할 수 있는지 확인하기 위해 계약 전에 공급자가 수행하는 체계적인

활동. (ISO 8402: 1994)

[주]

1 계약검토는 공급자의 책임이지만 고객과 함계 수행할 수 있다.

2 계약검토는 필요하면 다른 계약 조건에 따라 다시 반복될 수 있다.

4.54 계약자 (contractor) 계약상황에서 공급자

[주]

1 계약자는 "사업의 주관자"를 지칭한다.

2 불어로 "le titulaire du contrat est parfois appele le <<contractan>"라 부른다.

6

4.55 계측 (instrumentation) 프로그램 계측을 보시오.

4.56 계측 도구 (instrumentation tool) 프로그램 코드의 방문횟수 등 프로그램 수행에 관한

통계자료를 얻기 위해 특정 프로그램의 전략적인 지점에서의 카운터나 탐사자(probe)등을 만들어

삽입시켜주는 소프트웨어 도구.

4.57 계층 (hierarchy) 구성 요소의 특정 규칙에 따라 표준별 종속 등급이 있는 구조.

4.58 계층적 모델링(hierarchical modeling) 컴퓨터 시스템을 계층을 이루는 하위시스템으로

표현하여 성능을 평가하기 위한 기술로 각각의 하위 시스템을 그들의 성능상의 특성에 따라

분석하고 그 결과는 전체 시스템에 대한 성능을 평가하기 위해 사용된다. (IEEE STD 610.12-1990)

4.59 계층적 분해 (hierarchical decompose) 하향식 정렬을 반복 수행하여 시스템을 그의

구성요소로 분할하는 설계 방법. 기능 분해, 모듈화 분해, 단계적 정제도 보시오.

4.60 고객 (customer) 공급자가 제공하는 제품의 수령자(IEEE STD 1058.1-1987)

[주]

1 계약상황에서 고객을 구매자로 부른다.

2 예를 들어 고객은 최종 소비자, 사용자, 수령인 또는 구매자이다.

3 고객은 조직의 외부 또는 내부일 수 있다.

4.61 고급언어 (high level language) 고차원 언어(high order language)와 동의어.

4.62 고유 결함 (indigenous fault) 결함파종 과정의 일부로서 삽입되지 않은 컴퓨터 프로그램에

존재했던 결함.

4.63 고장 (failure) (1) 한 기능 단위가 그 필요한 기능을 수행할 능력이 중지됨. (ISO) (2) 설정된

한계 내에서 한 시스템이나 시스템 구성요소가 요구되는 기능을 수행할 수 없음. (3) 프로그래머

연산(조작)이 프로그램 요구와는 무관함.

4.64 고장 범주 (failure category) 오류 범주를 보시오.

4.65 고장 자료 (failure data) 오류 자료를 보시오.

4.66 고장 회복 (failure recovery) 고장 후에 그 시스템이 신뢰할만한 운영상태로 복귀(회복)하는

것.

4.67 고장율 (failure rate) (1) 주어진 측정단위에 대한 고장횟수의 비율. 예를 들면, 단위 시간당

고장횟수, 트랜잭션 수당 고장횟수, 컴퓨터 수행횟수 당 고장횟수가 있다. (2) 신뢰도를

모형화하는데 있어서 주어진 시간동안의 범주 혹은 엄격함(severity)에 대한 고장횟수의 비율.

7

예를 들면, 실행시간 당 고장횟수, 월 당 고장횟수가 있다. 고장율 (failure ratio)과 동의어.

4.68 고장율 (failure ratio) 고장율 (failure rate)과 동의어.

4.69 고차원 언어 (high order language) 중첩된 수식, 사용자가 정의한 자료형태, 초급언어에서 볼

수 없는 매개변수전달과 같은 특징을 포함하는 프로그래밍 언어로써 특정 컴퓨터나 특정 부류

(class)의 구조에 구애받지 않고 기계와는 독립적인 원시 프로그램을 작성하는데 사용할 수 있다.

한 개의 고차원 언어 문장은 다수의 기계연산을 대신한다. 기계어, 어셈블리어와 대조.

4.70 공급자 (supplier) (1) 고객에게 제품을 제공하는 기관 (2) 계약조건 하에서 시스템,

소프트웨어 제품 또는 소프트웨어 서비스의 공급을 위해 획득자와 계약을 체결하는 조직.(ISO)

[주]

1 고객 상황에서 공급자는 계약자라 부른다.

2 예를 들면 공급자는 생산자, 판매자, 수입자, 조립자 또는 서비스 조직이다.

3 공급자는 조직의 외부 또는 내부일 수 있다.

4 획득자는 획득조직의 일부분으로서 공급자로 지정될 수 있다.

4.71 공학 변경(engineering change) 형상 관리에서, 형상 항목이나 공식적인 정의 후에 정의된

다른 항목들의 형상 변경. 형상 제어; 공학 변경 제안을 보시오. 규격완화, 면제와 비교. (IEEE STD 610.12-1990)

4.72 공학 변경 제안(engineering change proposal) 형상 관리에서, 제안된 공학 변경과 변경이

기술되고 제안된 문서. 형상 제어를 보시오. (IEEE STD 610.12-1990)

4.73 관련 개발자(associated developer) 주 계약자 또는 하청 계약자도 아니지만 동일하거나 관련

시스템 또는 프로젝트에 관련이 있는 사람. (J-STD-016-1995)

4.74 관리 프로그램 (executive program) 감독 프로그램을 보시오.

4.75 교정 유지보수 (corrective maintenance) 컴퓨터 사용 중 발생하는 오류를 원 상태로 복구시킬

때 수행하는 절차. (ISO) 소프트웨어 유지보수도 보시오.

4.76 교차 어셈블러 (cross assembler) 어셈블하는 컴퓨터에 상관없이 목적으로 하는 다른

컴퓨터에서 실행할 수 있는 목적코드를 생성하는 어셈블러.

4.77 교차 컴파일러 (cross compiler) 컴파일하는 컴퓨터에 상관없이 목적으로 하는 다른

컴퓨터에서 실행할 수 있는 목적코드나 어셈블러코드를 생성하는 컴파일러.

4.78 교환성 (interchangeability) 동일한 요구사항을 충족시키기 위해 수정 없이 다른 것을 사용할

수 있는 개체의 능력. (ISO 8402:1994).

[주]

8

1 "기능적 교환성" 또는 "치수적 교환성"과 같은 수식어는 특정한 상황에 따라 사용된다.

2 위 정의는 품질 표준의 목적과 부합된다. "교환성"은 ISO/IEC Guide 2 에서는 다르게 정의한다.

4.79 구매자 (purchaser) 계약상황에서 고객

[주] - 구매자는 "사업 대상자"를 지칭한다.

4.80 구문 (syntax) (1) 문자의 의미나 해석하고 사용하는데 있어서의 방법과는 무관한 문자 또한

문자 집합 사이의 문제. (ISO) (2) 언어에서 표현의 구조. (ANSI) (3) 언어의 구조를 지배하는 규칙.

(ANSI) 의미론도 보시오.

4.81 구성 (configuration) 형상을 보시오.

4.82 구성요소 (component) 하나의 시스템이나 프로그램의 기본적인 부분.

4.83 구성요소 시험(component testing) 하나의 소프트웨어 요소(단위, 모듈 등) 또는 소프트웨어

요소의 집합의 설계를 구현한 것을 검증하기 위한 시험. (IEEE STD 1012-1986)

4.84 구성품 (building block) 상위계층의 프로그램 또는 모듈이 이용하는 개개의 프로그램 단위나

모듈.

4.85 구조 (architecture) (1) 프로그램 구조, 시스템 구조를 보시오. (2) 시스템의 조직적인 형태

또는 소프트웨어 항목들 사이의 인터페이스, 구성요소에 대한 식별.(J-STD-016-1995)

4.86 구조 설계 (architectural design) (1) 컴퓨터 시스템의 개발을 위한 골격을 만들기 위해

하드웨어와 소프트웨어 구성요소의 집합과 이들간의 인터페이스를 정의하는 과정. (2) 구조설계

(architectural design)의 결과.

4.87 구조적 설계 (structured design) 하향식 설계, 단계적 정제, 자료흐름 분석과 같은 원칙에

기초한 규칙을 응용하는 분야의 소프트웨어 설계 접근 방법.

4.88 구조적 시험(structured testing) 시스템이나 구성요소의 내부 메커니즘을 고려한 시험. 분기

시험, 경로 시험, 문장 시험 포함. 유리박스 시험; 화이트 박스 시험과 비슷함. 기능 시험과 비교. (IEEE STD 610.12-1990)

4.89 구조적 프로그래밍 언어 (structured programming language) 구조적 프로그램 구조를

제공하거나 구조적 프로그램의 개발을 용이하게 하는 프로그래밍 언어.

4.90 구조적 프로그램 (structured program) 하나의 입력 포인트 및 하나의 출력 포인트를 갖는

제어 구조의 집합으로 구성한 프로그램이며, 이 제어구조의 집합은 둘 이상의 연속된 명령어, 둘

이상의 명령 또는 연속된 명령어에 대한 조건부 선택, 명령어 및 연속된 명령어의 반복을 포함한다.

9

4.91 구축 (build) (1) 최종제품이 포함하게 될 기능 중 지정된 부분집합을 구현한 수행 가능한

소프트웨어 제품. (2) 소프트웨어 버전이 개발되는 기간. (J-STD-016-1995)

4.92 구현 (implementation) (1) 추상화를 보다 구체적 용어로 실현시키는 것, 특히 하드웨어 용어,

소프트웨어 용어 또는 두 가지 모두로 함. (2) 기계가 수행 가능한 프로그램의 한 형태, 또는

기계가 수행 가능한 형태로 자동으로 변환 할 수 있는 프로그램의 한 형태. (3) 설계를 코드로

변환하고 코드의 오류를 정정하는 과정.

4.93 구현 단계 (implementation phase) 소프트웨어 생명주기에서 설계문서로부터 소프트웨어

제품을 만들어내고 오류를 정정하는 기간을 말한다. 설치 및 확인 단계, 시험 단계도 보시오.

4.94 구현 요구사항 (implementation requirement) 소프트웨어 설계를 구현하는데 있어서

영향이나 제약이 되는 요구사항. 예를 들면, 설계 기술서, 소프트웨어 개발 표준, 프로그래밍 언어

요구사항, 소프트웨어 품질보증 기준 등을 말한다.

4.95규격완화 (deviation) (1) 특정 요구사항에서 벗어남. (2) 항목의 제조 이전에, 단위의 특정

개수나 특정 시간을 요구하는 설계 요구사항이나 특별한 성능 요구사항으로부터 벗어나도 된다는

문서화된 허가. 형상 제어도 보시오. 공학 변경(engineering change); 면제(waiver)와 비교. (IEEE STD 610.12-1990)[주] 공학변경과는 달리 규격완화는 영향 받는 항목을 정의한 문서의 개정을 요구하지 않음.

4.96귀납적 단정 방법 (inductive assertion method) 프로그램 입력, 출력, 중간의 조건을 묘사하는

단정으로부터 시작해서 출력단정을 만족하기 위해 입력단정에 연관해서 개발한 정리의 집합과

이것은 “참”이라는 것을 증명하는 정확도 증명기법.

4.97관례(conventions) 소프트웨어 항목에 있어서 일관성을 제공하고 원칙을 기술하기 위해

일반적으로 받아들여진 기준. (IEEE STD 730.1-1995)

4.98그래프 (graph) 가장자리(edge)와 아크(arc)로 불리는 연결점으로 이루어진 노드의

유한집합으로 구성된 모형.

4.99기계어 (machine language) 컴퓨터에서 직접 실행 가능한 자료와 명령어의 표현.

어셈블리어, 고급 언어와 대조.

4.100 기능 (function) 개체의 특별한 목적 또는 이것의 특징적인 작용.

4.101 기능 검증(functional verification) 기능에 대한 구조가 확인된 요구사항 기준선을

만족하는지 여부를 평가하는 프로세스.

4.102 기능 구조(functional architecture) 수행 순서, 제어나 데이터 흐름에 대한 조건, 요구사항

기준선을 만족하는 성능 요구사항들을 정의하는 기능과 그들의 하부기능, 인터페이스들의 배치.(IEEE 1220-1994)

10

4.103 기능 기준선(functional baseline) 개발자와 고객사이의 공식적인 합의문서로서 개발할

시스템 또는 형상항목의 기능적 특성을 기술하고 그 기능 요구사항을 충족하는지를 검증하는

방법을 기술한 산출물.

4.104 기능 단위 (functional unit) 특정한 목적을 수행할 수 있는 하드웨어나 소프트웨어 혹은

양쪽 모두에 속하는 개체. (ISO)

4.105 기능 명세(서) (functional specification) 반드시 수행해야 할 시스템이나 시스템 요소의

기능을 정의하는 명세(서). 성능 명세(서)도 보시오.

4.106 기능 분해 (functional decomposition) 시스템을 시스템의 기능과 부 기능에 직접

대응되는 시스템 요소로 분해하여 설계하는 방법. 계층적 분해도 보시오.

4.107 기능 설계 (functional design) 자료처리 시스템 각 부분사이의 작업관계를 나타내는

명세(서). (ISO) 개략 설계도 보시오.

4.108 기능 시험(functional testing) (1) 시스템이나 구성요소의 내부 메커니즘은 무시하고 단지

선택된 입력과 실행 조건에 따라 발생하는 출력에만 초점을 두는 시험. 블랙박스 시험과 비슷함.

구조적 시험과 비교. (2) 시스템이나 구성요소가 명세된 기능요구사항에 부합하는지 평가하기

위해 수행되는 시험. (IEEE STD 610.12-1990)

4.109 기능 요구사항 (functional requirement) 반드시 수행해야 하는 시스템이나 시스템

요소의 기능을 정의하는 요구명세(서).

4.110 기능 형상 감리(functional configuration audit) 형상 항목의 개발이 만족스럽게

완료되었는지 즉, 항목이 기능 또는 할당된 형상 식별에 명세된 성능과 기능적 특성들에 맞게

개발되었는지, 항목의 운영 문서나 보조 문서들이 만족스럽게 만들어졌는지를 검증하기위해

수행되는 감리. 형상 관리; 물리적 형상 감리도 보시오. (IEEE STD 610.12-1990)

4.111 기능 형상 식별(functional configuration identification) 형상 관리에서, 형상 항목을

설명하는 기술문서(technical document). 이것은 모든 필요한 기능적 특성들, 특정 기능적 특성이

달성되었음을 증명하기위해 요구되는 시험, 관련있는 형상 항목들과의 인터페이스 특성, 그리고

주요 기능적 특성과 부차적 기능적 특성의 식별, 및 설계 제약사항들을 규정하고 있다. 할당된

형상 식별; 제품 형상 식별과 비교. 기능 기준선도 보시오 . (IEEE STD 610.12-1990)

4.112 기록(record) 수행한 활동 또는 달성한 결과에 대해 객관적 증거를 갖춘 문서.(ISO 8402:1994)[주]

1. 품질 기록은 품질 요구사항의 충족 정도에 대한 객관적 증거를 제공하거나, 품질 시스템 요소에

11

대한 운영 유효성의 객관적 증거를 제공한다.

2. 품질 기록의 몇 가지 목적은 실증, 추적성과 예방 조치 및 시정 조치이다.

3. 기록은 어떠한 정보 매체에 기록되거나 저장될 수 있다.

4.113 기법(techniques) 주어진 문제를 해결하기 위한 기술적, 관리적인 절차.(IEEE 730.1-1995)

4.114 기준선 (baseline) (1) 공식적인 검토 및 합의가 끝난 명세(서) 또는 제품을 말하며 개발을

위한 기준이 되고 , 공식적인 변경절차를 통해서만 변경할 수 있다. (2) 형상항목의 생명주기

동안의 특정한 시점에 미디어에 상관없이 정형적으로 설계되고 확정되어 공식적으로 승인된

구성항목의 버전. 기존의 기준선과 이에 대해 승인된 변화가 추가된 것이 현재의 구성요소가

된다. 형상관리에는 세가지가 있다.

1. 기능기준선 즉, 최초로 승인한 기능 형상.

2. 할당기준선 즉, 최초로 승인한 할당기준선.

3. 제품기준선 즉, 최초로 승인했거나 조건부로 승인한 제품 형상. (DoD-STD 480A)

4.115 기준선 관리(baseline management) 형상 관리에서, 생명주기 동안 특정 시기에

공식적으로 형상 항목의 기준선을 식별하여 문서화하고, 그러한 문서들에 대한 변경을 관리하는

것을 말한다. (IEEE STD 610.12-1990)

4.116 내부 측정 값(internal measure) 시스템의 행위로부터 유도되지 않고, 직접적이든

간접적이든 제품 자체로부터 유도된 측정 값.

[주] 코드의 라인 수, 결함의 수는 제품 자체에 대한 내부 측정이다.

4.117 내부 품질(internal quality) 특정 조건에서 사용될 경우 명시적, 묵시적인 요구를

만족하는 제품의 속성의 총합.

[주]

1. “내부 품질”이라는 용어는 외부품질의 반대의미로 사용된다.

2. “속성”이란 용어는 특성이라는 용어로 사용된다.

4.118 내장 소프트웨어 (embedded software) 내장 컴퓨터 시스템에 사용하는 소프트웨어.

4.119 내장 컴퓨터 시스템 (embedded computer system) 주 목적이 계산만이 아닌 큰 시스템을

이루는데 절대적으로 필요한 컴퓨터 시스템. 예를 들면, 무기, 비행기, 지휘 및 통제 등에 사용하는

컴퓨터 시스템.

4.120 내포 (nest) (1) 어떤 종류의 구조 또는 여러 구조를 같은 종류의 구조 내에 합병시키는

것. 예를 들면, 한 루프가(내포된 루프) 다른 루프(내포하는 루프) 안에 내포되는 것, 한 부 루틴이

(내포된 서브루틴) 다른 부 루틴(내포 하는 서브루틴) 안에 내포되는 것. (ISO) (2) 부 루틴이나

자료를 다른 계층수준의 부 루틴이나 자료에 위치 시킴으로써 부 루틴은 재귀적인 부 루틴같이

12

실행할 수 있고, 자료 또한 재귀적으로 호출될 수 있다.

4.121 네트워크 (network) (1) 서로 연결되거나 관련이 있는 노드의 집합. (2) 분야 또는

문제지향의 자격부여에 관한 어떤 목적을 이루기 위해 설계해서 단일화한 용구, 문서, 인적지원의

조합. 예를 들면, 사회과학 네트워크, 과학정보 네트워크가 있다.

4.122 노드 (node) (1) 네트워크나 그래프의 어떤 분위기의 끝 지점 또는 두개이상의 분기의

접합점. (2) 트리 구조에서, 자료의 종속항목을 만드는 위치. (ANSI) (3) 네트워크에서, 전송

선으로 상호 연결된 하나 이상의 기능단위의 위치. (ISO) (4) 다이어그램에서 점으로 표시하여

상태나 사건을 표현함. (ANSI)

4.123 논리적 레코드 (logical record) 물리 환경과는 독립된 레코드, 동일 논리 레코드가

나뉘어 다른 위치의 물리 레코드가 될 수 있고 몇 개의 논리 레코드나 논리 레코드의 일부분들이

동일 물리 레코드 내에 위치할 수 있다. (ANSI)

4.124 논리적 파일 (logical file) 물리환경과는 독립된 파일. 동일 논리 파일이 나뉘어 다른

위치의 물리 파일이 될 수 있고 몇 개의 논리파일이나 논리파일의 일부분이 동일 물리 파일 내에

위치할 수 있다.

4.125 다단계 보안 (multilevel security) 시스템내의 모든 자료에 대해 알 필요도 정리할

필요도 없는 적어도 약간의 사용자가 있을 때 컴퓨터 시스템 내에서 병행적으로 저장되고

처리되는 자료의 연산을 다양한 보안 수준에서 허용하는 방법.

4.126 다중 프로그래밍 (multiprogramming) (1) 하나의 프로세서로 두개이상의 컴퓨터

프로그램의 실행이 제공되는 운영방법. (2) 컴퓨터에 서 두개 이상의 컴퓨터 프로그램을

병행적으로 실행하는 것. (ANSI) (3) 각 기능이 독자적으로 운영되는 것 같이 보이는 두개 이상의

기능을 병행적으로 실행하는 것.

4.127 단계(phase) 정의된 작업의 부분.(ISO 9000-3:1997)

4.128 단계적 정제 (stepwise refinement) 자료정의와 처리단계가 처음에는 넓게 정의되고

점점 상세하게 발전하는 시스템 개발 방법론. 계층적 분해, 상향식, 하향식도 보시오.

4.129 단어 (word) (1) 주어진 컴퓨터 내에서 정보를 저장하고 연산하는데 있어서 보통의

단위가 되는 비트나 선형적으로 나열된 문자의 집합. (2) 개체로 인식되는 문자열 또는 비트 열.

4.130 단위 (unit) 프로그램을 논리적으로 나누었을 때 나누어진 그 한 부분 (IEEE STD 1074-1995)

4.131 단위 요구사항 문서 (unit requirements documentation) 시험 대상의 단위 프로그램에

대해 시험을 위한 기능, 인터페이스, 성능, 설계 제약 등에 관한 요구사항을 기술해 놓은 문서.

13

(IEEE 610.12-1990)

4.132 단정 (assertion) (1) 프로그램 실행 중 특별한 지점에서 프로그램 변수가 갖추어야 할

조건의 집합 또는 존재해야 하는 프로그램 상태를 상술하는 논리적인 표현. 예를 들면, A 는 B

보다 큰 양수. (2) 프로그램을 수행하는 동안 특정지점에서 변수가 만족해야 하는 조건이나 그

지점에서 만족해야 하는 프로그램 상태를 나타내는 논리식. 입력단정, 출력단정을 보시오.

4.133 대수언어(algebraic language) Y = X + 5 와 같은 대수식을 조합하여 문장을 구성할 수

있도록 허용하는 프로그래밍 언어. 포트란과 같은 언어가 대표적.

4.134 대화식 (conversation) 인간의 대화와 유사한 사용자와 시스템 사이의 상호작용을 위해

제공하는 대화식 시스템에 관한 것.

4.135 대화식 (interactive) 사용자의 입력 하나 하나에 대하여 시스템이 응답하는 체제를 말함.

대화식(conversational)도 보시오.

4.136 덤프 (dump) (1) 덤프된 자료. (ISO) (2) 기억장소를 다른 목적으로 사용하거나 오류나

결함으로부터 보호하거나 오류 수정에 관련된 특별한 목적으로 일반적으로 내부 기억장치부터

외부 매체까지 기억장치의 일부분 또는 전체의 내용을 기록하는 것. (ISO)

4.137 데이터 구조 중심 설계(data structure-centered design) 시스템의 구조가 시스템이

다루어야 하는 데이터 구조의 분석으로부터 유도되는 소프트웨어 설계 기술. 입력-처리-출력;

모듈 분해; 객체 지향 설계; 신속 시제품화; 나선형 모델; 단계적 정제; 구조적 설계; 트랜잭션 분석;

변환 분석도 보시오. (IEEE STD 610.12-1990)

4.138 데이터베이스 (database) (1) 주어진 목적이나 주어진 자료처리 시스템에 사용하기에

충분하도록 적어도 한 개 이상의 파일로 구성한 자료의 집합. (ISO) (2) 시스템에서 중요시 되는

자료의 집합. (ANSI) (3) 기업에서 중요시 하는 자료의 집합. (ANSI)

4.139 데이터베이스 관리 시스템(database management system) 데이터베이스를 생성, 변경,

유지 보수하는데 기초가 되는 컴퓨터 프로그램의 집합.(J-STD-016-1995)

4.140 도구 (tool) 소프트웨어나 소프트웨어의 성능을 분석하는 하드웨어 장치. 소프트웨어

도구를 보시오.

4.141 도메인 메트릭(domain metric) 하나의 유효한 입력 샘플과 유효하지 않은 입력 샘플이

정확하게 처리되는 모듈의 수를 전체 모듈의 수로 나눈 결과.(IEEE 730.1-1989)

4.142 독립 검증과 확인 (independent verification and validation) (1) 제품의 개발책임

조직과는 기술적 및 관리적인 측면에서 분리되어 있는 조직에서 소프트웨어 제품을 검증하고

14

인증함. (2) 원래의 설계를 수행하는데 참여하지 않은 개인이나 그룹(동일조직에 속할 수 있음)이

소프트웨어 제품을 검증하고 인증함. 이 때 독립성 정도는 소프트웨어 중요성과 함수관계가 있다.

4.143 동적 바인딩 (dynamic binding) 프로그램의 실행 중에 수행되는 바인딩. 정적

바인딩과 대조.

4.144 동적 분석 (dynamic analysis) 프로그램의 실행을 기초로 하여 프로그램을 평가하는

과정.

4.145 동적 분석기 (dynamic analyzer) 프로그램의 실행을 모니터 함으로서 컴퓨터

프로그램의 평가를 돕는 소프트웨어 모니터, 트레이서. 동적 분석기와 대조.

4.146 동적 재구성 (dynamic restructuring) (1) 시스템을 운영하는 동안 소프트웨어

구성요소나 구조가 바뀌는 과정. (2) 프로그램을 실험 하는 동안 자료구조나 데이터베이스가

재구성되는 과정.

4.147 동적 할당 (dynamic allocation) 프로그램이 실행되는 동안 주소지정 가능한 주소와 다른

자원을 프로그램에 할당하는 것.

4.148 등급 (grade) 동일한 기능성 용도가 의도된 제품 또는 서비스에 대해 상이한 일련의

요구를 망라하는 특징이나 특성과 관련된 범주나 순위를 나타낸 것. (ISO 8402:1986)

[주]

1. 등급은 요건상의 계획된 차이를 나타내고 계획되어 있지 않으면 인식된 차이를 나타낸다.

기능적 용도와 비용과의 관계에 중점을 둔다.

2. 요구를 만족시킨다는 의미에서는 고급품이 부적절한 품질의 것일 수 있으며, 그 반대일 수도

있다. 예를 들면, 서비스가 나쁜 호화 호텔 또는 서비스가 우수한 작은 여인숙이 그것이다.

3. 등급이 수치로 표시되는 경우 최고등급을 1 로 하여 2, 3 ,4 의 순으로 등급이 내려간다. 예컨대

등급을 점수나 별의 개수로 표시할 때는 가장 낮은 등급에 가장 적은 점수나 별의 수가 주어진다.

4.149 라이브러리 (library) 소프트웨어 라이브러리, 시스템 라이브러리를 보시오.

4.150 라이브러리언 (librarian) 소프트웨어 라이브러리언을 보시오.

4.151 랑데뷰 (rendezvous) 병행 수행되는 작업에서 하나의 작업이 다른 작업의 엔트리를

호출하고, 이를 받아들이는 문장이 호출된 작업의 진행 중에 행해질 때 두 지점사이에 발생되는

상호작용.

4.152 레벨 (level) (1) 계층적인 배열에서 어떤 항목의 종속된 정도. (ISO) (2) 계층 구조에서의

서열. 어떤 항목에서 종속된 것이 없으면 그것이 최저 레벨이 되고 위의 항목이 없으면 그것이

최고 레벨이 된다.

15

4.153 레이블 (label) (1) 자료의 집합 내에 또는 수반하는 하나 이상의 문자로서 집합과 이를

식별하기 위한 정보를 가진다. (ISO) (2) 컴퓨터의 프로그래밍에서 명령어의 식별자. (ISO) (3)

테이프 또는 디스크 파일에서 레코드의 표시.

4.154 레코드 (record) 하나의 단위로 다루어지는 관련된 자료 또는 단어의 집합. (ISO)

논리적 레코드도 보시오.

4.155 루트 컴파일러 (root compiler) 컴파일러의 출력이 기계 의존적이고 프로그램의 중간

단계의 표현 인 것. 루트 컴파일러와 기계 의존적인 코드 생성기가 결합되면 완전한 컴파일러가

된다.

4.156 루틴 (routine) (1) 특별한 일을 수행하는 컴퓨터 프로그램 세그먼트. (2) 프로그램이

호출하는 연속된 명령어 또는 프로그램으로서 일반적이거나 자주 사용되는 것이다. 기능, 절차,

서브루틴, 서브프로그램도 보시오

4.157 루프 (loop) 어떤 조건이 만족될 동안 반복적으로 수행되는 명령어의 집합. (ISO) 반복

(iteration)도 보시오.

4.158 리스트 (list) (1) 자료의 항목이 순서화 된 집합. (ISO) (2) 특별한 기준에 맞게 자료의

항목을 인쇄하거나 표시하는 것. (ANSI) 연결 리스트를 보시오.

4.159 리스트 처리 (list processing) 리스트의 형태로 자료를 처리하는 방법. 연쇄리스트는

그들의 물리적 위치에 상관없이 논리적인 순서가 바뀔 수 있다. (ISO)

4.160 리스팅 (listing) (1) 인간이 읽을 수 있는 리스트 형태로 작성한 컴퓨터 출력. (2) 인간이

읽을 수 있는 본문 형태의 컴퓨터 출력.

4.161 릴리즈(release) 예를 들면 시험 릴리즈와 같이 특정한 목적으로 사용할 수 있도록 만든

형상항목의 특정한 버전.(ISO)

4.162 마스터 라이브러리 (master library) 정식으로 생산한 소프트웨어의 설명과 문서를

포함하는 소프트웨어 라이브러리.

4.163 마이크로 코드 (micro code) (1) 마이크로 프로그램의 기본적인 표현. (2) 마이크로

프로그램의 기억매체에서의 내부적인 표현. 펌웨어도 보시오.

4.164 마이크로 프로그램(micro program) 컴퓨터 연산과 동일한 기본적인 명령어의

연속으로서 특별한 기억장치에서 관리되고 컴퓨터의 명령어 레지스터의 컴퓨터 명령에 의해서

실행된다. (ISO) 마이크로 프로그램은 흔히 하드배선논리 (hard-wired logic)에서 흔히 사용한다.

16

펌웨어도 보시오.

4.165 마크로 (macro) (1) 프로그램이 어셈블 또는 컴파일 되는 동안 프로그램에서 마크로

명령어가 나타나는 각각의 위치에 이미 정의된 연속된 명령어가 프로그램에 삽입된다. (2) 마크로

명령어와 동의어.

4.166 마크로 명령어 (macro instruction) 원시언어와 똑같은 형태로 정의된 연속된 명령어에

의해 교체된 원시언어에서의 명령어. 마크로 명령어는 교체할 명령어에서의 매개변수를 위한

특별한 값일 수도 있다. (ISO)

4.167 마크로 프로세서 (macro processor) 프로그래머가 마크로를 정의하고 사용할 수 있게

하는 어셈블러와 컴파일러의 일부분.

4.168 매개 변수 (parameter) (1) 프로그램을 위해서 기술한 고정값과 의미 있게 주어진 변수.

(ISO) (2) 프로그램 루틴간에 값을 전달하는데 사용하는 변수. 실 매개변수, 형식 매개변수도

보시오.

4.169 맵 프로그램 (map program) 적재지도를 생성하는 것으로 특징 지워지는 컴파일러나

어셈블러.

4.170 메타 언어 (meta language) 언어나 언어를 설명하는데 사용하는 언어.

4.171 메타 컴파일러 (meta compiler) 컴파일러 생성기를 보시오.

4.172 메트릭(metric) 측정을 위해서 사용하는 측정의 범위와 방법. 소프트웨어 품질 메트릭을

보시오.

[주]

1. 메트릭은 외부 또는 내부일 수 있다.

2. 메트릭은 정성적인 자료를 범주화하기 위한 방법을 포함한다.

4.173 메트릭 값(metric value) 메트릭의 출력물 혹은 메트릭 범위값.

4.174 메트릭 샘플(metrics sample) 메트릭 데이터베이스에서 추출하고, 메트릭 확인에서

사용되는 메트릭 값의 집합

4.175 메트릭 프레임워크(metrics framework) 소프트웨어 시스템에 요구되는 품질속성을

조직, 선택, 통신, 평가하는데 사용되는 도구. 요소와 하부 요소, 소프트웨어 시스템에 대한

메트릭의 계층적 분류

4.176 메트릭 확인(metric validation) 메트릭이 정확히 품질 요인을 예측하는지 평가하는

17

활동이나 프로세스

4.177 명령어 (command language) 일정한 형식을 갖는 수행이 가능한 연산자로 구성하며,

운영체제에 의해 수행되는 기능을 나타내는데 사용한다. 제어 명령어와 동의어. (ISO)

4.178 명령어 (instruction) (1) 컴퓨터가 특정 연산이나 연산의 집합을 수행하도록 하는

프로그램 문장. (2) 프로그래밍 언어에서 하나의 연산과 그것의 연산자를 말해주는 의미 있는

표현. (ISO)

4.179 명령어 집합 (instruction set) 프로그래밍 시스템에서 컴퓨터나 한 프로그래밍 언어 또는

프로그래밍 언어에 대한 명령어의 집합. (ISO)

4.180 명령어 집합 기계 (instruction set machine) 명령어 집합으로 특정 지워지는 추상 기계.

4.181 명령어 추적 (instruction trace) 추적을 보시오.

4.182 명세(서) (specification) (1) 시스템 또는 시스템 구성요소의 요구사항, 설계, 행위, 다른

특성을 완전하고 정확하고 검증 가능한 방법으로 미리 기술한 문서. (2) 명세(서)를 만드는 과정.

(3) 주어진 요구사항이 만족되었는지를 결정할 수 있는 의미 있는 내용을 정의하는 과정 또는

제품이나 재료가 만족해야 하는 요구사항에 대한 간결한 문장. (ANSI N45.2.10-1973) (4) 제품

또는 서비스가 갖추어야 할 요건을 기술한 문서. (ISO 8402:1994-1986)

[주]

시방서는 도면이나 견본 또는 기타 관련 문서를 참조하거나 포함해야 하며, 시방서에 의해

적합성이 체크될 수 있는 수단과 기준을 표시해야 한다. 설계명세(서), 형식 명세(서), 기능 명세

(서), 인터페이스 명세(서), 성능 명세(서), 요구사항 명세도 보시오.

4.183 명세 변경 통보(specification change notice) 명세에 대한 변경을 제안, 전달,

기록하기위해 형상 관리에서 사용되는 문서. 형상 제어; 공학 변경; 개정 통보도 보시오. (IEEE STD 610.12-1990)

4.184 명세 트리(specification tree) 시스템의 모든 명세와 명세 사이의 관계를 묘사하는

다이어그램. 문서화 트리를 보시오. (IEEE STD 610.12-1990)

4.185 명세(서) 검증 (specification verification) 검증을 보시오.

4.186 명세(서) 언어 (specification language) 시스템 또는 시스템 구성요소의 요구, 설계, 행위

및 다른 특성을 명세 하는데 사용하는 것으로서 자연언어와 형식언어가 조합된 형태로서

기계처리도 가능한 언어.

4.187 모델 (model) 실세계의 처리, 장치 또는 개념의 표현. 분석 모델, 가용성 모델, 오류측정

모델, 오류 모델, 신뢰도 모델, 시뮬레이션, 통계 시험 모델도 보시오.

18

4.188 모듈 (module) (1) 컴파일, 다른 유니트와의 결합, 적재를 함에 있어 개별적으로 식별

가능한 프로그램 단위. 예를 들면, 입력, 출력, 어셈블러, 컴파일러, 연결편집기 실행 가능한 루틴

등이 있다. (ANSI)

4.189 모듈 시험(module testing) 구성요소 시험(component testing)을 보시오. (IEEE STD 1012-1986)

4.190 모듈강도 (module strength) 응집도를 보시오.

4.191 모듈성 (modularity) (1) 소프트웨어 내의 하나의 구성요소가 따른 구성요소에 최소한의

영향을 미치도록 개별적인 구성요소로 구성되어있는 정도. (2) 기능, 부 시스템, 입출력 등과 같은

특성을 기초로 시스템의 구성요소를 물리적 및 논리적 그룹으로 분할하는 개념 즉 시스템이

모듈로 구성된 정도.

4.192 모듈화 분해 (modular decomposition) 모듈로 분해하는 시스템 설계방법. 계층적

분해도 보시오.

4.193 모듈화 프로그래밍 (modular programming) 모듈이 집합된 형태로 프로그램이나

시스템을 설계하는 기법.

4.194 모의실험 (simulation) 다른 시스템으로 어떤 시스템의 선택된 물리적, 추상적 행위의

특성을 표현한 것. 디지털 컴퓨터 시스템에서 모의실험은 소프트웨어의 의해 수행된다. 예를

들면, (a) 컴퓨터 시스템에 의해 수행되는 연산의 의미에 의한 물리적인 현상 표현. (b) 다른

컴퓨터 시스템에 의한 컴퓨터 시스템의 동작의 표현. (ISO) 분석 모델과 대조.

4.195 모의실험 장치 (simulator) 시스템의 물리적, 추상적 행위에 대한 어떤 기능을 표현하는

장치, 자료처리 시스템 또는 컴퓨터 프로그램.

4.196 목적 프로그램 (object program) 컴파일, 어셈블이 완전히 끝나고 나서 컴퓨터에 적재될

준비가 끝난 프로그램. (ISO) 원시 프로그램과 대조.

4.197 목표 기계 (target machine) (1) 프로그램이 수행되는 컴퓨터. (2) 다른 컴퓨터에 의해

에뮬레이트 되는 컴퓨터. 호스트 기계(host machine) 와 대조.

4.198 목표 언어 (target language) 원시언어가 번역된 언어. (ANSI) 원시 언어와 대조.

4.199 무결성 (integrity) 승인받지 않은 호출, 소프트웨어나 자료의 수정이 컴퓨터 시스템

내에서 제어될 수 있는 정도. 보안도 보시오.

4.200 묵시적 요구(implied needs) 개체가 특정한 조건에서 사용될 때 명시적으로 제시되지는

19

않았지만 실제로는 필요한 요구.

[주] 요구가 문서화되어 있지 않은 경우에는 묵시적 요구가 실제적인 요구이다.

4.201 문서 (document) (1) 일반적으로 기계가 읽을 수 있고 영속성을 가지는 자료를 기록하는

자료매체. (ISO) 흔히 인간만이 읽을 수 있는 항목이 서술된다. 예를 들면, 기술적인 문서,

설계문서, 설명 서술 문서가 있다. (2) 문서를 만드는 것.

4.202 문서화 (documentation) (1) 주어진 주제에 대한 문서의 집합. (ISO) (2) 문서를 분류,

획득, 처리, 기록, 보급하는 활동을 포함하는 문서관리. (ISO) (3) 문서를 만들어내는 과정. (4)

요구사항, 절차, 또는 결과에 대한 정의, 보고, 증명활동을 묘사하는 문제나 그림의 정보. (ANSI

N45.2.10-1973) 사용자 문서화, 소프트웨어 문서화, 시스템 문서화를 보시오.

4.203 문서화 레벨 (documentation level) 문서화 레벨(level of documenta-tion)을 보시오.

4.204 문서화 레벨 (level of documentation) 요구되는 문서화의 범위, 내용, 형식,

품질등에대한 기술. 레벨의 선정은 프로젝트 비용, 사용용도, 노력정도 및 기타요인에 근거한다.

4.205 문서화 트리(documentation tree) 주어진 시스템을 위한 모든 문서들과 그들 사이의

관계를 묘사하는 다이어그램. 명세 트리도 보시오. (IEEE STD 610.12-1990)

4.206 문제점(problem) 명세된 성능 요구사항 내에서 요구된 기능을 수행하기 위한 시스템

혹은 구성요소의 무능한 상태. (IEEE STD 1074-1995)

4.207 물리적 검증(physical verification) 물리적 구조의 요구사항이 확인된 요구사항 기준선을

만족하며 검증된 기능적 구조를 추적할 수 있는지 여부를 평가하는 프로세스.(IEEE STD 1220-1994)

4.208 물리적 구조(physical architecture) 물리적인 요소의 배열. 물리적인 요소는 고객 제품을

위한 설계 해결책을 제공하거나 기능적 구조에 대한 요구사항과 요구사항 기준선을 만족시키기

위해 마련된 생명주기 프로세스를 나타낸다. (IEEE STD 1220-1994)

4.209 물리적 요소(physical element) 설계, 인터페이스(내부 및 외부), 요구사항(기능, 성능,

물리적 성격)에 의해서 정의된 물리적 구조 부분. (IEEE STD 1220-1994)

4.210 물리적 필요조건 (physical requirement) 시스템이나 시스템 구성요소가 가져야 하는

실질적인 특성을 지정하는 필요조건. 예를 들면, 모양, 형태, 크기, 무게가 있다.

4.211 물리적 형상 감리(physical configuration audit) 형상 항목이 그것을 정의한 기술 문서에

부합하는지 검증하기위해 수행되는 감리. 기능 형상 감리도 보시오. (IEEE STD 610.12-1990)

4.212 바이트 (byte) (1) 일반적으로 컴퓨터 단어보다 짧은 단위로 작용하는 2 진 문자열. (ISO)

20

(2) 일반적으로 컴퓨터 단어보다 짧은 단위로 작용하는 인접한 2 진 숫자의 집합. (ANSI/IEEE Std 488-1987)

4.213 바인딩 (binding) 식별자에 값이나 지시하는 대상을 할당하는 것. 예를 들면,

매개변수에 값을 할당하거나 기호주소나 컴퓨터 프로그램내의 라벨에 절대주소, 가상주소,

장치식별자를 할당하는 것이 있다. 강 바인딩, 약 바인딩을 보시오.

4.214 반복 (iteration) (1) 특정한 조건이 만족될 때까지, 혹은 특정조건이 만족되는 동안

컴퓨터 프로그램 언어로 작성된 문장을 여러 번 수행하는 과정. (2) 일련의 루프를 한번 수행함.

4.215 반복성 (repeatability) 시험 반복성을 보시오.

4.216 방법론 (methodology) 특정 문제영역의 문제를 해결하기 위해 구성한 방법, 규칙, 절차.

4.217 방향 그래프 (digraph) 방향 그래프 (directed graph) 를 보시오.

4.218 방향 그래프 (directed graph) 그래프의 가장자리(edge)가 한 방향 뿐인 것.

4.219 배정문 (assignment statement) 명령어는 연산의 나열을 표현하거나 피연산자(operand)

를 지정된 변수나 기호 또는 둘 모두에 배정한다. (ANSI)

4.220 버전(version) 항목의 식별된 인스턴스.(ISO)

[주] 소프트웨어 제품의 버전에 대한 수정은 형상관리 활동을 통해야 한다.

4.221 버전 기술 문서(version description document) 시스템이나 구성요소의 주어진 버전들을

식별하고 기록하는 문서. 시스템이나 구성요소 부분들의 목록과 이전 버전과 비교하여 다음

버전에서 생긴 변경들의 식별 그리고 버전의 설치와 운영 정보를 포함. (IEEE STD 610.12-1990)

4.222 번역기 (translator) 하나의 언어로 쓰여진 연속된 문장을 다른 언어의 동일한 연속된

문장으로 변환하는 프로그램. 어셈블러, 컴파일러, 해석기도 보시오.

4.223 베타 시험 (beta testing) 승인 시험 전에 고객에게 인도하여 수행하는 소프트웨어

시험으로, 이 단계에서는 고객이 승인한 생산 조건하에서 운영시험을 실시한다.

4.224 변경제어 (change control) 변경의 제안, 평가, 승인, 불허, 일정계획, 추적 등을 행하는

과정.

4.225 변경제어 위원회(change control board) 형상 통제 위원회를 보시오. (IEEE STD 610.12-1990)

4.226 변수 (variable) (1) 주어진 어떠한 값을 가질 수 있는 미지수. (ISO) (2) 프로그래밍에서

21

값을 나타내는 문자나 여러 문자의 집합이며 컴퓨터 프로그램의 수행 중에는 주소에 대응한다. (ANSI)

4.227 변이 (mutation) 프로그램 변이 (program mutation)을 보시오.

4.228 변형 (anomaly) (1) 소프트웨어 제품 또는 참조 문서에서 검증되었으나 실제의 예상을

벗어난 소프트웨어의 작동과 관련 문서에서 발견된 모든 것. 위험한 변형은 V & V(검증과 확인)이

다음 단계로 진행하기 전에 해결되어야 한다.(IEEE STD 1012-1986) (2) 요구사항이나 기대되는

행위 또는 기대되는 소프트웨어 성능에서 벗어나는 상황. (IEEE STD 1074-1995)

4.229 변환 (conversion) 다른 환경에서 유사한 기능을 수행할 수 있도록 기존의 소프트웨어를

수정하는 것. 예를 들면, Fortran 프로그램을 Ada 프로그램으로 변환하는 것. 한 컴퓨터에서

수행되는 프로그램을 또 다른 컴퓨터에서 수행되는 프로그램으로 변환하는 것.

4.230 변환 분석(transform analysis) 시스템의 구조가 시스템에서의 데이터 흐름과

데이터에서 수행되어야만 하는 변환을 분석함으로써 유도되는 소프트웨어 개발 기술. 변환 중심

설계와 비슷함. 데이터 구조 중심 설계; 입력-처리-출력; 모듈 분해; 객체 지향 설계; 신속

시제품화; 나선형 모델; 단계적 정제; 구조적 설계; 트랜잭션 분석; 트랜잭션 분석도 보시오. (IEEE STD 610.12-1990)

4.231 변환 중심 분석(transform-centered analysis) 변환 분석을 보시오. (IEEE STD 610.12-1990)

4.232 병행처리 (concurrent process) 다중처리기 상에서 병렬로 처리하거나 단일 처리기

상에서 비동기적으로 수행되는 처리. 처리기가 상호작용을 하거나, 한 처리기가 다른 처리기 또는

외부 사건으로부터 발생하는 정보를 기다리기 위해서 실행을 중지할 수도 있음. 순차 처리

(sequential processing) 와 대조.

4.233 보류시점(hold point) 지정된 조직 또는 권한권자의 승인없이는 활동이 더 이상

진행해서는 안되는, 해당 문서에서 정의된 시점. (ISO 8402:1994)

[주] 보류시점을 지나 진행하는 데에 대한 승인은 보통 서명형태로 제시되지만, 기타 다른 허가된

합의 시스템에 의해 제시될 수 있다.

4.234 보안 (security) (1) 우발적이거나 고의적인 호출, 사용, 수정, 파괴, 유출로 부터 컴퓨터

하드웨어와 소프트웨어를 보호하는 것. 보안은 사람, 자료, 통신, 컴퓨터 설비에 대한 물리적인

보호등과도 관련된다. (2) 권한이 없는 사람이나 시스템이 읽거나 쓰지 못하도록 하고 권한이

있는 사람이나 시스템만이 접근할 수 있도록 정보나 자료를 보호하는 것.(ISO)

4.235 보조 라이브러리언 (secretary librarian) 책임 프로그래머팀에서의 소프트웨어

라이브러리언.

22

4.236 보조 소프트웨어(support software) 컴파일러, 로더, 기타 유틸리티와 같은 소프트웨어를

개발하고 유지보수 하는데 도움을 주는 소프트웨어. 응용 소프트웨어와 비교. 시스템

소프트웨어와 대조. (IEEE STD 610.12-1990)

4.237 보조 지침서(support manual); 운영 시스템이나 형상요소를 생명주기 동안 서비스하고

관리하기위해 필요한 정보를 제공하는 문서. 하드웨어나 소프트웨어 그리고 그것들을 위해

서비스하고, 고치고, 다시 프로그래밍하기 위한 절차들을 기술. 유지보수 지침서와 비슷함. 진단

지침서; 설치 지침서; 운영자 지침서; 프로그래머 지침서; 사용자 지침서 참조. (IEEE STD 610.12-1990)

4.238 보호 (protection) 컴퓨터 시스템의 모든 부분 또는 일부를 사용하기 위해 접근하는 것을

제한하기 위한 준비. (ISO)

4.239 복잡도 (complexity) 하나의 시스템이나 시스템 구성요소의 복잡한 정도를 말하며

인터페이스의 개수나 복잡도, 조건분기의 개수나 복잡도, 내포되는 정도, 자료구조의 형식등과

같은 시스템 특성에 의하여 결정됨.

4.240 부 루틴 (subroutine) (1) 하나이상의 컴퓨터 프로그램이나 컴퓨터 프로그램내의 하나

이상의 위치에서 사용될 수 있는 연속된 문장의 집합. (ISO) (2) 다른 루틴의 부분이 될 수 있는

루틴. (ANSI) (3) 호출문에 의해 호출되는 부 프로그램으로서 입력값을 받거나 받지 않을 수도

있고 부 루틴의 이름 자체보다는 매개변수 명 프로그램 변수 메커니즘에 의해 출력값을 반환한다.

함수와 대조. 절차(procedure)도 보시오.

4.241 부 시스템 (subsystem) 어셈블러나 구성요소의 집합 또는 하나의 기능을 수행하기 위해

두 가지가 조합된 것.

4.242 부 프로그램 (subprogram) 하나 이상의 다른 프로그램에 의해 호출되는 프로그램 단위.

예를 들면, 절차(procedure), 함수(function), 부 루틴(subroutine) 등이 있다.

4.243 부분적 정당성 (partial correctness) 프로그램의 정확도 증명에서, 프로그램의

출력단정은 논리적으로 당연히 입력 단정과 처리절차에 따르게 된다는 것. 총 정확도 (total

correctness) 와 대조.

4.244 부작용 (side-effect) 프로그램, 부 프로그램, 연산의 처음의 기능에 따라 얻게 되는 결과

또는 이렇게 수행된 활동이나 과정.

4.245 부적합 (nonconformity) 규정된 요건을 충족시키지 못한 것. (ISO 8402:1994-1986)

[주]

1. 이 정의는 한가지 이상의 품질 특성 또는 품질 시스템 요소가 규정된 요건에서 벗어나거나 빠진

것을 포함한다.

23

2. '부적합'과 '결함'과의 기본적 차이는 규정된 요건과 의도된 사용을 위한 요건과의 차이이다.

4.246 부적합 처리(disposition of nonconformity) 부적합 사항을 해결하기위해 존재하는

부적합 개체를 처리하기 위해 취하는 행동. (ISO 8402:1994)

[주] 이런 행동은 교정의 꼴을 취하는데 예를 들면 수리, 재작업, 재등급, 특허와 문서 또는

요구사항의 개정과 같은 것들이다.

4.247 부트스트랩 (bootstrap) (1) 컴퓨터 내에 쉽게 적재되거나 영구히 존재하는 짧은

프로그램으로서 이를 실행시키면 운영체제 같은 큰 프로그램 또는 적재기를 기억장치로

가져온다. (2) 컴퓨터 프로그램이 기억장치에 완전히 적재될 때까지 부가적으로 적재되는

명령어의 집합. (ISO) (3) 자신의 작용에 의해 요구되는 상태로 자신을 가져오도록 설계한 장치나

기법. 예를 들면, 기계루틴의 처음 몇 개의 명령어는 자신의 나머지 부분을 입력장치로 부터

컴퓨터로 가져오도록 한다. (ANSI) (4) 컴퓨터 프로그램의 또 다른 버전을 만드는데 사용하는

컴퓨터 프로그램의 부분. (ANSI) (5) 부트스트랩을 사용하는 것. (ISO)

4.248 부트스트랩 적재기 (bootstrap loader) 부트스트랩을 적재하는데 사용하는 고정적인 부

루틴에서의 입력 루틴.(ISO)

4.249 분기 메트릭(branch metric) 모든 분기가 적어도 한번은 실행이 되는 모듈의 수를 전체

모듈의 수로 나눈 결과.(IEEE STD 730.1-1989)

4.250 분석(analysis) 이해를 목적으로 수행하는 검토 및 조사. (IEEE STD 1074-1995)

4.251 분석 단계 (analysis phase) 요구사항 단계 (requirements phase)를 보시오.

4.252 분석 모델 (analytical model) 어떤 현상 또는 프로세스를 해결 가능한 방정식의

집합으로 표현한 것. 모의실험과 대조.

4.253 불완전 오류수정 (imperfect debugging) 신뢰도 모형화에서 탐지된 결함을 정정하고

제거하려는 가정이 항상 성공적이지는 않다.

4.254 블록 (block) (1) 개체와 같이 취급되기 때문에 기술적이거나 논리적인 형태를 갖는

레코드의 문자열, 단어의 문자열, 문자형 문자열. (2) 연속적으로 기록되는 레코드 집합의

기록단위. 블록은 IBG (Interblock gaps)에 의해 분리되고 각 블록은 한 개 이상의 레코드를 갖는다.

(ANSI) (3) 비트나 N 항 숫자의 묶음이 전달되는 단위. 일반적으로 암호화 절차는 오류제어

목적으로 비트나 N 항 숫자의 묶음에 적용된다. (ANSI) (4) 단어, 문자, 숫자와 같은 것의 집합을

다루는 단위. (ANSI) 프로그램 블록을 보시오.

4.255 블록 구조 언어 (block structure language) 일련의 연속된 문장을 Begin 과 End

분리기호로 한계를 정해주는 설계 또는 프로그래밍 언어. 프로그램 블록을 보시오.

24

4.256 블록 도표 (block diagram) 시스템, 컴퓨터, 장치의 주요한 부분에 대한 기본적인 기능과

이들간의 함수적 관계를 나타내기 위해서 적절한 주해를 포함하여 기하학적인 그림으로 표현한

도식. 순서도와 대조.

4.257 비공식 시험(informal testing) 비형식 시험을 보시오.

4.258 비교기 (comparator) 두개의 컴퓨터 프로그램, 파일 또는 자료 집합으로서의 공통점과

차이점을 명시하기 위해 이들을 비교하는데 사용하는 소프트웨어 도구. 전형적인 비교대상으로

원시코드, 목적코드, 데이터베이스 파일 또는 시험결과가 있다.

4.259 비용 설계 (design-to-cost) 비용목표를 확립하는 것.(IEEE STD 1220-1994)

4.260 비인도 소프트웨어 제품(non-deliverable software product) 계약에 의해서 획득자에게

인도될 것이 요구되지 않는 소프트웨어 제품.(J-STD-016-1995)

4.261 비인도 항목(non-deliverable item) 계약하에 따라 인도될 필요는 없지만 소프트웨어

제품 개발에 사용할 수 있는 하드웨어 또는 소프트웨어 제품(ISO)

4.262 비절차적 프로그래밍 언어(nonprocedural programming language) 문제해결에 대한

절차를 기술하기 보다는 문제해결의 매개변수를 표현하기 위해 사용하는 프로그래밍 언어.(IEEE STD 1008-1987)

4.263 비정상 종료(abnormal end) 프로세스가 완전하게 끝나기 전에 종료하는 것

4.264 비트 (bit) binary digit 의 단축형으로서 0 이나 1 로 표현하는 정보의 단위.

4.265 비형식 시험(informal testing) 고객, 사용자 또는 관리자에 의해 검토되거나 승인되지

않은 시험 계획이나 절차들에 따라 수행되는 시험. 형식 시험과 비교. (IEEE STD 610.12-1990)

4.266 사본 (replication) 소프트웨어 제품을 하나의 매체에서 다른 매체로 복사한 것. (ISO 9000-3:1997)

4.267 4 세대 언어 (fourth generation language) 사용자와 자료처리 전문요원에게 고 수준의

통합된 사용자 기능, 자료관리 기능, 시스템 기능 등을 제공하는 자동화 개발 시스템.

4.268 사용자(user) 특정 기능을 수행하기 위하여 운영 시스템을 이용하는 개인 또는 조직(ISO)[주]

사용자는 획득자, 개발자, 유지보수자와 같은 다른 역할을 수행할 수도 있다.

25

4.269 사용자 문서 (user documentation) 원하는 결과를 얻기 위해 시스템을 사용하는 시스템

명령어들의 최종 사용자를 포함하는 문서로서, 예를 들면 사용자 매뉴얼 등이 있다. 시스템

문서와 대조.

4.270 사용자 안내서(user guide) 사용자 지침서를 보시오. (IEEE STD 610.12-1990)

4.271 사용자 인터페이스(user interface) 사용자와 컴퓨터 시스템의 하드웨어나 소프트웨어

구성요소 사이에 정보교환을 가능하게 하는 인터페이스. (IEEE STD 610.12-1990)

4.272 사용자 지침서(user manual) 바람직한 결과를 얻고자 시스템이나 구성요소를

사용하기위해 필요한 정보를 제공하는 문서. 시스템이나 구성요소의 기능, 제한사항, 선택사항,

제한된 입력, 기대되는 출력, 가능한 오류메시지, 그리고 특별한 명령들을 기술. 사용자 안내와

비슷함. (IEEE STD 610.12-1990)

[주] 컴퓨터 시스템을 운영하는 사람과 시스템을 사용하는 사람이 다른 경우, 사용자 지침서는

운영자 지침서와 구별된다.

4.273 사전명세 (prespecification) 모든 요구사항과 기타 요소들이 알려지기 전, 중요한 요소를

사전에 모두 확인할 수 있다는 가정하에 요구사항을 기술하고, 소프트웨어 시스템을 설계,

시험하고 평가하는 활동.

4.274 사회적 요구사항 (requirements of society) 법적 의무, 규정, 규칙, 규약, 법규와 다른

관련 사항. (ISO 8402:1994)

[주]

1 "다른 관련 사항"은 환경보호, 건강, 안전, 비밀보장, 에너지와 천연자원 보존을 포함한다.

2 품질 요구사항을 정의할 때 모든 사회적 요구사항을 고려해야 한다.

3 사회적 요구사항은 사법적이고 규정된 요구사항을 포함한다.

4.275 산출물(product) 소프트웨어 개발활동의 모든 출력물; 문서, 코드, 모델.(IEEE STD 1074-1995)

4.276 산출물 메트릭(product metric) 문서와 코드의 특징을 측정하는데 사용되는 메트릭

4.277 상세 설계 (detailed design) 구현하기에 충분하도록 완전한 설계까지 확장하기 위하여

(1) 예비설계에서 논리의 수행과정, 자료구조, 자료정의를 더 상세히 구성하는 과정. (2) 상세설계

과정의 결과.

4.278 상용제품(off-the-shelf product) 이미 개발 완료되어 이용 가능하거나 있는 그대로 또는

수정하여 사용할 수 있는 제품(ISO)

4.279 상태 자료(State data) 내부 상태를 정의하고 비교하기 위한 자료.

26

4.280 상태도 (state diagram) 시스템의 내부상태와 동일한 노드, 전이와 동일한 에지로

되어있는 방향 그래프로서 시스템의 상태변화를 묘사하는데 흔히 사용한다. 페트리 넷도 보시오.

4.281 상향식 (bottom-up) 계층구조에서 가장 낮은 수준의 소프트웨어 구성요소로부터

출발하여 최상위 수준의 구성요소까지 점점 높은 수준으로 발전시키는 접근방법이다. 예를 들면,

상향식 설계, 상향식 프로그래밍, 상향식 시험이 있다. 하향식과 대조.

4.282 상향식 설계 (bottom-up design) 가장 기본적이거나 근본적인 구성요소로 부터 시스템

설계를 시작해서 낮은 계층의 구성요소를 사용하여 점점 높은 계층의 구성요소로 발전시켜

나가는 것. 하향식 설계와 대조.

4.283 상호운용성 (interoperability) 두 개 이상의 시스템간에 정보를 교환하거나, 교환된

정보를 상호간에 사용할 수 있는 능력. 호환성(compatability)과 비교.

4.284 샘플 소프트웨어 (sample software) 데이터 수집과 메트릭 계산 절차의 예비 시험에서

이용하기 위한 데이터를 획득하기 위해 진행 중이거나 완료된 프로젝트에서 선택된 소프트웨어(IEEE 1061-1992)

4.285 생명주기 (life cycle) 소프트웨어 생명주기를 보시오.

4.286 생명주기 단계(life-cycle phase) 설계 또는 시험과 같이 특정 활동으로 구분할 수 있는

소프트웨어 개발 또는 운용의 일정한 기간. 각 단계들은 서로 중첩될 수 있다. 그 단계의 산출물이

완전히 검증되기 전에는 어떠한 단계도 종결되지 않는다.

4.287 생명주기 비용(life cycle cost) 제품의 개발, 제조, 시험, 배포, 운영, 지원, 교육에 대한

전체 투자. (IEEE STD 1220-1994)

4.288 생명주기 프로세스 제품(life cycle process product) 고객 제품을 지원하는 생명 주기

프로세스를 수행하기 위해 필요한 최종 항목. 이런 최종 항목은 제품, 프로세스, 또는 서비스이다. (IEEE STD 1220-1994)

4.289 생명주기 모델(life cycle model) 요구사항 정의부터 폐기까지의 시스템의 생명기간을

의미하며 소프트웨어 제품의 개발, 운영 및 유지보수에 포함되는 프로세스, 활동 및 태스크를

포함하는 프레임웍.(ISO)

4.290 생산 라이브러리 (product library) 현재 사용 가능한 소프트웨어를 포함하고 있는

소프트웨어 라이브러리.

4.291 서비스 (service) (1) 공급자와 고객의 관계에서 발생한 활동의 결과. 고객의 요구에

부합하는 공급자의 내부 활동. (ISO 8402:1994-1994) (2) 제품과 관련된 지원 가운데 인도, 설치,

27

유지보수, 훈련, 기타 노동 집약적인 활동. (IEEE STD 1220-1994)

[주]

1 공급자나 고객은 인력이나 장치의 접촉에서 나타낸다.

2 공급자와의 접촉에서 고객의 활동은 서비스 제공을 수립하는 것이다.

3 유형의 제품의 제공이나 사용은 서비스 제공의 한 형태이다.

4 서비스는 제조품과 유형의 제품의 공급과 연관된다.

4.292 서비스 제공 (service delivery) 공급자가 서비스를 제공하기 위해 필요한 활동

4.293 설계 (design) (1) 명세화된 요구사항을 만족시키기 위해 소프트웨어 시스템에 대한

소프트웨어, 구성요소, 모듈, 인터페이스, 시험방법, 자료 등을 정의하는 과정. (2) 설계과정의

결과.

4.294 설계 개체(design entity) 다른 요소들과 구조적, 기능적으로 다르고, 독립적으로

호명되고 참조되는 설계 요소. (IEEE STD 610.12-1990)

4.295 설계 검사 (design inspection) 검사를 보시오.

4.296 설계 검증 (design verification) 검증을 보시오.

4.297 설계 검토 (design review) (1) 비평이나 찬성을 하기위해 시스템의 예비 또는

상세설계를 사용자나 고객 또는 이해관계가 있는 관계자에게 제시하는 정식 회합. (2) 미흡한

설계부분을 찾아내고 개선할 목적으로 기존의 또는 기획된 설계에 대한 정식 검토로서 이것은

제품, 프로세스나 서비스에 대한 성능 향상 가능성 식별, 안전도 등의 사용적합성이나 환경의

관점과 경제적인 관점에 영향을 미칠 수 있다. (3) 설계요건을 만족시키고 문제점을 파악하고

해결책을 제시하기 위해 설계요건 및 설계의 능력을 평가하기 위한 공식적이고, 문서화된

포괄적이고 체계적인 설계에 대한 조사. (ISO 8402:1986)

[주]

1. 설계검토 그 자체 만으로는 설계의 적절성을 보장하는 것은 충분하지 않다.

2. 설계검토는 설계 과정의 어떤 단계에서도 수행할 수 있다.

3. 설계의 능력은 목적에 대한 적합성, 실행 가능성, 제조성, 계측성, 성능, 보전성, 안전성, 환경적

측면, 시간메트릭 및 생명주기 비용 등과 같은 사항이 관련된다.

4. 각각의 설계 검토에 참가하는 자는 품질에 영향을 미치는 모든 기능에 있어서 관련된 자격 있는

직원을 포함하는 것이 좋다.

4.298 설계서(design description) 시스템이나 구성요소의 설계를 기술하는 문서. 시스템 또는

구성요소 구조, 제어 로직, 데이터 구조, 입/출력 형식, 인터페이스 기술, 그리고 알고리즘을

포함함. 설계 문서; 설계 명세와 비슷함. 제품 명세도 보시오. 요구사항 명세와 비교. (IEEE STD 610.12-1990)

28

4.299 설계 단계 (design phase) 소프트웨어 생명주기 중에서 요구사항을 만족하기 위해

소프트웨어의 구조, 소프트웨어의 구성요소, 인터페이스, 자료를 만들고 문서화하고 검증하는

기간.

4.300 설계 단위(design unit) 논리적으로 관련있는 설계 요소들의 집합. Ada PDL 에서 설계

단위는 Ada 컴파일 단위로 표현됨. (IEEE STD 610.12-1990)

4.301 설계 명세 (design specification) 시스템이나 시스템의 구성요소의 설계 문서화에 대한

명세. 예를 들면, 소프트웨어 형상항목이다. 전형적인 내용으로는 시스템 또는 구성요소의

알고리즘, 제어논리, 자료구조, 사용하는 자료정보, 입출력 형식 그리고 인터페이스 설명 등을

포함한다. 요구사항 명세도 보시오.

4.302 설계 문서(design document) 설계서(design description)를 보시오. (IEEE STD 610.12-1990)

4.303 설계 방법론 (design methodology) 특정한 도구, 기법, 지침을 적용하도록 되어있는

설계를 하기 위한 조직적인 접근방법.

4.304 설계 분석 (design analysis) (1) 설계기준, 시스템의 효율성, 기타 기준에 맞는

요구사항에 관한 정확도를 결정하기 위한 설계의 평가. (2) 여러가지 설계 접근방법에 대한 평가.

예비 설계 (preliminary design)도 보시오.

4.305 설계 분석기 (design analyzer) 프로그램의 설계에 관한 정보를 입력으로 받아 모듈

계층도, 자료구조와 제어의 도식, 호출된 자료블록의 리스트와 같은 출력을 내보내는 자동화

설계도구.

4.306 설계 언어 (design language) 특별한 구조와 검증프로토콜을 가지는 언어로서 설계에

관한 문서를 만들고 분석, 개발하는 용도로 사용한다.

4.307 설계 요구사항 (design requirement) 소프트웨어 시스템이나 소프트웨어 시스템

구성요소의 설계에 영향을 미치고 제한을 두는 어떤 요구사항. 예를 들면, 기능 요구사항, 물리적

요구사항, 성능 요구사항, 소프트웨어 개발 표준, 소프트웨어 품질 보증 표준 등이 있다.

요구사항 명세도 보시오.

4.308 설계 요소(design element) 설계의 기본 구성요소 또는 기본 단위. (IEEE STD 610.12-1990)

4.309 설계 웍스루 (design walk-through) 웍스루를 보시오.

4.310 설계 표준(design standard) 설계 또는 데이터나 프로그램 구성요소의 설계 기술의

특징들을 서술하는 표준. (IEEE STD 610.12-1990)

29

4.311 설치 지침서(installation manual) 시스템이나 구성요소를 설치하는고, 초기 인수를

설정하고, 운영을 준비하는데 필요한 정보를 제공하는 문서. 진단 지침서, 보조 지침서; 사용자

지침서도 보시오. (IEEE STD 610.12-1990)

4.312 설치 및 점검 단계 (installation and checkout phase) 한 소프트웨어 제품이 그 운영

환경에 통합되고 요구된 데로 성능을 발휘하는 소프트웨어 생명주기에서의 기간.

4.313 성능 (performance) (1) 주어진 기능을 수행하기 위한 컴퓨터 시스템이나 부 시스템의

능력. (2) 주어진 기능을 수행하는 컴퓨터 시스템 또는 부 시스템의 능력의 정도. 예를 들면,

반응시간, 단위시간당 처리량, 트랜잭션의 개수가 있다.

4.314 성능 명세 (performance specification) (1) 시스템이나 시스템 구성요소를 위해 성능의

필요조건을 설명하는 명세(서). (2) 요구사항 명세와 동의어. (U.S. Navy usage) 기능 명세(서)도

보시오.

4.315 성능 요구사항(performance requirement) 기능에 대한 품질 속성 또는 기능적인

요구사항이 얼마나 잘 성취되어야 할 지를 식별한 측정 기준.(IEEE STD 1220-1994)

4.316 성능 척도(measure of performance: MOP) 성능 척도는 효과 척도(MOE)를 만족하기

위해 필요한 설계 요구사항을 제공. 각각의 효과를 측정하기 위해 여러 가지 방법의 성능 척도가

있다.(IEEE STD 1220-1994)

4.317 성능 평가 (performance evaluation) 연산목적이 얼마나 효과적으로 달성되는지를

결정하기 위한 시스템이나 시스템 구성요소에 대한 기술적 평가.

4.318 성능 필요조건 (performance requirement) 시스템이나 시스템 구성요소가 가져야 하는

성능의 특징을 상술하는 필요조건. 예를 들면, 속도, 정확도, 빈도수가 있다.

4.319 세그먼트 (segment) (1) 어느 순간에는 내부기억장치에서 관리되어 전체 컴퓨터

프로그램 없이도 수행될 수 있는 컴퓨터 프로그램과 독립된 부분. (ISO) (2) 두 분기점 사이의

연속된 컴퓨터 프로그램 문장. (3) 컴퓨터 프로그램을 세그먼트로 나누는 것. (4) 컴퓨터

프로그램과 데이터베이스.(J-STD-016-1995) 경로분석도 보시오. 구성요소, 모듈, 서브프로그램

문장도 보시오.

4.320 소프트웨어 (software) (1) 컴퓨터 시스템의 운영에 관련된 컴퓨터 프로그램, 절차, 규칙

관련된 문서와 자료. (2) 컴퓨터 시스템의 운영에 관련된 프로그램, 절차, 규칙, 관련된 문서. (ISO)

하드웨어와 대조.

4.321 소프트웨어 개발(software development) 소프트웨어 제품을 생성하기 위한 활동의 집합.

30

소프트웨어 개발은 신규 개발, 변경, 재사용, 재공학, 유지보수 등 소프트웨어가 결과물로 나오게

하는 모든 활동을 지칭. (J-STD-016-1995)

4.322 소프트웨어 개발 계획 (software development plan) 소프트웨어 제품의 개발을 위한

프로젝트계획.

컴퓨터 프로그램 개발 계획과 동의어.

4.323 소프트웨어 개발 노트북 (software development notebook) 주어진 소프트웨어 모듈

개발에 관련된 자료의 집합으로서 이것은 전형적으로 모듈에 관한 요구사항, 설계, 기술보고,

결과코드, 시험계획, 문제보고, 일정 계획, 노트 등을 포함한다. 프로젝트 노트북도 보시오.

4.324 소프트웨어 개발 라이브러리 (software development library) 소프트웨어 개발 노력에

관련된 인간과 컴퓨터가 읽을 수 있는 정보를 가지고 있는 소프트웨어 라이브러리.

4.325 소프트웨어 개발 생산성 (software development productivity) 소프트웨어를 생산하고

유지보수하기 위해 조직, 기술, 기법 및 자동화 도구 등으로 구성되는 상대적인 능력.

4.326 소프트웨어 개발 주기 (software development cycle) (1) 소프트웨어 제품 개발을 결정한

때부터 제품이 인도된 때까지의 기간. 이 주기는 전형적으로 요구사항단계, 설계 단계, 구현단계,

시험단계 그리고 때로 설치 및 확인단계를 포함한다. (2) 소프트웨어 제품개발을 결정한 때부터

개발자에 의해 제품이 더 이상 보강되지 않게 될 때까지의 기간. (3) 때로는 소프트웨어

생명주기와 동의어로 쓰인다. 소프트웨어 생명주기와 대조.

4.327 소프트웨어 개발 프로세스 (software development process) 사용자 요구사항을

소프트웨어 요구사항으로 변환하고, 소프트웨어 요구사항을 설계로 변환하고, 설계결과를 코드로

구현하고, 코드를 운영되기 위해 시험하고 문서화하고 검증하는 프로세스.

4.328 소프트웨어 개발 화일(software development file: SDF) 소프트웨어 개발의 산출물에

대한 저장소. 요구사항 정의, 설계, 구현, 개발자 내부 시험 정보, 일정 등이 저장되어 있다.(J-STD-016-1995)

4.329 소프트웨어 경험 자료 (software experience data) 모델, 신뢰도 예측, 기타 소프트웨어에

관한 정량적인 표현을 개발하는데 유용할 수 있는 소프트웨어의 사용이나 개발에 관련된 자료.

4.330 소프트웨어 공학 (software engineering) 소프트웨어를 개발하고 운영하고

유지보수하고 보존하기위한 체계적인 접근방법.

4.331 소프트웨어 공학 환경(software engineering environment) 소프트웨어 공학 활동을

수행하는데 필요한 장치, 하드웨어, 소프트웨어, 펌웨어, 절차, 문서. 케이스 도구, 컴파일러,

어셈블러, 연결기, 적재기, 운영체제, 디버거, 시뮬레이터, 문서화 도구, 데이터베이스 관리 시스템

31

등을 포함한다.(IEEE STD 610.12-1990)

4.332 소프트웨어 단위(software unit) 분리하여 컴파일 할 수 있는 코드의 일부.(ISO)

4.333 소프트웨어 데이터베이스 (software database) 운영하는 소프트웨어 시스템내부에

위치하고 값이 주어지고 정의된 자료를 모아 놓은 파일.

4.334 소프트웨어 도구 (software tool) 다른 컴퓨터 프로그램이나 관련 자료들을 식별, 시험,

분석 또는 유지보수하는데 도움을 주는 컴퓨터 프로그램. 예를 들면, 자동화 설계도구, 컴파일러,

시험도구, 또는 유지보수용 도구 등이 있다.

4.335 소프트웨어 라이브러리 (software library) 소프트웨어 개발, 사용, 유지보수를 돕도록

설계한 관련 문서와 소프트웨어의 집합. 이것은 소프트웨어 개발, 라이브러리, 마스터 라이브러리,

제품 라이브러리, 프로그램 라이브러리 소프트웨어 보관소 등을 포함한다. 시스템 라이브러리도

보시오.

4.336 소프트웨어 라이브러리언 (software librarian) 소프트웨어 라이브러리를 만들고,

통제하고, 유지관리할 책임이 있는 사람.

4.337 소프트웨어 명세 검토(software specification review) 소프트웨어 요구사항 검토 참조. (IEEE STD 610.12-1990)

4.338 소프트웨어 명세(서) (software documentation) 설계에 관련 상세한 설명, 능력에 대한

설명, 소프트웨어시스템으로부터 희망하는 결과를 얻기 위해 소프트웨어를 사용하기 위한

운영명령을 제공하는 인간이 읽을 수 있는 형태의 컴퓨터 리스팅과 출력결과를 포함하는

기술자료나 정보. 문서화, 시스템명세(서), 사용자 문서도 보시오.

4.339 소프트웨어 모니터 (software monitor) 다른 컴퓨터 프로그램을 수행하면서 그

프로그램의 수행에 관련된 상세한 정보를 제공해 주는 소프트웨어 도구.

4.340 소프트웨어 보관소 (software repository) 소프트웨어 및 관련문서를 보관하기 위하여

영구적인 기록 보관용의 장소를 제공하는 소프트웨어 라이브러리.

4.341 소프트웨어 생명주기 (software life cycle) (1) 소프트웨어 제품을 계획할 때 부터 제품이

더 이상 유용하지 않게 될 때까지의 기간으로서 이것은 전형적으로 요구사항단계, 설계단계,

구현단계, 시험단계, 설치 및 확인단계, 운영 및 유지 보수단계, 그리고 때로 보존단계를 포함한다.

(2) 소프트웨어 시스템의 생명이 진행됨에 따라 필요한 통제단계의 정의 및 편성. 보통 이러한

단계는 요구사항분석, 기능명세, 설계, 코딩, 시험, 설치, 운용 및 유지보수단계로 구분한다.

소프트웨어 개발 주기와 대조.

4.342 소프트웨어 생명주기 모델(software life cycle model) 소프트웨어 생명주기를 생성하기

32

위해 이 표준의 활동에 매핑하여 선택된 프레임워크.

4.343 소프트웨어 서비스(software service) 소프트웨어 개발, 유지보수, 운영과 같은

소프트웨어 제품과 관련된 활동, 작업 또는 임무의 실행.(ISO)

4.344 소프트웨어 설계 명세 (software design specification) 분석, 계획, 구현 그리고

의사결정을 위하여 작성하는 문서로써 소프트웨어 설계에 대한 모든 정보를 갖는다. 따라서

소프트웨어 설계명세는 시스템에 대한 청사진 또는 모델로 생각할 수 있다.

4.345 소프트웨어 시스템(software system) 단일 소프트웨어 프로젝트의 주체가 되는

소프트웨어

4.346 소프트웨어 시제품 (software prototyping) 주요 요구사항을 명세화 하기 전에 사용자의

요구사항을 검증 및 확인하기 위해 개발하는, 제안한 시스템의 모형 또는 불완전한 버전.

4.347 소프트웨어 시험 사건 (software test incident) 소프트웨어 시험 수행 중 발생한 사건.

별도의 조사를 필요로 한다. (IEEE STD 610.12-1990)

4.348 소프트웨어 시험 환경 (software test environment) 소프트웨어의 시험을 수행하기 위한

하드웨어, 소프트웨어, 펌웨어, 절차, 문서. 시뮬레이터, 코드 분석기, 시험 사례 생성기, 경로

분석기와 소프트웨어 공학 환경에서 사용된 도구를 모두 포함한다. (IEEE STD 610.12-1990)

4.349 소프트웨어 신뢰도 (software reliability) (1) 소프트웨어가 주어진 조건에서 지정된 시간

내에 한 시스템에 대하여 고장을 일으키지 않을 확률로서, 그 확률은 그 시스템에 있어서의 결함이

존재할 확률뿐만 아니라 그 시스템의 사용과 입력의 함수관계를 나타낸다. 시스템의 입력이

존재하는 결함과 부합되는지의 여부를 결정한다. (2) 프로그램이 주어진 시간과 조건하에서

요구하는 기능을 수행하는 능력.

4.350 소프트웨어 요구사항 검토(software requirement review) 소프트웨어 구성 항목에 대한

요구사항을 얼마나 잘 이해하고 적용하였는지를 평가하고, 예비 설계를 수행하기 위해 필요한

기본을 구성하고있는지를 결정하기 위해, 하나 이상의 소프트웨어 구성 항목들을 명세한

요구사항의 검토. 시스템 요구사항 검토도 보시오. (IEEE STD 610.12-1990)

[주] 미국 국방부는 소프트웨어 명세 검토(software specification review)라고 함.

4.351 소프트웨어 요구사항 명세 (software requirements specification) 소프트웨어에 대한

기능, 성능, 설계 시 제약조건 등과 같은 본질적인 요구사항 및 외부 인터페이스에 대하여 기술한

문서.

4.352 소프트웨어 요소(software element) 소프트웨어의 개발과 유지보수 기간에 생성되고

획득 가능한 인도할 수 있는 문서. 예를 들면 (1) 프로젝트 계획 문서 (2) 소프트웨어 요구사항과

33

설계 명세서 (3)시험 문서 (4) 사용자 인도 문서 (5) 프로그램의 소스 코드 (6) 보고서를 포함한다.(IEEE STD 1028-1988)

4.353 소프트웨어 유지보수 (software maintenance) (1) 소프트웨어를 인도한 후 결함을

제거하기 위한 수정. (2) 소프트웨어를 인도한 후 결함을 제거, 성능을 향상, 변화된 환경에 대한

적응을 위한 수정. 적응 유지보수, 교정 유지보수, 완전 유지보수도 보시오.

4.354 소프트웨어 잠재요인 분석 (software sneak analysis) 원하는 동작을 방해하거나

불필요한 동작을 일으킬 수 있는 조건 혹은 잠재적인 논리제거를 위한 경로를 식별하기 위하여

소프트웨어에 적용하는 기법.

4.355 소프트웨어 전개(software transition) 소프트웨어 개발에 대한 책임을 하나의 조직(예를

들면 개발 조직)에서 다른 조직(유지보수 조직)으로 넘기는 활동의 집합.

4.356 소프트웨어 제품 (software product) (1) 사용자에게 납품하도록 지정한 소프트웨어

제품. (2) 컴퓨터 프로그램, 절차, 관련된 문서 및 자료의 집합체.(ISO)

4.357 소프트웨어 제품 요구사항 문서(software product requirement document) 개발될

소프트웨어에 대한 모든 요구사항을 기술한 문서.

4.358 소프트웨어 컴포넌트(software component) 소프트웨어 시스템 혹은 모듈, 단위, 데이터,

문서와 같은 요소들을 참조하기위해 사용하는 일반적인 용어

4.359 소프트웨어 특성(software characteristic) 소프트웨어의 품질, 속성, 특징, 사건의

발생가능성.

4.360 소프트웨어 특징(software feature) (1) 소프트웨어 항목의 구별되는 특색. 예를 들면,

성능, 호환성, 기능성 (2) 요구사항 문서에 의해 명세되거나 암시되는 소프트웨어 특색. 예를 들면,

기능성, 성능, 속성, 설계 제약사항. (IEEE STD 610.12-1990)

4.361 소프트웨어 품질 (software quality) (1) 명세(서)와의 일치정도처럼 주어진 요구를

만족하기 위한 능력에 영향을 미치는 소프트웨어 제품의 모든 특성과 속성. (2) 소프트웨어가

요구되는 속성의 조합을 갖고 있는지의 정도. (3) 고객 또는 사용자에게 있어서 해당 소프트웨어가

그들의 기대에 어느 정도 부응하는가의 정도. (4) 현재 사용중인 소프트웨어가 고객의 기대에 어느

정도 부응하는가의 정도를 결정하는 소프트웨어의 제한 속성.

4.362 소프트웨어 품질 관리(software quality management) 소프트웨어 품질 정책을 결정하고

수행하는 모든 소프트웨어 관리 기능의 관점

4.363 소프트웨어 품질 보증 (software quality assurance) 품질 보증을 보시오

34

4.364 소프트웨어 품질 정책(software quality policy) 소프트웨어 품질에 관하여 최고 관리자에

의해 결정되는 모든 품질 활동의 취지와 조직의 방향

4.365 소프트웨어 품질 메트릭(software quality metric) 해당 소프트웨어의 품질에 영향을

미치는 속성을 어느 정도 보유하는지를 표현하는 함수(function)로서 그 함수의 입력은 해당

소프트웨어에 대한 자료이고 출력은 단일 수치로 표현된다. [주] 이 정의는 IEEE STD 610.12-1990

에서 설명하는 품질 메트릭의 정의와는 다르다.

4.366 소프트웨어 프로젝트(software project) 프로젝트 동의서에 조건에 만족하는 기술적이고

관리적인 모든 프로젝트 기능, 활동, 작업의 집합. 소프트웨어 프로젝트는 하나의 프로젝트일 수도

있고 다른 큰 프로젝트의 한 부분일 수도 있다. 소프트웨어 프로젝트는 소프트웨어 생명주기의

일부분에만 걸쳐 있다.

4.367 소프트웨어 프로젝트 관리(software project management) 소프트웨어 프로젝트를 계획,

조직, 감시, 제어하는 프로세스

4.368 소프트웨어 프로젝트 관리 계획(software project management plan, SPMP) 소프트웨어

프로젝트를 제어하기 위한 문서. 소프트웨어 프로젝트 관리 계획은 소프트웨어 프로젝트의

요구사항을 만족하기 위한 기술적, 관리적인 프로젝트의 기능, 활동, 작업을 정의한다.

4.369 소프트웨어 항목(software item) (1) 식별할 수 있는 소프트웨어 제품의 부분. (ISO 9000-

3:1997) (2) 컴퓨터 프로그램 또는 데이터베이스와 같은 사용자의 기능요구를 만족하는

소프트웨어의 집합으로 자격 시험, 형상관리의 대상. 소프트웨어 항목은 하나 이상의 소프트웨어

단위로 만들어진다. (3) 소스 코드, 객체 코드, 작업 제어 코드, 제어 데이터, 또는 이러한 항목들의

집합. (IEEE STD 610.12-1990)

4.370 소프트웨어 형상 관리 (software configuration management) 형상관리를 보시오.

4.371 소프트웨어 확인 및 검증 계획(software verification and validation plan) 소프트웨어를

확인 및 검증하기 위한 계획

4.372 소프트웨어 확인 및 검증 보고서(software verification and validation report)

소프트웨어의 확인 및 검증 결과와 품질 보증 결과를 기술한 문서.

4.373 속성(attribute) 개체의 측정 가능한 물리적 또는 추상적인 속성(property).

4.374 수리 (repair) 부적합 제품에 행동을 취함으로써 비록 처음에는 기술된 요구사항을

충족하지 못하지만 의도한 사용 요구사항을 만족시킬 수 있도록 하는 것. (ISO 8402:1994)

[주]

1 수리는 부적합 제품 처리의 한 형태이다.

35

2 수리는 적합했으나 사용 중 부적합 제품이 된 것을 유지보수 차원에서 원래상태로 회복시키기

위한 보수 행위를 포함한다.

4.375 수정 (modification) (1) 소프트웨어의 변경. (2) 소프트웨어의 변경과정.

4.376 수행 (execution) 컴퓨터에 의해 컴퓨터 프로그램의 명령어나 명령어들을 실행하는

과정. (ISO)

4.377 수행 시간 (execution time) (1) 프로그램을 수행하기 위하여 중앙 프로세서가 사용하는

시간의 양. (2) 프로그램이 수행되는 시간의 양. 실행 시간도 보시오.

4.378 수행 시간 이론 (execution time theory) 소프트웨어 신뢰도를 평가하기 위한 기초로

누적된 수행시간을 이용하는 이론.

4.379 순서도 (flow chart) 연산, 자료, 흐름, 도구를 표현하는 기호를 이용한 정의, 분석,

문제의 해결책에 대한 도식.

블록 다이어그램과 대조. (ISO)

4.380 순차 처리 (sequential process) 다음 것이 시작되기 전에 앞의 것이 끝나야 하는

방법으로 수행하는 처리. 병행처리와 대조.

4.381 순환 루틴 (recursive routine) 자신의 부 루틴으로 사용될 수도, 다른 부 루틴이나 자신에

대해 호출 될 수 도, 자기 자신을 호출할 수 도 있는 루틴, 일반적으로 순환루틴을 사용하려면 아직

끝내지 않은 자신의 상태에 관한 기록을 유지해야 한다. 예를 들면, 푸쉬다운 리스트가 있다.

4.382 스택 (stack) 나중에 들어간 것이 먼저 나오는 방법으로 호출되는 리스트. 큐와 대조.

4.383 스터브 (stub) (1) 상위 모듈의 개발과 시험동안 사용하는 각 프로그램 모듈. (2)

프로그램 단위의 본체를 대신하여 그 단위 프로그램이 다른 곳에 정의되어 있거나 정의될 것임을

나타내는 프로그램 문장. (3) 점증적 시험에서 구성 원소간의 연관성을 모의시험하기 위해 설계한

임시적인 모의 모듈이며 시험모듈로부터 호출되는 모듈의 역할을 대신하는 것으로 호출모듈이

기대하는 자료값을 제공할 수도 있다.

4.384 스트레스 시험(stress testing) 명세된 요구사항의 범위 내에 시스템이나 구성요소를

평가하기위해 수행되는 시험. (IEEE STD 610.12-1990)

4.385 스트링 (string) 문자나 물리적 요소를 선형적으로 연속되게 나열한 것. (ISO)

4.386 승인(approval) 개발자의 계획, 설계 또는 프로젝트 기간동안 나타나는 활동에 대한

획득자 측의 권한 있는 대표자의 인정으로 앞으로 수행할 일에 대한 기준이 됨.

36

4.387 시간 분석기 (time analyzer) 프로그램의 각 경로마다 명령어의 수행시간을 더하거나

또는 프로그램의 특정한 위치에 관찰자(probe)를 삽입한 다음 프로브들 사이의 수행시간을

측정함으로써 컴퓨터 프로그램이나 컴퓨터 프로그램 일부분의 수행시간을 예상하거나 측정하는

소프트웨어 도구.

4.388 시분할 (time sharing) (1) 한 프로세서에서 둘 이상의 프로세서에게 시간을 나누어주는

컴퓨터 시스템의 운영기법. (ISO) (2) 둘 이상의 사용자가 동시에 여러 컴퓨터 프로그램을 수행할

수 있도록 컴퓨터 시스템의 시간을 나누어 사용하도록 하는 기법. (ISO)

4.389 시스템 (system) (1) 특정한 기능을 수행하기 위하여 구성한 사람이나 기계 또는 방법의

모임. (2) 다양하게 상호 작용하는 특정한 구조 및 부 함수로 구성된 통합체. (3) 상호작용이나

상호종속에 의해서 연결되어 많은 기능을 수행하지만 단 한가지의 단위로서 작용하는 그룹이나

부 시스템. (ANSI N45.2.10 -1973) (3) 명시된 요구나 목적을 만족시키기 위하여 능력을 제공하는

하나 또는 그 이상의 프로세스, 하드웨어, 소프트웨어, 설비, 사람으로 구성되는 집합체.(ISO)

4.390 시스템 개발 주기(system development cycle) 시스템을 개발하겠다는 결정으로부터

시작하여 시스템이 최종 사용자에게 양도될 때까지의 시간 주기. 시스템 생명 주기와 비교.

소프트웨어 개발 주기도 보시오. (IEEE STD 610.12-1990)

[주] 시스템이 더 이상 향상되지않을 때, 즉 시스템 개발완료까지의 시간 주기, 또는 전체 시스템

생명 주기를 의미하기도 함.

4.391 시스템 검증 (system verification) 검증 (verification) 을 보시오.

4.392 시스템 구조 (system architecture) 시스템 구성요소간의 구조 및 관계. 시스템 구조는

그것의 운영환경과 시스템의 인터페이스를 포함한다.

4.393 시스템 라이브러리 (system library) 다른 프로그램에서 사용하거나 내장되어 있어서

참조하기 위해 호출될 수 있는 시스템 상주 소프트웨어의 집합. 예를 들면, 요구되는 프로그램에

합병 시킬 수 있는 연결 편집기에서의 루틴이 있다.

4.394 시스템 명세(서) (system documentation) 시스템의 요구사항, 설계사항, 상세설계, 능력,

제한사항, 기타특성을 알려주는 문서. 사용자 문서와 대조.

4.395 시스템 분할 구조(system breakdown structure: SBS) 프로젝트의 목적을 성취하기 위해

필요한 각 작업에 대해 자원의 할당과 작업의 할당과 이를 개발 팀에 할당하기 위해 사용하는

생명주기 프로세스와 요소에 대한 계층구조.

4.396 시스템 생명 주기(system life cycle) 시스템에 대한 생각을 착상하는 것으로부터

시작하여 시스템이 더 이상 사용할 수 없을 때까지의 시간 주기. 시스템 개발 주기와 비슷함. (IEEE STD 610.12-1990)

37

4.397 시스템 설계 (system design) (1) 하드웨어 및 소프트웨어 구조, 구성요소, 모듈,

인터페이스, 시스템 요구명세를 만족시키는 자료를 정의하는 과정. (2) 시스템 설계 과정의 결과.

4.398 시스템 설계 검토 (system design review) 시스템 요구사항을 형상 항목에 할당, 할당을

수행하는 프로세스, 다음 단계를 위한 계획, 제조 고려사항, 그리고 생산 계획을 평가하기 위해

수행하는 검토. (IEEE STD 610.12-1990)

4.399 시스템 소프트웨어(system software) 컴퓨터 시스템과 관련된 프로그램들의 운영과

유지보수를 쉽게 하는 컴퓨터 시스템이나 같은 종류의 컴퓨터 시스템을 위해 설계된 소프트웨어.

예를 들면, 운영체제, 컴파일러, 유틸리티가 있다. 응용 소프트웨어와 대조.

4.400 시스템 시험 (system testing) 요구사항에 적합한지를 검증하기 위해 모든 하드웨어와

소프트웨어를 시험하는 과정. 인수 시험, 자격 시험도 보시오.

4.401 시스템 신뢰도(system reliability) 특정 환경이나 시간에서 요구되는 작업이나 임무를

수행할 수 있는 모든 하드웨어와 소프트웨어 부 시스템을 포함하는 시스템의 확률. 운영 신뢰도,

소프트웨어 신뢰도도 보시오.

4.402 시스템 요구사항 검토(system requirement review) 시스템에 대하여 정의된 요구사항의

타당성과 완전성을 평가하고, 그러한 요구사항들을 생산하기위한 시스템 공학 프로세스를

평가하고, 시스템 공학 연구의 결과를 평가하고, 시스템 공학 계획을 평가하기위해 수행되는 검토.

소프트웨어 요구사항 검토도 보시오. (IEEE STD 610.12-1990)

4.403 시스템 유효성(system effectiveness) (1) 시스템의 의도된 용도를 만족하는지의 능력에

대한 측정. (2) 시스템 요소의 신뢰성과 유지보수성.

4.404 시스템 확인 (system validation) 확인 (validation) 을 보시오.

4.405 시작-끝 블록 (begin-end block) Begin 과 End 분리기호 안에 내포되고 단일입구와

단일출구에 의해 특징 지워지는 일련의 설계나 프로그램의 문장.

4.406 시정조치 (corrective action) 재발을 방지하기 위해 부적합사항, 결점 또는 다른

바람직하지 않은 사항의 원인을 제거하기 위해 취하는 행동. (ISO 8402:1994)

[주]

1 시정조치는 절차와 시스템에서와 같이 품질 루프의 어떤 단계에서도 품질개선 달성을 위한

변화를 포함한다.

2 "시정"과 "시정조치"는 구별된다.

"시정"은 수리, 재작업, 조정을 의미하며 존재하는 부적합 사항을 처리하는 것을 말한다.

"시정조치" 부적합 사항의 원인을 제거하는 것을 말한다.

38

4.407 시제품(prototype) 뒤 단계들 또는 시스템의 최종, 완전한 버전을 위한 모델 역할을 하는

예비 유형, 양식, 또는 시스템의 실례. (IEEE STD 610.12-1990)

4.408 시제품화(prototyping) 사용자 피드백을 허용하고, 가능성을 결정하고, 시기 적절성이나

개발 프로세스를 지원함에 있어서 발생하는 논점들을 조사하기 위해 하드웨어나 소프트웨어의

부분 또는 전체의 예비 버전을 개발하는 하드웨어와 소프트웨어 개발 기술. 신속 시제품화(rapid

prototyping)도 보시오. (IEEE STD 610.12-1990)

4.409 시제품화 전략(prototyping strategy) 시제품을 개발한 이후에 수행할 소프트웨어

개발활동의 방침. 이러한 방침으로 (1) 시제품을 버리고 일반 프로그래밍 언어로 시스템을

구축하는 방법. (2) 시제품이 완전한 시스템으로 진화할 때까지 변경 및 보강하는 방법. (3)

시스템 개발이 불가능하거나 더 이상 필요 없어서 사업 자체를 취소하는 방법 등이 있다.

4.410 시제품화 팀 (prototyping team) 소프트웨어 시제품화 방법에 경험 있는 프로그래머/

분석가와 시스템의 개발을 요구한 조직에 소속된 한두 명의 사용자로 구성되는 소규모의 팀. 팀의

목적은 시제품을 개발하고 시험하며, 시스템 요구사항과 관련된 변경사항에 대해 자문을

수행하는데 있다.

4.411 시험 (testing) (1) 수동 또는 자동 수단을 통하여 시험자료 집합에 대해 프로그램을 직접

수행시켜 봄으로써 프로그램의 동작을 검사하는 과정. (2) 수동 또는 자동수단을 통하여 시스템이

특정요구를 만족하는가를 검증하고 기대결과와 실제결과의 차이점을 확인함으로써 시스템 또는

시스템 구성요소를 평가하는 과정. 오류수정과 비교.

4.412 시험 가능성 (testability) (1) 소프트웨어가 시험기준의 설정 및 이 기준에 따른

소프트웨어의 평가를 편리하게 해주는 정도. (2) 요구사항 정의가 시험기준에 따르는

요구사항분석을 쉽게 해주는 정도. (3) 요구사항이 만족되는가를 결정하기 위하여 객관적이며

타당한 시험을 설계할 수 있는 정도.(ISO)

4.413 시험 계획 (test plan) 시험의 범위, 시험 방법, 시험에 소요되는 자원, 그리고 시험 일정

등을 명시한 문서.

4.414 시험 단계 (test phase) 소프트웨어 제품의 구성요소를 평가하고 통합하며 요구가

만족되었는지를 결정하기 위하여 소프트웨어 제품을 평가하는 소프트웨어 생명주기상의 단계.

4.415 시험 단위(test unit) 서로 관련있는 제어 자료(예를 들면, 테이블), 사용 절차, 운용

절차를 묶어 놓은 하나 또는 그 이상의 컴퓨터 프로그램 모듈로 아래의 조건을 만족해야 한다. (IEEE STD 610.12-1990)1. 모든 모듈은 컴퓨터 프로그램의 형태로 되어있다.

2. 시험 단위내의 적어도 한 모듈은 단위시험을 수행하지 않은 상태이다.

39

3. 관련 자료와 절차를 대상으로 시험 프로세스가 수행된다.

4.416 시험 로그 (test log) 시험 행위와 관련된 모든 세부 사항을 시간순서대로 기록한 것.

4.417 시험 명세(test specification) 성능과 설계 명세서가 사용자의 요구를 충족하는지를

보증하기 위해 수행하는 특정 시험을 위해서 사용되는 시험 기준과 방법에 대한 기술. 시험 명세는

시험하는 프로그램의 기능과 능력, 시험환경을 정의한다.

4.418 시험 목표 (test objective) 소프트웨어 문서에 기술되어 있는 요구 사항과 실제 작동하는

행위를 비교하여 특정 조건에서 측정되어질 소프트웨어 특징의 집합. (IEEE STD 1008-1987)

4.419 시험 반복 가능성 (test repeatability) 시험이 행해질 때마다 동일한 결과가 생성되는지를

보여주는 시험의 속성.

4.420 시험 범위(test coverage) 시험사례가 시스템 또는 소프트웨어에 대한 요구사항을

시험하는 정도.(ISO)

4.421 시험 베드 (test bed) (1) 시스템이나 시스템 구성요소를 시험하기 위해 필요한

시뮬레이터, 계측도구, 다른 지원 소프트웨어와 하드웨어를 갖고 있는 환경. (2) 시스템이나

시스템 구성요소를 시험하기 위해 필요하여 수집된 시험 사례.

4.422 시험 보고서 (test report) 시스템 또는 시스템 구성요소에 대하여 실행하는 시험의

행위와 결과를 표현하는 문서.

4.423 시험 사건 보고서(test incident report) 시험동안 발생한 사건을 기록한 문서. 시험 사례

명세; 시험 항목 전달 보고서; 시험 로그; 시험 계획; 시험 절차; 시험 보고서도 보시오. (IEEE STD 610.12-1990)

4.424 시험 사례 (test case) (1) 특정 프로그램 경로를 검사하거나 주어진 요구를 만족하는지를

검증하는 것과 같이 특정 목적을 위해 개발한 시험 자료와 이와 관련된 절차의 집합. (2) 시험에

사용하는 입력자료, 예상되는 결과, 그리고 수행조건 등을 명시한 문서.

4.425 시험 사례 명세(test case specification) 시험을 위한 입력, 조건, 예상되는 결과를

명세하는 문서. 시험 기술; 시험 명세와 비슷함. 시험 사건 보고서; 시험 로그; 시험 계획; 시험

절차; 시험 보고서도 보시오. (IEEE STD 610.12-1990)

4.426 시험 사례 생성기 (test case generator) 자동화 시험 생성기를 보시오.

4.427 시험 설계 (test design) 소프트웨어 시험 방법에 대한 자세한 내용을 명시한 문서.

4.428 시험 요약 보고서(test summary report) 시험 활동과 결과를 요약하는 문서. 시험 항목의

40

평가를 포함. 시험 사례 명세; 시험 사건 보고서; 시험 항목 전달 보고서; 시험 로그; 시험 계획;

시험 절차; 시험 보고서도 보시오. (IEEE STD 610.12-1990)

4.429 시험 운전기 (test driver) (1) 시험 입력을 종합하거나 시험하에서 항목을 호출하고 시험

결과를 보고하는 운전기. (2) 점증적 시험에서 구성 원소간의 연관성을 모의 시험하기위해 설계할

임시의 모의(dummy)모듈로서, 시험사례를 준비하며 시험모듈을 호출하고 시험 모듈의

수행결과를 출력하는 역할을 담당한다.

4.430 시험 유효성 (test validity) 시험이 명시된 목적을 성취하는 정도.

4.431 시험 준비 검토(test readiness review) (1) 하나이상의 구성 항목들에 대한 예비 시험

결과를 평가하기위해 수행되는 검토. 각 구성 항목을 위한 시험 절차가 완벽하고 시험 계획과

기술에 부합하는지, 시험 요구사항을 만족시키는지를 평가하고, 프로젝트가 구성 항목에 대한

형식 시험을 수행할 준비가 되어있는지를 검증하기위해 수행되는 검토. (2) 하드웨어나

소프트웨어 구성요소를 위해 수행되는 (1)과 같은 검토. 코드 검토; 형식 자격 검토; 설계 검토;

요구사항 검토와 비교. (IEEE STD 610.12-1990)

4.432 시험 자료 (test data) 시스템이나 시스템 구성요소를 시험하기 위해 만드는 자료. 시험

사례도 보시오.

4.433 시험 자료 생성기 (test data generator) 자동화 시험 생성기를 보시오.

4.434 시험 자료 집합 (test data set) 시험에 사용되는 입력자료의 집합.

4.435 시험 절차 (test procedure) (1) 주어진 시험에 대한 결과의 구성, 운용, 그리고 평가를

위한 자세한 명령어. 이와 관련된 절차의 집합은 시험절차문서를 구성하기 위하여 자주 병합된다.

(2) 시험 수행에 대한 순차적인 활동을 명시한 문서.

4.436 시험 절차 명세(test procedure specification) 시험 절차를 보시오.

4.437 시험 집합 구조(test set architecture) 시험 목표의 경험적인 분할을 반영한 시험 사례의

집합들의 중첩된 관계.

4.438 시험 항목 (test item) 시험 대상인 소프트웨어 항목. (IEEE STD 610.12-1990)

4.439 시험 항목 전달 보고서(test item transmittal report) 시험을 위해 제출될 하나 이상의

항목들을 식별하는 문서. 현재 상태와 위치 정보 포함. 시험 사례 명세; 시험 사건 보고서; 시험

로그; 시험 계획; 시험 절차; 시험 보고서도 보시오. (IEEE STD 610.12-1990)

4.440 식별자 (identifier) (1) 이름을 붙이거나, 지시하거나, 위치를 나타내는데 사용하는 부호.

41

식별자는 자료구조, 자료항목, 프로그램의 위치등에 관련된다. (2) 자료항목을 식별하거나,

이름을 붙이는데, 때로는 그 자료의 특정 성질을 나타내는데 사용하는 문자나 문자그룹. (ISO)

4.441 신뢰도 (reliability) (1) 주어진 시간과 조건하에 요구된 기능을 수행 할 수 있는 항목의

능력 또는 확률. (ANSI/ASQC A3-1978) (2) 개개의 사물이 주어진 조건하에 주어진 기간동안

요구되는 기능을 수행하는 능력. '신뢰성'이라는 용어는 요구기능을 수행하는 확률이나 비율을

나타내는 신뢰성 특성으로도 사용한다. 소프트웨어 신뢰도를 보시오.

[주]

이 정의는 IEC Publication 271 에서 인용한 것이다. IEC Publication 271 에 있는 이 용어가 갱신되면

이 용어의 정의는 그것으로 대체토록 한다. (ISO 8402:1994-1986)

4.442 신뢰도 모델 (reliability model) 신뢰도를 예측하고 추정하며 산정하는데 사용하는 모델.

신뢰도 산정도 보시오.

4.443 신뢰도 산정 (reliability assessment) 기존의 시스템이나 시스템 요소에 대해서 신뢰도의

수준을 결정 하는 과정.

4.444 신뢰도 성장 (reliability growth) 소프트웨어의 결함을 수정한 결과 신뢰도가 향상되는

것을 말함.

4.445 신뢰도 자료 (reliability data) 소프트웨어 생명주기의 특정 순간에서 소프트웨어에 대한

신뢰도를 평가하기 위한 자료. 예를 들면, 신뢰도 모델을 위한 오류자료, 시간자료 복잡도 같은

프로그램의 속성, 사용한 프로그램의 기술이나 프로그래머의 경험도 같은 특성이 이에 속한다.

4.446 신뢰도 평가 (reliability evaluation) 신뢰도 산정을 보시오.

4.447 신속 시제품화 (rapid prototyping) 개발 프로세스를 지원하는데 있어서 초기 피드백과

분석을 허용하기위해 개발 프로세스 초기에 시제품 개발을 강조하는 시제품화의 유형. 폭포수

모델과 비교. 데이터 구조 중심 설계; 점진적 개발; 입력-처리-출력; 모듈 분해; 객체지향 설계;

나선형 모델; 단계적 정제; 구조적 설계; 트랜잭션 분석; 변환 분석도 보시오. (IEEE STD 610.12-1990)

4.448 신호기 (semaphore) 적용이 끝나거나 사건이 발생함을 알리는 병행처리의 동기화에

사용하는 공유변수.

4.449 실 매개변수 (actual parameter) 부 프로그램에 전달하는 자료 또는 프로그램의

구성요소를 지명하기 위해 부 프로그램을 호출할 때 사용하는 매개변수 또는 수식. 형식

매개변수와 대조.

4.450 실시간 (real-time) (1) 프로세서 밖의 시간 요구사항에 따라 컴퓨터 밖의 다른

42

프로세스와 연결된 컴퓨터에 의해 자료를 처리하는 것. 이 용어는 대화식으로 운영되는 시스템,

진행 중에 인간의 간섭에 영향을 받을 수 있는 프로세스를 묘사하는데 사용하기도 한다. (ISO) (2)

물리적 프로세스가 발생하는 동안의 현실의 시간을 말하는 것. 예를 들면, 계산의 결과가 물리적

프로세스를 지배할 수 있게 하기위한 물리적 프로세스의 발생은 현실의 시간동안의 계산성능과

관련된다.

4.451 실행시간 (runtime) (1) 프로그램 실행에 소요되는 시간의 양. 통상적으로 실행시간은

중앙처리시간, 주변장치 작동시간, 호출시간 등을 포함한다. 예를 들면 5 시간의 실행시간. (2)

프로그램이 실행되기 시작하는 시간. 수행 시간 (execution time) 도 보시오.

4.452 안전성 (safety) (사람에게) 손상이나 해를 줄 위험이 수용 가능한 수준으로 제한된 상태. (ISO 8402: 1994)[주]

1 안전성은 품질의 한 부분이다.

2 위 정의는 품질 표준의 목적과 부합한다. "안전성"이란 용어는 ISO/IEC Guide 2 에는 다르게

정의되어 있다.

4.453 안전성 (stability) (1) 시스템의 상태를 불안정하게 하는 사건에도 불구하고 변화하지

않는 상태를 유지하는 능력. (2) 시스템의 상태를 불안정하게 하는 사건 후에 다시 원래의 상태로

되돌아 올 수 있는 능력.

4.454 알고리즘 (algorithm) (1) 유한한 단계 내에 주어진 문제의 답을 얻기 위해 잘 정의한

명령어의 유한한 집합. 예를 들면, 주어진 정밀도까지 sin X 를 계산하는 산술연산을 나열한 것.

(ISO) (2) 특정한 일을 수행하기 위해 연산의 순서를 정하는 잘 정의한 규칙의 유한한 집합.

4.455 알고리즘 분석 (algorithm analysis) 알고리즘을 사용할 때의 정확도와 특성을

결정하거나 이것을 충분히 이해하여 수정, 간소화 또는 개선하기 위한 알고리즘에 대한 시험.

4.456 알고리즘 언어(algorithmic language) 알고리즘을 표현하기 위해 고안된 프로그래밍

언어. 예를 들면 알골(ALGOL)과 같은 언어.

4.457 알파 시험 (alpha testing) 소프트웨어를 고객에게 인도하기 전에 개발자가 고객의

참여하에 가상으로 설정한 사용자 환경하에서 시스템 시험 또는 운영시험을 수행하는 소프트웨어

개발 프로세스의 한 활동.

4.458 어셈블(assemble) 어셈블리 언어로 작성된 프로그램을 기계언어로 전환하는 작업

4.459 어셈블러 (assembler) 어셈블에 사용하는 컴퓨터 프로그램. (ISO) 컴파일러, 해석기와

대조. 어셈블리 프로그램과 동의어.

43

4.460 어셈블러 언어(assembler language) 어셈블리 언어와 동의어.

4.461 어셈블러 코드(assembler code) 어셈블리 코드와 동의어.

4.462 어셈블리 언어 (assembly language) (1) 컴퓨터 중심 언어의 명령어는 일반적으로

컴퓨터 명령어와 1:1 대응이 되고 마크로 명령어를 사용할 수 있는 기능을 제공 하기도 한다. (ISO)

(2) 특정한 기계어의 명령어는 일반적으로 컴퓨터 명령어와 1:1 대응이 된다. 기계어, 고차원

언어와 대조. 어셈블, 어셈블러를 보시오.

4.463 어셈블리 코드(assembly code) 어셈블러에 의해서 인식이 가능한 형태로 표현된

컴퓨터의 명령어와 데이터의 정의.

4.464 언어 처리기 (language processor) (1) 번역, 해석, 그리고 서술된 프로그래밍 언어 처리를

위해 필요한 다른 기능을 수행하는 컴퓨터 프로그램. 예를 들면, Fortran 처리기, Cobol 처리기

등이 있다. (2) 번역, 해석 그리고 요구조건 명세(서)언어, 설계 언어, 또는 프로그래밍 언어와 같은

특정한 언어 처리를 위해 필요한 기능을 수행하는 소프트웨어 도구.

4.465 엄격성 (severity) 임계도 (criticality)를 보시오.

4.466 에뮬레이션 (emulation) 주로 다른 하드웨어로 하나의 컴퓨터 시스템의 일부분 또는

전체를 에뮬레이트하여 모방한 컴퓨터 시스템이 같은 자료를 받고 같은 프로그램을 실행하여

에뮬레이트 된 컴퓨터 시스템과 같은 결과를 얻는 것. (ISO)

4.467 에뮬레이터 (emulator) 에뮬레이션 (emulation)을 하는 하드웨어, 소프트웨어 또는

펌웨어.

4.468 N-항 (N-ary) (1) N 개의 가능한 서로 다른 값이나 상태를 가지는 선택, 선발 조건으로

특징 지워진다. (ISO) (2) N 개의 기수를 가지는 고정된 기수 시스템. (ISO)

4.469 연결 (connection) (1) 프로그램의 어떤 부문에서 다른 부분을 참조하는 것. (2) 정보를

운반하는 기능 단위간에 성립되는 연관관계. (ISO) 인터페이스도 보시오.

4.470 연결 리스트 (linked list) 연쇄리스트를 보시오.

4.471 연결 편집기 (linkage editor) 목적 모듈간의 상호참조 내용을 분석하고 각 요소가

재배치되도록 해서 독립적으로 번역된 하나 이상의 목적모듈과 적재모듈로부터 하나의

적재모듈을 만드는데 사용하는 컴퓨터 프로그램. (ANSI) 그러나, 모든 목적모듈이 실행에 앞서

연결되어야 하는 것은 아니다.

4.472 연산자 (operator) (1) 기호조작에서 있어서 연산으로 수행하는 작용을 표현하는 기호.

44

(ISO) 연산자의 예로 +, -, *, / 등이 있다. (2) 프로세스의 묘사에서 피연산자에 수행되는 작용을

표시하는 것. (ANSI) (3) 기계를 운영하는 사람. (ANSI) 피연산자도 보시오.

4.473 연상 기호 (mnemonic symbol) 인간의 사고를 돕기 위해 선택한 심볼. 예를 들면

"multiply"는 "MAY". (ISO)

4.474 연쇄 리스트 (chained list) 다음 항목의 위치를 나타내는 식별자를 가지는 여러 항목이

연결되는 리스트. (ISO) 연결리스트의 동의어.

4.475 예방 유지보수(preventive maintenance) 문제가 발생하기 전에 발생을 막기 위하여

수행되는 유지보수. (IEEE STD 610.12-1990)

4.476 예방책 (preventive action) 예방을 위하여 잠재적인 부적합사항, 결점 또는 다른 원치

않은 상황의 원인을 줄이기 위해 취하는 행동.

[주] 예방책은 절차와 시스템에서와 같이 품질 루프의 어떤 단계에서도 품질 개선을 달성을 위한

변화를 포함한다.

4.477 예비 (back-up) 시스템 고장이나 재해가 발생하면 처리를 다시 시작하거나 선택적인

컴퓨터장치의 사용을 위해 자료화일 또는 소프트웨어를 회복 가능하게 준비하는 것.

4.478 예비 설계 (preliminary design) (1) 설계대안을 분석하고 소프트웨어 구조를 정의하는

과정. 예비설계는 대개 컴퓨터 프로그램의 구성요소와 자료의 조직을 만들고 정의하는 것,

인터페이스의 정의, 시간과 크기의 평가준비를 포함한다. (2) 예비설계 과정의 결과. 설계 분석,

기능 설계도 보시오

4.479 예비 프로그래머 (back-up programmer) 책임 프로그래머 팀의 보조리더 팀이 개발한

소프트웨어의 상당한 분량을 직접 개발하며, 주임 프로그래머를 도와서 다른 팀원의 작업내용을

검토하고 필요할 경우에는 주임 프로그래머의 업무를 대행하고, 개발할 소프트웨어의 기술적

측면을 전반적으로 이해하는 임무를 수행하는 선임 프로그래머.

4.480 예상 버퍼링(anticipatory buffering) 데이터를 위해 필요한 예상 공간에 데이터를

저장하는 버퍼링 기술

4.481 예상 페이징(anticipatory paging) 어떤 페이지가 필요하다고 예상이 될 경우에 보조

기억장치로부터 주 기억장치로 전송하는 데 사용하는 저장 할당 기술.

4.482 예외 (exception) 정상적인 프로그램 실행의 중지원인이 되는 사건.

4.483 예측 메트릭(predictive metric) 개발동안에 적용되는 메트릭. 소프트웨어 품질 계수값을

예측하기위해 사용되는 메트릭

45

4.484 예측 평가(predictive assessment) 다른 메트릭의 값을 예측하기 위해서 예측 메트릭을

사용하는 프로세스

4.485 오류 (error) (1) 계산, 관찰, 측정된 값이나 조건과 실제 값 또는 이론적으로 정확한

값이나 조건사이의 모순. (ANSI) (2) 인간의 행위에 의한 사용자의 요구사항 누락이나 잘못된

해석, 설계 명세(서)에서 사용자의 요구사항 누락이나 잘못된 번역. 이것은 잘 사용되지 않는다.

고장 (failure), 결함 (fault) 도 보시오.

4.486 오류 메시지 메트릭(error message metric) 공식적으로 증명된 에러 메시지의 수를 전체

에러 메시지의 수로 나눈 결과.(IEEE STD 730.1-1989)

4.487 오류 모델 (error model) 남아있는 결함의 수, 신뢰도, 요구되는 시험시간, 소프트웨어

시스템의 유사한 특성을 예상하고 평가하는데 사용하는 수학적 모델. 오류 예측도 보시오.

4.488 오류 범주 (error category) 발생할 수 있는 오류, 고장, 결함의 종류의 집합. 범주는

나타나거나 발견될 때의 원인, 임계도, 영향, 생명주기 단계 또는 오류, 고장, 결함의 또 다른

특성으로 정의될 수 있다.

4.489 오류 분석 (error analysis) (1) 오류의 원인을 추적할 목적으로 발견한 소프트웨어의

결함을 조사하는 과정. (2) 결함의 원인, 결함이 발견된 개발단계, 이미 예방되거나 제거될 수

있었던 기존의 방법, 결함을 제거했던 방법과 같은 정보를 식별해내기 위해 발견한 소프트웨어

결함을 조사하는 과정. (3) 정량적인 비율과 경향을 측정하기 위해 소프트웨어의 오류, 고장,

결함을 조사하는 과정.

4.490 오류 예측 (error prediction) 소프트웨어 시스템에서 예상되는 소프트웨어 문제, 고장,

결함의 종류에 관한 정량적인 문장. 오류 모델도 보시오.

4.491 오류 예측 모델 (error prediction model) 오류 모델을 보시오.

4.492 오류 자료 (error data) 일반적으로 소프트웨어 문제, 고장, 결함, 변화에 대한 특성

그리고 발생하고 수정하는 조건 등을 묘사하는 정보의 의미로 사용된다.

4.493 오류 파종 (error seeding) 결함 파종을 보시오.

4.494 오류 회복 (error recovery) 고장 회복을 보시오.

4.495 오류수정 모델 (debugging model) 오류 모델 (error model) 을 보시오.

4.496 오버레이 (overlay) (1) 컴퓨터 프로그램에서 내부 기억장치에 영구적으로 유지되지

않는 세그먼트. (ISO) (2) 프로그램의 다른 단계동안 내부기억장치의 같은 영역을 반복적으로

46

사용하는 기법. (ANSI) (3) 컴퓨터 프로그램의 실행에서 현재는 필요가 없는 프로그램의 부분이

아직까지 차지하고 있는 기억장치에 또 다른 컴퓨터 프로그램의 세그먼트를 적재하는 것. (ISO)

4.497 완전 유지보수 (perfective maintenance) 성능, 유지보수가능성, 기타 소프트웨어의

특징을 향상시키기 위해 수행하는 유지보수. 적응 유지보수, 교정 유지보수도 보시오.

4.498 외부(external) 표준에서, 통제되지 않는 입력 정보소스나 출력정보 목적물. 그러므로

외부는 존재할 수도 있고 존재하지 않을 수도 있다. (IEEE STD 1074-1995)

4.499 외부 측정(external measure) 시스템의 행위에 대한 측정에서 유도된 제품의 간접 측정.

[주]

1. 시스템이란 의미는 관련된 하드웨어, 소프트웨어, 사용자를 포함한다.

2. 시험 동안에 발견된 결함의 수는 프로그램의 결함의 수에 대한 외부 측정이다.

3. 외부 측정은 설계의 목적에 보다 가깝게 품질의 속성을 평가하기 위해 사용된다.

4.500 외부 품질(external quality) 특정 조건에서 사용될 때 명시적, 묵시적인 요구를 만족하는

제품의 범위.

4.501 요구사항 (requirement) (1) 어떤 문제를 해결하거나, 특정한 목적을 위해서 사용자가

필요로 하는 조건이나 능력. (2) 계약표준, 명세(서) 또는 다른 형식으로 제시된 문서에 적합하여

시스템이나 시스템 구성요소가 갖추어야 할 조건이나 능력. 요구사항은 시스템이나 시스템

구성요소의 후속 개발단계의 자료가 된다. 요구사항 분석, 요구사항 단계, 요구사항 명세(서)도

보시오.

4.502 요구사항 검사 (requirement inspection) 검사를 보시오.

4.503 요구사항 검증 (requirement verification) 검증을 보시오.

4.504 요구사항 검토(requirement review) 시스템, 하드웨어 항목, 또는 소프트웨어 항목에

대한 요구사항이 프로젝트 관리자, 개발자, 사용자, 고객, 그리고 다른 이해관계가 있는

사람들에게 제시되어 비평이나 승인을 행하는 모임. 시스템 요구사항 검토, 소프트웨어 요구사항

검토 포함. 코드 검토; 설계 검토; 형식 자격 검토; 시험 준비 검토와 비교. (IEEE STD 610.12-1990)

4.505 요구사항 기준선(requirements baseline) 개발과 관리 과정에서 사용할 기능적, 물리적,

운영적 요구사항의 집합. (IEEE 1220-1994)

4.506 요구사항 기준선 확인(requirements baseline validation) 고객의 기대와 프로젝트 및

기업의 제약조건, 내부 및 외부적인 제약조건을 확인하기 위한 요구사항 분석 활동의 결과를

평가하는 프로세스. (IEEE 1220-1994)

47

4.507 요구사항 단계 (requirement phase) 소프트웨어 개발 생명주기의 한 단계로서 시스템의

기능이나 수행능력 같은 소프트웨어 제품을 위한 요구사항을 정의하고 문서화 한다.

4.508 요구사항 분석 (requirements analysis) (1) 시스템이나 소프트웨어 요구사항을

정의하기 위해서 사용자의 요구사항을 조사하고 확인하는 과정. (2) 시스템이나 소프트웨어

요구사항의 검증.

4.509 요구사항 시연 메트릭(requirement demonstration metric) 소프트웨어 요구사항

명세서에 나타난 기능들 가운데에서 성공적으로 시연 된 요구사항의 기능들을 전체 요구사항의

기능으로 나눈 결과. (IEEE STD 730.1-1989)

4.510 요구조건 명세(서) (requirements specification) 시스템이나 시스템 구성요소의

요구조건을 기술하는 명세(서). 예를 들면, 소프트웨어 형상항목, 전형적인 기능 요구사항, 성능

요구사항, 인터페이스 요구사항, 설계 요구사항, 개발표준 등을 포함한다.

4.511 요구조건 명세(서) 언어 (requirements specification language) 요구조건을 정의, 확인,

문서화 하는데 사용하는 특별한 구성 및 확인 규칙을 가지는 형식 언어.

4.512 운영 및 유지보수 단계 (operation and maintenance phase) 소프트웨어 제품을

운영환경에서 사용하고, 성능의 만족도를 조사하고, 새로운 요구사항에 반응하거나 문제점을

바로잡아 수정하는 동안의 소프트웨어 생명주기상의 기간.

4.513 운영 시험 (operational testing) 보통의 운영환경에서 최종 사용자가 수행하는

소프트웨어에 대한 시험. (DoD usage)

4.514 운영 신뢰도 (operational reliability) 시스템이나 소프트웨어 부 시스템이 실제환경에서

사용할 때의 신뢰도. 운영신뢰도는 특정한 또는 시험 환경에서의 신뢰도와는 다르다.

4.515 운영자 (operator) 시스템을 운영하는 조직(ISO)

4.516 운영자 지침서 (operator manual) 시스템이나 구성요소를 시작하고 운영하기위해

필요한 정보를 제공하는 문서. 운영 준비, 감시, 복구를 위한 절차들을 설명. 진단 지침서; 설치

지침서; 프로그래머 지침서; 보조 지침서; 사용자 지침서도 보시오. (IEEE STD 610.12-1990)

[주] 컴퓨터 시스템을 운영하는 사람과 시스템을 사용하는 사람이 다른 경우, 운영자 지침서는

사용자 지침서와 구별된다.

4.517 운영체제 (operating system) 프로그램의 실행을 제어하는 소프트웨어, 입출력 제어,

자료관리, 지원할당 스케줄링과 같은 서비스를 제공한다. 운영체제는 탁월한 소프트웨어이기도

하며 부분적으로 또는 완전하게 하드웨어로의 구현이 가능하다. (ISO) 운영체제는 한 지점에서

하드웨어의 지원을 제공한다.

48

4.518 운전기 (driver) 시스템이 또는 시스템 구성요소의 작용을 모의실험하는 프로그램.

시험 운전기도 보시오.

4.519 원자형(atomic type) 더 이상 나눌 수 없는 가장 작은 단위로 나누어져 있는 자료형.

4.520 웍스루 (walk-through) 설계자나 프로그래머가 본인이 작성한 설계나 코드의

세그먼트를 가지고 개발팀의 다른 구성원들을 리드하는 동안 다른 구성원들은 질문을 하면서

기법, 스타일, 가능한 오류들, 개발표준의 위반여부에 관하여 논평하는 것. 검사 (inspection)와

대조.

4.521 위험 관리(risk management) 위험에 대처하는 활동의 준비, 위험 식별, 위험 해소와

관련된 활동.

4.522 원시 언어 (source language) (1) 원시 프로그램을 작성하는데 사용하는 언어. (2)

번역해야 하는 문장으로 되어있는 언어. (ISO) 목표 언어와 대조.

4.523 원시 프로그램 (source program) (1) 컴퓨터에서 수행하기 전에 어셈블, 해석해야 하는

컴퓨터 프로그램. (2) 원시언어로 표현한 컴퓨터 프로그램. 목적 프로그램과 대조. (ISO)

4.524 유지보수성 (maintainability) (1) 소프트웨어를 쉽게 유지보수 할 수 있는 특성. (2) 기능

단위를 쉽게 유지보수하여 기존의 요구사항에 따라 수행하게 할 수 있는 것. (ISO) (3) 특정한

상태하에서 안정된 상태로 규정된 절차 및 자원을 사용하여 유지보수를 수행할 때 주어진 기간

내에 보존, 유지, 재저장, 사용하고 요구되는 기능을 수행할 수 있는 능력.

4.525 유지보수 (maintenance) 소프트웨어 유지보수를 보시오.

4.526 유지보수 계획 (maintenance plan) 소프트웨어 제품을 유지보수하기 위한 관리 및

기술적인 접근을 명시하는 문서. 전형적으로 도구, 자원, 기능, 일정과 같은 내용을 포함한다.

4.527 유지보수 단계 (maintenance phase) 운영 및 유지보수 단계를 보시오.

4.528 유지보수자(maintainer) 유지보수 활동을 수행하는 조직(ISO 12207:1995)

4.529 유틸리티 소프트웨어 (utility software) 응용 소프트웨어나 운영체제나 시스템 사용자가

필요로 하는 일반적인 지원기능을 수행하기위해 설계된 컴퓨터 프로그램이나 루틴.

4.530 유한 상태 기계 (finite state machine) 유한개의 상태와 이런 상태간의 변환으로 구성된

계산모형.

4.531 유형 (type) 자료 형을 보시오.

49

4.532 응용 생성기(application generator) 특정 응용프로그램의 영역에 대해서 하나 또는 그

이상의 문제를 해결하기 위한 프로그램을 생성하는 코드 생성기. 예를 들면, 급여계산 생성기.

4.533 응용 소프트웨어 (application software) 컴퓨터 시스템을 특정 분야에 사용하기 위하여

특별히 제작한 소프트웨어. 예를 들면, 항해, 포격제어, 급여계산, 회계업무용 소프트웨어가 있다.

시스템 소프트웨어와 대조.

4.534 응용 중심 언어 (application oriented language) (1) 통계분석 기계 설계를 위한 언어와

같이 한가지 특정한 응용분야에 적합한 기능이나 표기법을 갖춘 컴퓨터중심 언어. (2) 문제중심

언어의 문장은 사용자의 직업이나 업무와 관련된 용어와 같거나 유사하다 (ANSI)

4.535 응집도 (cohesion) 하나의 프로그램 모듈 내에서 수행되는 여러 태스크가 연관된 정도.

결합도와 대조.

4.536 의미론 (semantics) (1) 해석과 사용 방법과는 독립적인 문자의 의미에 대한 문자간의

또는 문자집합 간의 관계. (ISO) (2) 기호와 기호의 의미 사이의 관계. (ANSI) (3) 메타 언어로

만들어지는 컴퓨터 언어의 의미표현에 관한 분야. 구문(syntax)도 보시오.

4.537 의사 코드 (pseudo code) 컴퓨터 프로그램 설계에 사용하기 위한 프로그래밍언어와

자연언어의 조합.

4.538 의존도 (dependability) 유용성, 그것의 영향을 주는 요소(신뢰성, 유지보수성)를

표현하기 위한 총체적인 용어. (ISO 8402:1994)

[주]

1 의존도는 비양(非量)적인 용어의 일반적 표현에 사용한다.

2 의존도는 품질의 시간과 관련된 것 중 하나이다.

3 의존도의 정의와 [주]1 과 같은 설명은 IEC 50(191)에서 발취했으며 또한 관련 용어나 정의도

해당된다.

4.539 이식성 (portability) 소프트웨어가 한 컴퓨터 시스템이나 환경에서 다른 시스템이나

환경으로 쉽게 옮겨질 수 있는 성질.

4.540 이정표 (milestone) 어떤 프로젝트 요원이나 관리자가 책임을 지고 진행정도를

측정하는데 사용하는 계획된 사건. 예를 들면, 형식검사, 명세(서) 발행, 제품인도 등이 있다.

4.541 이중 코딩 (dual coding) 같은 명세(서)에 대하여 서로 다른 프로그래머 또는 서로 다른

프로그램팀이 개발한 기능적으로는 동일한 두개의 프로그램을 개발하는 기법. 원시코드의

결과는 같거나 다른 언어라도 무방하다. 이중코딩의 목적은 오류검출, 신뢰도 증대, 추가 문서

제공, 최종 결과에 영향을 미치는 프로그래밍의 오류 또는 컴파일러 오류의 가능성을 줄이기 위한

50

것이다.

4.542 인공 언어 (artificial language) 어셈블리 언어로 표현한 프로그램을 기계어로 번역하고

부 루틴과 연결하는 것. 일반적으로 어셈블 과정은 기호주소를 절대주소, 즉시주소, 재배치

가능주소 또는 가상주소로 바꾸고 어셈블리어 연산코드가 기계어 연산코드로 바뀜으로써

완성된다. 컴파일, 해석과 대조.

4.543 인도 (delivery) (1) 제품을 운영하기 위해서 사용자에게 배달하는 소프트웨어 개발

생명주기상의 시점. (2) 제품을 사용자가 받은 소프트웨어개발 생명주기상의 시점.

4.544 인도 소프트웨어 제품(deliverable software product) 획득자 또는 지정된 수령자에게

인도할 것이 요구되는 소프트웨어 제품.

4.545 인수(acceptance) 소프트웨어를 소유하기 위해 획득자 측의 권한 있는 대표자가

수행하는 행동.

4.546 인수 기준 (acceptance criteria) (1) 시험단계의 성공적인 완료와 인도 요구사항을

만족시키기 위해 소프트웨어 제품이 만족해야 하는 기준.

(2) 시스템 운영상태에 대해 요구사항 분석 단계에서 미리 설정해 놓은 기준으로서, 시스템이 미리

정해 놓은 기대치를 달성하는지를 확인하기 위한 측정 수단이 된다.

4.547 인수 시험 (acceptance test) 시스템이 인수기준을 만족시키는가와 고객이 시스템을

인수할 것인가를 결정할 수 있도록 행하는 형식검사. 자격검사, 시스템 검사도 보시오.

4.548 인자(argument) (1) 독립적인 변수 (2) 독립적인 변수에 대한 값 (3) 특정 데이터 또는

프로그램의 요소가 다른 모듈을 호출하며 전달하는 상수, 변수, 수식.

4.549 인터럽트 (interrupt) 외부적 사건에 의해 중지된 프로세스를 재수행 하도록 하는

컴퓨터 프로그램의 실행을 위한 프로세스의 중단. 인터럽션 (interruption) 과 동의어. (ISO)

4.550 인터페이스 (interface) (1) 경계부분. 접속기란 두개의 장치 또는 두개이상의 컴퓨터

프로그램에 의해 호출된 기억장소나 레지스터를 연결하는 하드웨어 구성요소이다. (ANSI) (2)

다른 시스템 구성요소와의 상호작용 또는 통신을 하는 것.

4.551 인터페이스 명세(서) (interface specification) 어떤 시스템이나 시스템의 요소에 대한

인터페이스 요구사항을 설명한 명세(서).

4.552 인터페이스 시험 (interface testing) 프로그램이나 시스템의 요소가 상호간에 정보나

제어를 정확히 교환하는지를 확인하기 위하여 시험하는 것.

51

4.553 인터페이스 요구사항 (interface requirement) 어떤 요구사항이나 시스템의 요소가

인터페이스 해야 하는 하드웨어, 소프트웨어, 데이터베이스를 명세화 한 요구사항으로, 이는

형식이나 시간 또는 접속상에서 야기되는 다른 인자의 제한조건 등을 점검한다.

4.554 일회용 코드 (throw-away code) 시제품을 근거로 시스템을 개발하는 방법. 시제품의

기능이 계속 보강되어 최종 시스템으로 진화하는 진화적인 시스템과는 달리, 시제품을 구현하여

더 이상 필요가 없을 때 버린다.

4.555 임계 값(critical value) 인수할 수 없는 품질의 소프트웨어를 확인하는데 사용되는

유효한 측정 값

4.556 임계 범위(critical range) 품질 측정 값에서 받아들이거나 혹은 받아들일 수 없는 범위.

4.557 임계 섹션 (critical section) 임계영역이라 불리는 다른 코드세그먼트와 상호 배타적으로

실행되는 코드세그먼트. 만약 컴퓨터 자원이나 자료 항목을 경쟁적으로 사용해야 한다면

코드세그먼트는 상호배타적으로 실행될 필요가 있다.

4.558 임계 소프트웨어(critical software) 안전성에 영향을 미치거나 또는 과도한 재정적,

사회적인 손실을 발생시키는 소프트웨어.(IEEE STD 730.1-1989)

4.559 임계도 (criticality) 시스템의 작동과 개발상의 오류나 고장에 영향을 주는 정도의

평가에 기반을 둔 소프트웨어 오류나 고장의 분류. (언제 오류를 바로잡아야 할지를 결정하는데

흔히 쓰인다.)

4.560 임계부분 우선 (critical piece first) 소프트웨어 시스템의 가장 중요한 부분을 최초에

구현하는데 중점을 두는 소프트웨어의 개발방식에 관한 것. 임계부분은 제공하는 서비스, 위험의

정도, 어려움 또는 그 외의 기준에 의해 정의할 수 있다.

4.561 입력 단정 (input assertion) 바르게 작동하기 위해서 프로그램 입력이 만족해야 할

조건을 명세화 한 논리수식.

4.562 입력-처리-출력(input-process-output) 수행될 각 처리의 단계들과 각 단계에 대한 입력

및 출력을 식별하는 소프트웨어 설계 기술. 데이터 구조 중심 설계; 모듈 분해; 객체 지향 설계;

급속한 프로토타이핑; 나선형 모델; 단계적 정제; 구조적 설계; 트랜잭션 분석; 변환 분석도

보시오. (IEEE STD 610.12-1990)

4.563 입찰(tender) 제품제공에 대한 제안요청에 따라 공급자가 낙찰을 위해 만든 제안.(ISO 9001)

4.564 자격(qualification) 개체가 명시한 요구사항을 충족시킬 수 있는가를 보여주는

프로세스(ISO)

52

4.565 자격 시험 (qualification testing) (1) 소프트웨어가 측정한 요구조건을 만족한다는 것을

증명하는 형식적인 검사로 대개 고객을 위해 개발자가 이를 행한다. (2) 공급자의 소프트웨어

제품이 명세서를 만족하고 목표 환경에서의 사용준비가 되어 있음을 보여주기 위하여 개발자가

수행하고 획득자가 입증하는 시험.(ISO) 인수 시험, 시스템 시험도 보시오.

4.566 자격 요구사항(qualification requirement) 소프트웨어 제품이 명세서에 적합하고

목표환경에서 사용하기 위한 준비가 된 자격을 갖기 위하여 만족되어야 하는 기준 또는 조건의

집합(ISO)

4.567 자격 있는 (qualified) 특정한 요구사항의 만족 가능성을 실증하였을 때 개체에 부여된

상태.

4.568 자격 처리 (qualification process) 개체가 특정한 요구사항을 만족시킬 수 있는지

어떤지에 관한 실증 처리

[주] - "자격 처리"라는 용어는 자주 이 처리를 가리킬 때 사용한다.

4.569 자동화 검사 사례 생성기 (automated test data generator) 자동화 시험 생성기를 보시오.

4.570 자동화 검증 도구 (automated verification tools) 소프트웨어 개발프로세스의 결과를

평가하는데 사용하는 소프트웨어 도구. 이 도구는 정확성, 완전성, 일관성, 추적가능성,

검사가능성, 표준화의 준수 여부를 검증하는데 도움을 준다. 예를 들면, 설계분석기, 자동화

검증시스템, 정적 분석기, 동적 분석기, 표준화된 강화기 등이 있다.

4.571 자동화 검증 시스템 (automated verification system) 컴퓨터 프로그램과 명세(서)의

표현을 입력으로 받아들여 프로그램의 정확성에 대한 증명을 산출하는 소프트웨어 도구. 자동화

검증 도구를 보시오.

4.572 자동화 설계 도구 (automated design tool) 소프트웨어의 합성, 분석, 모델링, 또는

문서화 작업을 도와주는 소프트웨어 도구. 예를 들면 모의 실험장치, 설계표현방식 처리기, 문서

생성기, 분석보조기 등이 있다.

4.573 자동화 시험 생성기 (automated test generator) 컴퓨터 프로그램과 검사기준을

입력으로 받아들여 검사기준에 부합하는 입력자료를 생성하고, 예상결과를 결정하여 주기도 하는

소프트웨어 도구.

4.574 자료 (data) 인간이나 자동적인 의미로 행하고 해석하고, 의사소통하기에 적합한

정형화된 방법으로 사실, 개념 또는 명령어 등에 대한 표현. 컴퓨터 자료, 제어 자료, 오류 자료,

신뢰도 자료, 소프트웨어 경험 자료도 보시오.

53

4.575 자료 구조 (data structure) 기억장소에서의 실제 기억형태와 상관없이 자료항목간의

순서와 접근의 용이성의 관계에 대한 정형화된 표현.

4.576 자료 사전 (data dictionary) (1) 관련된 항목의 성질과 함께 소프트웨어 시스템에서

사용되는 모든 자료항목에 대한 이름의 집합. 예를 들면, 자료항목의 길이, 표현과 같은 성질 표현.

(2) 자료흐름도의 집합에서 참조시키는 자료흐름, 자료요소, 파일, 데이터베이스, 프로세스의

정의어 집합.

4.577 자료 특성(data characteristic) 자료에 내재되어 있는 속성, 특징, 질, 어떠한 사건이

발생할 가능성.(IEEE STD 1008-1987)

4.578 자료 추상화 (data abstraction) 상세한 자료형과 이들간의 기능적 특성과 관련된 정의를

함으로써 필수적인 특정한 성질만을 추출하고 유지한 결과. 따라서 상세한 표현은 숨겨지고

분리된다. 정보은폐(information hiding)를 보시오.

4.579 자료 흐름 그래프 (data flow graph) 자료 흐름도와 동의어.

4.580 자료 흐름도 (data flow chart) 자료 흐름도 (data flow diagram)를 보시오.

4.581 자료 흐름도 (data flow diagram) 노드간의 연결과 같은 자료의 논리적인 흐름과 노도와

같은 자료에서 수행되는 자료출처, 자료저장소, 기억장소, 프로세스를 보여주는 시스템의 도식

자료 흐름 그래프. 자료 흐름도와 동의어.

4.582 자료형 (data type) 자신에 적용될 수 있는 조직과 객체의 특성을 구분하는 자료의 분류.

예를 들면, 정수, 실수, 논리 등이 있다.

4.583 자수검사 (self-inspection) 특정한 규칙에 따라 그 일의 실행자가 그 일을 검사. (ISO 8402:1994)[주] 자수검사의 결과는 처리(process)관리에 사용할 수 있다.

4.584 자연 언어 (natural language) 명백히 정의한 규칙이 없이 현재 사용법을 반영하여

일상적으로 사용되는 언어. (ISO) 예를 들면 영어, 중국어, 프랑스어, 소오벨리어 등이 있다. 형식

언어와 대조.

4.585 작업(task) (1) 관리 가능한 최소한의 수행 단위. 작업은 하나 또는 그 이상의 프로젝트

구성원에게 할당이 되도록 명확히 정의된다. 작업을 완료하기 위한 일의 명세는 일의 패키지로

문서화되어 있다. 관련 작업은 활동(activity)으로 묶여진다. (2) 관리 가측성에서 수행 주체의 가장

최소 단위. 하나의 작업은 한명 이상의 프로젝트 멤버에게 수행토록 할당된다. 관련된 작업들은

활동(activity)에 그룹화 된다.

4.586 작업 기술서(statement of work) 계약상황에서 수행되어야 하는 태스크를 기술하고

54

명시하기 위한 방법으로 획득자가 사용하는 문서.(ISO)

4.587 작업 산출물(work product) 프로젝트 기능, 활동, 작업의 유형의 결과물. 예를 들면,

고객의 요구사항, 프로젝트 계획, 기능적 명세서, 설계 문서, 소스와 목적 코드, 사용자 설명서,

설치 안내서, 시험계획, 유지보수 절차, 회의 시간, 일정, 예산, 문제점 보고서 등을 포함한다. 작업

산출물의 일부분은 프로젝트 인도물을 구성한다.

4.588 작업 패키지(work package) 활동 또는 작업(task)을 완료하기 위해 수행되는 일의

패키지. 일 패키지는 일의 산출물, 참여자, 예상 기간, 필요한 자원, 책임자의 이름, 기타 특별히

고려할 사항을 정의한다.

4.589 장애 (fault) (1) 기능 단위의 요구 기능을 수행하는데 실패의 원인이 되는 우발적인

조건. (ISO) (2) 소프트웨어에서 오류의 명시. 결함은 고장의 원인이 될 수 있다. 결함 (bug)과

동의어. (3) 컴퓨터 프로그램에 있어서 잘못된 단계, 프로세스 또는 자료의 정의.

4.590 장애 범주 (fault category) 오류 범주를 보시오.

4.591 장애 삽입 (fault insertion) 장애 파종을 보시오.

4.592 장애 파종 (fault seeding) 한 프로그램에 있는 고유결함의 수를 측정하기 위해 그

프로그램에 미리 정한 수 만큼의 결함을 고의로 더하는 것.

4.593 장애 허용 (fault tolerance) 제한된 수의 하드웨어나 소프트웨어 결함이 발생하더라도

정확한 수행이 계속되게 하는 시스템의 능력.

4.594 재공학(re-engineering) (1) 제품의 제조가 끝난 뒤에 설계의 결함을 수정하거나,

추가적인 개선을 하기 위해서 시스템을 개선하는 프로세스.(IEEE STD 1220-1994) (2) 이미

존재하는 시스템을 새로운 형태로 재조직화하는 프로세스. 역공학, 재구조화, 재문서화, 순공학,

목표의 재설정과 같은 작업이 포함된다. (J-STD-016-1995)

4.595 재배치 기계코드 (relocatable machine code) 컴퓨터의 실행에 앞서 상대주소가

절대주소로 번역되어야 하는 기계어 코드. 절대 기계코드와 대조.

4.596 재사용성 (reusability) 하나의 모듈이 여러 가지 응용으로 사용될 수 있는 정도.

4.597 재사용 가능한 소프트웨어 제품(reusable software product) 한번의 사용을 위해

만들었지만 다른 곳에서도 사용하거나 특별히 여러 프로젝트 또는 동일한 프로젝트의 여러

곳에서 사용하기 위해 개발한 소프트웨어 제품. 단지 프로그램에 한정되지 않고 요구사항, 구조

등도 해당됨.(J-STD-016-1995)

55

4.598 재작업 (rework) 부적합 제품에 행동을 취함으로써 기술한 요구사항을 만족시킬 수

있도록 하는 것. (ISO 8402:1994)

[주] - 재작업은 부적합 제품 처분의 한 형태이다.

4.599 저작 시스템(authoring system) 저작 언어와 함께 사용하기 위한 프로그래밍 시스템.

4.600 저작 언어(authoring language) 컴퓨터를 이용한 교육을 위한 프로그램을 작성하는데

사용하는 상위 레벨의 프로그래밍 언어.

4.601 적응 유지보수 (adaptive maintenance) 소프트웨어 제품을 변화된 환경에서 사용할 수

있도록 하기 위한 유지 보수.

4.602 적응성 (adaptability) 소프트웨어가 다양한 시스템 제약조건이나 사용자의 요구를

동시에 얼마나 충족시킬 수 있는가를 나타낸다.

4.603 적재 맵 (load map) 기억장치 내에 들어있는 컴퓨터 프로그램이나 자료의 전체 혹은

특정한 부분에 대한 위치, 크기 등을 나타내는 컴퓨터로 작성한 리스트.

4.604 적재 모듈 (load module) 실행하기 위해 주기억장치로 적재하기에 적합한 프로그램

단위. 이것은 일반적으로 연결 편집기의 출력이다. (ISO)

4.605 적재기 (loader) (1) 실행에 앞서 목적모듈을 주기억장치로 읽는 루틴. (2) 자료를

주기억장치로 읽어 들이는 루틴. 일반적으로 컴퓨터 프로그램이다. (ANSI)

4.606 적합 (conformity) 특정 요구사항의 충족

[주] - 위 정의는 품질 표준의 목적과 부합한다. "적합"이란 용어는 ISO/IEC Guide 2 에는 다르게

정의되어 있다.

4.607 전시도 (degree of demonstration) 특정 요구사항을 달성할 수 있다는 확신을 제공하기

위한 증거의 생산능력의 범위. (ISO 8402:1994)

[주]

1 전시도의 범위는 존재 확인부터 상세한 문서와 완성에 대한 객관적 증거의 제공까지 해당된다.

2 범위는 경제성, 복잡성, 혁신성, 안정성과 환경적 배려와 같은 기준에 의존한다.

4.608 전처리기 (preprocessor) 예비 계산이나 구조에 영향을 주는 컴퓨터 프로그램. (ISO)

프리컴파일러도 보시오.

4.609 절대 기계 코드 (absolute machine code) 사용할 때마다 고정된 기억장소로 적재해야

하고 재배치 할 수 없는 기계어 코드. 재배치가능 기계코드와 반대.

56

4.610 절대 명령어 모든 주소가 절대 주소로 지정되는 컴퓨터 명령어

4.611 절대 어셈블러; 절대주소를 지정하는 코드를 생성하는 어셈블러. 반대) 상대 어셈블러

4.612 절대 적재기 절대 기계 코드를 메인 메모리로 읽어들이고, 어셈블러나 컴파일러가

생성한 코드를 초기 주소에 할당하나, 메모리 할당을 수행하지 않는 로더

4.613 절대 주소; 주변장치 또는 저장장치의 지역에 영구적으로 할당되어 있으며 주소의

변환이나 계산을 수행하지 않고 지정이 가능한 주소공간. 명시 주소, 지정 주소와 동의어. 상대

주소, 재배치 주소, 기호 주소와 대조.

4.614 절대 코드; 모든 주소가 절대 주소에 배치되어 있는 코드

4.615 절차 (procedure) (1) 특정한 작업을 수행하도록 이름을 부여한 컴퓨터 프로그램의 일부.

(2) 문제를 풀기위해 취해야 할 행동의 순서 기술. (ANSI) (3) 문제를 풀기위해 취해야 할 행동의

순서. (ISO) (4) 어떤 일을 행할 때마다 완성하기 위해 행할 인위적 순서의 집합. (5) 활동을

수행하기 위한 특정한 방법. (ISO 8402:1994).

[주]

1. 대부분의 경우, 절차는 문서화한다. (예를 들면, 품질 시스템 절차서)

2. 절차가 문서화된 경우, '성문화된 절차, 문서화된 절차'라는 용어를 자주 사용.

3. 성문화/문서화된 절차는 일반적으로 활동의 목적과 범위가 기술되어 있으며 무엇을, 누가,

언제, 어디에서, 어떻게 해야 하는가와 어떤 재료, 장비, 문서를 사용해야 하는지 그리고 어떻게

그것들을 관리하고 기록하는지에 대해 기술하고 있다.

부 루틴, 부 프로그램, 기능, 모듈과 비교.

4.616 절차적 프로그래밍 언어(procedural programming language) 컴퓨터가 수행하는 연산의

순서를 표현하기 위해서 사용하는 프로그래밍 언어.(IEEE 1008-1987)

4.617 점진적 개발(incremental development) 요구사항 정의, 설계, 구현, 그리고 시험이 중복,

반복적으로 수행되어 결과적으로 전체 소프트웨어 제품이 점진적으로 완성되는 소프트웨어 개발

기술. 폭포수 모델과 비교. 데이터 구조 중심 설계; 입력-처리-출력; 모듈 분해; 객체 지향 설계;

급속한 프로토타이핑; 나선형 모델; 단계적 정제; 구조적 설계; 트랜잭션 분석; 변환 분석도

보시오. (IEEE STD 610.12-1990)

4.618 접근 제어 기법 ( access-control mechanism) 인가받은 컴퓨터 시스템에 대한 접근은

허용하고 인가받지 않은 접근은 불허하는 하드웨어 및 소프트웨어의 특징 또는 운영 및 관리절차.

4.619 접근의 용이성 (accessibility) 소프트웨어 구성요소의 선택적인 사용이나 유지보수에

대한 용이성 정도.

57

4.620 정밀도 (precision) (1) 거의 같은 값을 구별하는 능력의 정도, 예를 들면, 네 자릿수는

여섯 자리 수 보다 덜 정밀하다, 그렇지만 정확하게 계산된 네 자리 수는 부정확하게 계산된 여섯

자리 수보다 더 정밀하다.(ISO) (2) 정해진 양으로 식별하는 정도. 예를 들면, 세 자리수로 1000

까지의 가능한 수를 나타내는 것.

정확도 (accuracy)와 대조.

4.621 정보 은닉 (information hiding) 모듈간의 접속점에서 각 모듈의 내부작업은 가능한 한

드러내지 않도록 소프트웨어 설계 결정사항을 캡슐화하는 기술로서 각 모듈은 다른 모듈에

대해서는 블랙박스가 된다. 정보 은폐원리에서는 모듈의 인터페이스 명세(서)에 나타나 있지

않은 모듈에 관한 정보의 사용은 금하고 있다.

캡슐화도 보시오.

4.622 정의 단계 (definition phase) 요구사항 단계 (requirement phase) 를 보시오.

4.623 정적 바인딩 (static binding) 실행 중에 바꾸지 않을 목적으로 프로그램의 실행에 앞서

바인딩하는 것. 동적 바인딩과 대조.

4.624 정적 분석 (static analysis) 프로그램의 실행 없이 프로그램을 평가하는 과정.

탁상 검사, 코드 감리, 검사, 정적 분석기, 웍스루도 보시오. 동적 분석과 대조.

4.625 정적 시험 모델 (statical test model) 입력 자료집합에서 우연히 발견되는 프로그램

결함에 관련된 모델. 이 모델은 결함이 프로그램의 실패를 가져올 수도 있음을 보여준다.

4.626 정적분석기 (static analyzer) 프로그램의 실행 없이 프로그램의 평가를 돕는

소프트웨어도구. 예를 들면, 구문 검사기, 컴파일러, 교차참조 생성기, 표준 시행자, 순서도 등이

있다. 동적 분석기와 대조.

4.627 정확도 (accuracy) (1) 오류가 없음을 나타내는 특성. (ISO) (2) 오류가 없는 정도에 대한

정성적 평가로서 이것이 높으면 오류가 작다. (ISO) (3) 상대적인 오류의 함수로서 표현한 오류의

크기에 대한 정량적 메트릭으로서 이것이 높으면 오류가 작다. (ISO) (4) 오류가 없는 정도에 대한

정량적 평가. 정밀도(precision)와 대조.

4.628 정확도 (correctness) (1) 설계상의 결함 그리고 코딩상의 결함 즉 고장이 없는 정도. (2)

소프트웨어가 요구사항에 부응하는 정도. (3) 소프트웨어가 사용자의 기대에 부응하는 정도.

4.629 정확성 증명 (correctness proof) 정확성 증명 (proof of correctness) 을 보시오.

4.630 정확성 증명 (proof of correctness) (1) 프로그램이 그의 명세(서)를 만족시킨다는 것을

수학적으로 증명하는 정형적인 기술. (2) 이 기술을 적용하여 얻게 되는 프로그램의 증명. 부분

58

정확성, 총 정확성도 보시오.

4.631 제안요청서(request for proposal) 명시된 시스템, 소프트웨어 제품 또는 소프트웨어

서비스를 획득하기 위하여 입찰 대상자에게 획득의도를 알리기 위한 수단으로 획득자가 사용하는

문서. (ISO)

4.632 제약(constraints) 소프트웨어 생명주기 모델 선택, 프로젝트 계획, 관리를 제한하는

한정, 자원(resource), 역할 등

4.633 제어 구조 (control structure) 컴퓨터 프로그램에서 흐름의 제어를 결정하는 구조.

4.634 제어 문장 (control statement) 수행하는 연산의 순서에 영향을 미치는 프로그래밍 언어

문장.

4.635 제어 자료 (control data) 프로그램에서 연산모드 또는 부속모드를 선택하고, 순차적인

흐름을 유도하거나 또는 소프트웨어의 연산에 직접 영향을 미치는 자료.

4.636 제어 흐름 (flow of control) 알고리즘의 수행에서 실행되는 연산의 순서.

4.637 제품 (product) 활동 또는 처리의 결과. (ISO 8402:1994-1994)

[주]

1. 제품은 서비스, 하드웨어, 재료, 소프트웨어 또는 그것들의 부합물도 포함한다.

2. 제품은 유형의 것(부품, 재료), 무형의 것(지식, 개념) 또는 그것들의 부합물도 해당됨.

3. 제품이 의도된(예를 들면 고객에게 제공함) 또는 의도되지 않은(예를 들면 오염물질, 원치 않는

영향) 것일 수 있다.

4.638 제품 공학(product engineering) 제품을 정의, 설계, 생산 또는 조립하는 기술적 처리. (IEEE STD 610.12-1990)

4.639 제품 관리(product management) 제품 개발 주기동안 제품의 특징들을 정의, 조정,

제어함. 예를 들면, 형상 관리. (IEEE STD 610.12-1990)

4.640 제품 기준선(product baseline) 형상 항목의 기능적 특성, 물리적 특성, 상호운영 특성 및

인수 시험에 적용하는 특성들을 기술하는 문서로서 제품의 인수 시험과 물리적 형상 감사

완료시점의 산출물임.

4.641 제품 명세(서) (product specification) 설계 명세(서)와 동의어 (DoD usage)

4.642 제품 보증 (product certification) 보증을 보시오.

4.643 제품 분석(product analysis) 제품이 어떤 특징들을 가지는지를 결정하기위해

59

수작업이나 자동화된 수단을 이용하여 제품을 평가하는 처리. (IEEE STD 610.12-1990)

4.644 제품 책임 (product liability) 제품이나 서비스로 인한 인적 상해, 재산의 손상, 기타의

손해에 관련된 손실에 대해 배상하도록 생산자 또는 기타의 사람의 책임을 기술하는데 사용하는

일반적인 용어. (ISO 8402:1994-1986)

[주] 책임의 한계는 국가의 법률에 따라 나라마다 다르다.

4.645 제품 형상 식별(product configuration identification) 생산, 운영, 유지보수, 그리고 병참

지원을 하는 동안 형상 항목을 정의하는, 현재 승인되거나 조건적으로 승인된 기술 문서(technical

document). 모든 필요한 물리적 특성, 적합성(fit), 및 기능 특성과 인수 시험에 사용될 기능 특성

등을 기술한다. 할당된 형상 식별; 기능 형상 식별과 비교. 제품 기준선도 보시오. (IEEE STD 610.12-1990)

4.646 제한 (confinement) (1) 승인받지 않은 변경, 사용, 파괴의 금지 또는 승인된 호출동안에

자료를 넘겨주는 것을 금지함. (2) 승인받은 것 이외의 자료 또는 프로세스, 프로그램에 영향을

미치거나 호출하는 것을 금지하는 것으로 프로그램과 프로세스들에 대한 제약. 무결성도 보시오.

4.647 조건부 제어 구조 (conditional control structure) 어떤 조건의 만족에 따라 프로그램

제어의 흐름을 선택하는 프로그램 제어구조. 예를 들면, case, if..then..else..가 있다.

4.648 조직 (organization) 법인 조직이든 아니든 또는 공적이든 사적이든 간에 자신의 기능과

경영을 소유한 회사, 법인, 상사, 기업 또는 연구소 또는 관련 지역.

[주] 위 정의는 품질표준의 목적에 유효하다. "조직"이라는 용어는 ISO/IEC Guide 2 에서는 다르게

정의한다.

4.649 조직 구조(organizational structure) 책임, 권한과 관계를 정형하게 구성. (ISO 8402:1994-1994)

4.650 종료 증명 (termination proof) 정확성의 증명에서, 모든 특정 입력조건 하에서 종료할

프로그램에 대한 증명.

4.651 주석 (comment) (1) 프로그램의 수행에는 영향을 주지 않고 사람이 명확하게

판독하는데 도움을 주기 위해서 컴퓨터 프로그램과 제어언어 또는 자료 집합 내에 삽입해 넣는

정보. (2) 목적언어에 영향을 주지 않으면서 원시언어 문자를 사이에 삽입하거나 더하는 설명,

해설, 또는 참조문 등을 말함.(ISO)

4.652 주소 (address) (1) 기억장소의 특정한 부분인 레지스터 또는 다른 자료의 출처나 자료를

전송받는 목적지의 위치를 나타내는 문자나 문자의 집합. (2) 자료 항목 또는 장치를 말한다. (ISO)

4.653 주소 공간 (address space) 컴퓨터 프로그램에서 주소롤 지정할 수 있는 기억주소의 범위.

60

4.654 주소 항목(address field) 주소, 주소를 유도하기 위한 정보, 또는 피 연산자의 값을

가지고 있는 컴퓨터 명령어의 항목.

4.655 주소지정 예외(addressing exception) 사용가능한 기억장치의 범위를 넘어간 연산을

수행할 경우 발생하는 예외.

4.656 주요 설계 검토(critical design review) 하나 이상의 형상 항목들의 상세 설계가 명세된

요구사항을 만족시키는 지를 검토하고, 다른 형상 항목들과의 호환성을 검토하고, 각 형상 항목의

위기 영역을 평가하고, 생산가능성 분석 및 제품 명세를 평가하기 위하여 수행되는 검토. 예비

설계 검토; 시스템 설계 검토도 보시오. (2) (1)과 같이 하드웨어 또는 소프트웨어 구성요소의 검토. (IEEE STD 610.12-1990)

4.657 중복성 (redundancy) 시스템 수행에 있어 필수적인 어떤 요소에 이상이 발생했을 때

시스템을 향상시키기 위해서 연속적으로 수행시킬 수 있도록 해당 요소를 중복적으로 구성해

놓게 된다.

4.658 지시자(indicator) 다른 측정을 예측하기 위해서 사용되는 측정.

4.659 직접 메트릭(direct metric) 개발 또는 운영하는 동안에 적용되는 메트릭으로서

소프트웨어의 품질 요인을 나타낸다. (IEEE STD 1061-1992)

4.660 직접 측정(direct measure) 다른 속성의 측정에 의존하지 않는 속성의 측정.

4.661 진단 (diagnostic) (1) 컴퓨터 프로그램의 명세(서)를 생성해냄으로써 다른 시스템

구성요소에서 가능한 결함을 지적하는 것. (2) 결함이나 고장의 발견이나 분리를 말함.

4.662 진단 지침서(diagnostic manual) 시스템이나 구성요소의 진단 절차를 실행하고, 고장과

보수를 식별하기 위해 필요한 정보를 제공하는 문서. 시스템이나 구성요소의 진단 형태와 그에

따라 이용 가능한 진단 도구를 설명. 설치 지침서; 운영자 지침서; 보조 지침서; 사용자 지침서도

보시오. (IEEE STD 610.12-1990)

4.663 진화적 시제품화 방법 (evolutionary prototyping) 요구사항을 확인하여 인도할

시스템으로 신속히 진화시키기 위해, 시제품 체계 개발을 기반으로 하는 소프트웨어 생명주기

모형.

4.664 책임 프로그래머 팀 (chief programmer team) 책임 프로그래머, 예비 프로그래머, 서기/

라이브러리언, 추가적인 프로그래머 그리고 필요한 전문가로 구성하고 각 조직 구성원의

기술이용을 최적화하고 의사소통을 원할히 할 수 있도록 계획한 절차를 갖춘 소프트웨어 개발

집단.

4.665 처리 (process) (1) 유일한 컴퓨터 시스템에서 주어진 조건하에서 성취해야 되는 결과

61

또는 목적에 의해 정의된 사건의 유한한 순서. (ISO) (2) 처리에서 자료에 대한 연산이 수행되는

것. (ISO) (3) 입력물을 출력물로 변환하는 내부 관련 자원과 활동의 집합체. (ISO 8402:1994)

[주] - 자원은 인력, 자금, 시설, 장비, 기술과 방법을 포함한다.

4.666 처리율 (throughput) 일정기간동안 컴퓨터 시스템이 수행하는 작업량의 측정. 예를

들면, 일일 작업수가 있다. (ISO)

4.667 총 정확도 (total correctness) 정확도의 증명에서 프로그램의 출력단정은 논리적으로

입력단정과 처리절차에 따르고, 또한 프로그램은 명시된 입력조건 아래서 종료됨을 나타낸다.

부분 정확도와 대조.

4.668 총체적 품질관리 (total quality management) 모든 구성원의 참여를 전제로 하고 고객의

만족을 통해 지속적인 성공을 목표로 하며 조직 구성원들과 사회의 이익을 위해 품질에 초점을

맞추는 조직의 관리 접근방법

[주]

1 "모든 구성원"이란 표현은 모든 부서와 조직 구조의 모든 단계에서의 인력을 가리킨다.

2 최고 경영자의 강하고 확고한 지도력과 조직 구성원의 교육과 훈련이 이 접근방법의 성공에

필수적이다.

3 총체적 품질관리에서 품질 개념은 모든 관리 목표의 달성과 관련된다.

4 "사회의 이익"의 개념은 사회 요구사항을 충족시키는 것을 의미한다.

5 총체적 품질관리(TQM; Total quality management)는 가끔 "total quality", "CWQC(company-wide

quality control), "TQC(total quality control) 등으로 부른다.

4.669 최소 작업(minimum tasks) 모든 프로젝트에 적용할 수 있는 작업들. 위험 요소가 많이

포함된 소프트웨어는 위의 작업들을 반드시 포함하여야 하며, 위험 요소가 덜한 소프트웨어를

추천하는 작업들.

4.670 최종항목(end-item) 최종 제품을 보시오.

4.671 최종제품(end-product) 부품이나 조립제품의 어느 경우에나 최종 또는 완성된 상태의

제품.

4.672 추상 기계 (abstract machine) (1) 처리(process) 나 기계특성의 표현. (2) 마치 기계인

것처럼 입력을 처리는 모듈(module).

4.673 추상 자료형 내부의 데이터가 어떻게 표현되고 있는지 또는 그를 조작하는

오퍼레이션이 어떻게 구현되어 있는지를 생각하지 않고 데이터에 할당되어 있는 데이터의 속성과

오퍼레이션만을 알고 사용할 수 있는 자료형

4.674 추상화 (abstraction) (1) 주어진 문제에서 특정한 목적에 관련된 필수적인 정보만을

62

추출하고 나머지 정보는 무시하는 관점. (2) 추상화를 만들어나가는 과정.

4.675 추적 (trace) (1) 컴퓨터 프로그램의 수행기록으로 명령어를 수행한 순서를 나타낸다.

(ANSI) (2) 컴퓨터 프로그램의 수행도중에 발생하는 명령어 또는 프로그램 사건의 종류에 관한

기록. (3) 자취를 만드는 것.

4.676 추적기 (tracer) 추적에 사용되는 소프트웨어 도구.

4.677 추적성 (traceability) 어느 한 품목 또는 활동, 또는 유사품목 또는 활동의 이력,

적용상태 또는 소재지를 기록된 식별표시에 의해 추적하는 상태. (ISO 8402:1994-1986)

[주]

1. "추적성"이란 용어는 다음 세 가지의 중요한 의미 중 하나의 의미를 가질 수 있다.

a) 유통관점에서의 추적성은 제품 또는 서비스에 관련된다.

b) 검교정 관점에서의 추적성은 계측장비를 국가 또는 국제적 표준, 1 차 표준 또는 기초적 물리

정수 또는 특성에 연결시킨다.

c) 데이터 수집 관점에서의 추적성은 품질 루프를 통하여 발생되는 계산치 및 데이터를 제품 또는

서비스에 연결시킨다.

2. 추적성 요건에는 이력 중의 해당기간 또는 해당기점을 규정하는 것이 좋다.

4.678 출구 (exit) (1) 컴퓨터 프로그램, 루틴, 서브루틴에서 이들에 의해 더 이상 실행되지 않는

제어 실행후의 컴퓨터 프로그램, 루틴, 부 루틴 내의 마지막 명령어. (ISO) (2) 루틴에 의해 더 이상

실행되지 않는 제어 밖의 지점.

4.679 출력 단정 (output assertion) 프로그램이 정확하기 위해 프로그램의 출력이 만족해야

하는 한 개 이상의 조건을 말해주는 논리적인 표현.

4.680 측정(measurement) (1) 특정 규칙과 채점 규칙을 적용하여 개체의 속성을 기술하기

위해 번호를 메기거나 범주에 할당하는 프로세스. (2) 측정을 통해서 개체의 속성에 할당된 숫자나

범주.

[주] 범주는 속성의 질적인 측정을 나타내기 위해 사용한다.

4.681 측정방법(measure) 기준치와 비교하여 값을 확인하고 평가하는 방법.

4.682 측정하다(measure) 측정하는 행위.

4.683 캡슐화 (encapsulation) 모듈과 이에 대하여 제공된 명세(서) 내에 시스템 기능을

분리시키는 기법.

정보 은폐(information hiding) 도 보시오.

4.684 커널 (kernel) (1) 운영체제의 핵심. (2) 기본적인 기능의 캡슐화. 커널은 운영체제의

63

일부나 전체 또는 펌웨어 집합의 형태와 결합될 수 있다. (3) 컴퓨터의 성능평가를 위해 연구하는

컴퓨터 선택에 사용하는 모델.

4.685 컴파일 (compile) 고급언어로 쓰여진 프로그램을 그와 대등한 재배치가능 코드 또는

절대 기계 코드로 번역하는 작업. 어셈블, 해석과 대조.

4.686 컴파일러 (compiler) 컴파일에 사용하는 컴퓨터 프로그램. (ISO) 어셈블러, 번역기와

대조.

4.687 컴파일러 생성기 (compiler generator) 컴파일러를 생성하는데 사용하는 번역기나

해석기. 메타 컴파일러와 동의어.

4.688 컴파일러 컴파일러 (compiler compiler) 컴파일러 생성기를 보시오.

4.689 컴퓨터 (computer) (1) 실행되는 동안 인간의 간섭을 받지않고 산술연산이나

논리연산과 같은 여러 종류의 실질적인 계산작업을 수행할 수 있는 기능적 장치. (ISO) (2) 한 개

이상의 처리장치와 주변기기로 구성되며, 내부에 저장된 프로그램에 의해 제어받고, 인간의

간섭없이 산술연산이나 논리연산과 같은 여러 종류의 실질적인 계산작업을 수행할 수 있는

기능적인 프로그램이 가능한 장치.

4.690 컴퓨터 네트워크(computer network) 두개 이상의 컴퓨터가 서로 복잡하게 연결되어

있는 것. (ANSI)

4.691 컴퓨터 지원 소프트웨어 공학(CASE) 소프트웨어 공학 프로세스를 보조하기 위한

컴퓨터의 사용. 소프트웨어 설계, 요구사항 추적, 코드 생성, 테스트, 문서 생성, 그리고 다른

소프트웨어 공학 활동들을 위한 소프트웨어 도구의 응용을 포함. (IEEE STD 610.12-1990)

4.692 컴퓨터 소프트웨어 구성요소(computer software component) 컴퓨터 소프트웨어 형상

항목의 기능적 또는 논리적 분할 결과. 둘 이상의 소프트웨어 단위들의 묶음. (IEEE STD 610.12-1990)

4.693 컴퓨터 소프트웨어 형상 항목(computer software configuration item: SCCI) 최종 기능을

만족하며 획득자가 형상관리를 수행할 수 있도록 고안된 소프트웨어의 집합.(IEEE 610.12-1990)

4.694 컴퓨터 시스템 (computer system) 프로그램의 일부와 또는 전체와 그 프로그램의

실행을 위해 필요한 자료를 위해 공용기억장소를 사용하는 기능 단위. 하나 또는 그 이상의

컴퓨터와 그와 연관된 소프트웨어로 이루어진다. 사용자가 싣거나 지시한 프로그램을 실행한다.

산술연산과 논리연산을 포함한 사용자 자료처리지시를 수행한다. 또한 실행되는 동안

자기자신을 수행할 수 있다. 자기 혼자나 여러 개의 단위를 연결하여 구성한다. ADP 시스템,

컴퓨팅 시스템 (computing system) 과 동의어. (ISO)

64

4.695 컴퓨터 자료 (computer data) 컴퓨터간이나 혹은 컴퓨터 내부에서의 통신에 사용할 수

있는 자료. 이러한 자료는 컴퓨터가 해독 가능한 형태로 컴퓨터 외부에 존재하거나, 혹은 컴퓨터

기기 내부에 존재할 수 있으며 아날로그나 디지털 형태로 존재 할 수도 있다.

4.696 컴퓨터 프로그램 (computer program) 컴퓨터가 처리할 수 있도록 작성한 일련의

프로그램. 컴퓨터 프로그램의 처리과정은 프로그램을 실행시키거나 프로그램을 실행할 수

있도록 준비하기 위한 어셈블러, 컴파일러, 해석기, 혹은 번역기의 사용을 포함한다. (ISO)

프로그램도 보시오.

4.697 컴퓨터 프로그램 개발 계획 (computer program development plan) 소프트웨어 개발

계획을 보시오.

4.698 컴퓨터 프로그램 검증 (computer program verification) 검증을 보시오.

4.699 컴퓨터 프로그램 구성요소(computer program component) 컴퓨터 소프트웨어

구성요소와 동의어. (IEEE STD 610.12-1990)

4.700 컴퓨터 프로그램 주석 (computer program annotation) 주석을 보시오.

4.701 컴퓨터 프로그램 추상화 (computer program abstract) 컴퓨터 사용자로 하여금 컴퓨터

프로그램이 사용자의 요구와 지원에 적절히 일치하는가 하는 것을 결정할 수 있도록 충분한

정보를 전달하는 컴퓨터 프로그램에 대한 개략적인 서술.

4.702 컴퓨터 프로그램 형상 식별 (computer program configuration identification) 형상

식별을 보시오.

4.703 컴퓨터 프로그램 형상 항목(computer program configuration item) 컴퓨터 소프트웨어

형상 항목과 동의어. (IEEE STD 610.12-1990)

4.704 컴퓨터 프로그램 확인 (computer program validation) 확인을 보시오.

4.705 컴퓨터 하드웨어(computer hardware) 컴퓨터의 자료를 받아들이거나 저장, 데이터를

조작하는 순서를 수행 또는 제어에 관한 출력물을 생성하는 장치. 이런 장치들은 해석, 계산, 통신,

제어 또는 기타 논리적인 기능을 수행할 수 있다.

4.706 케이스 (case) 제어수식의 값에 따라 프로그램의 문장을 선택하여 수행하도록 하는 다중

분기 제어문. 제어 구조를 보시오.

4.707 코드 (code) (1) 자료를 이산적인 형태로 표현하는 분명한 규칙의 집합. (ISO) (2)

프로세서가 인식할 수 있는 기호로써 자료나 컴퓨터 프로그램을 나타내는 것. (ISO) (3) 루틴을

65

쓰는 것. (ANSI) (4) 하나 또는 그 이상의 컴퓨터 프로그램이나 컴퓨터 프로그램의 일부. (5) 보안

목적의 자료의 암호화.

4.708 코드 감리 (code audit) 소프트웨어 설계문서와 프로그래밍 표준에 따르는지를

개인이나 팀이 필요한 경우 도구를 사용해서 원시코드를 독립적으로 조사하는 것. 정확도와

효율성도 측정할 수 있다. 감리, 정적 분석, 검사, 웍스루도 보시오.

4.709 코드 검사 (code inspection) 검사를 보시오.

4.710 코드 검토(code review) 소프트웨어 코드가 비평이나 승인을 위해 개발자, 관리자,

사용자, 고객, 또는 다른 관계 있는 사람들에게 제시되는 모임. 설계 검토; 공식 품질 검토;

요구사항 검토(requirement review); 시험 준비 검토(test readiness review)와 비교. (IEEE STD 610.12-1990)

4.711 코드 생성기 (code generator) 프로그램, 프로그램 기능, 컴파일러의 일부로서 구문분석

결과와 같은 중간 수준의 표현으로 변형시키는 컴퓨터 프로그램.

4.712 코드 웍스루 (code walk-through) 웍스루를 보시오.

4.713 코딩(coding) (1) 소프트웨어 공학에서의 프로그래밍 언어를 가지고 컴퓨터 프로그램을

작성하는 프로세스를 말함. (2) 설계 명세의 로직과 데이터를 프로그래밍 언어로 변형하는 것.

소프트웨어 개발 프로세스도 보시오. (IEEE STD 610.12-1990)

4.714 코루틴 (coroutine) 주종관계를 갖지 않고 서로 호출하는 두개 이상의 모듈.

4.715 큐 (queue) 먼저 들어간 것이 먼저 나오는 식으로 호출되는 리스트. 스택과 대조.

4.716 크기측정 (sizing) 시스템이나 시스템 구성요소에 요구되는 원시 줄 수 또는 컴퓨터

기억장치의 양을 평가하는 과정.

4.717 클러스터 (cluster) 상향식 통합 시험에서 특정 소프트웨어의 부수적 기능을 수행하는

하위 수준의 모듈 집합.

4.718 키 (key) 자료의 집합 내에서 집합이나 이것의 식별에 관련된 정보를 가지는 하나

이상의 문자. (ISO)

4.719 탁상 점검 (desk checking) 원시코드를 단계별로 시험함으로써 논리나 문법상의 오류를

찾기 위한 손으로 모의실험하는 프로그램 실행. 정적분석도 보시오.

4.720 테이블 (table) (1) 하나 이상의 인수에 의해 애매모호하지 않게 관련 지어진 각 항목이나

자료 배열. (ISO) (2) 레이블이나 다른 항목과 관련된 위치 또는 그 외의 다른 방법에 의해

66

유일하게 지정된 항목에서의 자료 집합. (ANSI)

4.721 통합 (integration) 소프트웨어 요소나 하드웨어 요소 또는 두 가지 모두를 전체

시스템에 결합시키는 과정.

4.722 통합 데이터베이스(integrated database) 데이터, 스키마, 모델, 도구, 기술적인 관리

결정, 프로세스 분석 정보, 요구사항 변화, 프로세스와 제품의 메트릭 등 시스템 공학 프로세스의

모든 정보를 보관하는 저장소.

4.723 통합 시험 (integration testing) 소프트웨어 요소나 하드웨어 요소 또는 두 가지 모두를

전체 시스템이 통합될 때까지 결합하고 시험하는 순서적 진행 과정.

4.724 통합 프로그래밍 지원 환경(integrated programming support environment) 프로그래밍

지원 환경을 보시오. (IEEE STD 610.12-1990)

4.725 트리 (tree) 가지에 의해 연결된 노드로 구성된 추상적인 계층구조. 여기서 ① 각 가지는

한 노드에서 종속된 다른 노드를 연결하고 ② 어떤 노드에도 종속되지 않는 유일한 노드인 루트가

있고 ③ 루트를 제외한 모든 노드는 정확히 하나의 노드에 직접 종속된다.

4.726 트랜잭션 분석(transaction analysis) 시스템의 구조가 시스템이 처리하기위해

필요로하는 트랜잭션을 분석함으로써 유도되는 소프트웨어 개발 기술. 트랜잭션 중심 설계와

비슷함. 데이터 구조 중심 설계; 입력-처리-출력; 모듈 분해; 객체 지향 설계; 신속 시제품화;

나선형 모델; 단계적 정제; 구조적 설계; 변환 분석도 보시오. (IEEE STD 610.12-1990)

4.727 트랜잭션 중심 설계(transaction –centered design) 트랜잭션 분석을 보시오. (IEEE STD 610.12-1990)

4.728 특권 명령어 (privileged instruction) 감독 프로그램에 의해서만 사용되는 명령어. (ISO)

4.729 특별 생산허가 (production permit) 생산 전 또는 서비스의 제공 전에 특정한 양이나

특정한 기간동안 규정된 요건으로부터 벗어나는데 대한 서면 승인.

4.730 특별 시험 자료 (special test data) 프로그램에서 특별한 취급을 요구할 것 같은 시험자료.

4.731 특성(characteristic) 자료 특성 또는 소프트웨어 특성을 보시오.

4.732 특채 (concession) 이미 생산되었으나 규정된 요건에 적합하지 않은 자재 부품 또는

비품의 일정 양을 사용하거나 불출하는데 대한 서면 승인. (ISO 8402:1994-1986)

[주] 특채는 한정된 양이나 기간동안이어야 하며 특정 용도이어야 한다.

4.733 파스 (parse) 인공어 혹은 자연어 단위간의 관계를 좀더 기본적인 작은 단위로 나누어

67

구문의 구조를 결정하고 그 작은 단위간의 관계를 설정. 예를 들면, 블록, 문장, 식, 그리고

연산자와 피연산자들로 나눈다.

4.734 파종 (seeding) 결함 파종을 보시오.

4.735 패치 (patch) (1) 현재의 기계코드로 대치함으로써 이루어지는 목적 프로그램의 수정.

(2) 원시 프로그램을 재 컴파일하지 않고 목적프로그램을 변경하는 것.

4.736 폐기(retirement) 부분 또는 전체를 새로운 시스템으로 교체하거나 업그레이드

시스템을 설치함으로써 운영 및 유지보수 조직이 지원을 중단하는 것.(ISO)

4.737 폐기 단계 (retirement phase) 소프트웨어 제품에 대한 지원이 끝나는 소프트웨어

생명주기상의 기간.

4.738 펌웨어 (firmware) (1) 처리 과정동안 컴퓨터에 의해 동적으로 변경이 불가능한 부류의

기억장치에 적재된 컴퓨터 프로그램과 자료. (2) 사용자 입장에서 변경할 수 없는 컴퓨터

프로그램과 자료가 들어있는 하드웨어. 즉, 펌웨어에 들어있는 컴퓨터 프로그램과 자료는

소프트웨어로 분류되고, 그 프로그램과 자료가 들어있는 전기회로는 하드웨어로 분류된다. (3)

읽기 전용 기억장치(ROM)에 저장된 프로그램 명령어. (4) 정상적인 동작을 하는 동안에는 변하지

않는, 기능적 개체를 구성하고 있는 컴퓨터 프로그램과 하드웨어의 한 개의 단위로 이루어진

집합체. 그 하드웨어 단위에 저장된 컴퓨터 프로그램은 특정한 응용이나 작용에 맞는 요구를

만족시킬 고정된 논리윤곽을 가진 집적회로로서 저장된다. (4) 하드웨어 장치와 그 위에 읽기

전용 소프트웨어로 하드웨어 장치와 상주하는 컴퓨터 명령 또는 자료의 조합. 소프트웨어는

프로그램 제어에 의하여 수정될 수 없다.(ISO)

마이크로 코드, 마이크로 프로그램도 보시오.

4.739 페트리 네트 (petri net) 시스템의 정적인 성질과 동적인 성질을 보여주는 정보흐름의

요약. 정형모델 페트리네트는 일반적으로 위치와 전이라는 두 가지 형의 노드가 아크로 연결된

그래프로 표현되고 토큰이라는 것이 동적인 성질을 나타낸다. 상태도 (state diagram)도 보시오.

4.740 편집기 (editor) 컴퓨터에 기록한 자료를 선택적으로 수정하는 컴퓨터 프로그램.

4.741 평가(evaluation) 개체가 명시된 기준을 만족하는 정도에 대한 체계적인 결정(ISO)

4.742 포기 (abort) 동작이 완료되기 전에 처리를 끝내는 것.

4.743 면제(waiver) 형상 항목이나 다른 지정된 항목이 생산도중이나 검사를 위해 제출된 후에

명세 된 요구사항으로부터 벗어난 것이 발견되었으나 승인된 재작업을 통하여 또는 그냥 그대로

사용할 것을 인정하는 문서화된 허가. 형상제어도 보시오. 규격완화; 공학변경과 비교. (IEEE STD 610.12-1990)

68

4.744 포인터 (pointer) (1) 자료항목의 위치를 지시하는 식별자. (ANSI) (2) 자료항목의 값은

다른 자료항목의 위치를 지시함.

4.745 폭포수 모델(waterfall model) 개념 단계, 요구사항 단계, 설계 단계, 구현 단계, 시험

단계, 그리고 설치와 검토 단계와 같은 활동들로 구성되고, 그러한 활동들이 부분적인 중복을

허용하면서 순서대로 수행되는, 그러나 결코 반복을 허용하지않는 소프트웨어 개발 프로세스

모델. 점진적 개발; 신속 시제품화; 나선형 모델과 비교. (IEEE STD 610.12-1990)

4.746 표준 시행자 (standards enforcer) 규정된 개발표준에 따르도록 해주는 소프트웨어 도구.

표준은 모듈크기, 모듈구조, 약정 설명, 어떤 문장형식의 사용, 문서약정 등을 포함한다.

4.747 푸쉬다운 기억장소 (push down storage) 기억장치에서 가장 최근에 기억된 내용부터

재생하는 방법으로 자료를 다루는 기억장치. 즉, last-in first-out (LIFO). (ISO) 스택도 보시오.

4.748 품질 (quality) (1) 주어진 요구사항을 만족시키는 능력을 가진 제품이나 서비스의

전체적인 특징과 성격. (ANSI/ASQC A3-1978) (2) 제품이나 서비스가 지니고 있는 명시적 또는

암묵적 요구를 만족시키는 능력에 관한 특징 및 특징의 전체. (ISO 8402:1994-1987) 소프트웨어

품질을 보시오.

[주]

1. 계약 상황에서는 요구사항이 명시되지만, 그 밖의 상황에서는 암묵적 요구가 파악되고

정의되어야 한다.

2. 많은 경우 요구는 시간에 따라 변화할 수 있으므로 시방서의 정기적인 개정을 요한다.

3. 요구는 규정된 합부 기준을 가진 특징 또는 특성으로 변환되는 것이 보통이다. 요구에는 사용

용이성, 안전성, 유용성, 신뢰성, 보전성, 경제성 및 환경에 대한 측면이 포함될 수 있다.

4. '품질'이라는 용어는 비교적인 관점에서 우수함의 정도를 나타내거나 또는 기술적 평가를

위하여 정량적인 관점으로 사용되지 않는다. 이러한 경우에는 의미를 부여하는 형용사를

사용해야 하며 예를 들면, 다음과 같은 용어가 사용될 수 있다.

가) '상태적 품질': "우수성의 정도" 또는 "비교적"의미로 제품이나 서비스를 비교하여 상대적

기준에서 순위를 정하는 경우.

나) '품질 수준' 및 '품질 메트릭': 정밀한 기술적 평가를 정량적 관점에서 행하는 경우.

5. 제품이나 서비스의 품질은 설계, 생산 또는 서비스 활동 및 보전과 같은 상호 작용하는

활동들의 여러 단계에 영향을 받는다.

6. 만족스러운 품질의 경제적 달성에는 품질루프 (품질 스파이럴)의 모든 단계가 총체적으로

관련된다. 품질루프(품질 스파이럴) 내의 여러 단계의 품질에 대한 기여도는 때에 따라 강조를

위해 개별적으로 파악된다. 예컨대, '설계 품질'이나 '실행 품질'

7. 문헌에 따라서는 품질은 '용도에 대한 적합성', '목적에 대한 적합성', '고객만족도' 또는 '

요건에의 일치성'으로 정의되고 있다. 이들은 품질의 어떤 특정면만을 표현한 것이므로 좀더

충분한 설명이 요구되는 것이 통례이며 결국은 통상, 위에서 정의된 개념에 이르게 된다.

69

4.749 품질 감사 (quality audit) 품질활동 및 그 결과가 계획과 일치되는지의 여부 그리고 이들

계획이 효과적으로 실시되고 목표달성에 적합한 것인지의 여부를 결정하기 위한 체계적이고

독립적인 조사(ISO 8402:1994)

[주]

1. 품질 감사는 전형적으로 품질 시스템이나 그것에 관한 요소, 공정, 제품 또는 서비스에

적용되지만, 그것에 국한되지는 않는다. 이와 같은 감사는 흔히 품질 시스템 감사, 공정 품질

감사, 제품 품질 감사 또는 서비스 품질 감사라고 부른다.

2. 품질감사는 감사를 받는 구역에 직접적인 책임이 없는 직원에 의해서 수행되나, 관련된 인원과

협력하여 일하는 직원에 의하여 수행되는 것이 바람직하다.

3. 품질감사의 한 가지 목적은 개선 또는 시정조치의 필요성을 평가하는 것이다. 감사는 공정관리

또는 제품 합격 판정을 목적으로 수행하는 품질 사후심사 및 검사 활동과 혼동하지 않아야

한다.

4. 품질감사는 내부 또는 외부 목적을 위해서 실시될 수 있다.

4.750 품질 감사 관찰 (quality audit observation) 품질 감사 중 객관적 증거가 만들어졌고

구체화되어 있는 사실에 대한 기술

4.751 품질 감사원 (quality auditor) 품질 감사를 수행할 만한 자질을 갖춘 사람.

[주] 품질 감사를 주관하도록 임명을 받은 품질 감사원을 "선임 품질 감사원"이라 부른다.

4.752 품질 감시확인 (quality surveillance) 규정된 품질 요건이 만족되고 있음을 보장하기

위하여 절차, 방법, 조건, 공정, 제품, 서비스 및 기록들의 분석을 명시된 참조서와 비교하여

지속적으로 감시하고 확인하는 것

[주]

1. 품질 감시확인은 계약 요건이 만족되고 있음을 보장하기 위하여 고객에 의해서 또는 고객을

대신하여 수행되어도 좋다.

2. 품질 감시확인은 시간에 따라 열화 또는 품질 저하를 초래할 수 있는 요인을 고려해야 한다.

4.753 품질 개선 (quality improvement) 활동의 효율과 능률의 향상시키기 위한 조직과 조직

및 그의 고객이 함께 이익을 증진시키기 위한 처리(process)를 철저히 하는 행위.

4.754 품질 경영 (quality management) 전반적 경영기능 중에서 품질 방침을 결정하고

실행하는 측면

[주]

1 품질 경영에 대한 책임은 최고 경영자에게 있으나 바람직한 품질을 이루기 위해서는 조직

전원의 결의표명과 참여가 필요하다.

2 품질 경영은 품질 계획 수립, 운영 및 평가와 같은 품질에 관한 전략적 계획 수립, 자원의 배분 및

기타 체계적인 활동을 포함한다.

4.755 품질 계획 (quality planning) 품질 시스템 항목들의 적용을 위해 목적과 품질

70

요구사항을 수립하는 활동

[주] 품질 계획은 다음을 포함한다.

1. 생산 계획: 목적, 품질 요구사항, 구속을 수립할 뿐만 아니라 식별, 분류, 특징 가중치

2. 관리와 운영 계획: 조직과 일정이 포함된 품질 시스템의 적용 준비

3. 품질 계획서 준비와 품질 개선을 위한 대책 마련

4.756 품질 계획서 (quality plan) 특정의 제품, 서비스, 계약 또는 프로젝트에 관한 특정 품질

업무, 자원 및 활동순서를 정해놓은 문서 (ISO 8402:1994)

[주]

1. 품질계획서는 일반적으로 특정한 경우에 적용할 수 있는 품질매뉴얼의 일부분을 참조한다.

2. 계획서의 적용 범위에 따라 품질보증 계획서, 품질경영 계획서와 같은 수식어가 사용될 수

있다.

4.757 품질 관리 (quality control) 품질에 대한 요건들을 충족시키기 위하여 사용되는

운영기법 및 활동.

[주]

1. 혼란을 피하기 위해 제조 품질관리와 같이 품질관리의 협의의 개념이나 '전사적 품질관리

(CWQC)'와 같이 광의의 개념과 관련될 때에는 수식어를 포함한다는 것에 유의해야 한다.

2. 품질관리는 경제적 효과를 높이기 위해 품질 루프 (품질 스파이럴)의 해당 단계에서 공정(과정)

을 감시하고 불만족 상태 (부적합)의 원인을 제거하기 위한 운영기법과 활동을 포함한다.

4.758 품질 관련 비용(quality-related costs) 만족할 만한 품질에 도달하지 못할 때 발생하는

손실뿐만 아니라 만족스러운 품질 확보와 보증하기 위해 발생된 비용

[주]

1 품질 관련 비용은 자신의 기준에 따라 조직에서 분류된다.

2 어떤 손실은 수량을 계산하기가 어려우나 신용의 손실과 같이 매우 중요할 수 있다.

4.759 품질 루프 (quality loop) 요구의 파악으로부터 이들 요구가 만족되어 졌는지를

평가하기까지의 여러 단계에서 제품 또는 서비스의 품질에 영향을 주는 상호관련 활동의 개념적

모델

4.760 품질 매뉴얼 (quality manual) 품질 정책과 조직의 품질 시스템을 기술한 문서

[주]

1 품질매뉴얼은 조직의 활동을 총괄적 또는 부분적으로 관련된다. 매뉴얼의 제목과 범위는 적용

분야에 반영한다.

2 품질매뉴얼은 적어도 보통 다음사항을 포함한다.

가) 품질 정책

나) 책임, 권한과 품질에 영향을 미치는 경영, 수행, 검사 또는 검토 업무를 하는 인력의 내부적

관계

71

다) 품질 시스템 절차 또는 지침

라) 매뉴얼의 검토, 갱신 또는 관리에 관한 언급

3 품질매뉴얼은 조직의 필요에 따라 깊이나 형식이 다양할 수 있다. 한 문서 이상을 포함할 수

있다. 예를 들면 매뉴얼의 범위에 따라 "품질 보증 매뉴얼", "품질 관리 매뉴얼"이라는 수식어를

사용한다.

4.761 품질 모형(quality model) 품질에 대한 요구와 품질 평가를 명시하기 위한 기초를

제공하는 특성의 집합과 그들의 관계.

4.762 품질 방침 (quality policy) 최고 경영자에 의해 공식적으로 표명된 품질에 관한 조직의

전체적인 의지와 지시

[주] 품질 방침은 회사방침의 한 요소를 이루며 최고 경영자에 의해 인가된다.

4.763 품질 보증 (quality assurance) (1) 제정된 기술적인 필요조건에 적합한 항목이나 제품이

충분한 신용을 얻는데 필요한 계획적이고 조직적인 모든 행동의 패턴. (ANSI/IEEE Std 730-1981)

(2) 제품 또는 서비스가 주어진 품질요건을 만족시킬 것이라는 적절한 신뢰감을 주는데 필요한

모든 계획적이고 체계적인 활동. (ISO 8402:1994-1986)

[주]

1. 주어진 요건이 사용자의 요구를 충분히 반영하지 못하면 품질 보증은 완전하지 못하다.

2. 품질 보증을 효과적으로 행하기 위해서는 통상생산, 설치 및 검사작업의 검증 및 감사에 대한

적절성과 의도한 대로의 적용을 위해 설계 또는 시방서의 적절성에 영향을 주는 요소들에 대한

지속적인 평가가 요구된다. 신뢰감을 제공하는 것은 증거를 만드는 것을 포함할 수 있다.

3. 품질 보증은 조직 내부에서는 경영 도구가 되며, 계약 상황에서는 공급자측에 신뢰감을 갖게

한다.

4.764 품질 보증모델 (model for quality assurance) 주어진 상황에서 품질 보증 요구를

충족시켜주는 품질 시스템 요구사항의 표준화되고 선별된 형태

4.765 품질 속성(quality attribute) 제품의 품질에 영향을 미치는 형태나 특성. 품질 요소

(quality factor)도 보시오. (IEEE STD 610.12-1990)

[주] 품질 속성의 계층에서 높은 수준의 속성들은 품질 요소라 불리고, 낮은 수준의 속성들은 품질

속성이라 불림.

4.766 품질 손실 (quality losses) 처리(process)와 활동에서 자원의 잠재력 상실로 발생된 손실. (ISO 8402:1994: 1994)[주] - 품질 손실의 예는 자원 및 재료의 낭비뿐만 아니라 고객만족의 손실, 고객에게 가치를

증가시킬 수 있는 기회의 손실 등이다.

4.767 품질 시스템 (quality system) 품질경영을 실행하기 위한 조직구조, 책임, 절차, 과정 및

자원

72

[주]

1. 품질 감사는 품질 시스템 또는 그 요소, 공정, 제품 또는 서비스에 대해 주로 적용하나 그것에

한정되지 않는다. 이러한 감사는 '품질 시스템 감사', '공정 품질 감사', '제품 품질 감사', '서비스

품질 감사'로 불리우기도 한다.

2. 품질 감사는 감사 대상 업무에 직접 책임이 없는 자에 의해서 행하여지지만, 관련자와

협력하는 것이 바람직하다.

3. 품질 감사 목적 중의 하나는 개선 또는 시정 조치 필요성을 평가하는 것이다. 감사를 공정 관리

또는 제품 합부 판정만을 목적으로 하는 '감사확인'이나 '감사' 활동과 혼동해서는 안된다.

4. 품질 감사는 내부 또는 외부 목적으로 수행될 수 있다.

4.768 품질 시스템 심사 (quality system review) 품질 방침 및 환경의 변화로부터 초래되는

새로운 목표와 관련하여 품질 시스템의 상태 및 적절성에 대한 최고 경영자에 의한 공식적 평가

4.769 품질 요구사항 (requirements for quality) 요구의 표현 또는 요구의 실현과 검사를 위해

개체의 특징을 양적으로나 질적으로 기술한 요구사항. (ISO 8402:1994)

[주]

1 품질 요구사항은 고객이 기술하고 암시한 요구사항을 충분히 반영하는 것이 중요하다.

2 "요구사항"이란 용어는 조직의 내부 요구사항뿐만 아니라 거래와 계약상에 사용한다. 이

요구사항은 계획이 변경 시 상세하게 갱신되어야 한다.

3 예를 들면 특징에 대해 양적으로 기술된 요구사항은 정규 값, 비율 값, 제한편차, 허용오차를

포함한다.

4 품질 요구사항은 기능적인 용어로 표현되고 문서화해야 한다.

4.770 품질 요소 소프트웨어 품질에 영향을 주는 관리 중심의 속성

4.771 품질 정책(quality policy) 품질에 관하여 최고 관리자에 의해 결정되는 모든 품질활동의

취지와 조직의 방향

4.772 품질 메트릭 (quality metric) 그 품질에 영향을 끼치는 주어진 특징을 어느 정도 가지고

있는지를 측정하는 메트릭.

4.773 품질 평가 (quality evaluation) 개체가 특정한 요구사항을 성취할 수 있는지 대한

체계적인 검사. (ISO 8402:1994)

[주]

1 품질 평가는 공급자의 품질 능력을 결정하는데 사용된다. 이런 경우 특정한 환경에 따라 품질

평가의 결과는 자격부여, 승인, 등록, 증명 또는 증가 목적으로 사용될 수 있다.

2 추가적인 수식어는 범위(예를 들면 처리, 인력, 시스템)와 시간 조정(예를 들면 계약 전)에 따라

3 또한 전체 공급자 품질 평가는 금융과 기술적 자원의 평가를 포함할 수 있다.

4 영어로 품질 평가는 특정한 환경에서 "quality assessment", "quality appraisal" 또는 "quality

survey"로 부른다.

73

4.774 프로그래머 지침서(programmer manual) 컴퓨터 시스템을 위한 소프트웨어를

개발하거나 수정하기위해 필요한 정보를 제공하는 문서. 장비 구성, 운영 특징, 프로그래밍 형태,

그리고 컴퓨터 시스템의 컴파일러나 어셈블리 형태를 기술함. 진단 지침서; 설치 지침서; 운영자

지침서; 보조 지침서; 사용자 지침서도 보시오. (IEEE STD 610.12-1990)

4.775 프로그래밍 언어 (programming language) 프로그램을 표현하고 생성하도록 설계한

인공언어. (ISO)

4.776 프로그래밍 지원 환경 (programming support environment) 전반적인 소프트웨어

생명주기를 통해서 프로그래밍을 지탱해주는 능력을 제공하기 위하여 지시언어에 의해

사용하도록 하는 도구의 종합적인 모임. 환경은 대체적으로 설계, 편집, 컴파일, 적재, 시험,

배치관리, 프로젝트 관리를 위한 도구를 포함한다.

4.777 프로그램 (program) (1) 컴퓨터 프로그램. (2) 행해야 할 행동을 명시해 놓은 시간표나

계획. (3) 컴퓨터 프로그램을 설계하고 쓰고 검사하는 것. (ISO)

4.778 프로그램 계측 (program instrumentation) (1) 실행감시, 정당성의 증명, 지원감시, 그

밖의 일을 쉽게 하기 위하여 컴퓨터 프로그램에 삽입하는 명령이나 가정과 같은 탐사기구. (2)

탐사를 준비하고 컴퓨터 프로그램에 넣는 과정.

4.779 프로그램 구조 (program architecture) 컴퓨터 프로그램의 구성요소간의 조직과 관계.

프로그램 구조는 가동 환경하에서 프로그램간의 인터페이스도 포함한다.

4.780 프로그램 라이브러리 (program library) 컴퓨터 프로그램의 체계적인 모임.

소프트웨어 라이브러리, 시스템 라이브러리도 보시오.

4.781 프로그램 명세(서) (program specification) 컴퓨터 프로그램에 대한 명세(서).

설계명세(서), 기능 명세(서), 성능명세(서), 요구사항 명세(서)를 보시오. 설계 명세(서)와 동의어

4.782 프로그램 변이 (program mutation) (1) 변경을 감시하는 시험사례 프로그램의 능력을

평가하기 위해서 고의적으로 바꾼 프로그램. (2) 프로그램 검사자료를 충분하게 하기위해

프로그램을 전환해가는 과정. 프로그램 전환 (program mutant)와 동의어.

4.783 프로그램 보호 (program protection) 컴퓨터 프로그램에 대한 인가되지 않은 호출이나

수정을 예방하기 위한 내외부 제어의 응용.

4.784 프로그램 블록 (program block) 문제해결을 목적으로 하는 언어에서 관련된 문장을

묶어놓거나 루틴의 한계를 정하거나, 기억장소할당을 지정하거나, 레이블의 응용성을

서술하거나 혹은 다른 목적으로 컴퓨터 프로그램을 나누는 컴퓨터 프로그램의 분할을 말한다.

74

(ANSI)

4.785 프로그램 설계언어 (program design language) 설계 언어를 보시오.

4.786 프로그램 정확도 (program correctness) 정확도를 보시오.

4.787 프로그램 지원 라이브러리 (program support library) 소프트웨어 개발 라이브러리를

보시오.

4.788 프로그램 합성 (program synthesis) 프로그램 명세(서)를 프로그램으로 변환하는 것을

돕는 소프트웨어 도구의 사용.

4.789 프로그램 확장 (program extension) 현재의 소프트웨어의 능력의 범위를 넓히도록

증진시키는 것.

4.790 프로그램의 유효성 (program validation) 컴퓨터 프로그램 유효성과 동의어. 유효성을

보시오.

4.791 프로세스(process) (1) 입력을 출력으로 변환시키는 관련된 활동의 집합(ISO) (2)

소프트웨어 생명주기에서 수행되는 기능. 프로세스는 활동들로 구성된다. (IEEE STD 1074-1995)

(3) 결과를 도출하기 위한 작업, 행동, 활동의 순서.(IEEE STD 1220-1994) (4) 목적을 수행하기

위해서 수행하는 활동의 조직적인 집합.(J-STD-016-1995)

[주] 활동이라는 용어는 자원(resource)의 사용을 포함한다.

4.792 프로세스 관리(process management) 제품을 개발하거나 서비스를 수행하기위해

수행되는 작업의 방향 설정, 제어 및 조정. (IEEE STD 610.12-1990)

4.793 프로세스 설계자(process architect) 조직에서 표준 정립을 관리하는 사람이나 그룹

4.794 프로세스 메트릭(process metric) 소프트웨어 시스템을 개발하고, 구현, 유지보수에서

사용되는 방법, 기술과 도구의 특징을 측정하는 데 사용하는 메트릭

4.795 프로젝트 계획 (project plan) 프로젝트를 수행하기 위한 접근방법을 기술하는 문서.

계획은 전형적으로 해야 할 일, 요구되는 지원사항, 사용할 방법, 이에 따르는 형상관리와

품질보증절차, 시간계획 등을 포함한다.

4.796 프로젝트 기능(project function) 소프트웨어 프로젝트의 전 기간에 걸쳐있는 활동. 예를

들면 프로젝트 관리, 형상 관리, 품질 보증, 확인 및 검증.

4.797 프로젝트 노트북 (project notebook) 어떤 프로젝트에 속하는 메모, 계획, 전문적 보고서

등과 같이 쓰여진 것을 모아 놓은 것. 프로젝트 파일과 동의어. 소프트웨어 개발 노트북도 보시오.

75

4.798 프로젝트 동의서(project agreement) 프로젝트의 책임자와 고객이 동의한 문서 또는

문서의 집합. 프로젝트 동의 문서는 계약, 작업 지시, 시스템 공학 명세서, 사용자 요구사항 명세서,

기능 명세서, 소프트웨어 프로젝트 관리 계획, 업무 계획 등을 포함한다.(IEEE 1058.1-1987)

4.799 프로젝트 인도물(project deliverables) 사용자에게 인도되어야 할 제품. 수량, 인도 날짜,

인도 장소는 프로젝트 동의서에 명시되어 있다.(IEEE 1058.1-1987)

4.800 프로젝트 파일 (project file) 프로젝트 노트북을 보시오.

4.801 프로젝트 환경(project environment) 목적, 성공요인, 프로젝트 이정표, 제품개발을

지원하기 위한 시스템 공학 활동에 대한 관리활동의 우선순위를 정의한 환경.

4.802 프로토콜 (protocol) (1) 컴퓨터 시스템 또는 네트워크의 프로세스 또는 응용간의

상호작용을 제어하는 협정이나 규칙의 집합. (2) 통신을 하기 위해 기능 단위의 수행을 제어하는

규칙의 집합. (ISO)

4.803 프롬프트 (prompt) (1) 시스템이 다음명령이나 메세지, 또는 사용자의 행동을 받아들일

준비가 되었음을 사용자에게 알려주는 메세지. (2) 시스템에 다음 명령, 요소, 혹은 다른 입력을

받아들일 준비가 되었음을 사용자에게 알려주는 것.

4.804 프리 컴파일러 (precompiler) 컴파일러가 받아들일 수 없는 소스 코드의 부분을

컴파일러가 받아들일 수 있는 동등한 코드로 생성하는 컴퓨터 프로그램. 예를 들면, 구조적

Fortran 을 ANSI 표준 Fortran 으로 변형시키는 프리 프로세서.

4.805 플래그 (flag) (1) 오류, 상태, 또 다른 특정조건의 발생을 알리는 표시자. (2) 식별을 위해

사용하는 표시자의 여러 유형. 예를 들면, 단어표시 (word mark). (ISO) (3) 단어의 끝과 같은 어떤

조건의 발생을 알려주는 문자. (ANSI) (4) 프로그램에서 오류, 상태, 또 다른 특정조건을 표시하기

위한 것.

4.806 피감사자 (auditee) 감사를 받는 조직. (ISO 8402:1994)

4.807 피연산자 (operand) (1) 수행되는 연산에서의 개체. (ISO) (2) 연산할 때 피연산자는

명령어의 주소로 식별한다. (ANSI) 연산자도 보시오.

4.808 필수 프로세스(integral process) 성공적으로 프로젝트를 완수하기 위해 꼭 필요한

프로세스로서 관리 프로세스와 개발 프로세스와 같은 핵심 프로세스에 해당되지 않는 프로세스.

필수 프로세스는 검증, 확인, 소프트웨어 형상관리, 문서 개발과 훈련을 말한다. (IEEE 1074.1-1995)

4.809 하드웨어 (hardware) 컴퓨터 프로그램, 절차, 규칙, 관련문서와 대조되는 자료처리에

76

사용되는 물리적도구.

소프트웨어와 대조. (ISO)

4.810 하드웨어 항목(hardware item) 명세, 시험, 형상관리 등을 위해 고안된 하드웨어의 집합.

4.811 하드웨어 형상 항목(hardware configuration item: HWCI) 획득자가 형상관리를 수행할

수 있도록 고안된 하드웨어의 집합. (MIL-STD-498)

4.812 하청계약자 (subcontractor) 공급자에게 제품을 제공하는 기관

[주]

1 하청주는 자는 공급자라 한다.

2 불어로 "le sous-contractant etre appele <<sous-traitan> ou <<sous-commandie>"라고 부른다.

4.813 하향식 (top-down) 계층의 최상위레벨부터 시작하여 점차 하위레벨로 진행해 내려오는

방식으로 하향식 설계, 하향식 프로그래밍, 하향식 시험 등이 있다.

상향식과 대조.

4.814 하향식 설계 (top-down design) 시스템의 주된 구성요소를 확인한 다음 그들을 다시

하위레벨 구성요소로 분해하는 과정을 원하는 만큼 상세한 정도까지 반복한다. 상향식 설계와

대조.

4.815 하향식 시험 (top-down testing) 계층적으로 구성된 프로그램을 하위레벨 구성요소의

시뮬레이션을 통하여 상위에서 하위로 점차적으로 검사해나가는 과정.

4.816 할당(allocation) (1) 시스템 또는 프로그램에 요구사항, 자원 등을 분배하는 절차. (2)

앞의 정의가 이루어진 결과.

4.817 할당 기준선(allocated baseline) 시스템이나 상위 형상항목에 대한 기능적 특성,

상호운영 특성 및 인터페이스 특성과 설계제약 사항 등을 기술한 문서. 일반적으로 요구명세 완료

시점의 산출물임. 개발 형상; 기능적 기준선; 제품 기준선도 보시오.

4.818 할당된 형상 식별(allocated configuration identification) 형상관리에 있어서 상위 수준

형상항목의 부분인 형상항목의 개발을 관리하는 승인된 명세서. 각각의 명세서는 상위 수준의

형상항목의 특성으로부터 할당된 기능적 특성을 정의하고, 할당된 기능적 특성의 성취를

시연하기 위해 요구되는 시험을 설정하고, 다른 관련있는 형상항목에 대한 필요한 인터페이스

요구사항을 묘사하고, 설계 제약을 설정한다. 기능 형상 식별, 제품 형상 식별, 할당 기준선도

보시오.

4.819 함수 (function) 호출되면 함수의 이름이 표시된 곳에서 식을 계산하여 호출한곳에 값을

돌려주는 부 프로그램. 부 루틴과 대조.

77

4.820 합동 검토(joint review) 개발자와 획득자의 대표들의 회의로 프로젝트의 상태,

소프트웨어 제품에 대한 평가와 토론을 수행.(J-STD-016-1995)

4.821 해석 (interpret) 다음문장을 번역하고 수행하기 전에 컴퓨터 프로그램의 원시문장을 한

개씩 번역하고 수행함. (ISO) 어셈블, 컴파일과 대조.

4.822 해석기 (interpreter) (1) 컴퓨터 프로그램을 해석하는데 사용되는 소프트웨어,

하드웨어, 또는 펌웨어. 컴파일러, 어셈블러와 대조. (2) 번역에 사용되는 컴퓨터 프로그램. (ISO)

4.823 행위 분석(behavioral analysis) 기능적 물리적 구조를 평가하기 위해서 시스템의 논리적,

물리적 실행을 하는 분석. (IEEE STD 1220-1994)

4.824 행위 설계(behavioral design) 사용자의 관점에서 시스템 또는 개별적인 소프트웨어

항목이 어떻게 행동할 것인가에 대한 설계. 구조 설계와는 반대 개념.

4.825 허용한계 (tolerance) 시스템이 여러가지 비정상적인 조건하에서 동작을 계속 할 수

있는 능력.

4.826 협정(agreement) 수행할 업무의 관계에 따르는 용어나 조건의 정의

4.827 형상 (configuration) (1) 컴퓨터 시스템의 배열 또는 본질, 수 그리고 기능 단위들의

주요한 특성들에 의해서 정의된 네트워크, 더 상세히 말하면 형상에는 하드웨어 형상과

소프트웨어 형상이 있다. (ISO) (2) 시스템 또는 시스템 성분의 특별한 설명을 정의하는 구현,

설계, 그리고 요구사항. (3) 기술적인 문서화작업에 나타나고 생산에 수행되는 하드웨어와

소프트웨어의 기능적, 물리적 특성. (DoD-STD 480A)

4.828 형상 감리 (configuration audit) 요구되는 모든 형상항목이 만들어졌는지, 현재 형상이

명세화된 요구 사항에 일치하는지, 기술적 문서화 작업이 완전하고 정확하게 형상항목을

서술하는지, 모든 변화가 해결되었는지를 증명하는 과정.

4.829 형상 관리 (configuration management) (1) 시스템의 형상항목을 정의하고 식별하는

과정으로, 시스템의 생명주기 동안 항목을 제어하며 항목에 대한 변화요구의 형상항목의 상태를

기록하고 완전성을 증명함. (2) ① 형상항목의 기능적, 물리적 특성을 식별하고 문서화하며, ② 이런 특성의 변화를 제어하며, ③ 변경처리와 변경상태를 기록하고 보고하는 체제. 변경제어,

형상 동일화, 형상 제어, 형상 상태보고리, 형상 감사도 보시오.

4.830 형상 기준선(configuration baseline) 기준선을 보시오.

4.831 형상 상태 기록 관리(configuration status accounting) 형상 상태보고를 보시오.

78

4.832 형상 상태보고 (configuration status accounting) (1) 형상 동일화와 승인된 형상의 변화,

그리고 제안된 변화상태의 구현을 포함한 형상을 효율적으로 관리하는데 필요한 정보를 기록하고

관리하는 것. (DoD-STD 480A) (2) 형상 항목을 효과적으로 관리하기위해 필요한 정보들을

기록하고 보고하는 것. 승인된 형상 문서 기록과 식별 번호, 제안된 변경, 이탈, 포기의 상태,

승인된 변경의 구현 상태, 형상 항목의 모든 단위들의 형상에 관한 정보를 기록하고 보관. (MIL-STD-973-1992)

4.833 형상 색인(configuration index) 제품을 구성하는 형상 항목들에 대한 색인을 제공하는

형상 관리에서 사용되는 문서. 형상 항목 개발 기록도 보시오.

4.834 형상 식별 (configuration identification) (1) 시스템이 형상항목을 지적하고 형상항목의

특성을 기록하는 과정. (2) 형상항목을 정의하는 승인된 문서화 작업. (3) 명세(서), 그림, 연관된

리스트에 나타난 형상항목에 대한 현재 승인되거나 부분적으로 승인된 문서화 작업과 그것에

참조된 문서. (DoD-STD 480A)

4.835 형상 통제 (configuration control) (1) 형상을 공식적으로 설정한 후에 형상항목의

변화를 수용하는 과정과 평가 승인 또는 비승인의 결정과정. (2) 체계적 평가, 조정, 승인 또는

불인정, 그리고 공식적인 형상의 설정 후 승인된 형상항목 변경의 구현. (DoD-STD 480A)

4.836 형상 통제 위원회 (configuration control board) 제안된 변경요청 사항을 승인 또는

불인정하고, 승인한 변경을 구현한 결과를 확인하고 평가할 수 있는 모임.

4.837 형상 항목 (configuration item) (1) 형상관리를 위한 단위로서 하드웨어 또는 소프트웨어

요소의 집합. (2) 하드웨어 또는 소프트웨어의 집합, 또는 그들의 일부분으로써 최종 사용 함수를

만족하며 형상관리를 위해 정한다. 항목은 복잡도와 크기에 따라 다양하다. 개발과 초기생산

단계에서는 형상항목은 계약 시 직접 언급된 명세(서) 항목이며 운영과 유지보수단계에서는

수정될 수 있는 항목. (DoD-STD 480A) (3) 최종사용 기능을 만족하고 주어진 참조 시점에서

유일하게 식별할 수 있는 형상내의 개체(ISO)

4.838 형상 항목 개발 기록(configuration item development record) 형상 감리와 설계 검토

결과를 바탕으로 형상 항목의 개발 상태를 기록한 형상 관리에서 사용되는 문서. 형상 색인; 형상

상태 기록 관리도 보시오.

4.839 형식 검사 (formal testing) 공신력 있는 검사계획에 따라 검사행위를 수행하고 그

결과를 보고하는 과정.

4.840 형식 매개변수 (formal parameter) 호출하는 루틴이 부 프로그램에 전달하는 자료나

프로그램 요소를 표현하기 위하여 부 프로그램에서 사용하는 변수. 가 매개변수와 동의어. 실

매개변수와 대조.

79

4.841 형식 명세(서) (formal specification) (1) 설정된 기준에 잘 부합되게 쓰여진 명세(서). (2)

정확성 검증에 있어서 시스템이나 시스템 요소의 외부적 동작을 형식언어로 기술한 것.

4.842 형식 언어 (formal language) 사용하기에 앞서 이것에 대한 규칙이 명확히 확립된 언어.

술어해석(predicate calculus)과 같은 수학적이거나 논리적인 언어. 예를 들면, Fortran, Ada 와 같은

언어가 있다. 인공 언어와 동의어. 자연 언어와 대조.

4.843 형식 자격 검토(formal qualification review) 시스템을 구성하는 구성 항목 그룹이

계약상의 성능 요구사항을 만족시키는지 검증하는 시험, 검사, 또는 분석 처리. 코드 검토; 설계

검토; 요구사항 검토; 시험 준비 검토와 비교. (IEEE STD 610.12-1990)

4.844 호스트 기계 (host machine) (1) 프로그램이나 파일에 설치되어 있는 컴퓨터. (2) 다른

기계에서 수행될 소프트웨어를 개발하는데 사용하는 컴퓨터. (3) 다른 컴퓨터를 에뮬레이트

하는데 사용하는 기계. (4) 컴퓨터 네트워크에서 처리 능력을 네트워크의 사용자에게 제공하는

컴퓨터. 목표 기계와 대조. 목표 기계와 대조.

4.845 호출(invocation) 필수 프로세스(integral process)의 획득된 활동을 개시토록 하는 것. (IEEE STD 1074-1995)

4.846 호출된 프로세스(invoked process) 서브루틴을 호출하는 것과 같이 필수 프로세스중에서

호출하여 수행되는 프로세스.

4.847 호환성 (compatibility) (1) 두개 이상의 시스템간에 정보를 교환할 수 있는 성질. (2)

관련 요구사항을 만족하기 위해 특정한 상태 하에 있어 함께 사용할 수 있는 개체의 능력. (ISO

8402:1994) 상호운용성(interoperability) 과 비교.

[주] - 위 정의는 품질표준의 목적과 부합한다. "호환성"이란 용어는 ISO/IEC Guide 2 에는 다르게

정의하고 있다.

4.848 화일 (file) 단위로서 다루는 연관된 레코드의 집합. (ISO) 논리적 파일도 보시오.

4.849 확인 (validation) (1) 소프트웨어 요구사항의 만족을 보장하기 위해 소프트웨어 개발

프로세스의 끝부분에서 소프트웨어를 평가하는 과정. (2) 소프트웨어 개발 프로세스에서 생성한

최종 제품이 소프트웨어 요구사항을 만족하는지를 보장하기 위한 평가 과정. (3) 시험 및

객관적인 증거의 제시로 특정 용도에 대한 특별한 요구사항이 만족됨을 확인하는 것.(ISO) 검증

(verification)도 보시오.

[주]

1 설계 및 개발에서 확인은 사용자의 요구에 부합하는가를 결정하기 위하여 제품을 시험하는

프로세스로 생각할 수 있다.

2 <확인>은 일반적으로 정의된 운영 환경에서 최종제품에 대하여 시행한다. 이것은 앞

단계에서도 시행할 수 있다.

80

3 <확인됨>은 일치된 상태를 지정할 때 사용된다.

4- 중복 확인은 의도된 사용이 다를 경우 수행될 수도 있다.

4.850 확인된 메트릭(validated metric) 품질 요소 값과 통계적으로 연관된 값을 가진 메트릭.

4.851 활동(activity) (1) 소프트웨어 프로젝트의 목적을 성취하기 위한 일의 주요 단위. 활동은

시작과 종료일을 가지고 있으며, 일을 완성하기 위한 작업들의 상호협력과 필요 자원, 결과물을

가지고 있다. 활동은 계층적으로 작업들을 포함하고 있다.(IEEE 1058.1-1987) (2) 프로세스를

구성하는 작업. 작업(task)도 보시오. (IEEE STD 1074-1995)

4.852 회귀 시험 (regression testing) 시스템 자체나 시스템 구성요소를 수정할 때, 수정할

필요가 없는 부분과 수정된 사항 모두에 있어, 이들이 여전히 명세화된 요구사항에 일치함을

증명하기 위하여 선택적으로 재차 시험하는 것.

4.853 획득(acquisition) 시스템, 소프트웨어 제품 또는 소프트웨어 서비스를 사거나 얻는

프로세스

4.854 획득자(acquirer) 시스템, 소프트웨어 제품 또는 소프트웨어 서비스를 공급자로부터

획득하는 조직

[주]

획득자는 다음 중 하나일 수 있다: buyer, customer, owner, user, purchaser.

4.855 효과 기준(effectiveness criteria) 설계 해결책의 성공과 실패를 결정하는 데 사용되는

값의 범위.

4.856 효과 분석(effectiveness analysis) 설계 해결책이 얼마나 잘 수행되는 가 혹은 주어진 예상

연산 시나리오를 수행하는 가에 대한 분석.

4.857 효과 척도(measure of effectiveness: MOE) 기술적인 노력에 대한 만족도를 측정하기

위한 척도.4.858 효과 평가(effectiveness assessment) 제조, 테스트, 분배, 연산, 지원, 훈련, 환경 영향 ,

비용 효과와 생명 주기 비용에 관하여 설계 해결책을 평가.

4.859 효율(efficiency) 컴퓨터 자원을 최소한으로 소모하면서 소프트웨어의 예정된 기능을

계속 수행하는 정도를 나타내는 비율.

81

4. 참고자료

IEEE STD 1008-1987, IEEE Standard for Software Unit Testing (ANSI) IEEE STD 1012-1986, IEEE Standard for Software Verification and Validation Plans (ANSI) IEEE STD 1028-1988 (Reaff 1993), IEEE Standard for Software Reviews and Audits (ANSI) IEEE STD 1058.1-1987 (Reaff 1993), IEEE Standard for Software Project Management Plans

(ANSI) IEEE STD 1059-1993, IEEE Guide for Software Verification and Validation Plans (ANSI) IEEE STD 1061-1992, IEEE Standard for a Software Quality Metrics Methodology (ANSI) IEEE STD 1074-1995, IEEE Standard for Developing Software Life Cycle Processes (ANSI) IEEE STD 1074.1-1995, IEEE Guide for Developing Software Life Cycle Processes (ANSI) IEEE STD 1220-1994, IEEE Trial-Use Standard for the Application and Management of the

Systems Engineering Process IEEE STD 1298-1992 (AS 3563.1-1991), IEEE Software Quality Management System, IEEE

Part 1: Requirements (ANSI) IEEE STD 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology IEEE STD 730-1989, IEEE Standard for Software Quality Assurance Plans (ANSI) IEEE STD 730.1-1995, IEEE Guide for Software Quality Assurance Plans (ANSI) ISO 8402-1994, ISO Quality management and Quality assurance ISO 9000-3 Quality management and quality assurance standards – Part 3 : Guidelines for the

application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software

ISO 9001 Quality System- Model for quality assurance in design, development, production, installation and servicing

ISO/IEC 12207 Information technology - Software life cycle processes ISO/IEC 9126-1 Software quality characteristics and metrics Part 1 - Quality

characteristics and sub-characteristics ISO/IEC DIS 14598-1 Information Technology - Software Product Evaluation - Part 1: General

Overview ISO/IEC draft CD 14598-2 Information Technology - Software Product Evaluation - Part 2:

Planning and Management J-STD-016-1995 (IEEE STD 1498-1995), EIA/IEEE Interim Standard for Information

Technology-Software Life Cycle Processes- Software Development Acquirer-Supplier Agreement (Issued for Trial Use)

MIL-STD-498 Software Development And Documentation 정기원, 윤창섭, 김태현, “소프트웨어 프로세스와 품질”, 홍릉과학출판사, 1997

82

표준번호 : TTA.KO-11.0019

이 표준의 제·개정 및 발간을 위해 아래와 같이 여러분들이 공헌을 하였습니다.

과제제안 ETRI 표준초안 제출 ETRI(안유환, 이선미, 박현민)

표준화추진 위원회 S/W 응용기술연구반

표준안 검토 및 작성 의 장 : 함호상

부 의 장 : 신용우 간 사 : 박현민 위 원 : 조현규 위 원 : 김철홍 위 원 : 김종표

표준안 편집 및 감수 S/W 응용기술연구반

표준안 심의 정보통신소프트웨어기술위원회

83