T T A S t a n d a r d - cmmi version1.3, cmu-sei, 2010.11. - ieee 829, ‘소프트웨어 시험 문서 표준’ - ieee 830, ‘소프트웨어 요구 사항정의서 표준’ -

T T

A S

t a n

d a

r d

정보통신단체표준(국문표준)

TTAK.OT-11.0018-Part3 제정일: 2014 년 12 월 17 일

소프트웨어 연구 개발 프로세스 :

제 3 부 - 생명주기 프로세스

Software Research and Development Process :

Part 3 - Life Cycle Process


TTAK.OT-11.0018-Part3 제정일: 2014 년 12 월 17 일

소프트웨어 연구 개발 프로세스 :

제 3 부- 생명주기 프로세스

Software Research and Development Process :

Part 3 - Life Cycle Process

본 문서에 대한 저작권은 TTA 에 있으며, TTA 와 사전 협의 없이 이 문서의 전체 또는 일부를 상업적

목적으로 복제 또는 배포해서는 안 됩니다.

Copyrightⓒ Telecommunications Technology Association 2014. All Rights Reserved.


TTAK.OT-11.0018-Part3 i

서 문

1. 표준의 목적

본 표준은 연구 개발사업을 효율적이고 체계적으로 수행하기에 적합한 생명주기

프로세스를 제공하기 위함이다.

2. 주요 내용 요약

본 표준은 요구 사항 개발, 설계, 구현, 통합시험, 시스템시험 등 5 종의 프로세스로

구성되어 있다. 각 프로세스는 크게 요약, 프로세스 활동, 프로세스 적용으로 기술된다.

3. 표준 적용 산업 분야 및 산업에 미치는 영향

본 표준은 연구 개발사업에 적합한 생명주기 프로세스 및 활동들을 규정하여, 연구

개발사업을 효율적이고 체계적으로 수행할 수 있도록 해줄 것으로 기대한다.

4. 참조 표준(권고)

4.1. 국외 표준(권고)

- CMMI Version1.3, CMU-SEI, 2010.11.

- IEEE 829, ‘소프트웨어 시험 문서 표준’

- IEEE 830, ‘소프트웨어 요구 사항정의서 표준’

- IEEE 1008, ‘소프트웨어 단위 시험 표준’

- IEEE 1016, ‘소프트웨어 설계 기술서 표준’

4.2. 국내 표준

- 해당 사항 없음.


TTAK.OT-11.0018-Part3 ii

5. 참조 표준(권고)과의 비교

5.1. 참조 표준(권고)과의 관련성

본 표준은 CMMI V1.3 의 프로세스 내용을 참조하여 R&D 사업에 특화시켜 개발하였다.

5.2. 참조한 표준(권고)과 본 표준의 비교표

TTAK.OT-11.0018-Part3 CMMI V1.3 비고

1. 개요 - 추가

2. 표준의 구성 및 범위 - 추가

3. 참조 표준 (권고) - 추가

4. 용어정의 - 추가

5. 요구 사항 개발 프로세스 Requirements

Development 참조

6. 설계 프로세스 Technical Solution 참조

7. 구현 프로세스 Technical Solution 참조

8. 통합시험 프로세스 Verification 참조

9. 시스템시험 프로세스 Validation 참조

6. 지식 재산권 관련 사항

본 표준의 ‘지식 재산권 확약서’ 제출 현황은 TTA 웹사이트에서 확인할 수 있다.

※본 표준을 이용하는 자는 이용함에 있어 지식 재산권이 포함되어 있을 수 있으므로,

확인 후 이용한다.

※본 표준과 관련하여 접수된 확약서 이외에도 지식 재산권이 존재할 수 있다.

7. 시험 인증 관련 사항

7.1. 시험 인증 대상 여부



TTAK.OT-11.0018-Part3 iii

7.2. 시험 표준 제정 현황


8. 표준의 이력 정보

8.1. 표준의 이력

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

제 1 판 2014.12.17. 제정

TTAK.OT-11.0018-Part3

8.2. 주요 개정 사항



TTAK.OT-11.0018-Part3 iv

Preface

1. Purpose of Standard

This recommendation describes the process necessary to perform the R&D project

efficiently and systematically.

2. Summary of Contents

This recommendation details the requirements of the development design, implementation,

integration testing and system testing processes to perform the R&D project. An overview

of the procedural activity and the deployment of each process is described.

3. Applicable Fields of Industry and its Effect

This recommendation specifies the process for implementing the R&D project; as a result,

the R&D project can be performed efficiently and systematically.

4. Reference Standards(Recommendations)

4.1. International Standards(Recommendations)


- IEEE 829, “SW Test Standard”

- IEEE 830, “SW Requirement Definition Standard”

- IEEE 1008, “SW Unit Test Standard”

- IEEE 1016, “SW Design Standard”

4.2. Domestic Standards

- None


TTAK.OT-11.0018-Part3 v

5. Relationship to Reference Standards(Recommendations)

5.1. Relationship of Reference Standards(Recommendations)

This Recommendation refers to the CMMI V1.3.

5.2. Differences between Reference Standard(Recommendation) and this Standard

TTAK.OT-11.0018-Part3 CMMI V1.3 Remarks

1. Introduction - Addition

2. Scope of this standard - Addition

3. Reference Standards - Addition

4. Terms and Definitions - Addition

5. Requirements

Development Process Requirements Development Reference

6. Design Process Technical Solution Reference

7. Implementation Process Technical Solution Reference

8. Integration Test Process Verification Reference

9. System Test Process Validation Reference

6. Statement of Intellectual Property Rights

IPRs related to the present document may have been declared to TTA. The information

pertaining to these IPRs, if any, is available on the TTA Website.

No guarantee can be given as to the existence of other IPRs not referenced on the TTA

website.

And, please make sure to check before applying the standard.

7. Statement of Testing and Certification

7.1. Object of Testing and Certification


TTAK.OT-11.0018-Part3 vi

- None

7.2. Standards of Testing and Certification

- None

8. History of Standard

8.1. Change History

Edition Issued date Outline

The 1st edition 2014.12.17. Established

TTAK.OT-11.0018-Part3

8.2. Revisions

- None


TTAK.OT-11.0018-Part3 vii

목 차

1. 개 요 ································································································· 1

2. 표준의 구성 및 범위 ·············································································· 1

3. 참조 표준(권고) ··················································································· 1

4. 용어 및 약어 정의 ················································································· 1

5. 요구 사항 개발 프로세스 ········································································· 4

5.1. 개요 ···························································································· 4

5.2. 요구 사항 개발 활동 ········································································ 6

5.3. 요구 사항 개발 적용 ········································································ 9

6. 설계 프로세스 ···················································································· 10

6.1. 개요 ·························································································· 10

6.2. 설계 활동 ··················································································· 12

6.3. 설계 적용 ··················································································· 14

7. 구현 프로세스 ···················································································· 15

7.1. 개요 ·························································································· 15

7.2. 구현 활동 ··················································································· 16

7.3. 구현 적용 ··················································································· 17

8. 통합시험 프로세스 ··············································································· 18

8.1. 개요 ·························································································· 18

8.2. 통합시험 활동 ·············································································· 20

8.3. 통합시험 적용 ·············································································· 22

9. 시스템시험 프로세스 ············································································ 23

9.1. 개요 ·························································································· 23


TTAK.OT-11.0018-Part3 viii

9.2. 시스템시험 활동 ··········································································· 24

9.3. 시스템시험 적용 ··········································································· 26


TTAK.OT-11.0018-Part3 ix

Contents

1. Introduction ························································································· 1

2. Constitution and Scope ··········································································· 1

3. Reference Standards(Recommendations) ···················································· 1

4. Terms and Abbreviation Definitions ····························································· 1

5. Requirements Development Process ··························································· 4

5.1. Overview ······················································································ 4

5.2. Requirements Development Activity ······················································ 6

5.3. Requirements Development Deployment ················································ 9

6. Design Process ··················································································· 10

6.1. Overview ···················································································· 10

6.2. Design Activity ············································································· 12

6.3. Design Deployment ······································································· 14

7. Implementation Process ········································································ 15

7.1. Overview ···················································································· 15

7.2. Implementation Activity ··································································· 16

7.3. Implementation Deployment ···························································· 17

8. Integration Test Process ········································································ 18

8.1. Overview ···················································································· 18

8.2. Integration Test Activity··································································· 20

8.3. Integration Test Deployment ····························································· 22

9. System Test Process ············································································ 23

9.1. Overview ···················································································· 23


TTAK.OT-11.0018-Part3 x

9.2. System Test Activity ······································································· 24

9.3. System Test Deployment ································································· 26


TTAK.OT-11.0018-Part3 1

소프트웨어 연구 개발 프로세스 : 제3부 - 생명주기 프로세스

(Software Research and Development Process :

Part 3 - Life Cycle Process)

1. 개요

본 표준은 연구 개발 사업을 효율적이고 체계적으로 수행할 수 있도록 생명주기

프로세스의 활동들과 프로세스 적용 시 고려하여야 할 내용을 기술하고 있다.

2. 표준의 구성 및 범위

본 표준은 요구 사항 개발, 설계, 구현, 통합 시험, 시스템 시험 등 5 종의 프로세스로

구성되어 있다. 각 프로세스는 크게 요약, 프로세스 활동, 프로세스 적용으로 기술된다.

3. 참조 표준(권고)


- IEEE 829, ‘소프트웨어 시험 문서 표준’

- IEEE 830, ‘소프트웨어 요구 사항정의서 표준’

- IEEE 1008, ‘소프트웨어 단위 시험 표준’

- IEEE 1016, ‘소프트웨어 설계 기술서 표준’

4. 용어 및 약어 정의

4.1. 용어 정의

4.1.1. 검증(verification)

특정 요구 사항을 만족시키고 있음을 객관적으로 증명하기 위하여 시험을 수행하는

것



4.1.2. 동료 검토(peer review)

해결해야 할 결함을 식별하기 위해 업무 산출물을 개발하는 동안 수행되는

활동으로서, 동료와 함께 수행하는 것을 ‘동료 검토(peer review)’, 외부의 사람들과

함께 수행하는 것을 ‘합동 검토(joint review)’라고 하기도 함

4.1.3. 사업

연구원이 출연 또는 용역을 위탁한 정부, 산업계 또는 특정인 등과 협약(협정,

계약)한 과제를 말하며 협약과제라고도 함

4.1.4. 사업책임자

연구협약(계약)에 의하여 사업(협약과제)을 수행 관리하는 책임자

4.1.5. 사용자 요구 사항(user requirements)

고객의 요구와 기대를 고객이 이해할 수 있는 용어를 사용하여 요구 사항으로 변환한

것으로서 고객과의 합의가 반드시 이루어져야 함

4.1.6. 산출물(work product)

각 프로세스에서 산출되는 가공물을 말하며, 산출물에는 파일, 문서, 제품의 일부,

서비스, 프로세스 등이 될 수 있음

4.1.7. 시스템 요구 사항(system requirements)

시스템 요구 사항은 사용자 요구 사항으로부터 유도하는 것으로 제품의 기능적,

성능적, 물리적 특성을 포함하여 시스템에 요구되는 성능, 제약 사항 및 기타 상세한

내용을 서술한 것임



4.1.8. 시정 조치(corrective action)

발견된 부적합 사항 또는 기타 바람직하지 않은 상황의 근본 원인을 제거하여 재발을

방지하기 위한 조치

4.1.9. 요구 사항(requirements)

명시적인 요구(needs) 또는 기대(expectation), 일반적으로 묵시적이거나 의무적인

요구 또는 기대

4.1.10. 확인(validation)

의도된 사용 요구 사항을 만족시키고 있음을 객관적으로 증명하기 위하여 시험을

수행하는 것

4.1.11. 이해 당사자(stakeholder)

시스템 그 자체 또는 그들의 요구와 기대를 만족하는 특성들을 시스템이 갖고

있는지에 대한 권한이나 자격 또는 소유권을 가진 개인이나 단체를 말하며,

일반적으로 출연처, 사업참여자, 외주 기관, 고객, 최종 사용자 등 시스템과 관련된

모든 사람들이 포함될 수 있음

4.1.12. 절차(procedure)

활동 또는 프로세스를 수행하기 위하여 규정된 방식

4.1.13. 추적성(traceability)

고려 대상에 있는 것의 이력, 적용 또는 위치를 추적하기 위한 능력



4.1.14. 품질 보증(quality assurance)

개발되는 연구결과물 및 개발 과정이 품질 측면에서 충분한 신뢰성을 갖고 있다는

것을 보증하기 위하여 미리 계획된 체계적인 활동을 말함

4.1.15. 프로세스(process)

입력을 출력으로 변환시키는 상호 관련되거나 상호 작용하는 활동의 조합

4.1.16. 형상 관리(configuration management)

시스템 형상 요소의 기능적 특성이나 물리적 특성을 문서화하고 그들 특성의 변경을

관리하며, 변경의 과정이나 실현 상황을 기록/보고하여 지정된 요건이 충족되었다는

사실을 검증하는 것, 또는 그 과정

4.2. 약어

CMMI Capability Maturity Model Integration

MD Man Day

RD Requirements Development

DE Design

IM Implementation

IT Integration Test

ST System Test

5. 요구 사항 개발 프로세스

5.1. 개요

5.1.1. 목적

사업수행계획서를 바탕으로 참여 기업, 고객 및 기술 이전 업체 등의 요구 사항을

취합하여 사용자 요구 사항을 도출하고 이를 충족시키기 위해 시스템이 가져야 할 기능이나



특성을 정의하기 위함이다.

5.1.2. 시작 조건

[시작 기준]

사업수주 프로세스에서 사업수행계획서가 확정되거나, 요구 사항 개발 계획(담당자 및

일정)이 수립된다.

[입력물]

사업수행계획서 등

5.1.3. 활동도

(그림 5-1) 요구 사항 개발 프로세스 활동도

5.1.4. 확인

- 이해 당사자들이 동료 검토를 통하여 요구 사항 정의서의 내용을 확인한다.



- 품질 보증 담당자가 QA 검토를 통하여 프로세스 수행 여부를 확인한다.

5.1.5. 종료 조건

[종료기준]

요구 사항 정의서가 승인되고 요구 사항 추적표가 완료된다.

이해 당사자들이 마일스톤 점검 등을 통해 다음 단계로의 진행을 합의한다

[출력물]

사용자요구사항목록, 사용자요구사항정의서, 요소기술분석서,

시스템요구사항정의서, 시스템요구사항명세서, 요구사항추적표

5.1.6. 측정지표

- 투입 공수: 요구 사항정의 활동에 투입된 공수(MD)

- 요구 사항 수: 요구 사항 개발 프로세스를 통하여 정의된 요구 사항 건수

- 요구 사항 개발 단계의 결함밀도: 동료 검토를 통해 발견된 결함 밀도

5.2. 요구 사항 개발 활동

5.2.1. 사용자 요구 사항 도출(RD1 : Requirements Development 1)

요구 사항정의담당자는 획득된 요구(needs)와 사업수행계획서를 기반으로 요구 사항

제공자로부터 사용자 요구 사항을 도출하여 사용자요구사항목록을 작성한다.

� 요구 사항제공자로는 출연처, 공동연구기관, 시스템의 잠재사용자, 개발자 및 시험

담당자 등이 될 수 있다.

� 사용자요구사항목록은 RD2의 사용자요구사항정의서에 포함될 수 있다.

5.2.2. 사용자 요구 사항 분석 및 정의 (RD2)

요구 사항정의 담당자는 도출된 사용자 요구 사항과 요소기술을 분석하여 사용자요구

사항정의서를 작성한다.



� 사용자요구사항정의서 작성 시 시스템에서 요구되는 기능 및 특성들은 다음의

방법들을 통해 정의된다.

� 시스템의 운용 개념과 시나리오를 분석

� 시스템 프로토타입, 기능 및 성능 시뮬레이션, 유스 케이스, 혹은 모델링을 통하여

요구 사항의 타당성 및 완전성을 분석

� 관련 개발 담당자와의 협의를 통해 시스템 구성 요소별 요구 사항을 도출

� 실현 불가능한 요구 사항, 시스템 외부 인터페이스 및 시스템 제약사항을 분석

� 요구 사항 정의 담당자는 실현 불가능한 요구 사항에 대해 이해 당사자의 합의를 얻어

요구 사항으로부터 제외한다.

� 사용자 요구 사항과 관련된 다양한 요소기술에 대해 조사하고 분석한 결과는

요소기술분석서로 별도 작성할 수 있다.

� 사용자요구사항정의서와 RD3의 시스템요구사항정의서는 하나의 파일로 작성될 수

있다.

5.2.3. 시스템 요구 사항 정의 (RD3)

요구 사항정의담당자는 사용자 요구 사항 중 실현 가능한 사용자 요구 사항을 개발자의

관점에서 비기능적, 기능적인 항목별로 가시화 및 계량화하여 시스템요구사항정의서를

구체적으로 작성하고, 필요시 각 시스템 요구 사항을 상세화하여 시스템요구사항명세서를

작성한다.

� 사업책임자는 작성된 시스템요구사항정의서에 대해 동료 검토를 수행한다.

� 요구 사항의 가시화 및 계량화란 해당 요구 사항이 만족되거나 달성되었음을 측정

또는 확인할 수 있는 수준으로 표현하는 것을 뜻한다.

� 시스템요구사항정의서에는 전체 시스템의 구조도를 포함시켜 서브시스템을 표시하고,

서브시스템 별로 요구 사항을 분류하여 정의할 수 있다.



� 요구 사항을 정의할 때에는 요구 사항의 추적 및 관리를 위해 요구 사항 항목별로

고유의 식별자를 부여한다.

� 요구사항정의서를 검토할 때에는 요구 사항 정의 담당자, 요구 사항 관리 담당자,

개발자, 사업책임자 그리고 공동 연구 기관 등이 참여할 수 있다.

� 요구 사항정의서는 다음과 같은 특성을 가져야 한다.

완전성(completeness) 사용자의 요구 사항이 누락 없이 작성되어야 함

일관성(consistency) 사용자 요구 사항 내부 혹은 사용자 요구 사항 간에

불일치가 없어야 함

정확성(correctness) 사용자요구 사항에서 제시된 모든 기능이 시스템에서

만족되어 사용자 요구를 충족시켜야 함

테스트 용이성

(testability)

사용자 요구 사항에서 제시된 항목들은 테스트에

의해서 검증 가능해야 함

명확성(unambiguity) 사용자 요구 사항의 기술은 애매모호함 없이 명확하게

기술되어야 함

설계와의 독립성

(design-free)

사용자 요구 사항 정의로 인해 설계 대안에 제약을

주어서는 안됨

전달성(communicability)

사용자 요구 사항은 명시적으로 기술되어 이해가

용이하도록 하고, 애매 모호한 점이 없어 의사전달이

쉬워야 함

모듈화 및 변경에 대한

견고성

(modularity/

change robustness)

사용자 요구 사항의 작성시에 새로운 항목을 추가하고,

기존 항목을 수정 및 변경할 때 다른 부분에 커다란

영향을 미치지 않도록 기술되는 항목들이 구조화되어야

함

필요성(necessity) 기술된 요구 사항들은 사용자 요구 사항의 목적에

부합하여 원래의 사용자 요구 목적에 기여해야 함

5.2.4. 요구 사항 정의서 합의 및 승인 (RD4)

이해 당사자들은 마일스톤 점검 등을 통해 확정된 요구사항정의서에 대해 합의하고,



사업책임자의 승인을 받는다.

� 사업의 특성에 따라 요구사항정의서의 합의는 운영위원회 회의 등을 통하여 이루어질

수 있다.

5.2.5. 추적성 유지 (RD5)

요구 사항 정의 담당자는 사용자 요구 사항 및 시스템 요구 사항 간의 상호관계를

바탕으로 요구사항추적표를 작성하여 요구 사항에 대한 추적성을 보장한다.

� 요구 사항에 대한 추적성은 시스템에 대한 유효성을 확인(validation)하고자 할 때

유용하게 활용된다.

5.3. 요구 사항 개발 적용

5.3.1. 조정 지침

� 특정 방법론(Rational Unified Process 등)을 사용하여 요구 사항을 정의하는 경우

해당 방법론에서 제공하는 활동, 도구 및 기법을 활용하여 요구 사항을 정의할 수

있다.

5.3.2. 교육 및 훈련

� 요구 사항정의담당자, 사업책임자는 요구 사항 개발 프로세스에서의 책임 및 권한을

숙지하여야 한다.

� 사업과 관련된 모든 사업참여자는 정의된 사용자 요구 사항에 대해 숙지하여야 한다.

� 요구 사항정의서는 IEEE 830, IEEE1233을 참고한다.

5.3.3. 도구 및 장비




5.3.4. 관련 프로세스

� 사업수주 프로세스: 합의된 사업수행계획서를 바탕으로 요구 사항을 개발한다.

� 요구 사항관리 프로세스: 정의된 사용자 요구 사항은 요구 사항관리 프로세스에서

양방향 추적성이 관리되고 실제 구현 상태가 모니터링된다.

� 설계 프로세스: 요구 사항정의서는 설계 프로세스의 입력이 된다.

� 형상 관리 프로세스: 요구 사항 개발 프로세스의 결과물은 형상 관리항목으로

관리된다.

� 동료 검토 프로세스: 요구 사항 개발 프로세스의 주요 결과물은 동료 검토를 통하여

검증된다.

6. 설계 프로세스

6.1. 개요

6.1.1. 목적

요구 사항 개발 프로세스에서 작성된 요구사항정의서를 개발자 관점에서 분석하여 개발

시스템의 기능, 성능 및 구조를 정의하고, 시스템을 하위 계층 구조로 분해하여 이들의 기능

및 상호 관계를 정의하기 위함이다.

6.1.2. 시작 조건

[시작 기준]

요구 사항 개발 프로세스가 완료되거나, 설계 일정이 수립되고 담당자가 정해진다.

[입력물]

시스템요구사항정의서, 시스템요구사항명세서



6.1.3. 활동도

(그림 6-1) 설계 프로세스 활동도

6.1.4. 확인

- 이해 당사자들이 동료 검토를 통하여 작업 산출물의 내용을 확인한다.

- 품질 보증 담당자가 QA검토를 통하여 프로세스 수행 여부를 확인한다.

6.1.5. 종료 조건

[종료기준]

설계서가 확정되고 요구사항추적표가 작성된다.

이해 당사자들이 마일스톤 점검 등을 통해 다음 단계로의 진행을 합의한다.

[출력물]

설계서(시스템, 서브시스템, 컴포넌트), 요구사항추적표



6.1.6. 측정 지표

- 투입 공수: 시스템 설계 활동에 투입된 공수(MD)

- 설계 단계의 결함밀도: 동료 검토를 통해 발견된 결함 밀도

- 단계별 기능수: 설계 단계에서 정의된 기능수

6.2. 설계 활동

6.2.1. 설계 항목 도출 (DE1 : Design 1)

설계 담당자는 요구사항정의서에 정의되어 있는 각각의 시스템 요구 사항 항목들에

대하여 개발자 관점에서 분석하여 시스템 설계 항목을 도출한다.

� COTS, 상용 제품 또는 재사용과 같이 구매 또는 비개발적 항목이 포함된 경우 대체

솔루션에 대한 분석 및 평가를 통하여 도출된 설계항목을 포함하여야 한다.

6.2.2. 구성 요소 분할 및 구조설계 (DE2)

설 계담당자는 사용자 요구 사항 및 시스템 요구 사항으로부터 도출된 시스템 설계항목을

기반으로 시스템의 전체적인 구조를 결정하고, 이를 하위 구성요소로 분할한 후 서브시스템,

모듈 혹은 블록 단위로 내부 구조를 설계한다.

� 시스템 구조도 및 서브시스템 구조도는 시스템설계서 또는 서브시스템설계서에

포함된다.

� 시스템의 하부 구성 단위의 명칭은 과제마다 다르게 정의하여 사용할 수 있으며, 예를

들어 시스템은 서브시스템(subsystem)-블록(block)-유닛(unit)의 계층 구조를 가질 수

있다.

� 서브시스템이란 시스템의 기능을 공통의 속성, 하드웨어의 물리적 위치 등의 관점으로

구분한 것으로서, 독립적으로 기능이 가능한 시스템의 부분집합이다. 서브시스템으로의

분해기준은 다음과 같다.



� 타 서브시스템의 영향을 최소한으로 받는 독립성이 매우 강한 경우

� 조직 구성의 기준이 되는 경우

� 개발 완료 후 독립적인 시험이 가능한 경우

� 각 서브시스템이 하나의 제품이 될 수 있는 경우

6.2.3. 인터페이스 정의 (DE3)

설계 담당자는 시스템과 외부와의 인터페이스, 시스템 구성 요소 간의 인터페이스를

정의한다.

� 설계 결과, 정의되는 각각의 인터페이스는 시스템설계서, 서브시스템설계서 또는

블록설계서에 포함된다.

� 인터페이스 정의의 일관성 확보를 위하여 사전에 명명 규칙(Naming convention)을

확정하여 사용할 수 있다.

6.2.4. 동작 설계 및 확인 (DE4)

설계 담당자는 정의된 기능 및 성능 요구 사항 각각에 대하여 구성요소의 기능, 성능,

구조 및 상호관계를 측정되거나 확인될 수 있는 수준으로 표현하여 상세 설계를 실시한다.

� 동작 설계는 시스템설계서, 서브시스템설계서 또는 블록설계서에 포함되며, 작성

완료된 결과물은 동료 검토를 통하여 확인한다.

� 설계 담당자와 통합 시험 담당자는 시스템 설계 시 통합 시험에서 사용될 시험

시나리오를 수립할 수 있으며, 통합시험계획서를 작성할 수도 있다.

6.2.5. 추적성 유지 (DE5)

요구 사항관리담당자는 상위/하위설계서가 승인된 이후에 요구 사항정의서의 시스템 요구

사항과 상위/하위설계서에 정의된 설계 항목간의 추적성 유지를 위한 요구 사항추적표를

작성한다.



� 요구사항추적표 작성 시 누락된 부분이 있는 경우 해당 산출물을 수정한 후 요구

사항추적표를 보완한다.

6.3. 설계 적용

6.3.1. 조정 지침

� 시스템의 하위 구성 단위의 명칭은 사업마다 다르게 정의하여 사용할 수 있다.

(예: 시스템, 서브시스템, 컴포넌트, 블록, 유니트 등)

� 설계 단계는 사업 성격을 고려하여 정의할 수 있다.

6.3.2. 교육 및 훈련

� 시스템설계 담당자, 과제책임자, 사업책임자는 설계 프로세스에서의 책임 및 권한을

숙지하여야 한다.

� 사업과 관련된 모든 사업참여자는 정의된 설계 내용을 대해 숙지하여야 한다.

� 설계 담당자는 시스템이 차지하는 기능과 구조 그리고 시스템 운용 개념 및

시나리오 등을 이해하여야 하고, 관련 설계 도구와 기법을 숙지하여야 한다.

� SW 설계 기술서는 IEEE 1016, IEEE 1016.1을 참고한다

6.3.3. 도구 및 장비

� UML

� CASE Tool


� 요구 사항 개발 프로세스: 요구 사항정의서는 설계 프로세스의 입력이 된다.

� 구현 프로세스: 설계서는 구현프로세스의 입력이 된다.

� 형상 관리 프로세스: 설계 프로세스의 주요 결과물은 형상항목으로 관리된다.

� 동료 검토 프로세스: 설계 프로세스의 주요 결과물은 동료 검토를 통하여 검증된다.



7. 구현 프로세스

7.1. 개요

7.1.1. 목적

승인된 상위/하위설계서를 기반으로 하여 실제 연구 개발 결과물을 구현하기 위함이다.

7.1.2. 시작 조건

[시작 기준]

설계 프로세스가 완료되거나, 구현 일정이 정의되고 담당자가 정해진다.

[입력물]

설계서(시스템, 서브시스템, 컴포넌트)

7.1.3. 활동도

(그림 7-1) 구현 프로세스 활동도



7.1.4. 확인

- 이해 당사자들이 동료 검토를 통하여 작업산출물의 내용을 확인한다.


7.1.5. 종료 조건

[종료기준]

상위/하위설계서에 정의된 모든 구성 요소가 구현되고 시험된다.


[출력물]

구현 결과물, 단위시험 결과물, 요구사항추적표

7.1.6. 측정 지표

- 투입 공수: 구현 활동에 투입된 공수(MD)

- 구현 단계의 결함밀도: 동료 검토를 통해 발견된 결함 밀도

7.2. 구현 활동

7.2.1. 구현 (IM1 : Implementation 1)

개발자는 검토 완료된 상위/하위설계서를 기반으로 각각의 구성 요소를 구현하여 구현

결과물을 생성한다.

� 개발자는 구성 요소별 구현 특성에 따라 적절한 도구를 선정하여 활용할 수 있다.

구현된 구성 요소는 동료 검토를 실시할 수 있다.

� 개발자가 공개 소프트웨어 소스를 활용하였을 경우 해당 소프트웨어의 라이선스를

확인하고 사업의 정책과 일치하도록 하여야 한다. 필요시, 라이선스 검증 도구를

활용할 수 있다.



7.2.2. 단위 시험 (IM2)

개발자는 구현 단계에서 개발된 하드웨어 및 소프트웨어가 상위/하위설계서에서 정의된

대로 개발되었는가를 검증하기 위하여 단위 시험을 수행한다.

� 단위 시험은 담당 개발자가 자율적으로 수행하며, 필요 시 단위시험결과는 공식적인

산출물로 관리한다.

� 개발자는 코드 검토를 실시하거나 적절한 시험 도구를 선정하여 이용할 수도 있다.

또한 구현 결과물에 따라 상위/하위설계서를 수정, 보완하여 구현 결과물과 설계서

간의 일치성을 유지하여야 한다.

� 단위 시험 방법은 소프트웨어인 경우, Statement coverage testing, Branch coverage

testing, Predicate coverage testing, Path coverage testing, Boundary value testing,

Special value testing, Loop/Transaction/Graphic coverage testing 등이 포함될 수

있다.

7.2.3. 추적성 유지 (IM3)

개발자는 단위 시험이 완료된 후 요구 사항 담당자와 함께 시스템 상위/하위 설계 항목과

구현 결과물에 대한 요구사항추적표를 작성한다.

7.3. 구현 적용

7.3.1. 조정 지침

� 구현 결과물의 동료 검토는 사업에 따라 선택적으로 적용이 가능하다.

� 자동화된 설계 도구 사용시 구현 및 단위 시험이 하나의 활동으로 조정될 수 있다.

7.3.2. 교육 및 훈련

� 사업책임자, 개발자는 구현 프로세스에서의 책임 및 권한을 숙지하여야 한다.



� 개발자는 구현 규칙, 표준 등을 숙지하고, 필요 시 관련 교육을 이수해야 한다. (예:

Coding Standard 또는 Coding Rule 준수)

� 개발자는 구현 도구 및 기법과 단위 시험 방법을 숙지하여야 한다.

� 단위시험은 IEEE 1008을 참고한다.

7.3.3. 도구 및 장비

� C Compiler, CASE 도구

� Verilog-XL simulator, System C, Design Compiler, Synplicity

� Allegro, SpectraQuest, Schematic Capture, HSPICE

� Scenario definition and management tools


� 설계 프로세스: 설계서는 구현 프로세스의 입력이 되며, 그 내용이 구현되고

검증된다.

� 통합시험 프로세스: 구현 프로세스의 결과물은 통합시험 프로세스의 입력이 된다.

� 형상 관리 프로세스: 구현 프로세스의 주요 결과물은 형상 항목으로 관리된다.

� 동료 검토 프로세스: 구현 프로세스의 주요 결과물은 동료 검토를 통하여 검증된다.

8. 통합 시험 프로세스

8.1. 개요

8.1.1. 목적

개별적으로 검증된 시스템 구성물들이 성공적으로 통합되어 기능적으로 만족하는지

여부를 검증하기 위함이다.

8.1.2. 시작 조건

[시작 기준]



구현 프로세스가 완료되거나, 통합 시험 계획(담당자, 일정)이 수립된다.

[입력물]

구현결과물

8.1.3. 활동도

(그림 8-1) 통합시험 프로세스 활동도

8.1.4. 확인

- 이해 당사자들이 동료 검토를 통하여 작업 산출물의 내용을 확인한다.


8.1.5. 종료 조건

[종료기준]

구현결과물이 통합되고 통합시험을 통해 검증된다


[출력물]

통합시험계획서, 통합시험 Test case, 시스템통합환경, 통합시험결과서,

통합시스템, 결함보고서, 사용자 매뉴얼



8.1.6. 측정 지표

- 투입 공수: 통합 시험 활동에 투입된 공수(MD)

- 시정조치율: 조치 완료된 결함 수 /발견된 결함 수

8.2. 통합 시험 활동

8.2.1. 통합시험계획서 작성 (IT1 : Integration Test 1)

통합 시험 담당자는 통합시험계획서와 통합시험 테스트 케이스(test case)를 작성하고,

동료 검토를 통하여 확인한다.

� 통합시험계획서에는 시험 대상 시스템의 범위 및 대상, 시험 일정, 시험 전략, 시험

절차, 시험 환경 및 시험 결과에 대한 판정 기준, 완료 기준 등이 포함될 수 있다.

� 시험 전략에는 빅뱅 방식, 버텀-업(bottom-up), 탑-다운(top-down) 등이 있을 수

있다.

� 완료 기준의 예로는 ‘통합 대상물 간의 인터페이스는 최소 한번 이상 시험되어야 함’

등이 있을 수 있다.

8.2.2. 통합시험 환경 구축 (IT2)

통합 시험 담당자는 통합시험계획서에 따라 시스템을 시험하기 위한 시스템 통합 환경을

구축한다.

� 통합시험 환경 구축은 다음 작업을 포함한다.

� 통합시험을 위한 프로그램 작성

� 통합시험을 위한 장비 및 도구 구축

� 통합시험에 필요한 담당자 교육



8.2.3. 구성요소 통합 (IT3)

통합 시험 담당자는 통합시험계획서에 따라 개발 완료되고, 검증된 구현물을 시험 전략에

따라 통합하여 하나의 시스템을 구축한다.

8.2.4. 통합시험 수행 (IT4)

통합 시험 담당자는 오류 수정이나 기능 변경으로 인해 코드가 수정되는 경우 수정된

부분에 대한 재시험뿐 아니라 수정된 코드로 인해 영향을 받을 수 있는 다른 기능이나 해당

기능의 전 단계까지 회귀 시험을 수행한다.

통합 시험 담당자는 통합시험계획서 및 통합시험 테스트 케이스(test case)에 명시된 일정

및 절차에 따라 정의된 시험 항목을 시험한 후, 결함이 발생한 경우 결함보고서를 작성하여

이를 해당 개발자에게 전달하여 발생된 결함을 해결하도록 한다.

해당 개발자는 해결 요청을 받은 결함을 해결하고, 그 해결 내용과 결과물을 통합 시험

담당자에게 전달한다. 통합 시험 담당자는 결함이 해결된 결과물을 재시험으로 검증한다.

� 결함보고서는 통합시험결과서에 첨부될 수 있다.

� 결함보고서는 시험 환경 및 도구, 시험 조건 및 결함 내용, 결함 원인 등을 포함할 수

있다.

8.2.5. 통합시험 결과서 작성 (IT5)

통합 시험 담당자는 통합시험의 결과가 통합시험계획서에 정해진 수준에 도달한 경우

통합시험결과서를 작성하고, 동료 검토를 통하여 확인한다.

� 통합시험결과서에는 시험항목에 대한 통과 여부, 완료 기준 값과 충족 여부를

포함시키고, 결함 내용에 대한 분석을 통해 결함의 재발을 방지할 수 있도록 한다.

8.2.6. 사용자 매뉴얼 작성 (IT6)



통합 시험 담당자는 사용자매뉴얼을 작성하고, 동료 검토를 통하여 확인한다.

8.3. 통합시험 적용

8.3.1. 조정 지침

� 소규모사업의 경우 통합시험은 시스템시험과 함께 수행할 수 있다.

� 통합시험의 결함은 관리되어야 한다.

8.3.2. 교육 및 훈련

� 통합 시험 담당자는 통합시험 수행에 관련된 지식을 교육받아야 한다.

� SW 시험 문서는 IEEE 829, 단위 시험은 IEEE 1008을 참고한다.

8.3.3. 도구 및 장비

� Redmine (결함관리용)

� SVN

� 통합시험계획서에 정의된 도구 및 장비


� 구현 프로세스: 구현 프로세스의 결과물은 통합시험 프로세스의 입력이 된다.

� 형상 관리 프로세스: 통합시험 프로세스 과정 중 발생되는 결함과 수정사항은 형상

관리 프로세스를 따른다.

� 동료 검토 프로세스: 통합시험 프로세스의 주요 결과물은 동료 검토를 통하여

검증된다.

� 설계 프로세스: 통합시험 계획서는 시스템 설계서를 기반으로 작성된다.

� 시스템시험 프로세스: 통합시험 프로세스를 통해 검증된 시스템 단위 구현물은

시스템 시험 프로세스의 입력물로 사용된다.



9. 시스템시험 프로세스

9.1. 개요

9.1.1. 목적

통합시험 프로세스로 검증된 통합시스템을 대상으로 요구사항정의서에 기술되어 있는

시스템 요구 사항에 대한 시스템 구현물의 만족 여부를 확인하기 위함이다.

9.1.2. 시작 조건

[시작 기준]

통합시험 프로세스가 완료되거나 시스템시험 계획(담당자, 일정)이 수립된다.

[입력물]

시스템요구 사항정의서, 통합시스템

9.1.3. 활동도

(그림 9-1) 시스템시험 프로세스 활동도



9.1.4. 확인

- 이해 당사자들이 동료 검토를 통하여 작업산출물의 내용을 확인한다.


9.1.5. 종료 조건

[종료기준]

시스템시험을 통해 시스템요구 사항이 확인되고 검증된 구현결과물을 확정한다.


[출력물]

시스템시험계획서, 시스템시험 test case, 시스템시험환경, 결함보고서,

시스템시험결과서, 검증된 시스템구현물, 시험결과분석보고서

9.1.6. 측정 지표

- 투입 공수: 시스템시험 활동에 투입된 공수(MD)

- 시정조치율: 조치 완료된 결함 수/발견된 결함 수

9.2. 시스템시험 활동

9.2.1. 시스템시험계획서 작성 (ST1 : System Test 1)

시스템 시험 담당자는 시스템시험계획서를 작성하고 사업책임자의 승인을 받아

관련자에게 공지한다.

� 시스템시험계획서에는 시스템시험 대상 시스템의 범위 및 대상, 시스템시험 환경

(하드웨어 환경, 소프트웨어 환경, 시험 도구) 및 시스템 시험 결과에 대한 판정 기준

등을 포함할 수 있다.

� 시스템시험계획서를 동료 검토하여 계획된 대로 시험이 가능한지 검토한다.



� 시스템시험계획서와 요구사항정의서에서 정의한 시스템요구사항 간의 일치성은 요구

사항추적표를 통하여 확인한다.

9.2.2. 시스템시험 환경 구축 (ST2)

시스템 시험 담당자는 시스템시험계획서에 따라 시험환경을 구축하고 시스템시험 test

case를 작성한다.

� 시스템시험 테스트 케이스(test case)는 동료 검토를 통하여 시스템요구 사항을 충분히

시험할 수 있는지 검토되어야 한다.

� 시스템시험 환경 구축은 다음 작업을 포함할 수 있다.

� 시스템시험을 위한 프로그램 작성

� 시스템시험을 위한 장비 및 도구 구축

� 시스템시험에 필요한 담당자 교육

9.2.3. 시스템시험 수행 (ST3)

시스템 시험 담당자는 시스템시험계획서 및 시스템시험 테스트 케이스(test case)에

명시된 일정 및 절차에 따라 정의된 시험 항목을 시험한 후, 결함이 발생한 경우

결함보고서를 작성하여 이를 해당 개발자에게 전달하여 발생된 결함을 해결하도록 한다.

해당 개발자는 해결 요청을 받은 결함을 해결하고, 그 해결 내용과 결과물을 시스템 시험

담당자에게 전달한다. 시스템 시험 담당자는 결함이 해결된 결과물을 재시험으로 검증한다.

� 시스템시험에는 수명(신뢰성) 시험, 성능시험 등을 포함한다.

� 반복(회귀) 시험을 포함한다.

� 결함보고서는 시스템시험결과서에 첨부될 수 있다.

� 결함보고서에는 시험 환경 및 도구, 결함 내용, 결함 원인 등을 포함할 수 있다.



9.2.4. 시스템시험결과서 작성 (ST4)

시스템 시험 담당자 및 개발자는 시스템시험의 결과가 정해진 수준에 도달한 경우

시스템시험결과서를 작성한다.

� 시스템시험결과서에는 시험 항목에 대한 통과 여부, 완료 기준 값과 충족 여부를

포함한다.

9.2.5. 시험 결과 분석 (ST5)

시스템 시험 담당자는 결함보고서를 바탕으로 시험결과분석보고서를 작성한 후 측정분석

담당자에게 전달한다.

� 결함 내용에 대한 분석을 통해 재발을 방지할 수 있도록 한다.

9.3. 시스템시험 적용

9.3.1. 조정 지침

� 시스템시험의 결함은 관리되어야 한다.

� 시스템 성능 등 실측이 어려운 경우 시뮬레이션/해석적 방법을 수행할 수 있다.

9.3.2. 교육 및 훈련

� 시스템 시험 담당자는 시스템시험 수행에 관련된 지식을 교육받아야 한다.

� SW 시험문서는 IEEE 829를 참고한다.

9.3.3. 도구 및 장비

� 시스템시험에 적합한 도구 (시스템시험 계획서에서 정의)



�


� 형상 관리 프로세스: 시스템 시험 중 발생되는 결함과 수정사항은 형상 관리

프로세스를 따른다.

� 동료 검토 프로세스: 시스템시험 테스트 케이스(test case) 등 주요 결과물은 동료

검토를 수행한다.

� 측정 분석 프로세스: 시험결과분석보고서는 측정 분석 프로세스의 입력이 된다.

� 통합 시험 프로세스: 통합 시험 프로세스를 거쳐 산출된 검증된 시스템 단위

구현물은 시스템 시험 프로세스의 입력물로 사용된다.



표준 작성 공헌자

표준 번호 : TTAK.OT-11.0018-Part3

이 표준의 제정‧개정 및 발간을 위해 아래와 같이 여러분들이 공헌하였습니다.

구분 성명 위원회 및 직위 연락처 소속사

과제 제안 정효택 소프트웨어 품질평가

프로젝트 그룹 위원 [email protected] ETRI

표준 초안 제출

오행석 소프트웨어 품질평가


정효택 소프트웨어 품질평가


박영식 소프트웨어 품질평가


함영환 소프트웨어 품질평가


표준 초안 검토

오영배 소프트웨어 품질평가

프로젝트그룹 의장 [email protected] 수원여대

외 프로젝트 그룹 위원

표준안 심의

박승민 소프트웨어/콘텐츠

기술위원회 의장 [email protected] ETRI

외 기술위원회 위원

사무국 담당

김영화 - [email protected] TTA

이혜진 - [email protected] TTA


소프트웨어 연구 개발 프로세스 : 제 3 부 - 생명주기 프로세스

(Software Research and Development Process :

Part 3 - Life Cycle Process)

발행인 : 한국정보통신기술협회 회장

발행처 : 한국정보통신기술협회

463-824, 경기도 성남시 분당구 분당로 47

Tel : 031-724-0114, Fax : 031-724-0109

발행일 : 2014.12.

T T A S t a n d a r d - cmmi version1.3, cmu-sei, 2010.11. - ieee 829, ‘소프트웨어 시험 문서 표준’ - ieee 830, ‘소프트웨어 요구 사항정의서 표준’ -

Documents