- 1 -

시스템 수명주기

프로세스 프레임워크 보고서

2005.

- 2 -

목 차목 차목 차목 차

서 론서 론서 론서 론1.1.1.1.

필요성1.1 ··········································································································· 3

시스템 공학의 정의1.2 ···················································································· 4

시스템 공학의 발전과정 주요 연구내용1.3 ·················································· 5

시스템 공학과 소프트웨어 공학1.4 ······························································· 6

시스템 공학 프로세스1.5 ················································································ 7

시스템개발 단계화1.6 ·················································································· 10

시스템 공학 표준1.7 ····················································································· 12

시스템 공학관련 표준 현황시스템 공학관련 표준 현황시스템 공학관련 표준 현황시스템 공학관련 표준 현황2.2.2.2.

시리즈2.1 MIL-STD-499 ········································································ 15

2.2 EAI 632 ··································································································· 16

2.3 IEEE 1220 ······························································································ 18

시스템 공학 표준 비교2.4 ············································································ 19

시스템 공학 표준 채택 활용 현황시스템 공학 표준 채택 활용 현황시스템 공학 표준 채택 활용 현황시스템 공학 표준 채택 활용 현황3. /3. /3. /3. /

개요3.1 ············································································································ 22

미국3.2 ············································································································ 22

일본3.3 ············································································································ 27

유럽3.4 ············································································································ 27

표준 및 가이드 분석표준 및 가이드 분석표준 및 가이드 분석표준 및 가이드 분석4. ISO/IEC 152884. ISO/IEC 152884. ISO/IEC 152884. ISO/IEC 15288

4.1 시스템공학 시스템 수명주기 프로세스 표준ISO/IEC 15288 - ············· 31

4.2 시스템공학 적용가이드ISO/IEC TR 19760 -ISO/IEC 15288 ······· 37

시스템 수명주기 프로세스 프레임워크 설계방안시스템 수명주기 프로세스 프레임워크 설계방안시스템 수명주기 프로세스 프레임워크 설계방안시스템 수명주기 프로세스 프레임워크 설계방안5.5.5.5.

시스템수명주기 프로세스 프레임워크5.1 ················································· 43

시스템수명주기 프로세스와 발주관리 지침 연계방안5.2 ······················· 48

참고문헌참고문헌참고문헌참고문헌6.6.6.6. ········································································································ 52

부록 시스템수명주기 프로세스 프레임워크부록 시스템수명주기 프로세스 프레임워크부록 시스템수명주기 프로세스 프레임워크부록 시스템수명주기 프로세스 프레임워크A :A :A :A :

부록 개정 제안 분석부록 개정 제안 분석부록 개정 제안 분석부록 개정 제안 분석B : ISO/IEC 15288 & ISO/IEC 12207B : ISO/IEC 15288 & ISO/IEC 12207B : ISO/IEC 15288 & ISO/IEC 12207B : ISO/IEC 15288 & ISO/IEC 12207

- 3 -

그 림 목 차그 림 목 차그 림 목 차그 림 목 차

그림 소프트웨어 공학과 시스템 공학< 1-1> ···················································· 6

그림 시스템공학 프로세스< 1-2> ······································································· 8

그림 미 국방성 시스템 획득수명주기 프로세스< 1-3> ································· 11

그림 시스템 공학 표준 상속도< 1-4> ····························································· 11

그림 표준< 2-1> MIL-STD-499A ······························································ 15

그림 표준< 2-2> MIL-STD-499B ······························································ 16

그림 표준< 2-3> ANSI/EIA 632 ································································· 17

그림 프로세스 관계도< 2-4> ANSI/EIA 632 ············································· 17

그림 표준< 2-5> IEEE 1220 ········································································· 18

그림 시스템 공학 프로세스< 2-6> (SEP) ······················································· 19

그림 시스템 공학 표준 비교< 2-7> ································································· 20

그림 미 국방성의 표준채택 공지< 3-1> ISO/IEC 15288 ························ 23

그림 미 국방성의 표준채택 공지< 3-2> ISO/IEC TR 19760 ··················24

그림 미 국방성의 지시문서< 3-3> Defense Acquisition System ······ 24

그림 미국의 표준< 3-4> IEEE Std 15288-2004 ···································· 25

그림 록히드마틴의 표준 개념< 3-5> LM-IEP ············································· 26

그림 을 기초로 한 비용분석 개념< 3-6> ISO/IEC 15288 ························ 26

그림 일본 표준규격협회 표준화조사 연구 개발 성과보고서< 3-7> ············ 27

그림< 3-8> 기반 영국 국방부의 획득정책 프로세스 프레임워크ISO/IEC 15288 / 28

그림 기반 스웨덴 프로세스 아키텍처< 3-9> ISO/IEC 15288 ·················· 28

그림 호주 뉴질랜드 표준< 3-10> / ISO/IEC 15288 ··································· 29

그림 표준 프로세스 구조< 4-1> ISO/IEC 15288 ·······································34

그림 과 의 관계< 4-2> ISO/IEC 15288 12207 ·········································· 36

그림 국제 표준의 사용 개념< 4-3> ···································································39

그림 시스템 수명주기 프로세스 연관관계< 5-1> ·········································· 46

그림 프로세스 활동 구성< 5-2> ······································································· 47

그림 표준과 제안방법과의 비교< 5-3> ························································· 47

그림 시스템수명주기 프로세스와 발주관리 지침 연계방안< 5-4> ············ 47

- 4 -

표 목 차표 목 차표 목 차표 목 차

표 호주 뉴질랜드 표준< 3-1> / ISO/IEC 15288 ········································· 29

표 표준 제정 경과< 4-1> ISO/IEC 15288 ················································· 32

표 과 의 관계< 4-2> ISO/IEC 15288 12207 ············································· 36

표 단계 단계의 목적 및 중요 결정 게이트< 4-3> , ······································· 37

표 기술보고서 추진 경과< 4-4> ······································································· 38

표 시스템수명주기 프로세스 프레임워크 설계방안< 5-1> ··························· 44

표 시스템 수명주기 프로세스 구성< 5-2> ······················································ 45

- 1 -

서 론1.

- 2 -

서론1.

필요성1.1

과거로부터 현재까지 소프트웨어가 하드웨어의 비중을 능가하기 시작하면서 소프트웨어

관점에서의 개발표준이 지속적으로 발전되어 왔다 현재 국내외적으로 이. ISO/IEC 12207

대세라 할 정도로 소프트웨어 개발표준으로 자리 잡고 있다 이미 정통부에서는. ISO/IEC

을 기반으로 국내 실정에 적합한 소프트웨어 개발표준을 년간의 연구를 통하여12207 2

공공부분 발주관리 표준 프로세스 지침 이라는 명칭으로 완료한 상태이다 한편 시“ S/W ” .

스템 공학관점에서 볼 때 시스템 하드웨어 을 작동시키기 위한 소프트웨어는 시스템의 한( )

구성품으로써 다루어질 수밖에 없다 예를 들면 와 같은 고속열차를 만드는 프로젝트. KTX

에서 고속열차 자체를 만드는 하드웨어공학과 소프트웨어를 만드는 공정이 조화가 되도록

함께 고려되어져야 할 것이다 그 외에도 시스템공학은 휴먼웨어를 포함한 많은 고려사항이.

필요하다.

소프트웨어의 관점이 아닌 하드웨어의 관점에서 볼 때 비행기 전투기 고속열차 등 주요, ,

하드웨어의 생명은 하드웨어 안에서 작동하는 소프트웨어가 핵심이라는 것은 이제 상식적인

사실이다 그러므로 하드웨어 제조공정을 함께 고려한 소프트웨어 개발공정의 관리는 더욱.

중요해지며 이러한 맥락에서 본 연구에서는 정통부가 선도적 차원에서 시스템공학의 중요,

성을 인식하고 기반으로 하여 국내에 적용할 수 있는 시스템공학수명주기ISO/IEC 15288

프로세스 프레임워크를 설계하였다.

본 보고서의 장에서 살펴본 바와 같이 역시 미 국방부의 표준인2 ISO/IEC 15288

시리즈에서 발전하여 등을 거쳐MIL-STD-499 EIA 632, IEEE 1220 ISO/IEC

로 발전하였다 각 표준의 특성들이 제각기 있지만 소프트웨어 수명주기 프로세스15288 .

표준인 도 개발 관점의 미 국방부의 표준에서 발전하여 획득에서부터 폐ISO/IEC 12207

기까지의 수명주기를 망라한 표준으로 발전하였듯이 도 똑같은 개념으로ISO/IEC 15288

발전하여 왔다.

본 연구는 이와 같은 노력의 일환으로 시스템 공학의 개념을 정의하고 기존의 관련 표준

들을 분석한 후 최근 제정된 을 기반으로 국내 환경에 적합한 시스템 공, ISO/IEC 15288

학 프레임워크를 개발하는데 목적이 있다 본 연구의 결과를 기반으로 프레임워크가 확정되.

면 프레임워크를 실현하기 위한 후속지침의 개발이 지속적으로 필요할 것이다 또한 본 연.

구는 을 기반으로 개발된 공공기관 발주관리 지침과 연계하여 효과적이고ISO/IEC 12207

효율적인 시스템 획득을 지원하는 프레임워크의 개발을 염두에 두었다.

- 3 -

시스템 공학의 정의1.2

시스템 공학은 분야별 경험과 학문적 배경에 따라 조금씩 다르게 정의되어 왔다 가장 앞.

서가고 있는 미국 국제시스템공학협회(INCOSE: International Council on Systems

에서도 시스템 공학을 매우 다양한 내용으로 정의하고 있다 그러나 근본적Engineering) .

으로 하향식 프로세스 수명주기중심 프로세, (top-down process,) (lie-cycle oriented)

스 그리고 기능 활동 및 조직통합, (integration of functions, activities, and

프로세스라는 측면에서 공통적인 견해를 두고 있다organizations) .

국제시스템공학협회에서는 시스템 공학을 성공적인 시스템을 개발하기 위한 종합적인“

접근방법과 수단(Systems Engineering is an interdisciplinary approach and

으로 정의하고 있다means to enable the realization of successful systems)" .

국제시스템공학협회뿐만 아니라 미 국방성 기타 표준서나 또는 여러 사람들이, NASA,

시스템 공학을 다양하게 정의하고 있지만 그 기본은 고객 및 이해당사자의 요구를 충족시,

키는 시스템을 획득함에 있다 이를 좀 더 구체적으로 살펴보면 다음 네 가지 사항으로 요.

약된다 첫째 시스템 공학은 전체 적인 관점에서 시스템 하향식 분석. , (whole) (top-down)

과 상향식 통합 접근방법으로 이루어진다 둘째 시스템 설계 개발 생산 건(bottom-up) . , , , /

설 분배 운용 유지 및 지원 폐기 및 처분 등 모든 단계에 걸친 요구사항을 초기에 도출, , , ,

하여 획득하고 운용하는 수명주기 관점에서 다루어진다 셋째 초기 시스템요건(life-cycle) . ,

식별에 더 많은 노력을 기울인다 이러한 요건은 특정설계목표(system requirements) .

와 적합한 설계기준을 제시하고 설계 프로세스에 보다 빨리 효과적인 방법으로 의사를 결정

하고 분석할 수 있도록 미리 식별되어야 한다 과거부터 이러한 초기단계 의 사. (front-end)

전준비와 분석활동이 매우 미약했다 그 결과 생산 운용단계와 같은 수명주기 후반부 활동. /

에 더 많은 노력이 필요하게 되었고 이에 따라 제품생산 이후 설계변경과 수정보완 활동이,

수 없이 이루어질 수밖에 없었다 넷째 효율적인 시스템 설계 및 개발 프로세스는 다양한. ,

학문분야 에 종사하는 전문가들의 협력활동을 통하여 요구 시스템의 설(interdisciplinary)

계목표를 달성할 수 있다는 점이다.

따라서 시스템 공학 활동은 지속적 이고 반복적 이며 협력적(continuous) (iterative)

인 방법으로 요구 목표를 수렴 해 가는 피드백(incorporate) (convergence) (feed-back)

프로세스라고 할 수 있다.

시스템 공학 피드백 루프는 시스템의 필요성과 목적을 이해하고 이를 분명하게 정의한 다

음 이를 충족시킬 수 있는 대안을 도출하고 최적형상을 선택하는 과정이다 이를 바탕으로, .

시스템 설계와 통합을 수행하고 요구시스템을 개발해 간다 반복적인 과정이란 우선 이해된.

- 4 -

목표와 정의된 시스템 요건을 상호비교 절충하여 대안형상을 도출하는 활동을 말한다 이를.

위해 시스템설계 및 통합과정에서 반복적인 인터페이스 통제 그리고 통합시스템의 실제 특,

성시험 결과와 요건 목표를 비교한 다음 요구특성과 시스템 특성 및 데이터를 반복적으로/

조정하여 최적형상을 선택하게 된다.

반복적인 활동을 통한 궁극적인 목적은 보다 효과적이고 효율적인 방법으로 고객이 제시

한 요건을 충족시키도록 함에 있다 결국 누가 더 빨리 더 적은 노력으로 요건을 보다 좋. ,

은 시스템으로 충족시키느냐 하는 점이 시스템 공학의 기본목표라고 할 수 있다.

시스템 공학의 발전과정1.3

시스템 공학 접근방법은 세기 산업혁명과 차 세계대전을 거치면서 년대 기존시19 2 1950

스템의 최적화와 시스템을 분석하기 위해 시작된 운영분석 활동에(operations research)

서 비롯된다 년대에 들어와 시스템의 효율적인 개발관리 방법으로 분업화 전문화가. 1960

도입 되었다 이와 함께 효과적인 개발관리 방법으로 수석엔지니어 제도. (chief engineer)

를 적용하면서 고전적 시스템 공학 방법이 태동되었다 그 결과로 시스템 일반이론.

시스템적 접근론 시스템개발 프로세스(general system theory), (system approach), ,

그리고 작업분할구조도 체계가 발전되기 시작했다(WBS: Work Breakdown Structure) .

이와 함께 년대 우주항공 산업을 중심으로 한 대규모 시스템개발을 통해 소수의 전1970

문 시스템 엔지니어가 배출되기 시작했고 이와 더불어 시스템 공학 관리기법 대형시스템, ,

의 복잡도 계층구조분석 기법이 생겨났다(complexity), (hierarchy structure analysis) .

그러나 년대 우주항공 산업 축소와 함께 이에 종사하던 많은 시스템 엔지니어가 중소1980

기업체로 옮겨 갔으며 이들은 소규모 제품 및 사업에 시스템 공학 기법을 적용함으로써 다

양한 여러 분야의 시스템 엔지니어가 배출되기 시작했다 시간이 지남에 따라 이들은 자기.

가 하고 있는 방법이 최적의 방법인지 아닌지 궁금하게 되었다.

그 결과 각종 표준 아키텍팅 의사결정시스템(standards), (architecting), (decision

및 지식기반 관리시스템making system) (knowledge based management system)

이 구축되었다 이러한 기법을 널리 모든 산업분야에 확산하고 그 적용사례를 함께 공유하.

기 위하여 시스템 엔지니어 모임을 조직하게 되었다.

년 범세계적인 시스템 공학 표준을 제정한 후 미국 국내의 시스템 엔지니어 전문가1992

모임으로 를 조직하였고 년에 이를 국제적인 모임으로 가 설립되었NCOSE 1995 INCOSE

다 세기로 접어들면서 시스템 공학은 시스템 형태별 모델로 발전되기 시작했다 그리고. 21 .

여러 가지 시스템 공학 컴퓨터 지원도구 를 이에 적용함으로써 모델기반 시스템 공, CASE

학 기법이 태동되기 시작했다 나아가 모(MBSE: Model Based Systems Engineering) .

델기반 획득 기법 모델링 및 시뮬레이션 기법 그리고MBA: Model Based Acquisition) , ,

- 5 -

동시공학 통합 제품 및 프로세스 개발(concurrent engineering), (IPPD: Integrated

기법으로 발전되면서 시스템 제품개발기간 단축Product and Process Development)

및 비용절감과 함께 설계변경이나 제품하자 발생을 획기적으로 감소시키고 있다 날이 갈수.

록 보다 좋은 제품을 보다 빨리 보다 싸게 개발하게 되었다(better) (faster), (cheaper) .

이에 힘입어 우리나라도 산업전반에 이를 적용하고 확산하기 위하여 년 한국시스템 공2002

학협회 를 설립하였다(KCOSE: Korean Council on Systems Engineering) .

시스템 공학과 소프트웨어 공학1.4

오늘날 컴퓨터기술이 나날이 발전되어감에 따라 소프트웨어가 시스템형상에서 차지하는

비중이 점점 더 높아져 가고 있다 현재 평균적으로 시스템의 이상이 소프트웨어로 구. 50%

성되어 있기 때문에 하드웨어 설계자는 더 이상 소프트웨어를 고려하지 않고 설계 및 개발

활동을 할 수 없게 되었다 소프트웨어는 하드웨어 인력 설비 자료 등에 포함되어 시스템. , , ,

의 주요 요소로 다루어진다 소프트웨어에 대한 요구는 기능분석 및 할당. (functional

을 통하여 시스템 요구단계에서 직접 발생된다 을 나타analysis & allocation) . “what”

내는 운용 및 유지기능과 로 나타내는 절충대안분석에 따라 보다 구체적으로 정의“how”

된다 이러한 소프트웨어는 소프트웨어 공학 절차를 따라 개발된다. .

소프트웨어 공학 은 컴퓨터 프로그램의 절차와 이에 관련된 문(software engineering)

서를 개발하고 관리하는데 필요한 과학적이고 체계적인 절차를 말한다 이러한 소프트웨어.

공학 절차는 하드웨어 공학 절차와 함께 연동되어 있다 특히 하드웨어 시스템에 내장되어.

있는 소프트웨어 개발절차는 아래 그에서와 같이 시스템 개념설계 이후 하드웨어 개발 절차

와 유사하다 이는 요건계획 요건분석 설계 코딩 운용 및 유지보수 단계로 구성되어 있. , , , ,

다 하드웨어와 함께 개발된 소프트웨어는 통합시험을 거쳐 설계검증 및 확인이 이루어진.

다 사용 중에 문제가 발생되면 각각의 정비절차를 통해 보완하고 이를 통합해서 시험한다. .

- 6 -

그림 소프트웨어 공학과 시스템 공학그림 소프트웨어 공학과 시스템 공학그림 소프트웨어 공학과 시스템 공학그림 소프트웨어 공학과 시스템 공학< 1-1>< 1-1>< 1-1>< 1-1>

한편 소프트웨어 시스템을 개발하는 수명주기 모델로서 폭포수 모델, (waterfall

진화적 모델 나선형 모델 등이 있으며model), (evolutionary model), (spiral model) ,

이는 시스템 공학 모델과 동일하다 날이 갈수록 소프트웨어 요구가 증가하고 있어 소프트.

웨어 비용 또한 급속하게 증가하고 있다 따라서 시스템 공학과 소프트웨어 공학은 불가분.

의 관계로 함께 통합 발전되고 있다.

시스템 공학 프로세스1.5

기본 프로세스기본 프로세스기본 프로세스기본 프로세스1.5.11.5.11.5.11.5.1

시스템 공학 프로세스 란 통합팀에 의해 순차(SEP: Systems Engineering Process)

적이며 하향식 방법으로 적용하는 포괄적이고 반복 및 순환적으로 문제를 해결(top-down)

하는 프로세스를 말한다 이러한 프로세스는 고객의 요구와 요건을 시스템제품과 프로세스.

규격서로 변환하며 의사결정권자에게 필요한 정보를 생성하여 제공하게 된다.

이를 시스템 공학 아키텍처 라고 하며 이는 사용자 및 고객요구사항을 시(architecture)

스템 엔지니어로 하여금 하드웨어 소프트웨어 시험 생산성 프로그램 관리자 로지스틱, , , , ,

스 교육훈련 인력 및 인사 신뢰성 안전성 정비성 그리고 각종 환경관련 엔지니어 등으, , , , , ,

로 구성된 통합팀에 의해 시스템 규격서 를 생성하는 프로세스이(system specification)

다 이와 같이 한 레벨에서 생성된 자료는 다음 개발레벨의 입력 자료로 제공된다 따라서. .

기본적인 프로세스는 한 번에 한 레벨씩 순차적으로 적용되고 각각의 개발레벨에 따라 추,

- 7 -

가적인 세부내용과 정의가 제시되어진다.

시스템 공학 프로세스 과정에서 형성되는 아키텍처는 시스템을 보다 쉽게 기술하고 공통

적으로 이해하기 위하여 만들어진다 아키텍처라는 용어는 일반 공학 분야에서 여러 가지.

의미로 사용된다 여기서는 시스템을 만들기 위하여 하부 시스템을 어떻게 결합해야 하는지.

에 대한 설명으로 이해하면 된다 이러한 목적을 달성하기 위하여 기능적 물. (functional),

리적 및 시스템 아키텍처를 사용하고 있다 기능적 아키텍처는 할당(physical), (system) .

기능 과 성능요건 을 식별하기 위해(allocated function) (performance requirement)

이를 구조화한 아키텍처이다 물리적 아키텍처는 시스템이 하부시스템과 구성품으로 분해.

되어지는 구조를 나타낸다 이는 구체적으로 시스템을 구성하고 이는 형상제품.

으로 나타난다 시스템 아키텍처는 시스템을 운용하고 지원하는데(configuration item) .

필요한 모든 제품과 생산 및 건설 배치 운용 유기 폐기 교육훈련 및 검증에 필요한 모, , , , ,

든 수명주기 프로세스를 포함하고 있다.

시스템 공학 프로세스 정의시스템 공학 프로세스 정의시스템 공학 프로세스 정의시스템 공학 프로세스 정의1.5.21.5.21.5.21.5.2

시스템 공학 프로세스는 모든 개발단계 동안 하향식 이며 포괄적으로 운용되(top-down)

어야 한다 뿐만 아니라 문제해결을 위하여 반복적이고 순환적인 과정을 적용함으로써 다음.

과 같은 목적을 이루어 간다 첫째 필요성과 요건을 시스템 제품 과 프로세스. , (product)

규격서로 변화해간다 이는 개발단계가 진행됨에 따라 보다 높은 가치(process) . (value)

를 지는 규격서로 구체화되어 간다 둘째 의사결정권자에게 필요한 정보 를. , (information)

생성해 준다 셋째 한 단계에서 다음 단계로 옮겨 가기위해 필요한 모든 입력 자료를 제공. ,

하게 된다 이러한 목적을 달성하기 위한 프로세스를 도식하면 아래 그림과 같다 기본적으. .

로 시스템 공학 프로세스에 입력하상과 출력사항으로 되어 있다 시스템 공학 프로세스는.

요건분석 기능분석 및 할당(requirement analysis), (functional analysis and

요건루프 조합 설계루프allocation), (requirement loop), (synthesis), (design loop),

검증 및 시스템 분석 및 통제 로 구성되(verification), (system analysis and control)

어 있다.

- 8 -

그림 시스템공학 프로세스그림 시스템공학 프로세스그림 시스템공학 프로세스그림 시스템공학 프로세스< 1-2>< 1-2>< 1-2>< 1-2>

모든 시스템 공학 활동은 시스템 분석 및 통제활동을 통하여 총체적인 기술과 도구를 사

용하여 균형 을 이루어 간다 시스템 공학 통제는 의사결정과 요건을 추적하고(balance) . ,

기준을 유지하며 인터페이스와 위험도를 관리하는 활동이다 또한 비용과 일정 및 기술성, .

능을 추적하고 요건의 일치여부를 검증하며 프로젝트 진행과정을 검토 및 감사토록 한다, , .

프로세스 입력사항은 주로 고객의 필요성과 목적 요건과 프로젝트 제약사항으로 구성된,

다 입력사항이 특정하게 제한되어 있는 것은 아니지만 일반적으로 대상 시스템의 임무 효. ,

과도척도 시스템 환경요소 가용한 기술기반 이전(MOE: Measure Of Effectiveness), , ,

단계에서 출력된 요건과 의사 결정된 요건 및 이와 협력된 지식기반 요건이 포함되어 있다.

이러한 시스템 공학 프로세스는 제품개발단계에 따라 반복적으로 적용된다 이러한 입력.

자료 바탕위에 시스템 공학의 첫 번째 프로세스는 입력자료를 분석하는 요건분석

단계이다 요건분석의 목적은 대상시스템의 기능과 성능에 관한(requirement analysis) .

요건을 도출하는데 있다 고객이 요구한 입력자료는 대상시스템이 무슨 기능을 어떻게 수행.

할 것인지를 알아낸 다음 그 세부내용을 요건으로 변환하여 설정한다 시스템 엔지니어는.

설정된 요건이 분명하게 이해되어 있는지 그리고 포괄적이며 완전하면서 간결하게 표현되어

있는지를 검증한다 이 과정을 통해 대상시스템의 기능요건 과. (functional requirement)

설계 제약사항이 분명하게 정의되어진다 기능요건의 예를 들면 필요한 수량. , (how many),

품질 적용범위 시기 및 기간 그리고 가용성(how good), (how far), (when, how long)

에 대하여 정의되어진다 설계 유연성과 관련된 제약사항은 대상시스템의 환(how often) .

경조건 대상영역의 한계 내적 및 외적 위협의 보호 계약조건 거래 또는 규격표준 등을, , , ,

들 수 있다.

기능분석 프로세스는 상기 요건분석을 통해 식별된 상위레벨 기(functional analysis)

능을 하위레벨 기능으로 분해하는 과정에서 분석되어진다 이와 함께 상위레벨 성능요건.

이 하위레벨 기능에 할당되어진다 그 결과물은 제품 또는(performance requirement) .

품목의 기능적 아키텍처 를 기술한 규격서로서 이는 성능요건이(functional architecture)

- 9 -

논리적으로 무엇을 수행하는지를 설명해 준다 즉 요구시스템이 무엇을 수행해야 하고 어. , ,

떠한 방법으로 수행할 수 있는지 그리고 하위레벨 기능과 어떠한 차이점이 발생하고 있는지

를 설명해 준다 따라서 기능분석 및 할당 프로세스는 향후 물리적인 해결방안을 최적화하.

기 위해 필요한 정보를 제공해 주는데 있다.

상기 두 가지 프로세스를 통해 요건이 보다 구체화되고 세분화되어 대상시스템의 기능을

보다 분명하게 제시하게 된다 이와 같이 식별된 기능은 반드시 요건을 추적할 수 있어야.

한다 기능분석 및 할당 프로세스를 통해 제기된 문제점은 요구분석과정으로 피드백되어 요.

건이 충족될 때까지 반복 수행한다 이를 요건루프 프로세스라고 한다. (requirement loop) .

설계조합 단계는 물리적 및 소프트웨어적 관점에서 설계된 제품과 품(design synthesis)

목을 식별하고 정의하는 프로세스이다 그 결과물은 물리적 아키텍쳐. (physical

라고 부른다 정의된 부품은 최소한 하나 이상의 기능을 수행해야 한다 이architecture) . .

러한 물리적 아키텍처는 규격서 와 제품기준 을 제시하(specification) (product baseline)

는 기본적인 구조이다 설계로 조합된 물리적 아키텍처가 성능레벨이 요구기능을 충족하고.

있는지를 검증하기 위해 기능 아키텍처로 다시 반복되어진다 이러한 과정을 통해 대상시스.

템의 임무수행방법을 확인하고 설계조합의 최적화를 이루게 한다 이를 가리켜 요건루프에.

상응하는 설계루프 프로세스라고 부른다(design loop) .

시스템 공학 프로세스 결과에 대한 적용성 여부는 도출요건 과(derived requirement)

비교하는 검증 프로세스로 수행한다 이러한 검증활동은 모든 개발레벨에서(verification) .

원칙적으로 수행되어야 한다 프로세스에 의해 만들어진 모든 기준 에 대한. SE (baseline)

검증방법이 수립되어야 한다 예를 들면 각종 실험 시연 모델링 및 시뮬레이션 및 시험. , , , ,

등이 있다 공식적으로 수행되는 개발 및 운용시험평가는 매우 중요한 검증활동이다. .

시스템 공학 프로세스의 모든 단계에 걸쳐 사업진도 각종 대안평가 및 선정 활동 그리, ,

고 각종 문서 및 의사결정에 대한 기술관리활동이 시스템분석 및 통제(system analysis

프로세스로 수행된다 예를 들면 절충연구 효과도 분석 및 설계분석 활동을& control) . , ,

들 수 있다.

이러한 활동을 통해 프로그램 목적과 기술요건을 충족 가능한 각종 대안을 평가하고 성,

능 기능 및 설계요건의 정량적 기준을 제시하게 된다 분석활동에 사용되는 입력도구로서, , .

모델링 시뮬레이션 실험 및 시험 등이 있다 그리고 통제활동으로서는 위험관리 형상관, , . ,

리 데이터관리 주요활동을 기반으로 한 일정관리와 기술성능척도, , (TPM : technical

및 기술검토 등 성능을 기반으로 한 진도관리parameter measure), (technical review)

가 포함된다 이러한 시스템 분석 및 통제의 목적을 달성하기 위해서는 다음 사항을 지켜야.

한다.

대안을 결정하기에 앞서 시스템 효과도 수명주기별 자원 위험 및 고객요건에 미치는, ,•

영향을 평가해야 한다.

- 10 -

프로세스 결과물에 입각하여 규격서 요건과 각종 의사결정이 이루어져야 한다SE .•

프로세스는 입력에서 출력까지 반드시 추적성이 유지외어야 한다SE .•

개발일정과 획득시기는 상호 협조적으로 지원되어야 한다.•

시스템에 필요한 기술요구사항은 시스템 공학 활동에 포함되어 있어야 한다.•

기능과 성능에 영향을 주는 고객요건은 타당성 일관성 기대성 및 실현가능성이 있어, ,•

야 한다.

제품과 프로세스의 설계요건은 도출된 기능 및 성능요건을 추적할 수 있어야 한다.•

프로세스의 출력은 각 프로세스 단계에 적합한 규격서 의사결정사항 시스템 및 형상품, ,

목 아키텍처 및 각종 기준이 포함된다 일반적으로 이는 제품형상이나 제품을 개발하는데, .

필요한 모든 프로세스를 기술하거나 통제하는 데이터를 말한다.

시스템개발 단계화1.6

일반적으로 시스템개발 단계화는 세 가지의 분명한 레벨 또는 단계를 거쳐 진행되고 있

다 단계는 개념연구를 통하여 시스템개념을 기술하는 개념레벨의 시스템 기획단계이다. 1 . 2

단계는 시스템 성능에 대한 요건항목으로 나타내는 시스템 레벨단계이다 단계는 하부시스. 3

템과 구성품의 제품성능을 기술하고 생산단계에서의 제품상세규격을 설정하는 하부시스템/

구성품 레벨단계이다.

시스템 공학 프로세스는 일반적으로 형상기준 이라고 불리는(configuration baseline)

기술서 를 만들기 위하여 시스템 개발단계별 시스템 레벨별 한 단계씩 적용(description) ,

해 가는 프로세스이다 따라서 각각의 개발레벨과 이와 연관된 형상기준을 설정해 간다 예. .

를 들어 이러한 형상기준을 살펴보면 다음과 같다 형상기준은 시스템 기획을 수립하기 위.

한 개념연구단계에서 정의된 시스템 레벨 규격을 기술한 개념설계 기능기준(functional

예비시스템 설계단계에서 하부시스템과 구성품의 성능을 기술한 할당기준baseline),

그리고 하부시스템과 구성품의 상세규격을 기술하기 위해 정의된(allocated baseline),

제품기준 으로 점진적으로 시스템이 구체화 되어간다 이러한 기준상호(product baseline) .

간에 기본적인 관계를 나타내기 위하여 미 국방성에서는 아래 그림과 같은 획득수명주기 프

로세스를 사용하고 있다.

- 11 -

그림 미 국방성 시스템 획득수명주기 프로세스그림 미 국방성 시스템 획득수명주기 프로세스그림 미 국방성 시스템 획득수명주기 프로세스그림 미 국방성 시스템 획득수명주기 프로세스< 1-3>< 1-3>< 1-3>< 1-3>

그림에서 삼각형은 각종 기준을 통제하기 위하여 기준통제 의사결정점을 나타내며 의사,

결정 수단은 기술검토 및 감리 활동을 통해 검증되어진다 시스(technical review) (audit) .

템 계층구조 레벨에 따라 개발하려면 상위레벨 형상기준이 설정된 다음 후속 개발이 이루어

져야 한다 기술검토와 감리활동은 기준면에서 다음 단계 개발준비 완료여부를 확인하기 위.

해 사용되는 절차이다 이러한 검토 및 감사 프로세스는 시스템의 성숙정도를 평가하는 활.

동으로서 각종 의사결정 프로세스를 지원하는데 중요한 역할을 한다.

그림 시스템 공학 표준 상속도그림 시스템 공학 표준 상속도그림 시스템 공학 표준 상속도그림 시스템 공학 표준 상속도< 1-4>< 1-4>< 1-4>< 1-4>

시스템 공학 표준1.7

년대 이래 시스템 공학 프로세스의 표준에 대한 필요성이 제기되어 왔다 위 그림은1960 .

바로 이러한 요구를 충족시키기 위하여 시스템 공학 표준과 이와 밀접하게 연계되어 있는

소프트웨어 공학 표준의 발전 유래를 보여주고 있다.

년에 처음으로 제정된 군사 표준 는 그 후 군사표준과 함께 미 국1969 MIL-STD-499

방성표준으로 발전시키기 위하여 꾸준하게 노력해 왔다 드디어 로 기안. MIL-STD-499B

되었으나 미국방성획득정책 변화에 따라 표준으로 변경되지 못한 채 사장되었다 미국가표.

- 12 -

준원 전자산업협회(ANSI : American National Standard Association), (EIA:

및 국제전기전자학회Electronic Industries Alliance) (IEEE: International

에서 년에 시스템 공학 프로세스로Electronic and Electrical Engineers) 1998

로 표준을 제정하게 되었다 국제 시스템 공학 협회 에서는 본ANSI/EIA-632 . (INCOSE)

표준과 이와 연계된 시스템 공학 성숙도모델 을 근간으로EIA/Interim IS-731 (SECMM)

사용해 오고 있다 이는 어떠한 프로그램에 이를 반드시 적용해야 한다는 의도는 전혀 없.

다 오히려 시스템 공학 활동을 성공적으로 적용하기 위하여 무엇을 수행해야 하며 이를. ,

어떻게 수행할 것인지에 관심을 두고 있다 이러한 관점에서 시스템 공학 표준의 활용성이.

요구되어진다고 하겠다 우리도 이를 토대로 시스템 공학 표준을 제정할 필요가 있다 한편. .

소프트웨어 공학 표준은 년 및 년 미국방성표준이 함께 합쳐져 년1987 1988 1994

로 제정되어 오늘날까지 사용되어 오고 있다MIL-STD-498 .

- 13 -

시스템 공학 관련 표준 현황

- 14 -

시스템 공학 관련 표준 현황2.

시스템공학과 관련된 표준이나 모델들이 개발되기 시작한 지는 그리 오래되지 않았다.

년에 처음으로 개발된 시리즈가 있었지만 이 표준은 미 국방 시스1969 MIL-STD-499 ,

템의 획득에 초점을 둔 표준이었기 때문에 다른 산업분야에 널리 활용되지는 못했다 그러.

나 가 발간되지 못하면서 다양한 산업영역에 적용할 수 있는 시스템공학MIL-STD-499B

표준을 개발하려는 노력들이 년부터 시작되었다 이러한 노력들은1994 . EIA 632, IEEE

와 같은 표준들을 거치면서 현재 최초의 국제표준으로서1220, ANSI/EIA 632 ISO/IEC

발간된 것이다 이들 표준 이외에도 등과 같은 다양한15288 . SECAM, EIA 731, CMMI

프로세스 평가 모델들이 존재하지만 본 장에서는 제외한다.

시리즈2.1 MIL-STD-499

그림그림그림그림< 2-1> MIL-STD-499A< 2-1> MIL-STD-499A< 2-1> MIL-STD-499A< 2-1> MIL-STD-499A

표준표준표준표준

시스템공학과 관련된 최초의 표준은 년 미 공군 에서 개발한1969 (USAF)

시리즈로서 년에MIL-STD-499 , 1974 MIL-STD-499A Engineering Management

가 발간되었고 이후 년에는 초안, 1992 MIL-STD-499B Systems Engineering

이 검토를 위해 배포되었으나 시스템공학 표준에 포함될 내용에 대(Coordination Copy) ,

한 합의를 이끌어 내지 못한 채 년 성능 기술서 이, 1994 (performance specifications)

외의 국방 표준에 대한 미 국방부의 폐지 방침에 따라 정식 표준으로 발간되지는 못했다.

- 15 -

그러나 는 에서 나타나 있는 바와 같이 다른 시스템공학 표준들의 기초MIL-STD-499B

가 되며 시스템공학과 관련된 용어와 시스템공학 프로세스를 처음으로 정의한 데 그 의의,

가 있다

그림 표준그림 표준그림 표준그림 표준< 2-2> MIL-STD-499B< 2-2> MIL-STD-499B< 2-2> MIL-STD-499B< 2-2> MIL-STD-499B

시리즈는 미 국방부가 획득자의 관점에서 작성한 표준으로서 민수 산업MIL-STD-499

분야에 적용하기에는 적지 않은 한계를 가진데다 가 정식으로 발간되지, MIL-STD-499B

못함에 따라 군수 및 민수 산업영역에 공통으로 적용될 수 있는 시스템공학 표준을 개발하

려는 노력들이 년부터 시작되었다 이러한 노력으로 년에 개발된 표준이 각각1994 . 1994

과EIA/IS 632 Systems Engineering IEEE 1220 Trial Use IEEE Standard for

이다Application and Management of the Systems Engineering Process

2.2 EIA 632 (Processes for Engineering a System)

는 년 월에 배포된 임시 표준 으로서EIA/IS 632 1994 12 (interim standard)

의 상업용 버전에 해당된다 는 년MIL-STD-499B (commericial) . EIA/IS 632 1998

월 으로 계승 발전된다12 ANSI/EIA 632 Processes for Engineering a System .

는 미 전자산업협회 산하의ANSI/EIA 632 (Electronic Industries Alliance: EIA)

시스템공학위원회 에서 작업반 을(Systems Engineering Committee) (working group)

구성하여 개발한 표준으로서 시스템공학과 관련된 거의 모든 프로세스들을 고려하기 위해,

대상 범위를 확장하고 또 국방 및 항공우주 부문에 국한하지 않고 다른 모든 분야에도 적합

하도록 표준을 개발하였다.

- 16 -

그림 표준그림 표준그림 표준그림 표준< 2-3> ANSI/EIA 632< 2-3> ANSI/EIA 632< 2-3> ANSI/EIA 632< 2-3> ANSI/EIA 632

>>>>

이러한 특징은 및 프로세스 구성도로부터 쉽게 알 수 있EIA/IS 632 ANSI/EIA 632

다.

기술기술기술기술 프로세스프로세스프로세스프로세스

계획

프로세스

평가

프로세스

통제

프로세스

획득획득획득획득 & & & & 공급공급공급공급

공급 프로세스

획득 프로세스

시스템시스템시스템시스템 설계설계설계설계

요구사항 정의

프로세스

해결방안 정의

프로세스

제품제품제품제품 구현구현구현구현

구현 프로세스

이전 프로세스

기술기술기술기술 평가평가평가평가

시스템분석

프로세스

요구사항 논증

프로세스

시스템 검증

프로세스

최종제품 논증

프로세스

요구사항

설계

제픔

결과물

&

피드백

계획, 지시

&

상태

획득획득획득획득

요청요청요청요청

시스템시스템시스템시스템

제품제품제품제품

그림 프로세스 관계도그림 프로세스 관계도그림 프로세스 관계도그림 프로세스 관계도< 2-4> ANSI/EIA 632< 2-4> ANSI/EIA 632< 2-4> ANSI/EIA 632< 2-4> ANSI/EIA 632

- 17 -

특히 개발과정에서 기존의 모든 표준의 원리와 개념을 통합하고 다양한ANSI/EIA 632

산업 부문 및 기술영역의 관점을 반영하기 위해 개발을 맡은 작업반에 전문가는 물, EIA

론, ISO(International Organization for Standardization), IEEE(Institute of

Electrical and Electronics Engineers), INCOSE(International Council on

의 전문가들을 포함하여 표준간의 조화를 유지하려고 노력했다Systems Engineering) .

2.3 IEEE 1220 (IEEE Standard for Application and Management of

the Systems Engineering Process)

은 를 계승하여 년 월에 제정된 표준이다 그 이후IEEE 1220 MIL-STD-499B 1995 1 .

에 와 의 병합을 통해 상업용뿐만 아니라 정부분야에도IEEE 1220 Trial Use EIA 632

적용할 수 있는 하나의 시스템공학 실 사례를 개발할 의도였지만 년 월, 1995 6 IEEE

을 별도의 표준으로 개발하기로 결정하면서 와1220 , IEEE 1220 Full Use ANSI/EIA

는 서로 다른 성격의 표준으로 발전하게 된다632 .

그림 표준그림 표준그림 표준그림 표준< 2-5> IEEE 1220< 2-5> IEEE 1220< 2-5> IEEE 1220< 2-5> IEEE 1220

에 대한 년간의 적용 경험을 바탕으로 년 월에 배포된Trial Use 2 1999 1 IEEE 1220

는 나 보다 아주 상세한 수준으로 기술되었으며Full Use MIL-STD-499B EIA/IS 632 ,

소프트웨어와 하드웨어를 포함한 시스템 개발과 시스템의 수명주기를 고려한 프로세스의 개

발을 위해 전사조직 이 수행해야 할 총체적인 기술 활동들을 정의한다(enterprise) . IEEE

의 프로세스 구성도는 아래 그림과 같다1220 Full Use .

- 18 -

요구사항 분석요구사항 분석

요구사항 검증요구사항 검증

기능 분석기능 분석

기능 검증기능 검증

종합종합

설계 검증설계 검증

통제통제

요구 거래 연구 & 평가

기능 거래 연구 & 평가

설계 거래 연구 & 평가

프로세스 입력

요구사항 기준선

검증된 요구 기준선

기능적 아키텍처

검증된 기능적 아키텍처

검증된 물리적 아키텍처

프로세스 결과

요구사항 & 제약사항 충돌(conflict)

분해와 요구사항 할당 대안

분해/할당 거래 &효과(impacts)

설계 솔루션 요구사항 & 대안 분석

시스템

설계 솔루션 거래 & 효과(impacts)물리적 아키텍처

요구사항 거래 & 효과(impacts)

그림 시스템 공학 프로세스그림 시스템 공학 프로세스그림 시스템 공학 프로세스그림 시스템 공학 프로세스< 2-6> (SEP)< 2-6> (SEP)< 2-6> (SEP)< 2-6> (SEP)

시스템 공학 표준 비교2.4

본 절에서는 앞서 소개한 대표적 표준들의 특성을 비교하도록 한다 먼저 각 표준들의 공.

통점을 살펴보면 다음과 같다 첫째 표준들은 무엇을 해야 하는지. , " (what should be

에 대해서만 기술하고 있으며 어떻게 해야 하는지 에 대해서는done)" , " (how to do it)"

언급하고 있지 않다 경우에 따라서는 무엇 이 어떻게 로 해석되는 경우도 있지만 이것. " " " " ,

은 단지 관점의 차이일 뿐이다 오늘날 표준들은 이러한 문제점을 해결하기 위해 방법론이.

나 도구보다는 프로세스와 프로세스에 관련된 활동과 과업에 더욱 많은 초점을 둔다.

둘째 표준들은 시스템의 수명주기에 기반을 둔다 물론 수명주기는 대상 산업에 따라 또, . ,

는 주체 고객 계약자 개발자 사용자 등 의 목적에 따라 매우 다양하게 정의될 수 있지만( , , , ) ,

각 표준들은 표준에서 가정하는 바에 따라 수명주기를 정의하고 있다.

다음으로 표준들 간의 주요 차이점을 아래 그림을 통해 살펴보았다.

- 19 -

그림 시스템 공학 표준 비교그림 시스템 공학 표준 비교그림 시스템 공학 표준 비교그림 시스템 공학 표준 비교< 2-7>< 2-7>< 2-7>< 2-7>

는 의 비 군용 버전이기 때문에 대부분EIA/IS 632 MIL-STD-499B (demilitarized) ,

의 내용을 그대로 계승하고 있다 따라서 두 표준간의 차이점은 그리 크지 않다 이 두 표. .

준의 경우 시스템 개발을 위한 접근방법을 정의하고 있으며 프로세스의 상세수준면에서도,

타 표준들과 비교했을 때 중간 수준에 해당한다.

의 경우에도 시스템 개발을 위해 수행해야 할 활동과 과업에 대해 다루고 있IEEE 1220

지만 나 보다는 훨씬 상세한 수준에서 프로세스를 다루고, MIL-STD-499B EIA/IS 632

있다.

는 이들 표준들보다는 좀 더 상위 수준에서 프로세스를 다룬다 총 개ANSI/EIA 632 . 13

의 표준과 개의 요구사항으로 구성되어 있으며 개발단계 뿐만 아니라 그 이전의 개념화34 ,

단계에서 개발 이후의 전수단계까지 그 범주를 확대하고 있다 끝으로 의. ISO/IEC 15288

경우 최상위 수준의 표준으로서 시스템공학 프로세스 뿐만 아니라 경영, (management

프로세스까지 언급하고 있다or business) .

- 20 -

시스템 공학 표준 채택 활용 현황/

- 21 -

시스템 공학 표준 채택 활용 현황3. /

개요3.1

년 월 국제적인 표준을 제정하는 국제표준화기구2002 10 (ISO, International

에서 처음으로 하드웨어 소프트웨어 및 인간Organization for Standardization) ,

과의 인터페이스를 다루는 시스템 수명주기 프로세스 표준인 ISO/IEC

를 발행하였15288:2002 System Engineering-System Life Cycle Process

다 이는 년 월에 의 에서 초안 이 작성된. 1996 7 ISO/IEC JTC1/SC7 WG7 (N121)

이후 년간의 작업을 거쳐 표준으로 제정되었다 이후 년 월에는6 . 2003 11 ISO/IEC

에 대한 가이드로서15288 ISO/IEC TR 19760 System Engineering-A guide

을 발행하였다for the application of ISO/IEC 15288 .

이처럼 시스템 수명주기 표준이 공식적으로 발표되고 활용되기 시작한 것은 불과 년2~3

에 불과하다 따라서 실제 본 표준에서 제시하고 있는 시스템 수명주기의 단계와 프로세스.

들을 활용하여 해당되는 관리 분야 또는 프로젝트에 적용하고 그 효과를 나타내기에는 아직

시기상조이다 반면에 년부터 시스템 수명주기 프로세스에 대한 논의가 항공 및 우주. 1996

산업 군수 산업과 같은 거대 시스템 기업들이 시스템 수명주기에 관심을 갖고 참여하였고, ,

미국의 국제 시스템 공학 협의회(INCOSE, International Council on System

및 미 표준기구인 에서도 적극적으로 참여Engineering) IEEE Computer Society(CS)

하여 의견을 반영함으로써 활용성에 대한 기대는 높다고 할 수 있다.

의 활용 현황은 본 표준이 시스템 및 소프트웨어 공학 분야의 다양한ISO/IEC 15288

국제 표준에 있어서 하위 또는 특정 분야의 표준들에 대해 기본적인 상위표준(Principle

이고 공식적인 표준이 발행되고 적용하는 기간이 짧아서 표준적용에 대한 효과Standard)

측정은 어렵다고 볼 수 있다 따라서 현재 본 표준을 적용하거나 채택 활용하는 수준에서. ,

현황을 살펴보고자 한다.

미국3.2

미국은 시스템 공학 특히 소프트웨어 집중적인 시스템에 대한 수명주기 프로세스에 대해,

민간뿐만 아니라 정부차원에서도 가장 활발히 적용하고 활용하고 있다 특히 항공 산업 우. ,

주산업 대형 무기 사업을 정부차원에서 관리하거나 민간차원에서 프로젝트를 진행하면서,

- 22 -

시스템 공학 및 시스템 수명주기 프로세스의 필요성을 절실히 느끼고 표준 및 관련 활동에

매우 적극적이다.

공공분야공공분야공공분야공공분야3.2.13.2.13.2.13.2.1

미국의 공공분야에 있어서 시스템 공학 및 관련 프로세스를 가장 적극적으로 활용하고 있

는 국방성 은 년 월에 를 공식적으로 채택하였다 미(DoD) 2003 5 ISO/IEC 15288:2002 .

국방성은 를 전사적 뿐만 아니라 프로젝트 수준의 시스템 수명주기ISO/IEC 15288:2002

프로세스를 제공하고 있음을 알리고 시스템 공학 프로세스의 적용 및 관리 표준인, IEEE

과 시스템 공학을 위한 프로세스 표준인 와 병행하고 사용Std1220:1998 ANSI/EAI 632

할 것을 권고하고 있다.

특히 은 전체 시스템 수명주기 프로세스를 다루며, ISO/IEC 15288:2002 , IEEE

은 시스템의 설계 및 통제 활동을 상세하게 다루고 마지막으로Std1220:1998 ANSI/EAI

는 시스템 공학의 기술 관리 프로세스에 관련하여 무엇을 해야 하는 가에 대한 내용을632

다루고 있음에 따라 이러한 각 표준들 간의 범위와 상세화 정도를 감안하여 사용할 것을 권

고하고 있다.

그림 미 국방성의 표준채택그림 미 국방성의 표준채택그림 미 국방성의 표준채택그림 미 국방성의 표준채택< 3-1> ISO/IEC 15288< 3-1> ISO/IEC 15288< 3-1> ISO/IEC 15288< 3-1> ISO/IEC 15288

공지공지공지공지

년 월에는 가이드인 을 공식적으로 채택하고 활용할 것을2004 3 ISO/IEC TR 19760

권고하였다 이 권고는 의 표준문서를 적절하게 사용하고 표준의. ISO/IEC 15288:2002

효과적인 사용을 평가하는데 사용할 수 있음을 밝히고 있다.

- 23 -

그림 미 국방성의 표준채택그림 미 국방성의 표준채택그림 미 국방성의 표준채택그림 미 국방성의 표준채택< 3-2> ISO/IEC TR 19760< 3-2> ISO/IEC TR 19760< 3-2> ISO/IEC TR 19760< 3-2> ISO/IEC TR 19760

공지공지공지공지

또한 미군의 모든 획득에 관련한 최상위의 지시문서인 국방획득체계(DoD Directive

및 국방획득체계 시행 에 대한 가이드로 제시하고 있5000.1) (DoD Instruction 5000.2)

는 국방획득가이드북 장에서 시스템 공학 및 프로(Defense Acquisition Guidebook) 4

세스에 대한 가이드를 제시하고 있으며 주요한 시스템 공학 표준으로, ISO/IEC 15288,

및 을 제시하고 있으며 이 표준 간에 깊이와 수준이 상이함에 따라EIA 632 IEEE 1220 ,

서 적절한 조합을 통해 활용할 것을 명시하고 있다.

그림 미 국방성의 지시문서그림 미 국방성의 지시문서그림 미 국방성의 지시문서그림 미 국방성의 지시문서< 3-3> Defense Acquisition System< 3-3> Defense Acquisition System< 3-3> Defense Acquisition System< 3-3> Defense Acquisition System

또한 미 해군의 무기 및 정보체계 연구개발을 담당하는 SPAWAR(Space and Naval

- 24 -

사령부는 프로젝트 관리 정책Warfare) (Project Management Policy, SSCSDINST

지침 상에 보다 효율적인 시스템 개발 및 소프트5234.1A, 202, 30 November 2004)

웨어 개발을 위한 시스템 및 소프트웨어 표준으로 의 참고할 것을 명시하ISO/IEC 15288

고 있다.

미 국방성의 경우 다양한 미군의 획득에 있어서 특히 대형 무기체계 또는 정보시스템 도,

입에 있어서 이를 관리하고 통제하기 위한 수단으로 시스템 수명주기 프로세스 표준을 제시

하고 활용하고 있다.

민간분야민간분야민간분야민간분야3.2.23.2.23.2.23.2.2

국가 표준기구○

우선 미국의 표준기구인 에서 년 월IEEE Computer Society(CS) 2004 12 ISO/IEC

를 미국 표준인 로 발행하였다 미국의 표준으로 발15288:2002 IEEE Std 15288-2004 .

행하면서 에서는 표준의 전체 내용을 그대로 수용하면서 단지 부록IEEE ISO E(Annex

표준들과의 관계 를 추가하여 기존의 등과 같은 표준들E) ‘IEEE ’ IEEE 12207, 1220

과의 관계를 부가하여 표준으로 발행하였다.

그림 미국의그림 미국의그림 미국의그림 미국의< 3-4> IEEE Std< 3-4> IEEE Std< 3-4> IEEE Std< 3-4> IEEE Std

표준표준표준표준15288-200415288-200415288-200415288-2004

프로세스 개선 분야(Lockheed Martin)○

미국의 대표적인 방산기업인 록히드마틴은 항공기 미사일을 비롯해 군의 정보시스템분야,

선도하는 기업이다 이 기업은 복잡하고 광범위한 시스템 개발을 위해 시스템 공학 및 프로.

세스에 많은 노력을 기울이고 있으며 시스템 구축의 품질향상 생산성 향상 예측성 향상, , , ,

고객 만족을 위해 꾸준히 프로세스 개선을 수행하고 있다 특히 다양한 표준을 수용한.

- 25 -

표준을 개발하여 적LM-IEP(Lockheed Martin-Integrated Engineering Process)

용하고 있으며 이 자체표준에 시스템 공학 프로세스 표준으로 과, ISO/IEC 15288 IEEE

을 포함하고 있다1220 .

LM CPSs

ANSI/EIA-632

ISO 9001:2000

IEEE 1220

LM HardwareProcess Standard

ISO/IEC-12207

CMMI®® V1.1

ISO/IEC-15288

Common Source Standards

OrganizationalStandard Process

LM-IEPStandard

Industry Stds

Government Stds

Domain Specific Standards

Industry Stds

Government Stds

Project Specific Standards

ProjectDefinedProcess

In LM-IEP V2.0 issued 1/03In LM-IEP V2.0 issued 1/03

Integrated Processes

Integrated Work Products

Integrated Methods

Integrated Processes

Integrated Work Products

Integrated Methods

Tailored OSP

EPI Process& Methods

Informative only Informative only

CPS – Corporate Policy StatementEPI – Engineering Process Improvement

Reference Only

그림 록히드마틴의 표준 개념그림 록히드마틴의 표준 개념그림 록히드마틴의 표준 개념그림 록히드마틴의 표준 개념< 3-5> LM-IEP< 3-5> LM-IEP< 3-5> LM-IEP< 3-5> LM-IEP

비용분석 분야(Univ. of Southern California)○

대학의 소프트웨어 공학센터에서 시스템공학 활동을 기초로 한Southern California

비용예측모델 을 개발COSYSMO(Constructive System Engineering Cost Model)

함에 있어서 다양한 수준의 시스템 공학 활동을 식별하기 위하여 과ISO/IEC 15288

표준을 활용하고 있다 소프트웨어 공학센터는 년 월ANSI/EIA 632 . 2005 4 2005 NASA

발표를 통해 비용분석을 위한 작업분해도 및 단계 식별을 위Cost Analysis Symposium

해 시스템 수명주기 프로세스 표준을 활용하고 있다고 명시하고 있다.

- 26 -

COSYSMOSizeDriversEffortMultipliers

Effort

Calibration

# Requirements# Interfaces# Scenarios# Algorithms

- Application factors-8 factors

- Team factors-6 factors WBS guided by

ISO/IEC 15288그림 을 기초로 한 비용분석 개념그림 을 기초로 한 비용분석 개념그림 을 기초로 한 비용분석 개념그림 을 기초로 한 비용분석 개념< 3-6> ISO/IEC 15288< 3-6> ISO/IEC 15288< 3-6> ISO/IEC 15288< 3-6> ISO/IEC 15288

일본3.3

일본은 수명주기 프로세스 분야에 매우 적극적으로 참여하고 있다 소. ISO/IEC 12207

프트웨어 수명주기 프로세스 표준의 경우도 년 표준번호1998 SLCP-JCF 98( : JIS X

이라는 명칭으로 일부 감사기능을 추가하여 일본 표준으로 제정하였다 이후 시스템0160) .

수명주기 프로세스 표준인 이 년 월에 공식적으로 발표되면서ISO/IEC 15288 2002 11

년 월부터 자국의 표준화 작업에 착수하였다 년 월 일본표준위 의 정보2003 3 . 2004 2 (JSC)

기술전문위원회에서 표준번호 으로 승인하였고 동년 월에 공식적으로 발행JIS X 0170 , 6

하였다.

그림 일본 표준규격협회 표준화조사 연구 개발 성과보고서그림 일본 표준규격협회 표준화조사 연구 개발 성과보고서그림 일본 표준규격협회 표준화조사 연구 개발 성과보고서그림 일본 표준규격협회 표준화조사 연구 개발 성과보고서< 3-7> , 2004.3< 3-7> , 2004.3< 3-7> , 2004.3< 3-7> , 2004.3

유럽3.4

영국○

- 27 -

영국 국방부 의 효율적인 획득을 위하여 획득관리시스템(UK MoD) (AMS, Acquisition

을 운영하고 있으며 또한 국방 획득에 있어 주요 책임 위험 등에Management System) , ,

대해 도움을 주기 위하여 획득 정책 및 프로세스 프레임워크(Acquisition Policy and

를 마련하였다 이 프레임워크는 국방부에서Process Framework, APPF) . ISO/IEC

표준을 공식적으로 채택하고 이 표준을 기반으로 시스템 수명주기 프로세스에 대한15288

범주와 하위 범주를 바탕으로 해서 를 마련하였다 이 프레임워크는 모든 프로세스에APPF .

대하여 웹상으로 하이퍼링크를 통해 관련 활동에 대한 내용과 정책 그리고 전문가에 대한

정보를 제공하고 있다.

그림 기반 영국 국방부의 획득정책 프로세스그림 기반 영국 국방부의 획득정책 프로세스그림 기반 영국 국방부의 획득정책 프로세스그림 기반 영국 국방부의 획득정책 프로세스< 3-8> ISO/IEC 15288 /< 3-8> ISO/IEC 15288 /< 3-8> ISO/IEC 15288 /< 3-8> ISO/IEC 15288 /

프레임워크프레임워크프레임워크프레임워크

스웨덴○

스웨덴은 년 월에 을 자국의 표준인2003 5 ISO/IEC 15288 SS-ISO/IEC

으로 승인하였으며 동년 월에 공식적으로 발행하였다 특히 스웨덴의 경우15288:2003 6 .

스웨덴의 국방 연구기관인 에서 획득 관련한 관리 분야의 시스템 공학 프로세스와 관FMV

련하여 을 기반으로 관리 프로세스를 수립하여 활용하고 있다ISO/IEC 15288 .

- 28 -

그림 기반 스웨덴 프로세스 아키텍처그림 기반 스웨덴 프로세스 아키텍처그림 기반 스웨덴 프로세스 아키텍처그림 기반 스웨덴 프로세스 아키텍처< 3-9> ISO/IEC 15288< 3-9> ISO/IEC 15288< 3-9> ISO/IEC 15288< 3-9> ISO/IEC 15288

뉴질랜드○

뉴질랜드는 년에 을 자국의 표준인2003 ISO/IEC 15288 Australian/New Zealand

으로 공식적인 표준채택을 하였다Standard(AS/NZS) 15288:2003 .

그림 호주 뉴질랜드그림 호주 뉴질랜드그림 호주 뉴질랜드그림 호주 뉴질랜드< 3-10> / ISO/IEC 15288< 3-10> / ISO/IEC 15288< 3-10> / ISO/IEC 15288< 3-10> / ISO/IEC 15288

표준표준표준표준

의 각국 채택 및 활용 현황을 표로 정리하면 다음과 같다ISO/IEC 15288 .

- 29 -

표 호주 뉴질랜드 표준표 호주 뉴질랜드 표준표 호주 뉴질랜드 표준표 호주 뉴질랜드 표준< 3-1> / ISO/IEC 15288< 3-1> / ISO/IEC 15288< 3-1> / ISO/IEC 15288< 3-1> / ISO/IEC 15288

국가명 기관 채택시기 비고

미국

미국방부 년 월2003 5

IEEE년2004

월12

을ISO/IEC 15288 IEEE Std

로 발행15288-2004

Lockheed Martin 자체 시스템공학표준에 포함

Southern

California년 월2005 4 NASA Cost Analysis Symposium

일본 표준 규격협회 년 월2002 6

영국 국방부Acquisition Policy and

운영Framework

스웨덴 FMV 년 월2003 5

뉴질랜드 년2003

- 30 -

표준 및ISO/IEC 15288

가이드 구조 분석

- 31 -

표준 및 가이드 구조 분석4. ISO/IEC 15288

시스템공학 시스템 수명주기 프로세스 표준4.1 ISO/IEC 15288 -

표준 제정 경과표준 제정 경과표준 제정 경과표준 제정 경과4.1.14.1.14.1.14.1.1

는 시스ISO/IEC 15288 Systems Engineering Systems Life Cycle Processes―

템공학에 대한 최초의 국제 표준이다 년 월 실시된. 2002 6 FDIS(Final Draft

국제표준 최종초안 에 대한 투표 에서 국제표준으로서International Standard, ) (ballot)

의 발간이 승인되었으며 표준의 성숙도에 대한 평가에서도 총 점 중 점을 받아 국제, 5 4.7

표준으로 발간되기에 충분한 것으로 평가되었다.

동시적이며 통합된 형태로서 하드웨어와 소프트웨어를 모두 포함하는 시스템공학 표준이

존재하지 않던 년에 처음으로 에 대한 개발 계획이 수립되었다 총1994 ISO/IEC 15288 .

개국이 참여한 표준화 프로젝트는 년 월 초안의 개요 가 배포된18 1996 7 (draft outline)

이후 차례의 표준초안 발간과 차례의 분과위원회 초안5 (working draft) 4 (committee

발간을 거쳐 년 월 최종 국제표준안을 발간하였다 국제표준으로 발간되기까draft) , 2002 3 .

지 총 번의 개정을 거치면서 개 이상의 의견 이 해결되었다10 3800 (comments) .

의 개발을 담당하고 있는 조직은 의 합동기술위원회ISO/IEC 15288 ISO/IEC (Joint

인 산하의 분과위원회Technical Committee) JTC1 (subcommittee) SC7 Software–

으로서 시스템공학과 소프트웨어공학에 대한 프로세스 지원도and System Engineering ,

구 그리고 지원 기술에 대한 표준화를 담당하는 조직이다 은 다시 개의 작업반으로. SC7 12

나뉘어지는데 이 중에서 가 의 표준화, WG7 Life Cycle Management ISO/IEC 15288–

를 담당한다 이 작업반은 소프트웨어 수명주기 프로세스에 대한 국제 표준인. ISO/IEC

를 개발하기도 하12207 Information Technology Software Life Cycle Processes–

였다.

- 32 -

문서코드문서코드문서코드문서코드 일자일자일자일자 설명설명설명설명

WG 7 N121 년 월 일1996 7 23 초안 개요

WG 7 N131 년 월 일1997 1 21 의 개정 문서 코드와 일자 확인 개정N121 ( )

WG 7 N131 년 월 일1997 2 30 의 개정 문서 코드와 일자 확인 개정N131 2( )

WG 7 N178 년 월 일1997 11 6 WD1(Working Draft 1)

WG 7 N183 년 월 일1997 11 6 WD2(Working Draft 2)

WG 7 N217 년 월 일1998 7 5 Pre-WD3(Pre-Working Draft 3)

WG 7 N225 년 월 일1998 9 6 WD3(Working Draft 3)

WG7 N237 년 월 일1999 2 16 WD4(Working Draft 4)

WG7 N253 년 월 일1999 4 30 WD5(Working Draft 5)

WG7 N0285 년 월 일1999 7 8 CD1(Committee Draft 1)

WG7 N0316 년 월 일2000 1 21 CD2(Committee Draft 2)

WG7 N0387 년 월 일2000 9 1 초안CD3(Committee Draft 3) 1

WG7 N0422 년 월 일2001 1 9 최종CD3(Committee Draft 3)

WG7 N0474 년 월 일2001 6 25 검토를 위한 초안HoD FCD(Final Committee Draft) 1

WG7 N0492 년 월 일2001 7 22 FCD(Final Committee Draft)

ISO/IECISO/IECISO/IECISO/IEC

15288:200215288:200215288:200215288:2002년 월 일년 월 일년 월 일년 월 일2002 11 012002 11 012002 11 012002 11 01 발표발표발표발표First editionFirst editionFirst editionFirst edition

표 표준 제정 경과표 표준 제정 경과표 표준 제정 경과표 표준 제정 경과< 4-1> ISO/IEC 15288< 4-1> ISO/IEC 15288< 4-1> ISO/IEC 15288< 4-1> ISO/IEC 15288

표준 적용 분야표준 적용 분야표준 적용 분야표준 적용 분야4.1.24.1.24.1.24.1.2

의 목적은 시스템의 수명주기와 잘 정립된 프로세스들 그리고 관련 용ISO/IEC 15288

어에 대한 공통된 체계를 정립하는 것이다 이들 프로세스는 시스템 수명주기의 각 단계를.

관리하고 수행하기 위해 전체 시스템 수명주기 동안 적용될 수 있으며 이는 고객만족 달성,

이라는 궁극적 목표를 갖는 모든 관련 부문의 참여를 통해 이루어진다 또한 표준에서는 조.

직이나 프로젝트에서 사용되는 수명주기 프로세스의 정의 관리 및 개선을 지원하기 위한,

프로세스를 함께 제공하며 조직이나 프로젝트는 시스템을 획득하거나 공급하고자 할 때 이,

체계를 활용할 수 있다 이 표준에서의 시스템은 하나 이상의 하드웨어 소프트웨어 관련. , ,

프로세스 절차 설비 그리고 자연적으로 발생하는 개체 등으로 구성된 모든 시스템을 대상, ,

으로 한다.

이 적용가능한 대표적인 산업영역으로는 다음을 꼽을 수 있다ISO/IEC 15288 .

항공우주- (Aerospace)

통신- (Telecommunications)

- 33 -

수송시스템- (Transportation systems)

국방시스템- (Military systems)

조선- (Ship building)

경제 및 행정 시스템- (Finance and Administrative systems)

정보기술 시스템- (Information Technology systems)

표준의 구성 및 프로세스표준의 구성 및 프로세스표준의 구성 및 프로세스표준의 구성 및 프로세스4.1.34.1.34.1.34.1.3

표준의 구성표준의 구성표준의 구성표준의 구성4.1.3.14.1.3.14.1.3.14.1.3.1

본 표준의 구성은 총 장과 개의 부록으로 구성되어 있다 장에서 장까지는 표준에6 4 . 1 4

대한 범위 목적 적용 제한사항 및 용어 등에 대해서 기술하고 있으며 장에서는 개의, , , , 5 25

시스템 수명주기 프로세스 개의 프로세스 성과 및 개의 활동에 대해서 기술하고, 123 208

있다 마지막으로 장에서는 시스템 수명주기의 단계에 대하서 기술하고 있다 부록에서는. 6 .

프로세스 조정 수명주기 단계 소프트웨어 수명주기 표준인(Tailoring), , ISO/IEC 12207

과의 관계를 설명하고 있으며 마지막으로 시스템 및 구조에 대한 설명을 기술하고 있다, .

표준 프로세스표준 프로세스표준 프로세스표준 프로세스4.1.3.24.1.3.24.1.3.24.1.3.2

시스템 생명주기 프로세스 전체 구성시스템 생명주기 프로세스 전체 구성시스템 생명주기 프로세스 전체 구성시스템 생명주기 프로세스 전체 구성■■■■

수명주기 프로세스들은 다음 그림과 같이 계약 프로세스 전사(Agreement) ,

프로세스 프로젝트 프로세스 기술 프로세스의 가(Enterprise) , (Project) , (Technical) 4

지 프로세스 그룹으로 구성된다 각 생명주기 프로세스는 수명주기 어느 때에나 요구될 경.

우 시작될 수 있으며 그 사용에 있어 명확한 순서 없다 또한 특정 수명주기 프로세스가, .

다른 수명주기 프로세스와 동시에 실행될 수도 있으며 특정 수명주기 프로세스가 시스템 구

조의 계층적 재현 시 특정 레벨에 적용 가능하다 시스템 수명주기 프로세스에 대한 설명에.

서 프로세스가 표시되고 프로세스 그룹이 사용된 순서가 시스템 수명주기에서 프로세스 활

용의 연속에서 특정한 우선순위를 의미하지는 않으며 프로세스 그룹은 표준에 사용된 기본

개념들을 반영한다.

- 34 -

Enterprise Environment

Management

Investment

Management

System Life Cycle

Processes Management

Resource Management

Quality Management

기업기업기업기업 프로세스프로세스프로세스프로세스

Acquisition

Supply

계약체결계약체결계약체결계약체결 프로세스프로세스프로세스프로세스

Stakeholder Requirements

Definition

Requirements Analysis

Architectural Design

Validation

Transition

Verification

Integration

Operation

Maintenance

Disposal

Implementation

기술기술기술기술 프로세스프로세스프로세스프로세스

Project Planning

Project Assessment

Project Control

Decision Making

Risk Management

Configuration Management

Information Management

프로젝트프로젝트프로젝트프로젝트 프로세스프로세스프로세스프로세스

그림 표준 프로세스 구조그림 표준 프로세스 구조그림 표준 프로세스 구조그림 표준 프로세스 구조< 4-1> ISO/IEC 15288< 4-1> ISO/IEC 15288< 4-1> ISO/IEC 15288< 4-1> ISO/IEC 15288

계약 프로세스계약 프로세스계약 프로세스계약 프로세스(Agreement)(Agreement)(Agreement)(Agreement)■■■■

프로세스들은 획득자와 공급자 조직 사이의 계약을 체결하는 데 반드시 필요한 활동들

을 정의하며 계약 프로세스는 획득 프로세스 공급 프로세스 시스템 수명주기 프로세스, , ,

관리 프로세스 자원 관리 프로세스 품질 관리 프로세스들로 구성된다, , .

전사 프로세스전사 프로세스전사 프로세스전사 프로세스(Enterprise)(Enterprise)(Enterprise)(Enterprise)■■■■

시스템 제품 또는 서비스를 획득하고 공급하는 전사 프로세스는 프로젝트의 개시 지원, ,

제어를 통해 조직의 성능을 관리하는 것으로 프로젝트를 지원하고 조직의 목표와 수립된,

계약체결의 충족을 보장하는 데 반드시 필요한 자원과 인프라를 제공한다 전사 프로세스는.

전사 환경 관리 프로세스 투자 관리 프로세스 시스템 수명주기 프로세스 관리 프로세스, , ,

자원 관리 프로세스 품질 관리 프로세스들로 구성된다, .

프로젝트 프로세스프로젝트 프로세스프로젝트 프로세스프로젝트 프로세스(Project)(Project)(Project)(Project)■■■■

프로젝트 프로세스는 프로젝트 계획을 수립 및 발전시키고 계획에 대한 실제 성과와 진,

행을 평가하고 충족될 때까지 프로젝트의 실행을 제어하는 데 사용된다 개별 프로젝트 프.

로세스는 프로젝트 계획 또는 예측하지 못한 사건에서 필요한 경우 수명주기 내에서 언제든

지 프로젝트의 계층 구조의 어떠한 수준으로도 시작하며 프로젝트의 위험 요소와 복잡성에,

따라 엄격함과 형식성의 수준과 함께 프로젝트 프로세스에 적용된다 프로젝트 프로세스는.

- 35 -

프로젝트 계획 프로세스 프로젝트 평가 프로세스 프로젝트 통제 프로세스 의사결정 프로, , ,

세스 위험 관리 프로세스 형상 관리 프로세스 정보 관리 프로세스들로 구성된다, , , .

기술 프로세스기술 프로세스기술 프로세스기술 프로세스(Technical)(Technical)(Technical)(Technical)■■■■

기술 프로세스는 시스템에 대한 요구를 정의하고 그 요구를 효과적인 제품으로 전환하고

제품의 일관된 재생산을 가능하게 하고 필요할 경우에 제품을 사용하고 요구되는 서비스, ,

를 제공하고 이러한 서비스의 공급을 유지하고 제품이 서비스로부터 폐기된 경우 그 제품, ,

을 폐기하기 위해 사용된다 또한 사업과 프로젝트 기능이 시스템 이익을 최적화시키고 기.

술적 의사결정과 활동의 의해 발생하는 시스템 위험 요소를 감소시킬 수 있도록 해주는 활

동들을 정의하며 이러한 활동들은 제품과 서비스가 적시성과 가용성 비용 효율성 기능성, , , ,

신뢰성 사용 가능성 그리고 획득 및 공급 조직들에 의해 요구되는 다른 품질들을 포함하, ,

고 제품과 서비스가 보건 안전성 보안성 환경 요소들을 포함하는 사회의 기대 또는 규정, , , ,

된 요구사항과 일치하도록 지원한다 기술 프로세스는 이해관계자 요구사항 정의 프로세스. ,

요구사항 분석 프로세스 아키텍처 설계 프로세스 실행 프로세스 통합 프로세스 검증 프, , , ,

로세스 전환 프로세스 확인 프로세스 운영 프로세스 유지보수 프로세스 폐기 프로세스, , , , ,

들로 구성되어 있다.

부록부록부록부록■■■■

부록은 총 까지 총 개로 구성되어 있다 구성은 조정 프로세스ISO/IEC 15288 A-D 4 . ,

수명주기 단계 과의 관계 그리고 시스템 개념을 다루고 있다 각 부록의, ISO/IEC 12207 .

내용을 주요 내용을 간단하게 요약하면 아래와 같다.

부록 조정 프로세스A : (Tailoring Process)○

조정 프로세스는 수명주기 모델이 단계와 단계가 시스템 구축에 기여하는 것의 형태로 정

의되며 제품 또는 서비스 공급을 위한 계약체결 이행에 영향을 주는 개별 수명주기 단계가,

기술되고 변경 또는 신규 시스템 수명주기 프로세스가 정의된다, .

부록 수명주기 단계B :○

수명주기 모델링에 사용되는 시스템 수명주기 프로세스 내 하부구조를 구축하는데 사용된

며 개념설계단계 개발단계 생산단계(Concept Stage), (Development Stage),

운용단계 운용지원단계(Production Stage), (Utilization Stage), (Support Stage),

폐기단계 등 단계로 구성되어 있다(Retirement Stage) 6 .

- 36 -

Project Planning Project Assessment Project Control

Decision Making Risk Management Configuration Management Information Management

Stakeholder

Requirements

Definition

Requirements Analysis

Architectural Design

Validation

Transition

Verification

Integration

Operation

Maintenance

Disposal

Hardware Fabrication

Software CreationSoftware CreationSoftware CreationSoftware Creation

Refer toRefer toRefer toRefer to

ISO/IEC 12208:1995/AMD,1:2002ISO/IEC 12208:1995/AMD,1:2002ISO/IEC 12208:1995/AMD,1:2002ISO/IEC 12208:1995/AMD,1:2002

Operator Training

Implementation

Enterprise Environment

Management

Investment

Management

System Life Cycle

Processes Management

Resource Management

Quality Management

Acquisition

Supply

프로젝트프로젝트프로젝트프로젝트 프로세스프로세스프로세스프로세스

기술기술기술기술 프로세스프로세스프로세스프로세스

기업기업기업기업 프로세스프로세스프로세스프로세스

계약체결계약체결계약체결계약체결 프로세스프로세스프로세스프로세스

그림 과 의 관계그림 과 의 관계그림 과 의 관계그림 과 의 관계< 4-2> ISO/IEC 15288 12207< 4-2> ISO/IEC 15288 12207< 4-2> ISO/IEC 15288 12207< 4-2> ISO/IEC 15288 12207

부록 과 의 관계C : ISO/IEC 15288 12207○

시스템 수명주기를 구축하고 있는 을 설명하고 있다 시스템 요소가ISO/IEC 15288 .

개발될 때 시스템 요소의 특성에 대응되도록 적절한 표준이 적용된다 에서 구현되는 시. SW

스템 요소는 의 프로세스가 적용된다ISO/IEC 12207:1995/AMD.1:2002 . ISO/IEC

최종 발표 표준에서는 삭제되었으나 년도15288:2002 2001 FCD(Final Committee

에는 다음과 같이 과의 프로세스 수준이 비교되어 있다Draft) 12207 .

표 과 의 관계표 과 의 관계표 과 의 관계표 과 의 관계< 4-2> ISO/IEC 15288 12207< 4-2> ISO/IEC 15288 12207< 4-2> ISO/IEC 15288 12207< 4-2> ISO/IEC 15288 12207

ISO/IEC 15288

Enterprise Environment Management ProcessInvestment Management ProcessSystem Life Cycle Process Management Process

System Life Cycle Process Management Process, Enterprise Environment Process

Acquisition ProcessStakeholder Requirement Definition ProcessSupply ProcessRisk Management ProcessInformation Management ProcessRequirement Analysis ProcessArchitectural Design ProcessImplementation ProcessIntegration ProcessTransition ProcessTransition Process

Maintenance Process

← - → ISO/IEC 12207:1995/AMD.1:2002← - → ISO/IEC 12207:1995/AMD.1:2002

√ Management Process, Improvement Process√ Management Process, Improvement Process√ Infrastructure Process√ Infrastructure Process√ Supply Process√ Supply Process

√ Management Process, Improvement Process√ Management Process, Improvement Process

√ Acquisition Process√ Acquisition Process√ Development Process, Usability Process√ Development Process, Usability Process

√ Supply Process√ Supply Process√ Acquisition Process, Asset Management Process√ Acquisition Process, Asset Management Process

√ Documentation Process, Asset Management Process√ Documentation Process, Asset Management Process√ Development Process√ Development Process√ Development Process, Usability Process√ Development Process, Usability Process√ Development Process√ Development Process√ Development Process√ Development Process

√ Development Process√ Development Process√ Training Process√ Training Process√ Operation Process√ Operation Process√ Maintenance Process√ Maintenance Process

Operation Process

- 37 -

ISO/IEC 15288

Project Control Process

Disposal ProcessConfiguration Management ProcessProject Assessment ProcessQuality Management ProcessVerification ProcessValidation ProcessProject Assessment Process

Project Assessment ProcessEnterprise Environment Management Process

Resource Management Process

Decision Making Process

Project Assessment Process

Project Planning Process

Implementation

Project Assessment Process

← - → ISO/IEC 12207:1995/AMD.1:2002← - → ISO/IEC 12207:1995/AMD.1:2002

√ Human Resource Management Process√ Human Resource Management Process

√ Maintenance Process√ Maintenance Process√ Configuration Management Process√ Configuration Management Process√ Quality Assurance Process√ Quality Assurance Process√ Management Process√ Management Process√ Verification Process√ Verification Process√ Validation Process, Usability Process√ Validation Process, Usability Process

√ Joint Review Process√ Joint Review Process√ Audit Process√ Audit Process√ Audit Process√ Audit Process

√ Domain Engineering√ Domain Engineering

√ Product Evaluation Process√ Product Evaluation Process

√Management Process, Supply Process, Development Process√Management Process, Supply Process, Development Process

√ Tailoring Process√ Tailoring Process

√ Infrastructure Process√ Infrastructure Process

Tailoring Process

√ Management Process, Problem Resolution Process√ Management Process, Problem Resolution Process√ Management Process√ Management Process

Resource Management Process

√Problem Resolution Process, Development Process,Reuse Program Management Process√Problem Resolution Process, Development Process,Reuse Program Management Process

부록 시스템 개념 수명주기 개념에 대한 기술D : ,○

수명주기 단계수명주기 단계수명주기 단계수명주기 단계 목적목적목적목적 결정 게이트결정 게이트결정 게이트결정 게이트

개념설계단계이해당사자 요구사항 식별개념 탐색실행 가능한 해결책 제안 결정 대안- -

다음단계 실행․

현 단계 지속․

전단계로 복귀․

프로젝트 활동 보류․

프로젝트 종료․

개발단계

시스템 요구조건 상세 기술해결책 기술서 작성시스템 축조시스템 요건검증 및 요구검증

생산단계시스템 생산검사 및 시험평가

활용단계 사용자 요구사항을 만족하는 시스템 운영

지원단계 지속적인 시스템 능력 제공

폐기단계 시스템의 보관문서화 또는 폐기․

표 단계 단계의 목적 및 중요 결정 게이트표 단계 단계의 목적 및 중요 결정 게이트표 단계 단계의 목적 및 중요 결정 게이트표 단계 단계의 목적 및 중요 결정 게이트< 4-3> ,< 4-3> ,< 4-3> ,< 4-3> ,

시스템 공학 적용 가이드4.2 ISO/IEC TR 19760 -ISO/IEC 15288

목적목적목적목적4.2.14.2.14.2.14.2.1

이 기술 보고서는 시스템 수명주기 프로세스 표준 이후부터는 국제표ISO/IEC 15288 (

준이라 한다 의 실행을 위한 가이드라인을 제공한다 대형 및 소형 시스템 대형 및 소형) . ,

- 38 -

프로젝트 팀을 필요로 하는 시스템 그리고 신규 또는 기존 시스템에 적용이 가능하다 본, .

가이드에 포함된 지침들은 국제표준의 부록 와 본 기술 보고서 절의 지침을 이용하여 시A 4

스템 크기 프로젝트 인력 그리고 시스템 형태에 알맞게 조정될 수 있다, , . ISO/IEC TR

은 국제표준의 실행을 지원하는 문서뿐만 아니라 국제표준의 실행 효율성을 평19760 ISO

가하기 위한 문서들과의 링크를 제공한다ISO .

은 국제표준을 실행할 때 고려될 수 있는 요소들을 상세히 설명하ISO/IEC TR 19760

고 있다 또한 설명은 국제표준이 적용될 수 있는 다양하고 이해하기 쉬운 방법들을 통하여.

이루어진다.

사용전 숙지 사항사용전 숙지 사항사용전 숙지 사항사용전 숙지 사항4.2.2 ISO/IEC TR 197604.2.2 ISO/IEC TR 197604.2.2 ISO/IEC TR 197604.2.2 ISO/IEC TR 19760

을 적용하기 위해서는 사용자가 의 가용성ISO/IEC TR 19760 ISO/IEC 15288 ,

에 대한 친숙성 관련 조직 및 프로젝트 정책에 대한 친숙성 프로젝트 관ISO/IEC 15288 , ,

리 및 시스템 공학 시스템 라이프 사이클 모델에 대한 일반적 이해 등과 같은 조건을 구비,

하고 있어야 한다.

기술보고서 추진 경과기술보고서 추진 경과기술보고서 추진 경과기술보고서 추진 경과4.2.34.2.34.2.34.2.3

표 기술보고서 추진 경과표 기술보고서 추진 경과표 기술보고서 추진 경과표 기술보고서 추진 경과< 4-4>< 4-4>< 4-4>< 4-4>

문서코드문서코드문서코드문서코드 일자일자일자일자 설명설명설명설명

WG 7 N0388 년 월 일2000 9 1 WD1 (Working Draft 1)

WG 7 N0423 년 월 일2001 1 10 WD2 (Working Draft 2)

WG 7 N0475 년 월 일2001 8 6 WD3 (Working Draft 3)

WG 7 N0557 년 월 일2002 1 1 PDTR (Proposed Draft TR)

WG 7 N0578 년 월 일2002 1 11 PDTR (Proposed Draft TR)

ISO/IEC TRISO/IEC TRISO/IEC TRISO/IEC TR

19760:200319760:200319760:200319760:2003년 월 일년 월 일년 월 일년 월 일2003 11 152003 11 152003 11 152003 11 15

System engineering- A guide for application ofSystem engineering- A guide for application ofSystem engineering- A guide for application ofSystem engineering- A guide for application of

ISO/IEC 15288(System life cycle processes)ISO/IEC 15288(System life cycle processes)ISO/IEC 15288(System life cycle processes)ISO/IEC 15288(System life cycle processes)

의 구성의 구성의 구성의 구성4.2.4 ISO/IEC TR 197604.2.4 ISO/IEC TR 197604.2.4 ISO/IEC TR 197604.2.4 ISO/IEC TR 19760

구성구성구성구성4.2.4.14.2.4.14.2.4.14.2.4.1

시스템 공학 표준 적용을 위한 가이드ISO/IEC TR 19760 -15288 (System

는 년 월engineering-A guide for the application of ISO/IEC 15288) 2003 11

일에 발표되었다 총 장으로 구성되어 있으며 장에서 장까지는 본 기술 보고서의 범15 . 8 , 1 3

- 39 -

위와 목적 참고문헌 및 표준들의 전후관계를 기술하고 있다, .

장에서는 표준 사용을 위한 사용 개념 및 프로세스에 대한 조정을 다루고 있으4 15288

며 장에서는 시스템 프로젝트 시스템 수명주기의 개념을 설명함으로써 전반적인 표준의, 5 , ,

개념을 설명하고 있다 장과 장에서는 수명주기에 따른 국제 표준 프로세스의 적용에 대. 6 7

해 기술하고 있다 마지막으로 장에서는 조직에 의한 적용을 다룬다 부록은 개로 구성되. 8 . 3

어 있으며 본 표준과 다른 표준과의 관계 시스템 설계에 영향을 주는 요인 표준 프로세스, , ,

적용을 위한 요지를 기술하고 있다.

주요 내용주요 내용주요 내용주요 내용4.2.4.24.2.4.24.2.4.24.2.4.2

본 기술 보고서는 각 조직의 업무 특성 업무 전략 그리고 제품 또는 서비스를 위한 가, ,

용 기술들에 의해 운영된다 이들 변수들은 활용 가능한 사업 기회들에 제약 요소들을 제공.

한다 기회를 활용하기 위해 조직은 조직 프로젝트의 수행과 직무상의 조직 관리를 위한 정.

책과 프로세스를 수립한다 이러한 정책과 프로세스들의 수립을 지원하고 조직이 필요로 하.

는 자원들을 결정하기 위해 조직의 특정 표준화 프로세스와 하나 이상의 라이프 사이클 모

델들을 제공할 목적으로 국제표준을 사용할 수 있다.

ISO/IEC 15288ISO/IEC 15288ISO/IEC 15288ISO/IEC 15288

시스템시스템시스템시스템 수명주기수명주기수명주기수명주기

프로세스프로세스프로세스프로세스

단계단계단계단계

ISO/IEC 15288ISO/IEC 15288ISO/IEC 15288ISO/IEC 15288

시스템시스템시스템시스템 수명주기수명주기수명주기수명주기

프로세스프로세스프로세스프로세스

단계단계단계단계

조직

Social Responsibilities

Business strategy

사업의 특성

Domain of products

Regulatory considerations

기업

Policies and

Procedures

Resources

기업 통제

Decision gates and milestones

Resource availability

Expertise and skills availability

Technology availability

프로젝트

계획

Teams

Structure

계약체결

요구사항

일정

적용

프로세스

절차

시스템 수명주기 모델

Applicable stages

제약사항

범위 조정

프로세스 조정

사업착수Legend

System Life Cycle

주 흐름

제약사항

영향

그림 국제 표준의 사용 개념그림 국제 표준의 사용 개념그림 국제 표준의 사용 개념그림 국제 표준의 사용 개념< 4-3>< 4-3>< 4-3>< 4-3>

- 40 -

- 41 -

시스템 수명주기 프로세스

프레임워크 설계

- 42 -

- 43 -

시스템 수명주기 프로세스 프레임워크 설계5.

시스템수명주기 프로세스 프레임워크시스템수명주기 프로세스 프레임워크시스템수명주기 프로세스 프레임워크시스템수명주기 프로세스 프레임워크5.15.15.15.1

프레임워크 설계 방안프레임워크 설계 방안프레임워크 설계 방안프레임워크 설계 방안5.1.15.1.15.1.15.1.1

시스템 수명주기 프로세스 프레임워크의 내용은 기본적으로 가장 최근의 국제표준인

의 내용을 기반으로 작성하였다 년에 공표된 시스템 공학 시스템ISO/IEC 15288 . 2002 -

수명주기 프로세스 구성은 총 장과 개의 부록으로 구성되어 있다 장에서 장까지는6 4 . 1 4

표준에 대한 범위 목적 적용 제한사항 및 용어 등에 대해서 기술하고 있으며 장에서, , , , 5

는 개의 시스템 수명주기 프로세스 개의 프로세스 성과 및 개의 활25 , 123 (outcome) 205

동에 대해서 기술하고 있다.

하지만 은 해당하는 프로세스의 목적 활동 성과를 서술식으로 기술함ISO/IEC 15288 , ,

에 따라 기본적인 시스템 수명주기의 내용과 구성을 제시하기 위한 프레임워크 성격에 맞

지 않는 부분이 있으며 사용하는 용어 또한 또는 에서, ISO/IEC 12207 IEEE 12207

사용하고 있는 용어와 달라 우리나라에서 그대로 번역하여 사용하는데 어려움이 있다.

따라서 본 프레임워크에서는 프로세스의 구성을 목적 활동 산출물로 하면서 내용을 최, ,

대한 간략하게 구성하고자 하였다 목적부분은 전체의 내용을 간략하게 기술하고 활동부. ,

분의 경우는 최대한 명사 형태로 간략하게 작성하여 기존 발주관리 표준 프로세스와 동일

한 형태의 활동을 갖도록 하였다 산출물은 현재 성과 형태로 서술식으로 기술하고 있는.

내용을 본문의 내용을 기초로 산출물로 제시하였다 산출물에 대한 제시는. ISO/IEC

표준 본문에서 기술하고 있는 내용과 더불어 소프트웨어 공학 프로세스 테크놀로15288

지 에서 출판한 시스템 문서(Software Engineering Process Technology, SEPT) ‘

관리계획을 위한 템플릿(Template For a System Documentation Management

에서 기술하고 있는 산출물을 전부 수용하였고 공공부분 발주관리 표준 프로세스Plan)’ ,

지침을 만들면서 얻은 경험을 토대로 하여 각 프로세스와 활동에 필요한 추가적인 산출물

들을 제시하였다 시스템수명주기 프로세스 프레임워크 설계의 기본 원칙을 다시 한번 요.

약하면 다음과 같다.

의 프로세스 및 활동을 전부 수용함ISO/IEC 15288 .■

- 44 -

의 성과 를 성과의 취지를 고려하여 산출물로 대체하였ISO/IEC 15288 (outcome)■

음.

산출물은 의 산Template For a System Documentation Management Plan■

출물을 전부 수용하고 각 프로세스와 할동에 필요한 추가 산출물 제시하였음.

부록에 다음과 같은 사항들을 추가하였음.■

프로세스 활동 산출물 매트릭스- / -

산출물의 목적을 설명하는 산출물 기술서 추가-

산출물을 작성하기 위한 문서작성 절차-

시스템수명주기 프로세스와 발주관리 프로세스의 연계방안-

표 시스템수명주기 프로세스 프레임워크 설계방안표 시스템수명주기 프로세스 프레임워크 설계방안표 시스템수명주기 프로세스 프레임워크 설계방안표 시스템수명주기 프로세스 프레임워크 설계방안< 5-1>>< 5-1>>< 5-1>>< 5-1>>

- 45 -

프레임워크 구성프레임워크 구성프레임워크 구성프레임워크 구성 참조 문서참조 문서참조 문서참조 문서

장 배경1

장 개요2

장 참조문서3

장 용어4

장 장- ISO/IEC 15288 1 ~4

공공부문 소프트웨어 발주관리 표준 프로세스 지침- ,

2004

장 시스템 수명주기 프로세스5

프레임워크장- ISO/IEC 15288 5 (P.5 ~ P.39)

목적 장- ISO/IEC 15288 5 Purpose

활동 장- ISO/IEC 15288 5 Activities

산출물- Template For a System Documentation

Management Plan, SEPT, 2004

부록 수명주기 단계A

- ISO/IEC 15288 Annex D D.2 Life Cycle

Concepts(P.56)

- ISO/IEC TR 19760 7.2.1 Approaches(P.34)

부록 프로세스별 활동B -

산출물 매트릭스

- Template For a System Documentation

Management Plan, SEPT, 2004

- Evidence Product Checklist for ISO/IEC Standard

15288-System Engineering-System Life Cycle

Process, SEPT, 2002

부록 산출물 기술서C

- Template For a System Documentation

Management Plan, SEPT, 2004

- Evidence Product Checklist for ISO/IEC Standard

15288-System Engineering-System Life Cycle

Process, SEPT, 2002

부록 문서작성절차D- Template For a System Documentation

Management Plan, SEPT, 2004

부록 시스템 수명주기 표준E

프로세스와 발주관리

표준 프로세스 연계

- New Work Item Proposal-Revision of ISO/IEC

12207 Systems and Software Engineering-Software

Life Cycle Processes, ISO/IEC JTC1/SC7, 2005

공공부문 소프트웨어 발주관리 표준 프로세스 지침- ,

2004

프레임워크 수준 및 구성프레임워크 수준 및 구성프레임워크 수준 및 구성프레임워크 수준 및 구성5.1.25.1.25.1.25.1.2

본 시스템수명주기 프로세스 프레임워크의 구성은 총 장과 개의 부록으로 구성되어 있5 5

다 장에서 장까지는 표준에 대한 범위 목적 적용 제한사항 및 용어 등에 대해서 기술. 1 4 , , ,

하고 있으며 장에서는 개의 시스템 수명주기 프로세스 개의 활동 및 개의 산, 5 25 , 205 166

출물을 기술하고 있다 부록에서는 수명주기 단계 산출물 문서작성. (Life Cycle Stages), ,

절차 시스템 수명주기 표준 프로세스와 발주관리 표준 프로세스 비교 및 시스템 수명주기,

표준과 발주관리 표준과의 활용방안에 대해서 기술하고 있다.

- 46 -

구분구분구분구분

프로세스 그룹프로세스 그룹프로세스 그룹프로세스 그룹 프로세스프로세스프로세스프로세스 활동활동활동활동 산출물산출물산출물산출물

계약 2 17 24

전사 5 34 15

프로젝트 7 57 55

기술 11 94 72

합계합계합계합계 개4 개25 개205 166

표 시스템 수명주기 프로세스 구성표 시스템 수명주기 프로세스 구성표 시스템 수명주기 프로세스 구성표 시스템 수명주기 프로세스 구성< 5-2>< 5-2>< 5-2>< 5-2>

- 47 -

프레임워크 프로세스 연관관계프레임워크 프로세스 연관관계프레임워크 프로세스 연관관계프레임워크 프로세스 연관관계5.1.35.1.35.1.35.1.3

프로세스간의 연관관계는 개의 계약 전사 프로젝트 기술로 프로세스 그룹을 중심으로4 , , ,

하여 상호간에 요구되는 인터페이스 사항을 보여준다 본 프레임워크에서는. ISO/IEC

의 기술 프로세스를 개발 프로세스와 운영 유지보수 프로세스로 구분하였다 그림에15288 / .

서와 같이 주로 개발 프로세스 산출물내지는 결과를 바탕으로 프로젝트 프로세스에서 개발

프로세스를 관리를 하며 전사 프로세스를 통해 시스템 수명주기 프로세스의 정책 또는 절,

차를 정의한다.

획득획득획득획득획득획득획득획득 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

공급공급공급공급공급공급공급공급 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 계획계획계획계획계획계획계획계획 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 통제통제통제통제통제통제통제통제 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 의사결정의사결정의사결정의사결정의사결정의사결정의사결정의사결정

프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

위험관리위험관리위험관리위험관리위험관리위험관리위험관리위험관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

형상관리형상관리형상관리형상관리형상관리형상관리형상관리형상관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 평가평가평가평가평가평가평가평가 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

전사전사전사전사전사전사전사전사 환경환경환경환경환경환경환경환경 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

투자투자투자투자투자투자투자투자 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

시스템시스템시스템시스템시스템시스템시스템시스템 수명주기수명주기수명주기수명주기수명주기수명주기수명주기수명주기 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

자원자원자원자원자원자원자원자원 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

품질품질품질품질품질품질품질품질 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

이해당사자이해당사자이해당사자이해당사자이해당사자이해당사자이해당사자이해당사자 요구사항요구사항요구사항요구사항요구사항요구사항요구사항요구사항

정의정의정의정의정의정의정의정의 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

요구사항요구사항요구사항요구사항요구사항요구사항요구사항요구사항 분석분석분석분석분석분석분석분석 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

아키텍처아키텍처아키텍처아키텍처아키텍처아키텍처아키텍처아키텍처 설계설계설계설계설계설계설계설계 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

구현구현구현구현구현구현구현구현 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

통합통합통합통합통합통합통합통합 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

검증검증검증검증검증검증검증검증 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

전환전환전환전환전환전환전환전환 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

확인확인확인확인확인확인확인확인 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

운영운영운영운영운영운영운영운영 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

유지보수유지보수유지보수유지보수유지보수유지보수유지보수유지보수 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

폐기폐기폐기폐기폐기폐기폐기폐기 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

운영/유지보수 프로세스

개발프로세스

5.5 5.5 5.5 5.5 5.5 5.5 5.5 5.5 기술프로세스기술프로세스기술프로세스기술프로세스기술프로세스기술프로세스기술프로세스기술프로세스5.2 5.2 5.2 5.2 5.2 5.2 5.2 5.2 계약프로세스계약프로세스계약프로세스계약프로세스계약프로세스계약프로세스계약프로세스계약프로세스

5.4 5.4 5.4 5.4 5.4 5.4 5.4 5.4 프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

5.3 5.3 5.3 5.3 5.3 5.3 5.3 5.3 전사프로세스전사프로세스전사프로세스전사프로세스전사프로세스전사프로세스전사프로세스전사프로세스

타당한 솔루션

작업지시

대안제공

재 지시

작업산출물

평가

계획/요구사항계획갱신

요구사항

승

인

된

산

출

물

정책/절차

지원

/

보고

/

검토

공급/산출물획득요구/계약

그림 시스템 수명주기 프로세스 연관관계그림 시스템 수명주기 프로세스 연관관계그림 시스템 수명주기 프로세스 연관관계그림 시스템 수명주기 프로세스 연관관계< 5-1>< 5-1>< 5-1>< 5-1>

- 48 -

프로세스 활동 구성프로세스 활동 구성프로세스 활동 구성프로세스 활동 구성5.1.45.1.45.1.45.1.4

아래의 프로세스 활동 구성도는 에 서술식으로 기술되어 있는 활동ISO/IEC 15288

을 명칭화하여 도식한 것이다 의 프로세스와 활동을 기술한(Activity) . ISO/IEC 12207

형식으로 으로 표현함으로써 전체적인 프로세스와 활동을 보다 쉽게 파악할 수 있으며 다,

른 표준과의 구성 및 내용을 비교할 수 있도록 하였다.

5.2 5.2 계약계약계약계약계약계약계약계약 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

전사전사전사전사전사전사전사전사 환경환경환경환경환경환경환경환경 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

사업분야계획수립

수명주기정책/절차를준비

역할/책임/권한정의

수명주기모델의주기적검토

정책/절차공유

시스템시스템시스템시스템시스템시스템시스템시스템 수명주기수명주기수명주기수명주기수명주기수명주기수명주기수명주기 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

시스템수명주기프로세스수립

테일러링정책/절차수립

방법/도구식별

평가척도수립

프로세스실행관찰

사업기준을정의

5.3 5.3 전사전사전사전사전사전사전사전사 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

투자투자투자투자투자투자투자투자 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

투자계획수립

프로젝트책임/권한정의

예측산출물식별

자원할당

프로젝트인터페이스식별

보고/검토회일정명시

프로젝트평가

프로젝트조정

프로젝트지연/취소

프로세스개선기회식별

프로세스/방법/도구개선

자원자원자원자원자원자원자원자원 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

자원지원항목결정/제공

인적요소외자원확보

인력유지/관리

참여인력동기부여

다수프로젝트의관리인터페이스통제

품질품질품질품질품질품질품질품질 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

품질관리정책/표준/절차수립

품질관리목적/목표수립

책임권한정의

고객만족/결과보고서평가

주기적품질계획검토

품질개선상태관찰

프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 계획계획계획계획계획계획계획계획 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

프로젝트목표/제약사항식별

프로젝트범위정의

과업분할구조(WBS) 작성

프로젝트성과척도정의

프로젝트비용정의및예산계획

프로젝트 평가 프로세스

프로젝트상태평가

품질보증수행

프로젝트팀평가

지원인프라적정성/가용성평가

프로젝트진척평가

프로젝트일정정의/유지

5.4 5.4 프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 통제통제통제통제통제통제통제통제 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

요구및변경사항관리

교정활동수행

예방활동수행

문제해결활동수행

변화관리

계약변경활동수행

계약교정활동수행

프로젝트승인

관리및기술적검토/신기술관찰

데인터분석및권고

형상관리형상관리형상관리형상관리형상관리형상관리형상관리형상관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

형상관리전략정의

형상통제항목식별

책임/권한구조수립

인프라/서비스정의

외부프로젝트와연계한획득정의

성과척도/연관자료정의

프로젝트품질계획수립

기술관리계획수립/시행

주기적보고서제공

의사결정의사결정의사결정의사결정의사결정의사결정의사결정의사결정 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

의사결정전략정의

의사결정과정참여

환경/요구사항식별

의사결정전략선정및성공척도식별

대안활동결과평가

결과기록/추적/평가/보고

처리결과기록유지

위험관리위험관리위험관리위험관리위험관리위험관리위험관리위험관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

위험접근방법수립

위험식별/정의

위험확률결정

위험평가

위험우선순위부여

위험취급전략결정

위험수용한계정의

위험취급활동식별

위험관련의사소통

위험기록유지

그림 프로세스 활동 구성그림 프로세스 활동 구성그림 프로세스 활동 구성그림 프로세스 활동 구성< 5-2>< 5-2>< 5-2>< 5-2>

- 49 -

시스템수명주기 프로세스와 발주관리 지침 연계방안시스템수명주기 프로세스와 발주관리 지침 연계방안시스템수명주기 프로세스와 발주관리 지침 연계방안시스템수명주기 프로세스와 발주관리 지침 연계방안5.25.25.25.2

과 통합방안 제안 분석과 통합방안 제안 분석과 통합방안 제안 분석과 통합방안 제안 분석5.2.1 ISO/IEC 15288 ISO/IEC 122075.2.1 ISO/IEC 15288 ISO/IEC 122075.2.1 ISO/IEC 15288 ISO/IEC 122075.2.1 ISO/IEC 15288 ISO/IEC 12207

본 연구에서 제안한 시스템 수명주기 프로세스와 공공부분 발주관리 지침과의 연계S/W

방안에 관련하여 과제 수행기간 동안 다양한 접근을 시도했다 그 중에서도 캐나다에서.

과 을 통합하기 위해 제안한 방법을 벤치마킹하여 적용ISO/IEC 15288 ISO/IEC 12207

하려는 시도를 해보았다.

이 제안에서는 과 이 사용하는 용어와 기술하는 상ISO/IEC 15288 ISO/IEC 12207

세화 정도 가 서로 상이하여 이를 함께 이용하는데 많은 문제가 있음을 인식하고(Level) ,

공통용어 사용 이용 가능한 공통 프로세스 이름 사용 통합 등을 통해, , 12207 AMD

및 를 연계 및 통합함으로써 수명주기 전반에 걸친 호환성과15288:2002 12207:1995

일관성을 유지하며 최대한 일관성 있는 용어와 개념을 사용하도록 하였다 이를 간단히 요.

약하면 다음과 같다.

현재 표준인 과 제안한12207 AMD, 12207:1995, 15288:2003 12207R, 15288R

과의 관계는 아래 그림과 같다.

그림 표준과 제안방법과의 비교그림 표준과 제안방법과의 비교그림 표준과 제안방법과의 비교그림 표준과 제안방법과의 비교< 5-3>< 5-3>< 5-3>< 5-3>

- 50 -

에서 프로세스는 의 프로세스와 같고 이는 에 그대12207 AMD 12207:1995 , 12207R

로 반영되고 각 프로세스의 목적과 결과물 또한 에 반영된다 의 컴12207R . 12207 AMD

포넌트 프로세스는 의 활동과 같고 이는 의 컴포넌트 일부 프로세스12207:1995 12207R

와 일부 활동에 반영된다 의 컴포넌트 프로세스의 일부 목적은 의. 12207 AMD 12207R

컴포넌트 프로세스의 목적이 되며 나머지 다른 목적과 결과물은 의 부록에12207R PRM

반영된다 의 작업은 의 작업에 반영되며 의 리스트는. 12207:1995 12207R 12207:1995

의 노트에 반영된다12207R .

의 프로세스와 각 프로세스의 목적과 결과는 의 프로세스 및 목적15288:2003 15288R

과 결과에 반영되고 부록의 목적과 결과물에도 반영된다 에는 활동이라는PRM . 15288R

상세화 정도 레벨이 프로세스 아래에 추가된다 이는 과 상세화를 정도를 맞추기 위. 12207

해 추가시킨 것이다 의 활동과 노트는 각각 의 작업과 노트에 그대. 15288:2003 15288R

로 반영된다.

시스템수명주기 프로세스와 발주관리 지침 연계방안시스템수명주기 프로세스와 발주관리 지침 연계방안시스템수명주기 프로세스와 발주관리 지침 연계방안시스템수명주기 프로세스와 발주관리 지침 연계방안5.2.25.2.25.2.25.2.2

캐나다에서 제안한 방법대로 시스템 수명주기 프로세스와 발주관리 지침을 연계하기 위해

서는 다음과 같은 제한점이 있다 첫째는 을 그대로 가감없이 수용하는. ISO/IEC 15288

것을 기본 원칙으로 했다 그러므로 시스템수명주기 프로세스를 기반으로 발주관리 지침을.

용어의 통일 프로세스 활동 등의 조화를 통한 접근을 시도할 경우는 기존에 개발된 발주관,

리 지침의 많은 변경이 요구된다 이 방법은 현재 시점에서 불가능하다는 결론에 도달했다. .

두 번째로는 발주관리 지침을 기반으로 시스템수명주기 프로세스를 통합시키는 방안이 있울

수 있다 이 방법은 발주관리 지침을 수정없이 활용할 수는 있으나 을 그. ISO/IEC 15288

대로 수용한다는 기본 원칙에 위배된다 그러므로 본 연구에서는 다음 그림과 같이 시스템.

수명주기 프로세스를 기반으로 그대로 사용하면서 소프트웨어 개발 부분ISP/IEC 15288

을 발주관리지침의 요구사항 분석 구조설계 상세설계 코딩 및 단S/W , S/W , S/W , S/W

위시험 통합 자격시험 부분만을 활용하는 방향으로 결론을 맺었다 이 방법이, S/W , S/W .

국제표준을 그대로 수용하면서 발주관리 지침을 활용할 수 있는 현재 시점에서의 최적 대안

이라는 것이 본 연구 수행팀의 제안이다.

- 51 -

기술기술기술기술 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹기술기술기술기술 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹

개발개발개발개발 프로세스프로세스프로세스프로세스

이해당사자요구사항정의

이해당사자요구사항정의

요구사항분석

요구사항분석

아키텍처설계

아키텍처설계

S/WS/WS/WS/W요구사항요구사항요구사항요구사항분석분석분석분석

S/WS/WS/WS/W구조구조구조구조설계설계설계설계

S/WS/WS/WS/W상세상세상세상세설계설계설계설계

S/WS/WS/WS/W코딩코딩코딩코딩 및및및및단위시험단위시험단위시험단위시험

S/WS/WS/WS/W통합통합통합통합

S/WS/WS/WS/W자격자격자격자격시험시험시험시험

구현구현 통합통합 검증검증 전환전환 확인확인 운영운영

계약계약계약계약 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹계약계약계약계약 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹

프로젝트프로젝트프로젝트프로젝트 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹프로젝트프로젝트프로젝트프로젝트 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹

전사전사전사전사 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹전사전사전사전사 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹

개념단계개념단계개념단계개념단계 개발단계개발단계개발단계개발단계 생산단계생산단계생산단계생산단계 운용운용운용운용

시스템

시스템

시스템

시스템수명주기

수명주기

수명주기

수명주기

프로세스

프로세스

프로세스

프로세스

소프트웨어

소프트웨어

소프트웨어

소프트웨어

발주관리

발주관리

발주관리

발주관리프로세스

프로세스

프로세스

프로세스

그림 시스템수명주기 프로세스와 발주관리 지침 연계방안그림 시스템수명주기 프로세스와 발주관리 지침 연계방안그림 시스템수명주기 프로세스와 발주관리 지침 연계방안그림 시스템수명주기 프로세스와 발주관리 지침 연계방안< 5-4>< 5-4>< 5-4>< 5-4>

참고문헌

- 52 -

- 53 -

참고문헌6.

ISO/IEC 15288 Systems engineering-System life cycle processes :∙

INTERNATIONAL STANDARD , 2002-11-01

ISO/IEC TR 19760 Systems engineering - A guide for the application∙

of ISO/IEC 15288(System life cycle processes), 2003-11-15

ISO/IEC 12207:1995/AMD1:2002 Amendment to 12207∙

ISO/IEC 12207:1995/AMD2:2004 Amendment to 12207∙

MIL-STD-499A(USAF) MILITARY STANDARD Engineering∙

Management , 1969-07-17

IEEE 1220 Standard for Application and Management of the Systems∙

Engineering Process , 1998-12-08

EIA-632 Processing for Engineering a System , 1999-01-07∙

NASA System Engineering Handbook, Shishko, Robert and R. G.∙

Chamberlain Draft, 1992

INCOSE, System Engineering Handbook, V.10(1998), 2.0(2000) &∙

3.0(2004)

Concurrent Engineering & Integrated Product Development Handbook∙

to Understanding and Implementation, Office of the Assistant

Secretary of Defence(Production and Logistics) Wash, D. D.

20301-8000

Integrated Logistics Support Guide, DSMC, Fort Belvoir, VA∙

- 54 -

Risk Management; Concepts and Guidance, DSMC, Fort Belvoir, VA∙

ANSI/AIAA G-043-1992, Guide for the Preparation of Operational∙

Concept Documents

MIL-STD-498, "Software Development and Documentation", December∙

1994.

IEEE/EIA 12207.0, "Software Life Cycle Processes", March 1998.∙

IEEE/EIA 12207.1, "Software Life Cycle Processes - Life Cycle Data",∙

April 1998.

IEEE/EIA 12207.2, "Software Life Cycle Processes - Implementation∙

Considerations", April 1998.

- 55 -

부록 A

시스템 수명주기 프로세스 프레임워크

- 56 -

- 57 -

부록 시스템 수명주기 프로세스 프레임워크A

배경1.

현실태 및 문제점현실태 및 문제점현실태 및 문제점현실태 및 문제점1.11.11.11.1

년부터 정통부에서는 소프트웨어 수명주기인 을 기반으로 국내 현2002 ISO/IEC 12207

실에 적합한 공공기관발주관리 지침을 개발하여 정통부에서 제도화하려는 시도 중에 있다.

이와 더불어 소프트웨어가 단독으로 동작하는 관점에서 벗어나 시스템 차원에서의 소프트웨

어 작동을 포함하는 시스템 공학의 중요성이 대두되어 현재 국제표준인 ISO/IEC 15288

을 기반으로 국내 현실에 맞는 시스템 공학 수명주기의 프레임워크를 개발하려하고 있다.

이 보고서는 그러한 연구의 일환으로 시스템 공학의 개념을 정의하고 기존의 관련 시스템

공학 표준들을 분석한 후 최근의 을 기반으로 국내 환경에 적합한 시스, ISO/IEC 15288

템 공학 프레임워크를 개발하는데 그 목적이 있다 금년 프레임워크가 확정되면 지속적으로.

프레임워크를 실현할 수 있는 후속지침의 개발이 필요할 것이다 또한 을. ISO/IEC 12207

기반으로 개발된 공공기관 발주관리 지침과의 연계로 효과적이고 효율적인 시스템 획득을

지원하는 프레임워크의 개발을 염두에 두고 있다.

해외현황 및 시사점해외현황 및 시사점해외현황 및 시사점해외현황 및 시사점1.21.21.21.2

년 월 국제적인 표준을 제정하는 국제표준화기구2002 10 (ISO, International

에서 처음으로 하드웨어 소프트웨어 및 인간Organization for Standardization) ,

과의 인터페이스를 다루는 시스템 수명주기 프로세스 표준인 ISO/IEC

를 발행하였15288:2002 System Engineering-System Life Cycle Process

다 이는 년 월에 의 에서 초안 이 작성된. 1996 7 ISO/IEC JTC1/SC7 WG7 (N121)

이후 년간의 작업을 거쳐 표준으로 제정되었다 이후 년 월에는6 . 2003 11 ISO/IEC

에 대한 가이드로서15288 ISO/IEC TR 19760 System Engineering-A guide

을 발행하였다for the application of ISO/IEC 15288 .

이처럼 시스템 수명주기 표준이 공식적으로 발표되고 활용되기 시작한 것은 불과 년2~3

에 불과하다 따라서 실제 본 표준에서 제시하고 있는 시스템 수명주기의 단계와 프로세스.

들을 활용하여 해당되는 관리 분야 또는 프로젝트에 적용하고 그 효과를 나타내기에는 아직

- 58 -

시기상조이다 반면에 년부터 시스템 수명주기 프로세스에 대한 논의가 항공 및 우주. 1996

산업 군수 산업과 같은 거대 시스템 기업들이 시스템 수명주기에 관심을 갖고 참여하였고, ,

미국의 국제 시스템 공학 협의회(INCOSE, International Council on System

및 미 표준기구인 에서도 적극적으로 참여Engineering) IEEE Computer Society(CS)

하여 의견을 반영함으로써 활용성에 대한 기대는 높다고 할 수 있다.

의 활용 현황은 본 표준이 시스템 및 소프트웨어 공학 분야의 다양한ISO/IEC 15288

국제 표준에 있어서 하위 또는 특정 분야의 표준들에 대해 기본적인 상위표준(Principle

이고 공식적인 표준이 발행되고 적용하는 기간이 짧아서 표준적용에 대한 효과Standard)

측정은 어렵다고 볼 수 있다.

개요2.

목적목적목적목적2.12.12.12.1

본 표준은 사람이 만드는 시스템의 수명주기를 기술하는데 사용되는 보편적 틀을 구축하

고 있다 본 표준은 시스템 수명주기와 관련된 프로세스 집합과 그와 관련된 용어를 정의하.

고 있다 프로세스는 시스템 구조 계층내 어떤 수준에서도 적용될 수 있다 프로세스의 선. .

택된 집합은 시스템 수명주기 단계를 관리하고 실행하는데 수명주기 동안 계속 사용될 수

있다 이는 고객만족 달성의 궁극적 목적을 갖고 있는 모든 이해당사자 참여를 통하여 완수.

된다.

본 표준은 조직 또는 프로젝트 내에서 활용되는 수명주기 프로세스의 정의 통제 및 개선,

을 지원하는 프로세스를 제공한다 조직과 프로젝트가 시스템을 획득하거나 공급할 때 본.

표준이 정한 수명주기 프로세스를 활용할 수 있다.

적용적용적용적용2.22.22.22.2

본 표준은 시스템의 개념설계 개발 생산 활용 지원 및 폐기를 포함한 시스템 수명주기, , , ,

모든 과정에 적용되고 조직 내부 또는 외부에서 완성되는 시스템의 획득과 공급에도 적용,

된다 본 표준의 수명주기 프로세스는 시스템과 그 구성요소에 대하여 동시적이며 반복적이.

고 순환적으로 적용될 수 있다.

시스템의 목적 응용영역 복잡성 규모 신규성 적응성 양 위치 수명기간 및 진화 등, , , , , , , ,

- 59 -

때문에 시스템의 광범위한 다양성이 존재한다 본 표준은 모든 인위적 시스템의 수명주기를.

구성하는 프로세스를 기술하고 있다 그러므로 본 표준은 특정 시스템의 하나 대량생산 시. ,

스템 및 개조 적응형 시스템에 적용된다, .

본 표준은 시스템 획득자과 공급자 모두의 역할을 하는 조직에 대하여도 적용된다 여기.

에는 자기 스스로 책임과 의무를 부과한 단일 이해당사자 또는 다수 이해당사자의 상황에

도 적용될 수 있다 이해당사자는 같은 조직 또는 다른 조직일 수도 있으며 그와 같은 상. ,

황은 비공식적 계약체결에서부터 공식적 계약체결에 까지 광범위 하다.

본 표준이 정한 프로세스는 비즈니스 환경 즉 방법 기법 도구 훈련된 전문인력 구축의, , , ,

기초로 활용될 수 있다 이는 프로세스의 성공적 실행의 결과로 발생되는 프로세스 성과와.

프로세스 목적으로 특징 지워지는 프로세스 기준모델을 제공한다 그러므로 본 표준은.

에서 규정한 지원프로세스 평가의 기준 모델로 활용될 수 있다ISO/IEC TR 15504-2 .

또한 국제표준은 다음 형태중의 하나 또는 그 이상의 방법으로 활용되어 질 수 있다.

-조직에 의한 활용조직에 의한 활용조직에 의한 활용조직에 의한 활용 바람직한 프로세스 환경을 구축하는데 도움을 준다 조직에 의하여: .

활용되는 프로세스는 방법 절차 기법 도구 및 훈련된 전문가의 하부구조에 의하여 지, , ,

원될 수 있다 조직은 프로젝트를 실행하고 관리하며 수명주기 단계를 통하여 시스템을. ,

발전시키는데 하부구조 환경을 사용할 수 있다 국제표준은 국제표준 조건대비 공표되.

고 구축된 환경의 적합성을 평가하는데 사용된다.

-프로젝트에 의한 활용프로젝트에 의한 활용프로젝트에 의한 활용프로젝트에 의한 활용 제품과 서비스를 제공하기 위하여 구축된 환경의 요소를 선정하:

고 구조화하고 활용하는데 도움을 준다 국제표준은 공표되고 구축된 환경대비 프로젝.

트 적합성 평가에 사용된다.

-획득자 및 공급자에 의한 활용획득자 및 공급자에 의한 활용획득자 및 공급자에 의한 활용획득자 및 공급자에 의한 활용 프로세스 및 업무활동과 관계된 계약을 이끌어 내는데:

도움을 준다 계약을 통해서 국제표준에 있는 프로세스와 업무활동이 선택되고 협상되.

며 합의되며 실행된다 국제표준은 계약을 하는데 있어서 지침서로 사용된다. .

참조문서3.

ISO/IEC 15288 Systems engineering-System life cycle processes :∙

INTERNATIONAL STANDARD , 2002-11-01

ISO/IEC TR 19760 Systems engineering - A guide for the application∙

of ISO/IEC 15288(System life cycle processes), 2003-11-15

ISO/IEC 12207:1995/AMD1:2002 Amendment to 12207∙

ISO/IEC 12207:1995/AMD2:2004 Amendment to 12207∙

- 60 -

MIL-STD-499A(USAF) MILITARY STANDARD Engineering∙

Management , 1969-07-17

IEEE 1220 Standard for Application and Management of the Systems∙

Engineering Process , 1998-12-08

EIA-632 Processing for Engineering a System , 1999-01-07∙

NASA System Engineering Handbook, Shishko, Robert and R. G.∙

Chamberlain Draft, 1992

INCOSE, System Engineering Handbook, V.10(1998), 2.0(2000) &∙

3.0(2004)

Concurrent Engineering & Integrated Product Development Handbook∙

to Understanding and Implementation, Office of the Assistant

Secretary of Defence(Production and Logistics) Wash, D. D.

20301-8000

Integrated Logistics Support Guide, DSMC, Fort Belvoir, VA∙

Risk Management; Concepts and Guidance, DSMC, Fort Belvoir, VA∙

ANSI/AIAA G-043-1992, Guide for the Preparation of Operational∙

Concept Documents

MIL-STD-498, "Software Development and Documentation", December∙

1994.

IEEE/EIA 12207.0, "Software Life Cycle Processes", March 1998.∙

IEEE/EIA 12207.1, "Software Life Cycle Processes - Life Cycle Data",∙

April 1998.

IEEE/EIA 12207.2, "Software Life Cycle Processes - Implementation∙

Considerations", April 1998.

용어4.

부록 참조※

시스템수명주기 프로세스 프레임워크5.

- 61 -

개요개요개요개요5.15.15.15.1

시스템의 복잡성이 전례 없는 수준에 까지 증가하고 있다 이는 시스템을 만들고 이용하.

는 조직에 어려움을 가중시키기도 하지만 새로운 기회를 부여하기도 한다 특히 최근의 시.

스템은 대부분 소프트웨어를 포함하고 있으며 심지어 시스템 구축 비용의 상당부분을 정보

시스템 구축에 활용하고 있다 이러한 측면에서 휴먼웨어 하드웨어 소프트웨어 등을 총 망. , ,

라하는 시스템 공학의 프로세스 활동 및 산출물에 대한 식별은 성공적인 시스템 구축에 필,

수요소이다 이에 따라 시스템 수명주기 프로세스 프레임워크는 시스템공학 국제표준을 기.

초로 해당하는 프로세스를 제시하고 이에 대한 이해를 돕기 위한 내용으로 구성된다.

- 62 -

프레임워크 구성프레임워크 구성프레임워크 구성프레임워크 구성 참조 문서참조 문서참조 문서참조 문서

장 배경1

장 개요2

장 참조문서3

장 용어4

장 장- ISO/IEC 15288 1 ~4

공공부문 소프트웨어 발주관리 표준-

프로세스 지침, 2004

장 시스템 수명주기 프로세스5

프레임워크장- ISO/IEC 15288 5 (P.5 ~ P.39)

목적 장- ISO/IEC 15288 5 Purpose

활동 장- ISO/IEC 15288 5 Activities

산출물- Template For a System Documentation

Management Plan, SEPT, 2004

부록 수명주기 단계A

- ISO/IEC 15288 Annex D D.2 Life Cycle

Concepts(P.56)

- ISO/IEC TR 19760 7.2.1

Approaches(P.34)

부록 프로세스별 활동 산출물B -

매트릭스

- Template For a System Documentation

Management Plan, SEPT, 2004

- Evidence Product Checklist for

ISO/IEC Standard 15288-System

Engineering-System Life Cycle Process,

SEPT, 2002

부록 산출물 기술서C

- Template For a System Documentation

Management Plan, SEPT, 2004

- Evidence Product Checklist for

ISO/IEC Standard 15288-System

Engineering-System Life Cycle Process,

SEPT, 2002

부록 문서작성절차D- Template For a System Documentation

Management Plan, SEPT, 2004

부록 시스템 수명주기 표준 프로세E

스와 발주관리 표준 프로세스

연계

- New Work Item Proposal-Revision of

ISO/IEC 12207 Systems and Software

Engineering-Software Life Cycle

Processes, ISO/IEC JTC1/SC7, 2005

공공부문 소프트웨어 발주관리 표준-

프로세스 지침, 2004

프레임워크 설계 방안프레임워크 설계 방안프레임워크 설계 방안프레임워크 설계 방안5.1.15.1.15.1.15.1.1

시스템 수명주기 프로세스 프레임워크의 내용은 기본적으로 가장 최근의 국제표준인

의 내용을 기반으로 작성하였다 년에 공표된 시스템 공학 시스템ISO/IEC 15288 . 2002 -

수명주기 프로세스 구성은 총 장과 개의 부록으로 구성되어 있다 장에서 장까지는6 4 . 1 4

표준에 대한 범위 목적 적용 제한사항 및 용어 등에 대해서 기술하고 있으며 장에서, , , , 5

는 개의 시스템 수명주기 프로세스 개의 프로세스 성과 및 개의 활동에 대해25 , 123 205

- 63 -

서 기술하고 있다.

하지만 은 해당하는 프로세스의 목적 활동 성과를 서술식으로 기술함ISO/IEC 15288 , ,

에 따라 기본적인 시스템 수명주기의 내용과 구성을 제시하기 위한 프레임워크 성격에 맞

지 않는 부분이 있으며 사용하는 용어 또한 또는 에서, ISO/IEC 12207 IEEE 12207

사용하고 있는 용어와 달라 우리나라에서 그대로 번역하여 사용하는데 어려움이 있다.

따라서 본 프레임워크에서는 프로세스의 구성을 목적 활동 산출물로 하면서 내용을 최, ,

대한 간략하게 구성하고자 한다 목적부분은 전체의 내용을 간략하게 기술하고 활동부분. ,

의 경우는 최대한 명사 형태로 간략하게 작성하여 기존 발주관리 표준 프로세스와 동일한

형태의 활동을 갖도록 하였다 산출물은 현재 성과 형태로 서술식으로 기술하고 있는 내용.

을 본문의 내용을 기초로 산출물로 제시하였다 산출물에 대한 제시는. ISO/IEC 15288

표준 본문에서 기술하고 있는 내용과 더불어 소프트웨어 공학 프로세스 테크놀로지

에서 출판한 시스템 문서(Software Engineering Process Technology, SEPT) ‘

관리계획을 위한 예시(Template For a System Documentation Management

에서 기술하고 있는 산출물의 명칭을 참고하여 작성하였다Plan)’ .

따라서 이러한 프레임워크 설계 방안에 따라 본 보고서에서는 향후 별도의 프레임워크 분

리를 용이하게 하기 위하여 절에서 절까지의 내용을 프레임워크에 맞게 구성하였5.2 5.10

다 특히 표준과의 호환성을 위하여 프로세스를 기술하는 절부터. ISO/IEC 15288 5.2 5.5

절은 표준과 동일한 프로세스와 번호체계를 따랐다 또한 부터 절까지의 내용을 향. 5.6 5.10

후 표준의 부록의 내용을 담았다.

구분구분구분구분

프로세스 그룹프로세스 그룹프로세스 그룹프로세스 그룹 프로세스프로세스프로세스프로세스 활동활동활동활동 산출물산출물산출물산출물

계약 2 17 24

전사 5 34 15

프로젝트 7 57 55

기술 11 94 72

합계합계합계합계 개4 개25 개205 166

시스템 수명주기 프로세스 구성시스템 수명주기 프로세스 구성시스템 수명주기 프로세스 구성시스템 수명주기 프로세스 구성< >< >< >< >

프레임워크 수준 및 구성프레임워크 수준 및 구성프레임워크 수준 및 구성프레임워크 수준 및 구성5.1.25.1.25.1.25.1.2

본 표준의 구성은 총 장과 개의 부록으로 구성되어 있다 장에서 장까지는 표준에5 5 . 1 4

대한 범위 목적 적용 제한사항 및 용어 등에 대해서 기술하고 있으며 장에서는 개의, , , , 5 25

시스템 수명주기 프로세스 개의 활동 및 개의 프로세스 산출물을 기술하고 있다 부, 208 91 .

록에서는 수명주기 단계 프로세스 산출물 문서작성 절차 시스템(Life cycle Stages), , ,

- 64 -

수명주기 표준 프로세스와 발주관리 표준 프로세스 비교 및 시스템 수명주기 표준과 발주관

리 표준과의 활용방안에 대해서 기술하고 있다.

프레임워크 프로세스 연관관계프레임워크 프로세스 연관관계프레임워크 프로세스 연관관계프레임워크 프로세스 연관관계5.1.25.1.25.1.25.1.2

프로세스간의 연관관계는 개의 계약 전사 프로젝트 기술로 프로세스 그룹을 중심으로4 , , ,

하여 상호간에 요구되는 인터페이스 사항을 보여준다.

획득획득획득획득획득획득획득획득 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

공급공급공급공급공급공급공급공급 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 계획계획계획계획계획계획계획계획 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 통제통제통제통제통제통제통제통제 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 의사결정의사결정의사결정의사결정의사결정의사결정의사결정의사결정

프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

위험관리위험관리위험관리위험관리위험관리위험관리위험관리위험관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

형상관리형상관리형상관리형상관리형상관리형상관리형상관리형상관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 평가평가평가평가평가평가평가평가 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

전사전사전사전사전사전사전사전사 환경환경환경환경환경환경환경환경 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

투자투자투자투자투자투자투자투자 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

시스템시스템시스템시스템시스템시스템시스템시스템 수명주기수명주기수명주기수명주기수명주기수명주기수명주기수명주기 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

자원자원자원자원자원자원자원자원 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

품질품질품질품질품질품질품질품질 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

이해당사자이해당사자이해당사자이해당사자이해당사자이해당사자이해당사자이해당사자 요구사항요구사항요구사항요구사항요구사항요구사항요구사항요구사항

정의정의정의정의정의정의정의정의 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

요구사항요구사항요구사항요구사항요구사항요구사항요구사항요구사항 분석분석분석분석분석분석분석분석 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

아키텍처아키텍처아키텍처아키텍처아키텍처아키텍처아키텍처아키텍처 설계설계설계설계설계설계설계설계 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

구현구현구현구현구현구현구현구현 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

통합통합통합통합통합통합통합통합 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

검증검증검증검증검증검증검증검증 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

전환전환전환전환전환전환전환전환 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

확인확인확인확인확인확인확인확인 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

운영운영운영운영운영운영운영운영 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

유지보수유지보수유지보수유지보수유지보수유지보수유지보수유지보수 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

폐기폐기폐기폐기폐기폐기폐기폐기 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

운영/유지보수 프로세스

개발프로세스

5.5 5.5 5.5 5.5 5.5 5.5 5.5 5.5 기술프로세스기술프로세스기술프로세스기술프로세스기술프로세스기술프로세스기술프로세스기술프로세스5.2 5.2 5.2 5.2 5.2 5.2 5.2 5.2 계약프로세스계약프로세스계약프로세스계약프로세스계약프로세스계약프로세스계약프로세스계약프로세스

5.4 5.4 5.4 5.4 5.4 5.4 5.4 5.4 프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

5.3 5.3 5.3 5.3 5.3 5.3 5.3 5.3 전사프로세스전사프로세스전사프로세스전사프로세스전사프로세스전사프로세스전사프로세스전사프로세스

타당한 솔루션

작업지시

대안제공

재 지시

작업산출물

평가

계획/요구사항계획갱신

요구사항

승

인

된

산

출

물

정책/절차

지원

/

보고

/

검토

공급/산출물획득요구/계약

- 65 -

프로세스 활동 구성프로세스 활동 구성프로세스 활동 구성프로세스 활동 구성5.1.35.1.35.1.35.1.3

아래의 프로세스 활동 구성도는 에 서술식으로 기술되어 있는 활동ISO/IEC 15288

을 명칭화하여 도식한 것이다 의 프로세스와 활동을 기술한(Activity) . ISO/IEC 12207

형식으로 으로 표현함으로써 전체적인 프로세스와 활동을 보다 쉽게 파악할 수 있으며 다,

른 표준과의 구성 및 내용을 비교할 수 있도록 하였다.

5.2 5.2 계약계약계약계약계약계약계약계약 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

전사전사전사전사전사전사전사전사 환경환경환경환경환경환경환경환경 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

사업분야계획수립

수명주기정책/절차를준비

역할/책임/권한정의

수명주기모델의주기적검토

정책/절차공유

시스템시스템시스템시스템시스템시스템시스템시스템 수명주기수명주기수명주기수명주기수명주기수명주기수명주기수명주기 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

시스템수명주기프로세스수립

테일러링정책/절차수립

방법/도구식별

평가척도수립

프로세스실행관찰

사업기준을정의

5.3 5.3 전사전사전사전사전사전사전사전사 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

투자투자투자투자투자투자투자투자 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

투자계획수립

프로젝트책임/권한정의

예측산출물식별

자원할당

프로젝트인터페이스식별

보고/검토회일정명시

프로젝트평가

프로젝트조정

프로젝트지연/취소

프로세스개선기회식별

프로세스/방법/도구개선

자원자원자원자원자원자원자원자원 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

자원지원항목결정/제공

인적요소외자원확보

인력유지/관리

참여인력동기부여

다수프로젝트의관리인터페이스통제

품질품질품질품질품질품질품질품질 관리관리관리관리관리관리관리관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

품질관리정책/표준/절차수립

품질관리목적/목표수립

책임권한정의

고객만족/결과보고서평가

주기적품질계획검토

품질개선상태관찰

프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 계획계획계획계획계획계획계획계획 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

프로젝트목표/제약사항식별

프로젝트범위정의

과업분할구조(WBS) 작성

프로젝트성과척도정의

프로젝트비용정의및예산계획

프로젝트 평가 프로세스

프로젝트상태평가

품질보증수행

프로젝트팀평가

지원인프라적정성/가용성평가

프로젝트진척평가

프로젝트일정정의/유지

5.4 5.4 프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트프로젝트 통제통제통제통제통제통제통제통제 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

요구및변경사항관리

교정활동수행

예방활동수행

문제해결활동수행

변화관리

계약변경활동수행

계약교정활동수행

프로젝트승인

관리및기술적검토/신기술관찰

데인터분석및권고

형상관리형상관리형상관리형상관리형상관리형상관리형상관리형상관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

형상관리전략정의

형상통제항목식별

책임/권한구조수립

인프라/서비스정의

외부프로젝트와연계한획득정의

성과척도/연관자료정의

프로젝트품질계획수립

기술관리계획수립/시행

주기적보고서제공

의사결정의사결정의사결정의사결정의사결정의사결정의사결정의사결정 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

의사결정전략정의

의사결정과정참여

환경/요구사항식별

의사결정전략선정및성공척도식별

대안활동결과평가

결과기록/추적/평가/보고

처리결과기록유지

위험관리위험관리위험관리위험관리위험관리위험관리위험관리위험관리 프로세스프로세스프로세스프로세스프로세스프로세스프로세스프로세스

위험접근방법수립

위험식별/정의

위험확률결정

위험평가

위험우선순위부여

위험취급전략결정

위험수용한계정의

위험취급활동식별

위험관련의사소통

위험기록유지

- 66 -

계약 프로세스5.2

개요개요개요개요5.2.15.2.15.2.15.2.1

내 외부 조직의 계약을 체결하기 위한 요구사항을 기술하며 다음과 같은 프로세스로 구성/

된다.

획득 프로세스a)

공급 프로세스b)

획득 프로세스획득 프로세스획득 프로세스획득 프로세스5.2.25.2.25.2.25.2.2

목적목적목적목적5.2.2.15.2.2.15.2.2.15.2.2.1

획득 프로세스의 목적은 획득자의 요구사항에 부합하는 제품 또는 서비스를 확보하는 것

이다.

활동활동활동활동5.2.2.25.2.2.25.2.2.25.2.2.2

획득계획 수립a)

요구사항 준비b)

공급자와 의사소통c)

공급자 선정d)

공급자와 계약협상e)

계약 이행 평가f)

최종산출물 확인g)

대금 지급h)

산출물산출물산출물산출물5.2.2.35.2.2.35.2.2.35.2.2.3

획득계획서a) *

대금지급계획서b) *

공급자 성과 관리 계획서c) *

시스템 인수 계획서d) *

계약서e) *

시스템 인수 전략계획서f)

- 67 -

요구사항정의서g) *

제안요청서h) *

고객 공급자합의서i) - *

획득전략서j) *

공급자 선정 계획서k) *

협약서l) (charter)*

합의서m) (correspondence)*

공급 프로세스공급 프로세스공급 프로세스공급 프로세스5.2.35.2.35.2.35.2.3

목적목적목적목적5.2.3.15.2.3.15.2.3.15.2.3.1

공급 프로세스의 목적은 획득자에게 합의된 요건을 만족하는 제품 또는 서비스를 제공 것

이다.

활동활동활동활동5.2.3.25.2.3.25.2.3.25.2.3.2

획득자 식별a)

요구사항 평가b)

요청사항 대응책 준비c)

계약 협의d)

계약 체결e)

계약 이행 결과 평가f)

최종산출물 인도g)

대금 수령 및 통보h)

최종산출물 책임 이관i)

산출물산출물산출물산출물5.2.3.35.2.3.35.2.3.35.2.3.3

제안서a) *

계약서b) *

사업수행계획서c)

시스템개발 계획서d)

인수확인서e)

검증결과보고서f)

확인결과보고서g)

품질관리결과보고서h)

- 68 -

합동고객 공급자 감리검토계획서i) *

협력업체 관리 계획서j) *

요청 응답서k) *

전사 프로세스5.3

개요개요개요개요5.3.15.3.15.3.15.3.1

전사 프로세스는 프로젝트 착수 지원 및 통제를 통하여 제품 또는 서비스를 획득하고 공,

급하기 위한 조직의 능력을 관리하며 다음과 같은 프로세스로 구성된다.

전사 환경 관리 프로세스a)

투자 관리 프로세스b)

시스템 수명주기 프로세스 관리 프로세스c)

자원 관리 프로세스d)

품질 관리 프로세스e)

전사 환경 관리 프로세스전사 환경 관리 프로세스전사 환경 관리 프로세스전사 환경 관리 프로세스5.3.25.3.25.3.25.3.2

목적목적목적목적5.3.2.15.3.2.15.3.2.15.3.2.1

전사 환경 관리 프로세스 목적은 본 국제표준 범위에서 조직의 사업에 요구되는 정책과

절차를 정의하고 유지하는 것이다.

활동활동활동활동5.3.2.25.3.2.25.3.2.25.3.2.2

사업 분야 계획 수립a)

시스템 수명주기 정책 절차를 준비b) /

역할 책임 권한 정의c) / /

사업 기준 정의d)

시스템 수명주기 모델의 주기적 검토e)

정책 절차 공유f) /

- 69 -

산출물산출물산출물산출물5.3.2.35.3.2.35.3.2.35.3.2.3

조직 비전 정의서a) *

조직 사업전략 계획서b) *

투자 관리 프로세스투자 관리 프로세스투자 관리 프로세스투자 관리 프로세스5.3.35.3.35.3.35.3.3

목적목적목적목적5.3.3.15.3.3.15.3.3.15.3.3.1

투자 관리 프로세스 목적은 조직의 목표를 만족시키기 위해 충분하고 적합한 프로젝트를

착수하고 유지하는 것이다 투자 관리 프로세스는 조직 자금과 자원의 적절한 투자를 위임.

하고 선정된 프로젝트 착수하는데 필요로 하는 권한을 재가하는 것이다 투자 관리 프로세.

스는 조직이 정당하다고 확인한 프로젝트의 지속적인 자격조건 검토를 수행하거나 또는 정

당화 확인 지속적 투자를 위한 방향이 재조정 되는 것이다, .

활동활동활동활동5.3.3.25.3.3.25.3.3.25.3.3.2

투자 계획 수립a)

프로젝트 책임 권한 정의b) /

예측 산출물 식별c)

자원 할당d)

프로젝트 인터페이스 식별e)

보고 검토회 일정 명시f) /

프로젝트 권한 부여g)

프로젝트 평가h)

프로젝트 조정i)

프로젝트 지연 취소j) /

산출물산출물산출물산출물5.3.3.35.3.3.35.3.3.35.3.3.3

투자관리 계획서a)

비용 대 효과 분석서b)

시스템 수명주기 프로세스 관리 프로세스시스템 수명주기 프로세스 관리 프로세스시스템 수명주기 프로세스 관리 프로세스시스템 수명주기 프로세스 관리 프로세스5.3.45.3.45.3.45.3.4

목적목적목적목적5.3.4.15.3.4.15.3.4.15.3.4.1

시스템 수명주기 프로세스 관리 프로세스의 목적은 효과적인 시스템 수명주기 프로세스가

조직에서 활용 가용하도록 보증하는 것이다 시스템 수명주기 프로세스 관리 프로세스는 조.

- 70 -

직의 목적 및 방침과 일관성이 있고 개별 프로젝트의 특성을 충족하기 위하여 견실한 방법,

으로 정의되고 채택되고 유지되고 있으며 활용되고 있는 효과적이며 검증된 방법과 도구, ,

가 적용될 수 있도록 하는 시스템 수명주기 프로세스를 제공한다.

활동활동활동활동5.3.4.25.3.4.25.3.4.25.3.4.2

시스템 수명주기 프로세스 수립a)

테일러링 정책 절차 수립b) /

방법 도구 식별c) /

평가척도 수립d)

프로세스 실행 관찰e)

프로세스 개선 기회 식별f)

프로세스 방법 도구 개선g) / /

산출물산출물산출물산출물5.3.4.3.5.3.4.3.5.3.4.3.5.3.4.3.

시스템 수명주기 프로세스 관리 계획서a) *

시스템 수명주기 정의 계획서b) *

프로세스 평가 계획서c) *

프로세스 개선 계획서d) *

자원 관리 프로세스자원 관리 프로세스자원 관리 프로세스자원 관리 프로세스5.3.55.3.55.3.55.3.5

목적목적목적목적5.3.5.15.3.5.15.3.5.15.3.5.1

자원 관리 프로세스의 목적은 프로젝트에 자원을 제공하는 것이다 자원 관리 프로세스는.

시스템 수명주기 전 기간동안 조직 및 프로젝트 목표달성을 지원하기 위하여 프로젝트에 필

요한 재원 재료 및 서비스를 제공한다 이것은 시스템 수명주기 프로세스 실행을 위한 자, .

격이 있는 교육받고 숙련되고 경험이 있는 인력의 공급을 포함한다 자원 관리 프로세스는.

자원 정보 및 기술의 효과적인 조정과 공유를 확실히 한다, .

활동활동활동활동5.3.5.25.3.5.25.3.5.25.3.5.2

자원 지원항목 결정 제공a) /

인적요소 외 자원 확보b)

인력 유지 관리c) /

참여인력 동기 부여d)

다수 프로젝트의 관리 인터페이스 통제e)

- 71 -

산출물산출물산출물산출물5.3.5.35.3.5.35.3.5.35.3.5.3

자원 관리 계획서a) *

기반 구축 계획서b) *

훈련 계획서c) *

품질 관리 프로세스품질 관리 프로세스품질 관리 프로세스품질 관리 프로세스5.3.65.3.65.3.65.3.6

목적목적목적목적5.3.6.15.3.6.15.3.6.15.3.6.1

품질 관리 프로세스의 목적은 제품 서비스 및 시스템 수명주기 프로세스의 실행결과가,

기업조직 품질 목표를 만족하고 고객만족을 달성하는 것을 확실하게 하는 것이다.

활동활동활동활동5.3.6.25.3.6.25.3.6.25.3.6.2

품질관리 정책 표준 절차 수립a) / /

품질관리 목적 목표 수립b) /

책임 권한 정의c) /

고객만족 결과보고서 평가d) /

주기적 품질 계획 검토e)

품질 개선 상태 관찰f)

산출물산출물산출물산출물5.3.6.35.3.6.35.3.6.35.3.6.3

품질관리계획서a) *

품질진척 보고서b) *

품질목표서c) *

시스템 품질 계획서d) *

프로젝트 프로세스5.4

개요개요개요개요5.4.15.4.15.4.15.4.1

프로젝트 프로세스는 프로젝트 계획을 수립하고 발전시키는데 계획대비 프로젝트의 실질,

적 성과와 진도를 평가하는데 프로젝트 구현을 통한 프로젝트 실행을 통제하는데 사용되며,

다음과 같은 프로세스로 구성된다.

- 72 -

프로젝트 계획 프로세스a)

프로젝트 평가 프로세스b)

프로젝트 통제 프로세스c)

프로젝트 의사결정 프로세스d)

위험관리 프로세스e)

형상관리 프로세스f)

정보관리 프로세스g)

프로젝트 계획 프로세스프로젝트 계획 프로세스프로젝트 계획 프로세스프로젝트 계획 프로세스5.4.25.4.25.4.25.4.2

목적목적목적목적5.4.2.15.4.2.15.4.2.15.4.2.1

프로젝트 계획 프로세스 목적은 효과적이고 실행 가능한 프로젝트 계획을 만들어 내고 의

사소통 하는 것이다 프로젝트 계획 프로세스는 프로젝트의 범위 및 기술적 업무활동을 결.

정하고 프로세스 출력물 프로젝트 과업 및 인도물품을 식별하고 성과척도와 프로젝트 과, , ,

업 완수에 요구된 자원을 포함한 프로젝트 과업 수행에 필요한 일정을 수립하는 것이다.

활동활동활동활동5.4.2.25.4.2.25.4.2.25.4.2.2

프로젝트 목표 제약사항 식별a) /

프로젝트 범위 정의b)

작업분할구조 작성c) (WBS)

프로젝트 일정 정의 유지d) /

프로젝트 성과척도 정의e)

프로젝트 비용 정의 및 예산 계획f)

책임 권한 구조 수립g) /

기반 서비스 정의h) /

외부 프로젝트와 연계한 획득 정의i)

기술관리계획 수립 시행j) /

성과척도 연관 자료 정의k) /

프로젝트 품질 계획 수립l)

산출물산출물산출물산출물5.4.2.35.4.2.35.4.2.35.4.2.3

프로젝트 관리 계획서a) *

프로젝트 계약관리 계획서b)

프로젝트 변경관리 계획서c)

프로젝트 재정관리 계획서d)

- 73 -

프로젝트 통제 계획서e)

프로젝트 품질보증 계획서f)

감리계획서g) *

공학 계획서h)

소프트웨어 개발 계획서I)

시스템 안전 계획서j)

시스템 보안 계획서k)

종합시험 계획서l)

작업분할구조도m) (WBS)

문서화계획서n)

변환계획서o) *

프로젝트계획서p) *

프로젝트 팀 구조와 운영역할 계획서q) *

프로젝트 일정r) *

브리핑자료s) *

프로젝트 평가 프로세스프로젝트 평가 프로세스프로젝트 평가 프로세스프로젝트 평가 프로세스5.4.35.4.35.4.35.4.3

목적목적목적목적5.4.3.15.4.3.15.4.3.15.4.3.1

프로젝트 평가 프로세스 목적은 프로젝트의 상태를 결정하는 것으로 프로세스는 주기적으

로 주요 이벤트에서 요구조건 계획 및 전체적인 사업 계획대비 진도 및 성과를 평가하는,

것이다 중요한 변동이 발견되었을 경우 정보는 관리 조치를 위하여 의사소통 되어야 한다. .

활동활동활동활동5.4.3.25.4.3.25.4.3.25.4.3.2

프로젝트 상태 평가a)

품질 보증 수행b)

프로젝트 팀 평가c)

지원 인프라 적정성 가용성 평가d) /

프로젝트 진척 평가e)

관리 및 기술적 검토 감리 검사 수행f) / /

주요 프로세스 신기술 관찰g) /

데이터 분석 및 권고h)

주기적 보고서 제공i)

- 74 -

산출물산출물산출물산출물5.4.3.35.4.3.35.4.3.35.4.3.3

프로젝트 평가 계획서a)

프로젝트 평가결과 보고서b)

분석 보고서c) Trade-off

프로젝트 통제 프로세스프로젝트 통제 프로세스프로젝트 통제 프로세스프로젝트 통제 프로세스5.4.45.4.45.4.45.4.4

목적목적목적목적5.4.4.15.4.4.15.4.4.15.4.4.1

프로젝트 통제 프로세스 목적은 프로젝트 계획 실행을 지시하는 것이며 추정된 예산 내,

에서 계획 및 일정에 따라 프로젝트를 수행하고 기술적 목표를 만족을 확실하게 하는 것이

다 프로젝트 통제 프로세스는 프로젝트 업무활동을 다른 프로젝트 또는 기술적 프로세스로.

부터 식별된 편차와 변동을 시정하기 위하여 적절하게 재조정하는 것이 포함된다 재조정에.

는 가능할 경우 재기획이 포함된다.

활동활동활동활동5.4.4.25.4.4.25.4.4.25.4.4.2

요구 및 변경사항 관리a)

교정활동 수행b)

예방활동 수행c)

문제해결활동 수행d)

변화관리e)

계약 변경활동 수행f)

계약 교정활동 수행g)

프로젝트 승인h)

산출물산출물산출물산출물5.4.4.35.4.4.35.4.4.35.4.4.3

프로젝트 통제 계획서a)

프로젝트 변경 보고서b)

요구사항 상태 보고서c)

프로젝트 진척 보고서d)

문제해결계획서e) *

교정조치보고서f) *

편차보고서g) *

의사결정 프로세스의사결정 프로세스의사결정 프로세스의사결정 프로세스5.4.55.4.55.4.55.4.5

- 75 -

목적목적목적목적5.4.5.15.4.5.15.4.5.15.4.5.1

의사결정 프로세스의 목적은 가장 효과적인 대안을 선택하는 과정이다 프로세스는 구체.

화되고 바람직하거나 최적화된 결과에 도달하기 위하여 요구 성격 및 근원이 무엇이던 간,

에 시스템 수명주기 동안에 마주치는 의사결정 요구에 응답하는 것이다 대안활동은 분석되.

어야 하며 활동경로는 선택되고 지정되어야 한다 결정과 이의 사유는 향후 의사결정을 지.

원하기 위하여 기록되어야 한다.

활동활동활동활동5.4.5.25.4.5.25.4.5.25.4.5.2

의사결정 전략 정의a)

의사결정 과정 참여b)

환경 요구사항 식별c) /

의사결정전략 선정 및 성공척도 식별d)

대안활동 결과 평가e)

결과 기록 추적 평가 보고f) / / /

처리결과 기록 유지g)

산출물산출물산출물산출물5.4.5.35.4.5.35.4.5.35.4.5.3

의사결정 계획서a)

분석보고서b) Trade-off

의사결정 결과 보고서c)

의사결정 전략서d) *

위험관리 프로세스위험관리 프로세스위험관리 프로세스위험관리 프로세스5.4.65.4.65.4.65.4.6

목적목적목적목적5.4.6.15.4.6.15.4.6.15.4.6.1

위험관리 프로세스 목적은 품질 비용 일정 또는 기술적 특성 변화에 따른 불확실한 사, ,

건의 영향을 줄이는 것이며 프로세스는 전체 수명주기 동안 각 위험에 대하여 적절한 처리

또는 수용의 형태로 대응하는 위험을 식별하고 평가하고 처리하고 모니터링 하는 것이다.

활동활동활동활동5.4.6.25.4.6.25.4.6.25.4.6.2

위험 접근방법 수립a)

위험 식별 정의b) /

위험 확률 결정c)

위험 평가d)

위험 우선순위 부여e)

- 76 -

위험 취급 전략 결정f)

위험 수용 한계 정의g)

위험취급활동 식별h)

위험관련 의사소통i)

위험 기록 유지j)

산출물산출물산출물산출물5.4.6.35.4.6.35.4.6.35.4.6.3

위험관리 계획서a) *

위험해결 활동 계획서b)

위험 분석 보고서c)

위험 상태 보고서d)

위험관리서e) *

위험관리요약서f) *

시스템위험분석 계획서g) *

형상관리 프로세스형상관리 프로세스형상관리 프로세스형상관리 프로세스5.4.75.4.75.4.75.4.7

목적목적목적목적5.4.7.15.4.7.15.4.7.15.4.7.1

형상관리 프로세스 목적은 프로젝트 또는 프로세스의 식별된 모든 산출물의 무결성을 확

립하고 유지하는 것이며 관련된 당사자에게 이용 가능하게 한다.

활동활동활동활동5.4.7.25.4.7.25.4.7.25.4.7.2

형상관리 계획 수립a)

형상통제항목 식별b)

형상 정보 관리c)

형상 평가d)

산출물산출물산출물산출물5.4.7.35.4.7.35.4.7.35.4.7.3

형상관리계획서a) *

형상 통제결과 보고서b)

형상 정보관리 보고서c)

형상 평가결과 보고서d)

형상항목기준서e) *

형상관리전략서f) *

시스템 제품 배포서g) *

- 77 -

정보관리 프로세스정보관리 프로세스정보관리 프로세스정보관리 프로세스5.4.85.4.85.4.85.4.8

목적목적목적목적5.4.8.15.4.8.15.4.8.15.4.8.1

정보관리 프로세스 목적은 시스템 수명주기 또는 사후에 관련 당사자에게 적시에 완전하

고 유효한 프로젝트 관련 정보를 제공하는 것이다 정보관리 프로세스는 정보를 생성하며. ,

채집하고 변환하며 존속하며 재생하고 보급하며 처분하는 것이다 이것은 기술 프로젝트. , ,

기업조직 계약체결 및 사용자 정보를 포함한 지정된 정보를 관리한다, .

활동활동활동활동5.4.8.25.4.8.25.4.8.25.4.8.2

정보 항목 정의a)

권한 책임 부여b) /

권리 의무 위임 사항 정의c) / /

내용 의미 형태 매체 정의d) / / /

정보 항목 확보e)

정보 항목과 이의 저장 기록 유지f)

정보유지활동 정의g)

정보 재생 배포h) /

공식 문서 제공i)

지정 정보 기록보관j)

정보 폐기k)

산출물산출물산출물산출물5.4.8.35.4.8.35.4.8.35.4.8.3

프로젝트 정보관리 계획서a)

정보품질 분석 보고서b)

정보품질 진척 보고서c)

교훈보고서d) *

문서e) trade-study *

상태보고서f) *

문서화프로세스g) *

훈련 메뉴얼h) *

기술 프로세스5.5

- 78 -

개요개요개요개요5.5.15.5.15.5.15.5.1

기술프로세스는 시스템에 대한 요구사항 정의로부터 제품으로의 전환 제품의 재생산 서, ,

비스제공 및 유지 제품의 폐기까지의 수행내역들을 정의하는 것이다, .

이해당사자 요구사항 정의 프로세스a) ( Stakeholder Requirements Definition

Process)

요구사항 분석 프로세스b) (Requirements Analysis Process)

아키텍쳐 설계 프로세스c) (Architectural Design Process)

구현 프로세스d) (Implementation Process)

통합 프로세스e) (Integration Process)

검증 프로세스f) (Verification Process)

전환 프로세스g) (Transition Process)

확인 프로세스h) (Validation Process)

운영 프로세스i) (Operation Process)

정비 프로세스j) (Maintenance Process)

폐기 프로세스k) (Disposal Process)

이해당사자 요구사항 정의 프로세스이해당사자 요구사항 정의 프로세스이해당사자 요구사항 정의 프로세스이해당사자 요구사항 정의 프로세스5.5.25.5.25.5.25.5.2

목적목적목적목적5.5.2.15.5.2.15.5.2.15.5.2.1

이해당사자 요구사항 정의 프로세스의 목적은 정의된 환경 속에서 사용자 및 다른 이해당

사자가 필요로 하는 서비스를 제공하는 시스템 요구사항을 정의하는 것이다 이는 시스템.

수명주기를 통하여 시스템과 함께 관여된 이해당사자 또는 이해당사자 계층집단과 이해당사

자의 요구사항 및 희망사항을 식별하는 것이다 이를 시스템이 갖고 있는 운영환경과 의도.

된 상호작용 기능을 표현하고 시스템이 요구사항을 이행하고 있다는 것을 확증하기 위하여,

결과적 운영 서비스가 요구검증 되는 것의 기준이 되는 이해당사자 요구조건의 공통집합으

로 분석하고 변환하는 것이다.

활동활동활동활동5.5.2.25.5.2.25.5.2.25.5.2.2

이해당사자 식별a)

요구사항 추출b)

제약사항 정의c)

대표 집단 정의d)

- 79 -

사용자와 시스템 상호작용 식별e)

요구사항 구체화f)

요구조항 분석g)

요구조항 문제 해결h)

이해당사자에게 피드백i)

이해당사자 선임j)

이해당사자 요구사항 기록k)

이해당사자 요구사항 유지l)

산출물산출물산출물산출물5.5.2.35.5.2.35.5.2.35.5.2.3

운영개념 기술서a)

제품 및 서비스 요구 계획서b)

시스템 개념 계획서c)

제품 및 서비스 요구서d) *

안전계획서e) *

보안계획서f) *

인적요소요구서g) *

요구서h) *

안전요구서i) *

보안요구서j) *

요구사항 분석 프로세스요구사항 분석 프로세스요구사항 분석 프로세스요구사항 분석 프로세스5.5.35.5.35.5.35.5.3

목적목적목적목적5.5.3.15.5.3.15.5.3.15.5.3.1

요구사항 분석 프로세스 목적은 요구되는 서비스에 대하여 이해당사자의 요구사항 기반,

의 관점을 서비스가 납품되는데 필요한 제품의 기술적 관점으로 변환하는 것이다.

요구사항 분석 프로세스는 제약요인들이 허용하는 범위까지 이해당사자 요구조건을 충족

하는 미래 시스템의 표상을 구축하는 것이며 그 어떤 구체적 실행을 의미하는 것은 아니,

다 이는 개발자의 관점에서 시스템이 가져야 하는 특성과 이해당사자 요구조건을 만족하는.

정도의 크기를 규정하는 측정 가능한 시스템 요구조건에 기인한다.

활동활동활동활동5.5.3.25.5.3.25.5.3.25.5.3.2

시스템 기능 경계 정의a)

개별기능 정의b)

제약요인 정의c)

- 80 -

기술 품질 정의d) /

요구사항 기능 구체화e) /

요구사항 통합성 분석f)

요구사항 추적성 제시g)

요구사항 유지h)

산출물산출물산출물산출물5.5.3.35.5.3.35.5.3.35.5.3.3

요구사항 명세서a)

인터페이스 요구사항명세서b)

기능상세 계획서c) *

기능상세서d) *

규정 및 표준요구서e) *

시스템 요구사항 명세서f) *

아키텍쳐 설계 프로세스아키텍쳐 설계 프로세스아키텍쳐 설계 프로세스아키텍쳐 설계 프로세스5.5.45.5.45.5.45.5.4

목적목적목적목적5.5.4.15.5.4.15.5.4.15.5.4.1

아키텍쳐 설계 프로세스 목적은 시스템 요구조건을 만족시키는 해결책을 종합하는 것이

다 아키텍쳐 설계 프로세스는 관리할 수 있고 개념적이며 궁극적으로 실현 가능한 규모의.

분리된 분제의 집합으로써 표현된 해결책 영역을 요약하고 정의한다 시스템의 기술적 및.

상업적 요구조건과 위험과 일관성을 갖는 상세 수준에서 하나 이상의 실행 전략을 식별하고

조사한다 이로부터 아키텍쳐 설계 해결책은 시스템을 구성하는 시스템 요소들의 집합으로.

부터 형상화되는 요구조건 형태로 정의된다 위 프로세스 결과로부터 나오는 구체화된 요구.

조건은 실현된 시스템 요구검증과 조합 및 요구검증 전략 수정의 기초가 된다.

활동활동활동활동5.5.4.25.5.4.25.5.4.25.5.4.2

아키텍쳐 설계 정의a)

시스템 기능 분할 할당b) /

아키텍쳐 설계 분석 및 설계 기준 설정c)

시스템 요구사항 결정d)

와 요소 결정e) H/W S/W

대안 설계 해결책 평가 및 상세 수준 모델링f)

외부 시스템과의 인터페이스 정의 문서화g) /

물리적 설계 구체화h)

아키텍쳐 설계 정보 기록i)

- 81 -

아키텍쳐 설계와 시스템 요구사항간 상호 추적성 유지j)

산출물산출물산출물산출물5.5.4.35.5.4.35.5.4.35.5.4.3

아키텍처 설계 명세서a) *

인터페이스 설계기술서b) *

시스템방법론 도구 및 기술 계획서c) *

시스템 상세설계 명세서d) *

시스템 수명주기 적용프로세스e) *

시스템 수명주기 활동 및 작업 매핑 문서f) *

시스템 방법론 도구 및 기술서g) *

구현 프로세스구현 프로세스구현 프로세스구현 프로세스5.5.55.5.55.5.55.5.5

목적목적목적목적5.5.5.15.5.5.15.5.5.15.5.5.1

구현 프로세스 목적은 명세화된 시스템 요소를 생산하는 것이다 이 프로세스는 구체화된.

거동 인터페이스 및 구현 제약요소를 선택된 구현기술의 실행기법에 따라 시스템 요소를,

창조하는 제조활동으로 전환한다 시스템 요소는 선택된 구현기술에 적합한 재료 및 또는. /

정보를 처리를 통하고 적절한 기술적 전문분야 또는 학문을 사용하여 만들어 지거나 채택된

다 이 프로세스 결과는 요건검증을 통한 아키텍쳐 설계 요구조건과 요구검증을 통한 이해.

당사자 요구조건을 만족시키는 시스템 요소이다.

활동활동활동활동5.5.5.25.5.5.25.5.5.25.5.5.2

구현전략 수립a)

제약사항 식별b)

시스템 항목 구현 채택c) /

계약 만족 증거 기록d)

포장 보관e) /

산출물산출물산출물산출물5.5.5.35.5.5.35.5.5.35.5.5.3

구현계획서a) *

구현결과보고서b)

통합 프로세스통합 프로세스통합 프로세스통합 프로세스5.5.65.5.65.5.65.5.6

목적목적목적목적5.5.6.15.5.6.15.5.6.15.5.6.1

- 82 -

통합 프로세스 목적은 아키텍쳐 설계와 일관성을 갖도록 시스템을 조립하는 것이다 통합.

프로세스는 시스템 요구조건에서 명시된 제품을 만들기 위해 온전하거나 부분적 시스템 형

상을 형성하는 시스템 요소를 조합한다.

활동활동활동활동5.5.6.25.5.6.25.5.6.25.5.6.2

조합순서와 전략 정의a)

제약사항 식별b)

관련 시스템과 재료 확보c)

시스템 항목 확보d)

기준 순응 보장e)

시스템 항목 통합f)

통합정보기록유지g)

산출물산출물산출물산출물5.5.6.35.5.6.35.5.6.35.5.6.3

통합계획서a) *

통합결과 보고서b)

운영 설치 매뉴얼c) /

문제해결보고서d)

검증 프로세스검증 프로세스검증 프로세스검증 프로세스5.5.75.5.75.5.75.5.7

목적목적목적목적5.5.7.15.5.7.15.5.7.15.5.7.1

검증 프로세스 목적은 규정된 설계 요구조건이 시스템에 의하여 이행되었는가를 확인하는

것이다 이 프로세스는 시스템 구현과정의 부적합 또는 부적합에 영향을 주는 프로세스를.

바로잡는 교정활동 실행에 요구된 정보를 제공한다.

활동활동활동활동5.5.7.25.5.7.25.5.7.25.5.7.2

검증 전략 정의a)

검증 계획 정의b)

잠재 제약사항 식별 공유c) /

검증 준비 확인d)

검증 수행e)

검증 자료 생성f)

검증 분석 기록 보고g) / /

결과물결과물결과물결과물5.5.7.35.5.7.35.5.7.35.5.7.3

- 83 -

검증계획서a) *

검증결과 보고서b)

문제해결보고서c)

측정절차 계획서d) *

시험 및 평가서e) *

추적문서f) *

검증 전략서g) *

검증 전략 요약서h) *

전환 프로세스전환 프로세스전환 프로세스전환 프로세스5.5.85.5.85.5.85.5.8

목적목적목적목적5.5.8.15.5.8.15.5.8.15.5.8.1

전환 프로세스 목적은 운영환경에서 이해당사자 요구조건으로 명시된 서비스를 제공하는

능력을 갖추는 것이다 이 프로세스는 적절한 기반시스템 즉 계약체결서에서 정의된 운용. ,

시스템 지원시스템 운용자 훈련 시스템 사용자 훈련 시스템과 함께 요건검증된 시스템을, , ,

설치한다.

활동활동활동활동5.5.8.25.5.8.25.5.8.25.5.8.2

전환 전략 준비a)

운용 장소 준비b)

시스템 납품c)

설치 접속d) /

설치시험e)

시스템 활성화f)

서비스 시연g)

설치관련사항 기록유지h)

산출물산출물산출물산출물5.5.8.35.5.8.35.5.8.35.5.8.3

전환 계획서a)

전환결과보고서b)

문제해결보고서c)

설치계획서d) *

책임전환계획서e) *

제품 또는 서비스 전달 계획서f) *

책임 전환서g) *

- 84 -

시스템 인수서h) *

시스템 할당서i) *

시스템 설치서j) *

전환 전략서k) *

확인 프로세스확인 프로세스확인 프로세스확인 프로세스5.5.95.5.95.5.95.5.9

목적목적목적목적5.5.9.15.5.9.15.5.9.15.5.9.1

확인 프로세스 목적은 시스템을 사용할 때 시스템이 제공하는 서비스가 이해당사자 요구

조건을 수용한다는 객관적 증거를 제시하는 것이다 이 프로세스는 비교 영향평가를 수행하.

여 이해당사자 요구조건이 올바르게 정의되었다는 것을 확증한다.

활동활동활동활동5.5.9.25.5.9.25.5.9.25.5.9.2

확인 전략 정의a)

확인 계획 준비b)

확인 준비 보장c)

확인 수행d)

확인자료 생성e)

부분적 확인 수행f)

확인자료 분석 기록 보고g) / /

산출물산출물산출물산출물5.5.9.35.5.9.35.5.9.35.5.9.3

확인계획서a) *

확인결과보고서b)

문제해결보고서c)

확인서d) *

확인 전략서e) *

최종시험보고서f) *

운영 프로세스운영 프로세스운영 프로세스운영 프로세스5.5.105.5.105.5.105.5.10

목적목적목적목적5.5.10.15.5.10.15.5.10.15.5.10.1

운용 프로세스 목적은 서비스를 제공하기 위하여 시스템을 사용하는 것이다 이 프로세스.

는 직원에게 시스템 운용을 할당하고 서비스 및 운용자 시스템 성능을 모니터한다 서비스- .

- 85 -

를 유지하기 위하여 계약체결 이해당사자 요구조건 및 조직의 제약요소와 연관된 운용상,

문제를 식별해내고 분석한다.

활동활동활동활동5.5.10.25.5.10.25.5.10.25.5.10.2

운영전략 준비a)

관련 서비스 확보b)

운용자 배치c)

시스템 활성화d)

재료 소모e)

운용상태 관찰f)

시스템 관찰g)

고장 식별 활동 수행h)

시정요구 조치 결정i)

인간 원인 문제 교정j)

지속적 사용자 의사소통k)

산출물산출물산출물산출물5.5.10.35.5.10.35.5.10.35.5.10.3

운영 계획서a) *

운영 결과보고서b)

문제해결보고서c)

사용자메뉴얼d) *

운영 전략서e) *

유지보수 프로세스유지보수 프로세스유지보수 프로세스유지보수 프로세스5.5.115.5.115.5.115.5.11

목적목적목적목적5.5.11.15.5.11.15.5.11.15.5.11.1

유지보수 프로세스 목적은 서비스를 제공하는 시스템의 능력을 유지시키는 것이다 유지.

보수 프로세스는 서비스를 전달하고 분석을 위한 문제점을 기록하며 교정적응완벽한 예방, ․ ․

활동을 하는 시스템 능력을 모니터하고 복구된 능력을 확인한다.

활동활동활동활동5.5.11.25.5.11.25.5.11.25.5.11.2

유지보수 전략 준비a)

제약사항 정의b)

시스템 요소 및 서비스 확보c)

문제 보고서 및 사고 기록 작성d)

- 86 -

교정 절차서 작성e)

교정활동 수행f)

물류 활동 만족 확인g)

예방 정비 수행h)

고장 식별활동 수행i)

유지보수 활동 기록 유지j)

산출물산출물산출물산출물5.5.11.35.5.11.35.5.11.35.5.11.3

유지보수 계획서a)

유지보수 결과보고서b)

문제해결보고서c)

유지보수요구서d) *

유지보수전략서e) *

시스템 위험식별 및 분석서f) *

시스템 위험부담 식별 요약서g) *

예방정비서h) *

폐기 프로세스폐기 프로세스폐기 프로세스폐기 프로세스5.5.125.5.125.5.125.5.12

목적목적목적목적5.5.12.15.5.12.15.5.12.15.5.12.1

폐기 프로세스 목적은 시스템 개체의 실존을 끝나게 하는 것이다 이 프로세스는 최종상.

태 조건이 부여되어 있고 최초 또는 받아들일 수 있는 환경으로 복귀토록 되어있는 시스템

및 그 모든 폐기 제품을 활동성을 잃게 하고 분해하고 제거한다 이 프로세스는 규제계약체. ․

결조직 제약요소 및 이해당사자 요건에 따라 시스템 요소와 폐기 제품을 환경적으로 건전․

한 방법으로 파괴저장하거나 또는 교정한다 폐기와 관련된 기록이 요구될 경우 운용자 및.․

사용자의 건강 환경의 안전이 모니터 될 수 있도록 기록을 유지한다, .

활동활동활동활동5.5.12.25.5.12.25.5.12.25.5.12.2

폐기전략 정의a)

제약 사항 공유b) .

시스템 또는 서비스 확보c)

시스템 비활성화d)

인력 철수 및 운용지식 기록e)

시스템을 관리 가능한 요소 해체f)

시스템 제거g)

- 87 -

시스템 보관 규정화h)

시스템 파기i)

폐기 확인j)

시스템 수명주기 전 과정에 대한 정보 보관k)

산출물산출물산출물산출물5.5.12.35.5.12.35.5.12.35.5.12.3

폐기계획서a) *

폐기결과보고서b)

문제해결보고서c)

폐기 전략서d) *

폐기 보고서e) *

- 88 -

부록 수명주기 단계A. (Life cycle Stages)

서론서론서론서론A.1A.1A.1A.1

수명주기 단계는 수명주기 모델링에 사용되는 시스템 수명주기 프로세스 내 하위 구조를

구축하는데 사용되며 아래의 단계로 구성된다6 .

개념 단계a) (Concept Stage)

개발 단계b) (Development Stage)

생산 단계c) (Production Stage)

운용 단계d) (Utilization Stage)

지원 단계e) (Support Stage)

폐기 단계f) (Retirement Stage)

개념단계개념단계개념단계개념단계A.2A.2A.2A.2

목적목적목적목적A.2.1A.2.1A.2.1A.2.1

개념 단계는 새로운 사업기회에 대한 영향을 평가하고 예비 시스템 요구조건 및 타당한

설계 해결책을 개발하는 목적으로 실행한다.

활동활동활동활동A.2.2A.2.2A.2.2A.2.2

이해관계자 요구사항 식별a)

개념 탐색b)

실행가능 솔루션 제안c)

개발 단계개발 단계개발 단계개발 단계A.3A.3A.3A.3

목적목적목적목적A.3.1A.3.1A.3.1A.3.1

개발 단계는 획득자 요구조건을 만족하고 생산시험평가운용지원 및 폐기 될 수 있는 목․ ․ ․

적시스템 개발을 위해 수행한다.

활동활동활동활동A.3.2A.3.2A.3.2A.3.2

- 89 -

시스템 요구사항 정교화a)

솔루션 기술서 작성b)

시스템 구축c)

시스템 검증 및 확인d)

생산 단계생산 단계생산 단계생산 단계A.4A.4A.4A.4

목적목적목적목적4.14.14.14.1

생산 단계는 제품을 생산하고 제조하며 제품을 시험평가하고 필요할 경우 관련된 지원기, ․

반시스템을 생산하는 것을 실행한다.

활동활동활동활동4.24.24.24.2

시스템 생산a)

감사 및 시험b)

운용 단계운용 단계운용 단계운용 단계A.5A.5A.5A.5

목적목적목적목적A.5.1A.5.1A.5.1A.5.1

활용단계는 제품 운용 의도된 환경에서 서비스를 제공 지속적 운용 효과성 확증을 위하, ,

여 실행된다.

활동활동활동활동A.5.2A.5.2A.5.2A.5.2

사용자 요구사항을 만족하는 시스템 운용a)

지원 단계지원 단계지원 단계지원 단계A.6A.6A.6A.6

목적목적목적목적A.6.1A.6.1A.6.1A.6.1

지원단계는 물류 정비 지속적인 목적시스템 운용 및 지속 가능한 서비스를 제공하기 위, ,

하여 실행한다.

활동활동활동활동A.6.2A.6.2A.6.2A.6.2

지속적 시스템 능력 유지a)

- 90 -

폐기 단계폐기 단계폐기 단계폐기 단계A.7A.7A.7A.7

목적목적목적목적A.7.1A.7.1A.7.1A.7.1

폐기단계는 목적시스템 및 관련된 운용지원 서비스 제거방법을 제공과 폐기 시스템 자체․

를 운용지원하기 위하여 실행한다.․

활동활동활동활동A.7.2A.7.2A.7.2A.7.2

시스템을 저장 기록 또는 처분a) ,

- 91 -

부록 프로세스별 활동 산출물 메트릭스B. -

활동과 산출물에 대한 매트릭스를 작성하여CRUD(Create, Read, Update, Delete)

각 활동에 대하여 어떤 산출물이 생성 읽고 참조 수정 삭제되는지에 대해서 일목 요연하, ( ), ,

게 표시하였다.

획득 프로세스획득 프로세스획득 프로세스획득 프로세스B.1B.1B.1B.1

산출물< >

활동< >

a)

획

득

계

획

서

*

b)

대

금

지

급

계

획

서

*

c)

공

급

자

성

과

관

리

계

획

서

*

d)

시

스

템

인

수

계

획

서

*

e)

계

약

서

*

f)

시

스

템

인

수

전

략

계

획

서

g)

요

구

사

항

정

의

서

*

h)

제

안

요

청

서

*

i)

고

객

공

급

자

합

의

서

*

j)

획

득

전

략

서

*

k)

공

급

자

선

정

계

획

서

*

l)

협

약

서

*

m)

합

의

서

*

획득계획 수립a) C C C

요구사항 준비b) C C

공급자와 의사소통c) C C U

공급자 선정d) C C C

공급자와 계약협상e) C U R U U

계약 이행 평가f) R R R R

최종산출물 확인g) C R

대금 지급h) R

- 92 -

공급 프로세스공급 프로세스공급 프로세스공급 프로세스B.2B.2B.2B.2

산출물< >

활동< >

a)제안서*

b)계약서*

c)사업수행계획서

d)시스템개발계획서

e)인수확인서

f)검증결과보고서

g)확인결과보고서

h)품질관리결과보고서

i)합동고객공급자감리검토계획서*

j)협력업체관리계획서*

k)요청응답서*

획득자 식별a)

요구사항 평가b)

요청사항 대응책 준비c) C

계약 협의d) R R C

계약 체결e) C C C U

계약 이행 결과 평가f) R R C R C

최종산출물 인도g) C R

대금 수령 및 통보h) C C

최종산출물 책임 이관i) R

- 93 -

전사 환경 관리 프로세스전사 환경 관리 프로세스전사 환경 관리 프로세스전사 환경 관리 프로세스B.3B.3B.3B.3

산출물< >

활동< >

a)조직비전정의서*

b)조직사업전략계획서*

사업 분야 계획 수립a) C C

시스템 수명주기 정책 절차를b) /

준비R

역할 책임 권한 정의c) / / R

사업 기준 정의d) R

시스템 수명주기 모델의e)

주기적 검토U

정책 절차 공유f) / R R

- 94 -

투자 관리 프로세스투자 관리 프로세스투자 관리 프로세스투자 관리 프로세스B.4B.4B.4B.4

산출물< >

활동< >

a)

투

자

관

리계

획

서

b)

비

용

대

효

과

분

석

서

투자 계획 수립a) C

프로젝트 책임 권한 정의b) / R

예측 산출물 식별c) R

자원 할당d)

프로젝트 인터페이스 식별e)

보고 검토회 일정 명시f) /

프로젝트 권한 부여g)

프로젝트 평가h) C

프로젝트 조정i)

프로젝트 지연 취소j) / R

- 95 -

시스템 수명주기 프로세스 관리 프로세스시스템 수명주기 프로세스 관리 프로세스시스템 수명주기 프로세스 관리 프로세스시스템 수명주기 프로세스 관리 프로세스B.5B.5B.5B.5

산출물< >

활동< >

a)

시

스

템

수명

주

기

프

로

세스

관

리

계

획

서*

b)

시

스

템

수명

주

기

정

의

계획

서

*

c)

프

로

세

스평

가

계

획

서

*

d)

프

로

세

스개

선

계

획

서

*

시스템 수명주기 프로세스a)

수립C

테일러링 정책 절차 수립b) / C R

방법 도구 식별c) / R

평가척도 수립d) R

프로세스 실행 관찰e) C

프로세스 개선 기회 식별f) R

프로세스 방법 도구 개선g) / / C

- 96 -

자원 관리 프로세스자원 관리 프로세스자원 관리 프로세스자원 관리 프로세스B.6B.6B.6B.6

산출물< >

활동< >

a)

자

원

관

리계

획

서

*

b)

기

반

구

축

계

획

서

*

c)

훈

련

계

획서

*

자원 지원항목 결정 제공a) / C

인적요소 외 자원 확보b) C

인력 유지 관리c) / R C

참여인력 동기 부여d) R

다수 프로젝트의 관리e)

인터페이스 통제U

- 97 -

품질 관리 프로세스품질 관리 프로세스품질 관리 프로세스품질 관리 프로세스B.7B.7B.7B.7

산출물< >

활동< >

a)

품

질

관

리계

획

서

*

b)

품

질

진

척

보

고

서

*

c)

품

질

목

표

서

*

d)

시

스

템

품

질

계

획

서

*

품질관리 정책 표준 절차a) / /

수립C C

품질관리 목적 목표 수립b) / R C

책임 권한 정의c) / R

고객만족 결과보고서 평가d) /

주기적 품질 계획 검토e) C R R

품질 개선 상태 관찰f) U R

- 98 -

프로젝트 계획 프로세스프로젝트 계획 프로세스프로젝트 계획 프로세스프로젝트 계획 프로세스B.8B.8B.8B.8

산출물< >

활동< >

a)

프로

젝

트

관

리

계획

서

*

b)

프로

젝

트

계

약

관리

계

획

서

c)

프로

젝

트

변

경

관리

계

획

서

d)

프로

젝

트

재

정

관리

계

획

서

e)

프로

젝

트

통

제

계획

서

f)

프로

젝

트

품

질

보증

계

획

서

g)

감

리

계

획

서

*

h)

공학

계

획

서

I)

소프

트

웨

어

개

발계

획

서

j)

시스

템

안

전

계

획서

k)

시스

템

보

안

계

획서

l)

종

합

시

험

계

획

서

m)

작업

분

할

구

조

도(

W

B

S)

n)

문서

화

계

획

서

o)

변

환

계

획

서

*

p)

프로

젝

트

계

획

서*

q)

프로

젝

트

팀

구

조와

운

영

역

할

계획

서

*

r)

프로

젝

트

일

정

*

s)

브

리

핑

자

료

*

프로젝트a)

목표제약사항식별/C C

b) 프로젝트범위정의 U C R

c) 작업분할구조(WBS)

작성C

프로젝트일정d)

정의유지/R C C C C U C C C

프로젝트성과척도e)

정의C C U

프로젝트비용정의f)

및예산계획R U C

책임권한구조수립g) / R R R R R

기반서비스정의h) / R

외부프로젝트와i)

연계한획득정의R

기술관리계획j)

수립시행/R

성과척도연관자료k) /

정의R R

프로젝트품질계획l)

수립R

- 99 -

프로젝트 평가 프로세스프로젝트 평가 프로세스프로젝트 평가 프로세스프로젝트 평가 프로세스B.9B.9B.9B.9

산출물< >

활동< >

a)

프로

젝

트

평

가

계획

서

b)

프로

젝

트

평

가

결과

보

고

서

c)

Tr

a

d

e-

o

ff

분

석

보

고

서*

프로젝트 상태 평가a) C

품질 보증 수행b) R

프로젝트 팀 평가c) R

지원 인프라 적정성 가용성d) /

평가R

프로젝트 진척 평가e) R

관리 및 기술적 검토 감리f) / /

검사 수행R

주요 프로세스 신기술 관찰g) / R C

데이터 분석 및 권고h) R C

주기적 보고서 제공i) R

- 100 -

프로젝트 통제 프로세스프로젝트 통제 프로세스프로젝트 통제 프로세스프로젝트 통제 프로세스B.10B.10B.10B.10

산출물< >

활동< >

a)

프

로

젝

트통

제

계

획

서

b)

프

로

젝

트변

경

보

고

서

c)

요

구

사

항상

태

보

고

서

d)

프

로

젝

트진

척

보

고

서

e)

문

제

해

결

계

획

서

*

f)

교

정

조

치

보

고

서

*

g)

편

차

보

고

서

*

요구 및 변경사항 관리a) C C

교정활동 수행b) C C

예방활동 수행c) U

문제해결활동 수행d) U C C C

변화관리e) R R

계약 변경활동 수행f) U

계약 교정활동 수행g) U R R

프로젝트 승인h) R R R

- 101 -

의사결정 프로세스의사결정 프로세스의사결정 프로세스의사결정 프로세스B.11B.11B.11B.11

산출물< >

활동< >

a)

의

사

결

정계

획

서

b)

T

r

a

de-

o

f

f

분

석보

고

서

*

c)

의

사

결

정결

과

보

고

서

d)

의

사

결

정

전

략

서

*

의사결정 전략 정의a) C C

의사결정 과정 참여b) R R

환경 요구사항 식별c) / R R

의사결정전략 선정 및d)

성공척도 식별R R

대안활동 결과 평가e) C

결과 기록 추적 평가 보고f) / / / R C

처리결과 기록 유지g) R

- 102 -

위험관리 프로세스위험관리 프로세스위험관리 프로세스위험관리 프로세스B.12B.12B.12B.12

산출물< >

활동< >

a)

위

험

관

리계

획

서

*

b)

위

험

해

결활

동

계

획

서

c)

위

험

분

석보

고

서

d)

위

험

상

태보

고

서

e)

위

험

관

리

서

*

f)

위

험

관

리

요

약

서

*

g)

시

스

템

위

험

분

석

계

획

서

*

위험 접근방법 수립a) C C C

위험 식별 정의b) / R R

위험 확률 결정c) C

위험 평가d) C

위험 우선순위 부여e) R

위험 취급 전략 결정f) R R C

위험 수용 한계 정의g) R

위험취급활동 식별h) R

위험관련 의사소통i) R R

위험 기록 유지j) C

- 103 -

형상관리 프로세스형상관리 프로세스형상관리 프로세스형상관리 프로세스B.13B.13B.13B.13

산출물< >

활동< >

a)

형

상

관

리계

획

서

*

b)

형

상

통

제결

과

보

고

서

c)

형

상

정

보관

리

보

고

서

d)

형

상

평

가결

과

보

고

서

e)

형

상

항

목

기

준

서

*

f)

형

상

관

리

전

략

서

*

g)

시

스

템

제

품

배

포

서

*

형상관리 계획 수립a) C C C

형상통제항목 식별b) R C

형상 정보 관리c) C C

형상 평가d) C

- 104 -

정보관리 프로세스정보관리 프로세스정보관리 프로세스정보관리 프로세스B.14B.14B.14B.14

산출물< >

활동< >

a)

프로

젝

트

정

보

관리

계

획

서

b)

정보

품

질

분

석

보고

서

c)

정보

품

질

진

척

보고

서

d)

교

훈

보

고

서

*

e)

t

r

a

d

e

s

t

u

d

y

문

서

*

f)

상

태

보

고

서

*

g)

문

서

화

프

로

세

스

*

h)

훈

련

메

뉴

얼

*

정보 항목 정의a) C C

권한 책임 부여b) / R

권리 의무 위임 사항 정의c) / / R C

내용 의미 형태 매체 정의d) / / / R R

정보 항목 확보e) R C C C

정보 항목과 이의 저장 기록 유f)

지C C

정보유지활동 정의g) R

정보 재생 배포h) / R R

공식 문서 제공i) R

지정 정보 기록보관j) R

정보 폐기k) R

- 105 -

이해당사자 요구사항 정의 프로세스이해당사자 요구사항 정의 프로세스이해당사자 요구사항 정의 프로세스이해당사자 요구사항 정의 프로세스B.15B.15B.15B.15

산출물< >

활동< >

a)

운

영

개

념

기

술

서

b)

제

품

및

서

비

스

요

구

계

획

서

c)

시

스

템

개

념

계

획

서

d)

제

품

및

서

비

스

요

구

서

e)

안

전

계

획

서

f)

보

안

계

획

서

g)

인

적

요

소

요

구

서

h)

요

구

서

i)

안

전

요

구

서

j)

보

안

요

구

서

이해당사자 식별a) C

요구사항 추출b) R C

제약사항 정의c) R

대표 집단 정의d) R

e) 사용자와시스템상호작용식별 R

요구사항 구체화f) R C C C

요구조항 분석g) R C R R C C C C

요구조항 문제 해결h) R

이해당사자에게 피드백i) R

이해당사자 선임j) R

이해당사자 요구사항 기록k) R

이해당사자 요구사항 유지l) R

- 106 -

요구사항 분석 프로세스요구사항 분석 프로세스요구사항 분석 프로세스요구사항 분석 프로세스B.16B.16B.16B.16

산출물< >

활동< >

a)

요

구

사

항명

세

서

b)

인

터

페

이스

요

구

사

항

명세

서

c)

기

능

상

세

계

획

서

*

d)

기

능

상

세

서

*

e)

규

정

및

표

준

요

구

서

*

f)

시

스

템

요

구

사

항

명

세

서

*

시스템 기능 경계 정의a) C C

개별기능 정의b) R C C

제약요인 정의c) R

기술 품질 정의d) / R R C

요구사항 기능 구체화e) / R R R R C

요구사항 통합성 분석f) R R

요구사항 추적성 제시g) R

요구사항 유지h) R R

- 107 -

아키텍쳐 설계 프로세스아키텍쳐 설계 프로세스아키텍쳐 설계 프로세스아키텍쳐 설계 프로세스B.17B.17B.17B.17

산출물< >

활동< >

a)

아

키

텍

처설

계

명

세

서

*

b)

인

터

페

이스

설

계

기

술

서*

c)

시

스

템

방

법

론

,

도

구

및

기

술

계

획

서

*

d)

시

스

템

상

세

설

계

명

세

서

*

e)

시

스

템

수

명

주

기

적

용

프

로

세

스

*

f)

시

스

템

수

명

주

기

활

동

및

작

업

매

핑

문

서

*

g)

시

스

템

방

법

론

도

구

및

기

술

서

*

아키텍쳐 설계 정의a) C

시스템 기능 분할 할당b) / R C

아키텍쳐 설계 분석 및 설계 기c)

준 설정R C C C C

시스템 요구사항 결정d) U U

와 요소 결정e) H/W S/W U

대안 설계 해결책 평가 및상세f)

수준 모델링R C

외부 시스템과의 인터페이스 정g)

의 문서화/R

물리적 설계 구체화h) R

아키텍쳐 설계 정보 기록i) U

아키텍쳐 설계와 시스템 요구사j)

항간 상호 추적성 유지R

- 108 -

구현 프로세스구현 프로세스구현 프로세스구현 프로세스B.18B.18B.18B.18

산출물< >

활동< >

a)

구

현

계

획서

*

b)

구

현

결

과보

고

서

구현전략 수립a) C

제약사항 식별b) R

시스템 항목 구현 채택c) / R

계약 만족 증거 기록d) C

포장 보관e) / R

- 109 -

통합 프로세스통합 프로세스통합 프로세스통합 프로세스B.19B.19B.19B.19

산출물< >

활동< >

a)

통

합

계

획서

*

b)

통

합

결

과보

고

서

c)

운

영

/

설치

매

뉴

얼

d)

문

제

해

결보

고

서

조합순서와 전략 정의a) C

제약사항 식별b) R

관련 시스템과 재료 확보c) R C

시스템 항목 확보d) R R

기준 순응 보장e) R C C

시스템 항목 통합f) R

통합정보기록유지g) R R R

- 110 -

검증 프로세스검증 프로세스검증 프로세스검증 프로세스B.20B.20B.20B.20

산출물< >

활동< >

a)

검

증

계

획서

*

b)

검

증

결

과보

고

서

c)

문

제

해

결보

고

서

d)

측

정

절

차

계

획

서

*

e)

시

험

및

평

가

서

*

f)

추

적

문

서

*

g)

검

증

전

략

서

*

h)

검

증

전

략

요

약

서

*

검증 전략 정의a) C C

검증 계획 정의b) C C

잠재 제약사항 식별 공유c) / R

검증 준비 확인d) R

검증 수행e) U C C

검증 자료 생성f) R C C

검증 분석 기록 보고g) / / R R

- 111 -

전환 프로세스전환 프로세스전환 프로세스전환 프로세스B.21B.21B.21B.21

산출물< >

활동< >

a)

전

환

계

획서

b)

전

환

결

과보

고

서

c)

문

제

해

결보

고

서

d)

설

치

계

획

서

*

e)

책

임

전

환

계

획

서

*

f)

제

품

또

는

서

비

스

전

달

계

획

서

*

g)

책

임

전

환

서

*

h)

시

스

템

인

수

서

*

i)

시

스

템

할

당

서

*

j)

시

스

템

설

치

서

*

k)

전

환

전

략

서

*

전환 전략 준비a) C C

운용 장소 준비b) R

시스템 납품c) C C C

설치 접속d) / R C C C C

설치시험e) R C

시스템 활성화f) R

서비스 시연g) R

설치관련사항 기록유지h) R C

- 112 -

확인 프로세스확인 프로세스확인 프로세스확인 프로세스B.22B.22B.22B.22

산출물< >

활동< >

a)

확

인

계

획서

*

b)

확

인

결

과보

고

서

c)

문

제

해

결보

고

서

d)

확

인

서

*

e)

확

인

전

략

서

*

f)

최

종

시

험

보

고

서

*

확인 전략 정의a) C

확인 계획 준비b) C

확인 준비 보장c) R

확인 수행d) C

확인자료 생성e) R C

부분적 확인 수행f) R C C

확인자료 분석 기록 보고g) / / R U U

- 113 -

운영 프로세스운영 프로세스운영 프로세스운영 프로세스B.23B.23B.23B.23

산출물< >

활동< >

a)

운

영

계

획서

*

b)

운

영

결

과보

고

서

c)

문

제

해

결보

고

서

d)

사

용

자

메

뉴

얼

*

e)

운

영

전

략

서

*

운영전략 준비a) C C

관련 서비스 확보b) R C

운용자 배치c) R C R

시스템 활성화d) R

재료 소모e) R

운용상태 관찰f) R C

시스템 관찰g) R R

고장 식별 활동 수행h) R

시정요구 조치 결정i) R

인간 원인 문제 교정j) R

지속적 사용자 의사소통k) R R

- 114 -

유지보수 프로세스유지보수 프로세스유지보수 프로세스유지보수 프로세스B.24B.24B.24B.24

산출물< >

활동< >

a)

유

지

보

수계

획

서

b)

유

지

보

수결

과

보

고

서

c)

문

제

해

결보

고

서

d)

유

지

보

수

요

구

서

*

e)

유

지

보

수

전

략

서

*

f)

시

스

템

위

험

식

별

및

분

석

서

*

g)

시

스

템

위

험

부

담

식

별

요

약

서

*

h)

예

방

정

비

서

*

유지보수 전략 준비a) C C

제약사항 정의b) R

c) 시스템 요소 및 서비스 확보 R C

문제 보고서 및 사고 기록d)

작성C C C

교정 절차서 작성e) R R

교정활동 수행f) R R

물류 활동 만족 확인g) R

예방 정비 수행h) R

고장 식별활동 수행i) R R C

유지보수 활동 기록 유지j) R R C

- 115 -

폐기 프로세스폐기 프로세스폐기 프로세스폐기 프로세스B.25B.25B.25B.25

산출물< >

활동< >

a)

폐

기

계

획서

*

b)

폐

기

결

과보

고

서

c)

문

제

해

결보

고

서

d)

폐

기

전

략

서

*

e)

폐

기

보

고

서

*

폐기전략 정의a) C C

제약 사항 공유b) R

시스템 또는 서비스 확보c) R

시스템 비활성화d) C

e) 인력 철수 및 운용지식 기록 R C

시스템을 관리 가능한 요소f)

해체R R

시스템 제거g) R

시스템 보관 규정화h) R

시스템 파기i) R R

폐기 확인j) R

시스템 수명주기 전 과정에k)

대한 정보 보관R C

- 116 -

부록 산출물 기술서C.

프로세스 그룹명 프로세스명 산출물 수

계약 프로세스5.2획득 프로세스5.2.2 13

공급 프로세스5.2.3 11

획득 프로세스획득 프로세스획득 프로세스획득 프로세스C.1C.1C.1C.1

획득계획서a) *

자원 획득에 관해 무엇을 언제 어떻게 수행 하는지에 대해 작업 활동, , (Task)/

을 기술한다 여기에는 자원에 대해 개발 또는 구입 에 관한 사항을 포(Activity) . “ ” “ ”

함한다.

대금지급계획서b) *

벤더에 대한 지불 방법에 대해 무엇을 언제 어떻게 관리하는지에 대한 작업 활, , (Task)/

동 을 기술한다(Activity) .

공급자 성과 관리 계획서c) *

공급자의 성과 감시에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

시스템 인수 계획서d) *

시스템과 시스템의 인수에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업, , (Task)/

활동 을 기술하며 인수 기준을 포함한다(Activity) .

계약서e) *

둘 이상의 이해당사자 간에 동의한 계약을 기술한다.

시스템인수 전략계획서f)

시스템의 인수에 대한 전략적 계획에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작, ,

업 활동 을 기술한다(Task)/ (Activity) .

- 117 -

요구사항정의서g) *

시스템 요구사항의 정의에 대해서 무엇을 언제 어떻게 정의하고 관리하는지에 대한 작, ,

업 활동 을 기술한다(Task)/ (Activity) .

제안요청서h) *

가능한 입후보자에게 정보를 얻기 위한 공식적인 요청을 기술한다.

고객공급자합의서i) *

고객과 공급자 사이의 계약에 대한 정보를 기록한다.

획득전략서j) *

발주 전략에 대한 정보를 기록한다.

공급자 선정 계획서k) *

공급자의 선정에 대해서 무엇을 언제 어떻게 관리 하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

협약서l) (charter)*

프로젝트의 범위와 제품을 식별하고 헌장은 프로젝트를 지원을 위해 핵심 당사자 사이에

서명된다.

합의서m) (correspondence)*

해당 프로젝트에 의해 제공되는 양자간 합의 사항을 기록한다.

공급 프로세스공급 프로세스공급 프로세스공급 프로세스C.2C.2C.2C.2

제안서a) *

벤더가 어떻게 사용자 요구사항을 충족시킬지에 관한 문서로서 비용 일정 정보관리를, ,

포함한다.

계약서b) *

둘 이상의 이해당사자 간에 동의한 계약을 기술한다.

사업수행계획서c)

사업수행의 계획에 대해서 무엇을 언제 어떻게 정의하고 관리하는지에 대한 작업, ,

- 118 -

활동 을 기술한다(Task)/ (Activity) .

시스템개발 계획서d)

시스템개발 계획에 대해서 무엇을 언제 어떻게 정의하고 관리하는지에 대한 작업, ,

활동 을 기술한다(Task)/ (Activity) .

인수확인서e)

시스템의 인수확인에 대한 정보를 기록한다.

검증결과보고서f)

시스템에 대한 검증 결과를 보고한다.

확인결과보고서g)

시스템의 이상 유무에 대한 확인결과를 보고한다.

품질관리결과보고서h)

시스템의 품질 및 상태를 보고한다.

합동고객 공급자 감리검토계획서i) *

공급자가 제공한 품목에 대해서 감리와 검토를 수행하기 위한 계획을 식별한다.

협력업체 관리 계획서j) *

협력업체에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

요청 응답서k) *

요청 응답에 대한 정보를 기록한다.

- 119 -

프로세스 그룹명 프로세스명 산출물 수

전사 프로세스5.3

전사 환경 관리 프로세스5.3.2 2

투자 관리 프로세스5.3.3 2

시스템 수명주기 프로세스 관리5.3.4

프로세스4

자원 관리 프로세스5.3.5 3

품질 관리 프로세스5.3.6 4

전사 환경 관리 프로세스전사 환경 관리 프로세스전사 환경 관리 프로세스전사 환경 관리 프로세스C.3C.3C.3C.3

조직 비전 정의서a) *

공급자가 제공한 품목에 대해서 감리와 검토를 수행하기 위한 계획을 식별한다.

조직 사업전략 계획서b) *

조직의 업무에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

투자 관리 프로세스투자 관리 프로세스투자 관리 프로세스투자 관리 프로세스C.4C.4C.4C.4

투자관리 계획서a)

시스템 획득의 투자관리에 대해서 무엇을 언제 어떻게 정의하고 관리하는지에 대한 작, ,

업 활동 을 기술한다(Task)/ (Activity) .

비용 대 효과 분석서b)

시스템의 비용 대 효과 분석결과를 요약 보고한다.

시스템 수명주기 프로세스 관리 프로세스시스템 수명주기 프로세스 관리 프로세스시스템 수명주기 프로세스 관리 프로세스시스템 수명주기 프로세스 관리 프로세스C.5C.5C.5C.5

시스템 수명주기 프로세스 관리 계획서a) *

시스템 수명주기 개발에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활, , (Task)/

동 을 기술한다(Activity) .

시스템 수명주기 정의 계획서b) *

- 120 -

시스템의 수명주기 처리에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업, , (Task)/

활동 을 기술한다(Activity) .

프로세스 평가 계획서c) *

프로세스 실행 가능성 효율성 효과성에 대해서 무엇을 언제 어떻게 평가 하는지에 대, , , ,

한 작업 활동 을 기술한다(Task)/ (Activity) .

프로세스 개선 계획서d) *

프로세스 개선에 대해서 무엇을 언제 어떻게 보장 하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

자원 관리 프로세스자원 관리 프로세스자원 관리 프로세스자원 관리 프로세스C.6C.6C.6C.6

자원 관리 계획서a) *

자원에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동 을, , (Task)/ (Activity)

기술한다 이 계획은 프로젝트 일정과 자원 계획을 정의한다. .

기반 구축 계획서b) *

프로젝트의 기반구조 관리를 위해 무엇을 언제 어떻게 관리하는지에 대해 작업, , (Task)/

활동 을 기술한다(Activity) .

훈련 계획서c) *

훈련 대해서 무엇을 언제 어떻게 수행 하는지에 대한 작업 활동 을, , (Task)/ (Activity)

기술한다.

품질 관리 프로세스품질 관리 프로세스품질 관리 프로세스품질 관리 프로세스C.7C.7C.7C.7

품질관리계획서a) *

산출물과 프로세스 품질에 대해서 무엇을 언제 어떻게 보장 하는지에 대한 작업, ,

활동 을 기술한다(Task)/ (Activity) .

품질진척 보고서b) *

품질을 관리하기 위한 시스템 정보를 기록한다.

품질목표서c) *

- 121 -

프로젝트의 품질 목표에 대한 정보를 기록한다.

시스템 품질 계획서d) *

시스템의 품질에서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

프로세스 그룹명 프로세스명 산출물 수

프로젝트 프로세스5.4

프로젝트 계획 프로세스5.4.2 19

프로젝트 평가 프로세스5.4.3 3

프로젝트 통제 프로세스5.4.4 7

프로젝트 의사결정 프로세스5.4.5 4

위험관리 프로세스5.4.6 7

형상관리 프로세스5.4.7 7

정보관리 프로세스5.4.8 8

프로젝트 계획 프로세스프로젝트 계획 프로세스프로젝트 계획 프로세스프로젝트 계획 프로세스C.8C.8C.8C.8

프로젝트 관리 계획서a) *

프로젝트에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

프로젝트 계약관리 계획서b)

프로젝트의 계약에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

프로젝트 변경관리 계획서c)

프로젝트의 변경에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

프로젝트 재정관리 계획서d)

프로젝트의 재정에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

- 122 -

프로젝트 통제 계획서e)

프로젝트의 통제에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

프로젝트 품질보증 계획서f)

프로젝트의 품질보증에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활, , (Task)/

동 을 기술한다(Activity) .

감리계획서g) *

감리에 대해 무엇을 언제 어떻게 수행하는지에 대해 작업 활동 을 기, , (Task)/ (Activity)

술한다.

공학 계획서h)

공학에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동 을, , (Task)/ (Activity)

기술한다.

소프트웨어 개발 계획서i)

소프트웨어 개발에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

시스템 안전 계획서j)

시스템의 안전관리에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

시스템 보안 계획서k)

시스템의 보안에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

종합시험 계획서l)

시스템의 종합시험 계획에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업, , (Task)/

활동 을 기술한다(Activity) .

작업분할구조도m) (WBS)

작업분할구조에 대한 정보를 기록한다.

- 123 -

문서화계획서n)

시스템의 문서화 계획에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활, , (Task)/

동 을 기술한다(Activity) .

변환계획서o) *

유지보수 단계에서부터 생산 시스템까지의 변경사항에 대해 무엇을 언제 어떻게 이동,

하는지에 대해 작업 활동 을 기술한다(Task)/ (Activity) .

프로젝트계획서p) *

프로젝트 계획의 모든 것들에 대해서 무엇을 언제 어떻게 관리 하는지에 대한 작업, ,

활동 을 기술한다(Task)/ (Activity) .

프로젝트 팀 구조와 운영역할 계획서q) *

프로젝트 팀의 구조와 운영에 대해서 무엇을 언제 어떻게 관리 하는지에 대한 작업, ,

활동 을 기술한다 이것은 조직의 보고 구조에 대해 상세히 정의하고 역(Task)/ (Activity) .

할과 책임에 대해 명확히 정의한다.

프로젝트 일정r) *

프로젝트의 일정에 대한 정보를 기록한다.

브리핑자료s) *

프로젝트를 위한 간결한 정보를 기록한다.

프로젝트 평가 프로세스프로젝트 평가 프로세스프로젝트 평가 프로세스프로젝트 평가 프로세스5.8.95.8.95.8.95.8.9

프로젝트 평가 계획서a)

프로젝트 평가 계획에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

프로젝트 평가결과 보고서b)

프로젝트의 평가 결과를 보고한다.

분석 보고서c) Trade-off

분석 결과를 보고한다Trade-off .

- 124 -

프로젝트 통제 프로세스프로젝트 통제 프로세스프로젝트 통제 프로세스프로젝트 통제 프로세스C.10C.10C.10C.10

프로젝트 통제 계획서a)

프로젝트 통제 계획에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

프로젝트 변경 보고서b)

프로젝트의 변경 사항을 기록 유지하며 요약 보고한다.

요구사항 상태 보고서c)

프로젝트의 요구사항에 대한 상태 및 처리결과를 보고한다.

프로젝트 진척 보고서d)

프로젝트 일정에 따른 진척 결과를 보고한다.

문제 해결 계획e) *

문제점들에 대해서 무엇을 언제 어떻게 관리 및 해결 하는지에 대한 작업 활동, , (Task)/

을 기술한다 관리에 대한 주의를 끌어내기 위해 문제점들을 어떻게 분류할지(Activity) .

정의한다.

교정조치 보고서f) *

교정 활동의 결과를 보고한다.

편차 보고서g) *

시스템의 외부환경으로 인한 편차 결과와 상태를 보고한다.

의사결정 프로세스의사결정 프로세스의사결정 프로세스의사결정 프로세스C.11C.11C.11C.11

의사결정 계획서a)

의사결정에 대한 전략 정보에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업, ,

활동 을 기술한다(Task)/ (Activity) .

분석보고서b) Trade-off

분석 결과를 보고한다Trade-off .

- 125 -

의사결정 결과 보고서c)

의사결정에 대한 정보와 그 결과를 보고한다.

의사결정 전략서d) *

위험관리 프로세스위험관리 프로세스위험관리 프로세스위험관리 프로세스C.12C.12C.12C.12

위험관리 계획서a) *

위험에 대해서 무엇을 언제 어떻게 절차화 하는지에 대한 작업 활동, , (process) (Task)/

을 기술한다(Activity) .

위험해결 활동 계획서b)

의사결정 해결에 대한 전략 정보에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업, ,

활동 을 기술한다(Task)/ (Activity) .

위험 분석 보고서c)

위험 분석한 결과를 보고한다.

위험 상태 보고서d)

위험 상태 조사 결과를 보고한다.

위험관리서e) *

위험 관리를 구현하기 위한 요구사항에 대한 정보를 기록한다.

위험관리요약서f) *

식별된 위험 관련된 해결책 결과 프로젝트의 마무리에서 노출된 위험에 대한 정보를 기, ,

록한다.

시스템위험분석 계획서g) *

시스템의 위험 요소에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

형상관리 프로세스형상관리 프로세스형상관리 프로세스형상관리 프로세스C.13C.13C.13C.13

- 126 -

형상관리계획서a) *

형상관리에 대해 무엇을 언제 어떻게 관리하는지에 대해 작업 활동, , (Task)/ (Activity)

을 기술한다.

형상 통제결과 보고서b)

형상 통제 활동 결과를 보고한다.

형상 정보관리 보고서c)

형상 정보관리 활동 결과를 보고한다.

형상 평가결과 보고서d)

형상 평가결과를 보고한다.

형상항목기술서e) *

형상 품목 기준선에 대한 정보를 기록한다.

형상관리전략서f) *

형광 관리 전략에 대한 정보를 기록한다.

시스템 제품 배포서g) *

배포된 시스템의 형상 정보를 기록하며 알려진 문제를 포함한다.

정보관리 프로세스정보관리 프로세스정보관리 프로세스정보관리 프로세스C.14C.14C.14C.14

프로젝트 정보관리 계획서a) *

프로젝트의 정보관리에 대해 무엇을 언제 어떻게 관리하는지에 대해 작업 활동, , (Task)/

을 기술한다(Activity) .

정보품질 분석 보고서b)

정보에 대한 품질을 정도를 보고한다.

정보품질 진척 보고서c)

정보에 대한 품질 향상 정도를 보고한다.

교훈보고서d) *

- 127 -

프로젝트의 교훈 결과에 대한 정보를 기록한다.

문서e) trade-study *

에 대한 정보를 기록한다trade-study .

상태보고서f) *

프로젝트의 상태 정보를 주간 월간 보고한다, .

문서화프로세스g) *

프로젝트 문서화 관리 방법론을 구현하기 위해 사용된 프로세스를 문서화하다.

훈련 매뉴얼h) *

훈련을 어떻게 수행할지 기술한다.

프로세스 그룹명 프로세스명 산출물 수

기술 프로세스5.5

이해당사자 요구사항 정의5.5.2

프로세스10

요구사항 분석 프로세스5.5.3 6

아키텍쳐 설계 프로세스5.5.4 7

구현 프로세스5.5.5 2

통합 프로세스5.5.6 4

검증 프로세스5.5.7 8

전환 프로세스5.5.8 11

확인 프로세스5.5.9 6

운영 프로세스5.5.10 5

유지보수 프로세스5.5.11 8

폐기 프로세스5.5.12 5

이해당사자 요구사항 정의 프로세스이해당사자 요구사항 정의 프로세스이해당사자 요구사항 정의 프로세스이해당사자 요구사항 정의 프로세스C.15C.15C.15C.15

운영개념 기술서a)

시스템의 운영에 대한 정보를 기록한다.

제품 및 서비스 요구 계획서b)

- 128 -

산출물 또는 서비스를 위한 프로젝트 요청사항에 대해서 무엇을 언제 어떻게 관리 하는, ,

지에 대한 작업 활동 을 기술한다(Task)/ (Activity) .

시스템 개념 계획서c)

시스템의 개념에 대해서 무엇을 언제 어떻게 정의 하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

제품 및 서비스 요구서d) *

제품 또는 서비스 요청에 대한 정보를 기록한다.

안전계획서e) *

시스템 안전 요구사항에 대해서 무엇을 언제 어떻게 만족 시키는지에 대한 작업, ,

활동 을 기술한다(Task)/ (Activity) .

보안계획서f) *

제품과 프로젝트 보안 요구사항에 대해서 무엇을 언제 어떻게 만족시키는지에 대한 작, ,

업 활동 을 기술한다(Task)/ (Activity) .

인적요소요구서g) *

인적 요소를 기본으로 하는 요구사항에 대한 정보를 기록한다.

요구서h) *

인적 요소를 기본으로 하는 요구사항에 대한 정보를 기록한다.

안전요구서i) *

시스템의 안전 요구사항에 대한 정보를 기록한다.

보안요구서j) *

시스템과 프로젝트의 보안 요구사항에 대한 정보를 기록한다.

요구사항 분석 프로세스요구사항 분석 프로세스요구사항 분석 프로세스요구사항 분석 프로세스C.16C.16C.16C.16

요구사항 명세서a)

요구사항에 대한 정보를 기록한다.

- 129 -

인터페이스 요구사항명세서b)

인터페이스 요구사항에 대한 정보를 기록한다.

기능상세 계획서c) *

시스템의 기능 요구사항에 대해 무엇을 언제 어떻게 정의 관리 나열 하는지에 대해 작, , , ,

업 활동 을 기술한다(Task)/ (Activity) .

기능상세서d) *

상세 기능 요구사항에 관한 정보를 기록한다.

규정 및 표준 요구서e) *

제품에 영향을 주는 규정과 표준에 대한 정보를 기록한다.

시스템 요구사항 명세서f) *

시스템 요구사항에 대한 정보를 기록한다.

아키텍쳐 설계 프로세스아키텍쳐 설계 프로세스아키텍쳐 설계 프로세스아키텍쳐 설계 프로세스C.17C.17C.17C.17

아키텍처 설계 명세서a) *

구조 요구사항과 시스템의 설계에 대한 정보를 기록한다.

인터페이스 설계기술서b) *

모든 레벨에서 시스템 인터페이스에 대한 정보를 기록한다.

시스템방법론 도구 및 기술 계획서c) *

시스템의 방법 도구 기술에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업, , , ,

활동 을 기술한다(Task)/ (Activity) .

시스템 상세설계 명세서d) *

디자인 명세가 상세히 된 시스템에 대한 정보를 기록한다.

시스템 수명주기 적용프로세스e) *

프로젝트에 의해 사용된 시스템 수명주기 프로세스에 대한 정보를 기록한다.

시스템 수명주기 활동 및 작업 매핑 문서f) *

- 130 -

시스템 수명주기 활동과 프로젝트 일정에 프로젝트 일정에 연관되는 작업에 관한 정보를

기록한다.

시스템 방법론 도구 및 기술서g) *

시스템 방법 도구 시스템을 설계하고 개발하기 위해 사용된 기술에 대한 정보를 기록한, ,

다.

구현 프로세스구현 프로세스구현 프로세스구현 프로세스C.18C.18C.18C.18

구현계획서a) *

시스템 구현을 위한 전략에 대한 정보를 기록한다.

구현결과보고서b)

시스템 구현에 대한 정보를 보고한다.

통합 프로세스통합 프로세스통합 프로세스통합 프로세스C.19C.19C.19C.19

통합계획서a) *

서브시스템을 시스템에 통합함에 있어 무엇을 언제 어떻게 관리하는지에 대해 작업, ,

활동 을 기술하고 통합 전략에 대한 정보를 기록한다(Task)/ (Activity) .

통합결과 보고서b)

시스템 통합에 대한 결과를 보고한다.

운영 설치 매뉴얼c) /

시스템의 운영 및 설치에 대한 방법을 기록한다.

문제해결보고서d)

문제점의 해결 결과를 보고한다.

검증 프로세스검증 프로세스검증 프로세스검증 프로세스C.20C.20C.20C.20

검증계획서a) *

시스템의 검증에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업 활동, , (Task)/

을 기술한다(Activity) .

- 131 -

검증결과 보고서b)

시스템의 이상 유무 검증결과를 보고한다.

문제해결보고서c)

문제점의 해결 결과를 보고한다.

측정절차 계획서d) *

품질보증과 명세서에 기초하여 프로젝트의 성공을 위한 핵심 측정사항에 대해 무엇을 언,

제 어떻게 수행하는지에 대해 작업 활동 을 기술한다, (Task)/ (Activity) .

시험 및 평가서e) *

시스템 테스트와 평가를 수행하기 위한 프로세스에 대한 정보를 기록한다.

추적문서f) *

배송된 시스템에 대하여 설계와 요구사항 사이의 추적성에 대한 정보를 기록한다.

검증 전략서g) *

검증 전략에 대한 정보를 기록한다.

검증 전략 요약서h) *

검증 작업 활동의 결과 구별된 위험의 상태 검증 의견에 관한 요약된 정보를 기록한다/ , , .

전환 프로세스전환 프로세스전환 프로세스전환 프로세스C.21C.21C.21C.21

전환 계획서a)

시스템의 전환에 대해 무엇을 언제 어떻게 관리하는지에 대해 작업 활동, , (Task)/

을 기술한다(Activity) .

전환결과보고서b)

시스템의 전환 결과를 보고한다.

문제해결보고서c)

문제점의 해결 결과를 보고한다.

- 132 -

설치계획서d) *

시스템 설치에 대해 무엇을 언제 어떻게 관리하는지에 대해 작업 활동, , (Task)/

을 기술한다(Activity) .

책임전환계획서e) *

고객에게 산출물 또는 서비스 운반에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작, ,

업 활동 을 기술한다(Task)/ (Activity) .

제품 또는 서비스 전달 계획서f) *

산출물 또는 서비스의 배송에 대해서 무엇을 언제 어떻게 관리하는지에 대한 작업, ,

활동 을 기술한다(Task)/ (Activity) .

책임 전환서g) *

시스템 운반을 위한 책임에 대한 정보를 기록한다.

시스템 인수서h) *

배송된 시스템과 서브시스템의 인수를 위한 프로세스에 대한 정보를 기록한다.

시스템 할당서i) *

하드웨어 소프트웨어 인적요소에 대한 시스템 배치에 대한 정보를 기록한다, , .

시스템 설치서j) *

시스템 설치에 대한 정보를 기록한다.

전환 전략서k) *

추이 전략에 대한 정보를 기록한다.

확인 프로세스확인 프로세스확인 프로세스확인 프로세스C.22C.22C.22C.22

확인계획서a) *

확인계획에 대해 무엇을 언제 어떻게 관리하는지에 대해 작업 활동, , (Task)/ (Activity)

을 기술한다.

확인결과보고서b)

시스템의 확인 결과를 보고한다.

- 133 -

문제해결보고서c)

문제점의 해결 결과를 보고한다.

확인서d) *

시스템을 확인하기 위해 사용했던 확인 방법에 대한 정보를 기록한다.

확인 전략서e) *

확인 전략에 대한 정보를 기록한다.

최종시험보고서f) *

시스템 요구사항에 대한 정보를 기록한다.

운영 프로세스운영 프로세스운영 프로세스운영 프로세스C.23C.23C.23C.23

운영 계획서a) *

시스템의 운영에 대해 무엇을 언제 어떻게 관리하는지에 대해 작업 활동, , (Task)/

을 기술한다(Activity) .

운영 결과보고서b)

시스템의 운영에 대한 결과를 보고한다.

문제해결보고서c)

문제점의 해결 결과를 보고한다.

사용자메뉴얼d)

시스템을 어떻게 사용할지 그리고 어떻게 유지하는지에 관한 정보를 제공한다.

운영 전략서e) *

시스템의 운영 전략에 대한 정보를 기록한다.

유지보수 프로세스유지보수 프로세스유지보수 프로세스유지보수 프로세스C.24C.24C.24C.24

유지보수 계획서a)

시스템의 유지보수에 대해 무엇을 언제 어떻게 관리하는지에 대해 작업 활동, , (Task)/

- 134 -

을 기술한다(Activity) .

유지보수 결과보고서b)

시스템의 유지보수 결과를 보고한다.

문제해결 보고서c)

문제점의 해결 결과를 보고한다.

유지보수 요구서d) *

유지보수 요구사항에 대한 정보를 기록한다.

유지보수 전략서e) *

유지보수 전략에 대한 정보를 기록한다.

시스템 위험식별 및 분석서f) *

시스템 위험요소 식별과 분석 결과에 대한 정보를 기록한다.

시스템 위험부담 식별 요약서g) *

프로젝트의 마지막 시점에서 시스템 위험요소의 요약에 대한 정보를 기록한다.

예방정비서h) *

예방 유지보수 요구사항에 대한 정보를 기록한다.

폐기 프로세스폐기 프로세스폐기 프로세스폐기 프로세스C.25C.25C.25C.25

폐기계획서a) *

시스템 혹은 서브시스템의 폐기 수행에 관해 무엇을 언제 어떻게 폐기관리를 하는지에, ,

대해 작업 활동 을 기술한다(Task)/ (Activity) .

폐기결과보고서b)

시스템의 폐기 결과를 보고한다.

문제해결보고서c)

문제점의 해결 결과를 보고한다.

- 135 -

폐기 전략서d) *

시스템 또는 서브시스템의 폐기를 위한 전략 정보를 기록한다.

폐기보고서e) *

시스템 또는 서브 시스템의 폐기의 결과를 보고한다.

- 136 -

부록 문서작성 절차D.

프로젝트 요구문서 식별프로젝트 요구문서 식별프로젝트 요구문서 식별프로젝트 요구문서 식별D.1D.1D.1D.1

문서 관리 정책문서 관리 정책문서 관리 정책문서 관리 정책D.1.1D.1.1D.1.1D.1.1

문서의 개발 유지 분배 관리를 위한 프로젝트 정책을 기술한다, , , .

계약과 프로젝트 분석계약과 프로젝트 분석계약과 프로젝트 분석계약과 프로젝트 분석D.1.2D.1.2D.1.2D.1.2

내용 포맷 그리고 배포를 포함하는 문서 요구사항의 나열을 위한 계약과 프로젝트 계획,

을 분석한다.

계약 분석 검증계약 분석 검증계약 분석 검증계약 분석 검증D.1.3D.1.3D.1.3D.1.3

고객에게 계약 분석을 보내고 고객 승인을 받는다.

문서 관리 방법론 검증문서 관리 방법론 검증문서 관리 방법론 검증문서 관리 방법론 검증D.1.4D.1.4D.1.4D.1.4

기 존재하는 프로젝트 문서 프로세스와 절차를 검증한다 문서에 대해서 모든 품질 요구.

사항이 충족되는 것을 검증하기 위한 정보가 포함된다 표준과 프로세스는 식별되는데 이것.

은 문서 관리 방법론을 보증한다 그리고 계획서 안에 있는 항목들은 식별된 품질 요구사항.

을 충족시킨다 다음은 문서 품질 요구사항을 요약한다. .

철자법과 문법 체크-

포맷 스타일과 버전- ,

내용 일관성과 및 다른 문서간의 일관성-

업데이트 되는 수정 히스토리-

수행된 검토와 결과-

문서 변경 게시판-

주기 완성의 승인-

오직 승인된 변화의 구현-

알맞은 기준선-

알맞은 패키지화와 분배-

문서 관리 방법론 훈련 준비문서 관리 방법론 훈련 준비문서 관리 방법론 훈련 준비문서 관리 방법론 훈련 준비D.1.5D.1.5D.1.5D.1.5

필요에 따라 자료를 준비한다 그리고 문서 관리 방법론에 대한 훈련을 제공하기 위한, .

자원을 식별한다.

- 137 -

문서 작성자 식별문서 작성자 식별문서 작성자 식별문서 작성자 식별D.2D.2D.2D.2

문서 할당 매트릭스문서 할당 매트릭스문서 할당 매트릭스문서 할당 매트릭스D.2.1D.2.1D.2.1D.2.1

각 항목에 대해서 문서 저자와 지원 인력을 할당하기 위해 모든 프로젝트 조직의 회의를

주선한다 책임을 포함하며 프로젝트 관리자로부터 지원을 보장받는다. .

문서 관리 방법론 훈련문서 관리 방법론 훈련문서 관리 방법론 훈련문서 관리 방법론 훈련D.2.2D.2.2D.2.2D.2.2

프로젝트 수명주기 전반에 걸쳐 문서 방법론 훈련 세션을 주선한다.

사용자 식별사용자 식별사용자 식별사용자 식별D.3D.3D.3D.3

사용자 식별사용자 식별사용자 식별사용자 식별D.3.1D.3.1D.3.1D.3.1

문서 고객을 식별하고 각 항목의 화제 에 대한 지식수준이나 경험정도를 식별한(Topic)

다 또한 두 번째 사용자나 독자를 식별한다. .

사용자 기대 식별사용자 기대 식별사용자 기대 식별사용자 기대 식별D.3.2D.3.2D.3.2D.3.2

사용자의 기대를 식별한다 여기에는 특정 사용자의 특징에 관한 연구를 포함한다 만약. .

가능 하다면 핵심 고객인 문서 저자 문서 교정자 등으로 배치되어야 한다 사용자 분석에, , .

서 건의한 문서의 모습을 기술해야 한다 특히 조직 동기 특별한 필요사항 그리고 특성 영. , ,

역에 집중해야 한다 사용자의 지식수준을 결정하고 알맞은 용어 사용에 동의를 해야 한다. .

사용자 분석 체크리스트사용자 분석 체크리스트사용자 분석 체크리스트사용자 분석 체크리스트D.3.3D.3.3D.3.3D.3.3

사용자 분석 절차에 따라 문서에 대해 체크리스트를 개발한다 여기에는 사용자 작업도.

포함한다 작업이 수행되는데 있어 영향을 미치는 다른 요소가 있는지 확인한다 충족 시켜. .

야 할 이해 당사자의 요구사항이 있는지 그리고 문서가 유용한지 확인한다.

문서의 목표 요구사항 검증문서의 목표 요구사항 검증문서의 목표 요구사항 검증문서의 목표 요구사항 검증D.3.4 ,D.3.4 ,D.3.4 ,D.3.4 ,

고객에게 제공된 프로젝트 문서의 나열을 보장하고 문서를 위한 목적 요구사항 사용자, ,

기대사항이 제출된다 문서의 각 아이템에 대해 알맞은 정도의 상세화가 되어 있는지 결정.

한다 충돌되는 요구사항이 있는지 확인한다 할당된 자원 안에서 문서 작성을 보장하도록. .

일정과 예산을 검증한다.

문서 인구 통계문서 인구 통계문서 인구 통계문서 인구 통계D.3.5D.3.5D.3.5D.3.5

문서 저자를 정의하고 문서의 각 항목을 위한 사용자의 인구 통계 정보를 정의한다.

- 138 -

데이터의 원천 식별데이터의 원천 식별데이터의 원천 식별데이터의 원천 식별D.4D.4D.4D.4

문서 데이터의 원천 식별문서 데이터의 원천 식별문서 데이터의 원천 식별문서 데이터의 원천 식별4.14.14.14.1

문서 요구사항과 고객 기대사항에 기초하여 문서 데이터 수집자 이러한 데이터 원천의, , ,

각 항목을 위한 데이터를 식별한다 그리고 어떻게 그 데이터가 재표현되고 사용되는지 식.

별한다 만약 필요하다면 고객과 문서 사용자간에 회의를 배치한다. , .

문서 데이터의 원천 확인문서 데이터의 원천 확인문서 데이터의 원천 확인문서 데이터의 원천 확인D.4.2D.4.2D.4.2D.4.2

고객에게 원천 리스트에 대해서 서명을 하게 함으로서 고객과 함께 문서 데이터 원천을

검증한다.

데이터 관리데이터 관리데이터 관리데이터 관리D.4.3D.4.3D.4.3D.4.3

개발된 또는 프로젝트에서 획득된 데이터는 프로젝트 매니저나 조직 정책에 의해 결정된

형상관리 또는 문서작성 통제 아래 놓이게 된다.

문서 설계와 개발 프로세스문서 설계와 개발 프로세스문서 설계와 개발 프로세스문서 설계와 개발 프로세스D.5D.5D.5D.5

문서 작업 요구문서 작업 요구문서 작업 요구문서 작업 요구D.5.1D.5.1D.5.1D.5.1

저자가 문서의 항목에 대해 개발 또는 변경을 시작하기 이전에 문서 저자는 작업을 시작

에 대한 권한을 받기 위하여 작업 요청서를 완성시킨다 작업 요청서는 저자의 매니저와 문.

서 관리자에 의해 검토되며 이것은 저자에게 요구되는 것이 무엇인지 다른 인력들이 그들의

역할과 책임을 인식하는 것을 보장한다 작업 요청서는 문서 상태에 대한 정보를 계속 추적.

하는데 사용되기도 한다 저자부터 문서 관리자에게까지 주간 상태 보고서는 문제점과 위험.

사항을 포함하는 문서 상태를 인식하는데 도움을 준다.

문서 식별문서 식별문서 식별문서 식별D.5.2D.5.2D.5.2D.5.2

유일한 문서 식별 요구사항을 식별한다 여기에는 버전 식별에 관한 정보가 포함되며 문.

서 식별의 한 부분으로서 버전이 어떻게 문서의 한 부분으로 만들어 지는지에 대한 정보를

포함한다 문서작성의 시스템으로서 문서 집합을 설계 한다. .

문서 발주문서 발주문서 발주문서 발주D.5.3D.5.3D.5.3D.5.3

알맞은 문서의 개발을 위해 회사 이름을 계약한다 일단 문서의 한 항목이 회사 이름에. ,

의해 승인되면 문서의 항목은 최종 검토 기준선 설정 배포를 위해 문서 관리자에게 자동적,

- 139 -

으로 이전된다.

문서 설계문서 설계문서 설계문서 설계D.5.4D.5.4D.5.4D.5.4

요구사항과 기대사항을 기초로 하여 문서의 개요와 요약정보를 개발한다 저자의 매니저.

와 문서 매니저로부터 승인을 받는다.

문서 매핑문서 매핑문서 매핑문서 매핑D.5.5D.5.5D.5.5D.5.5

문서 항목에 대해 문서의 데이터 요구사항 기대사항의 매핑을 통해 문서 추적성을 개발, , ,

한다.

문서 개발문서 개발문서 개발문서 개발D.5.6D.5.6D.5.6D.5.6

문서 설계와 데이터에 기반하여 문서를 개발한다 필요에 따라 문서의 상태를 갱신한다, . , .

문서 테스트와 검증문서 테스트와 검증문서 테스트와 검증문서 테스트와 검증D.6D.6D.6D.6

문서 일관성 절차문서 일관성 절차문서 일관성 절차문서 일관성 절차D.6.1D.6.1D.6.1D.6.1

문서의 각 항목과 다른 산출물 사이 내에서 일관성을 보장하기 위해 절차를 개발한다.

문서 체크리스트문서 체크리스트문서 체크리스트문서 체크리스트D.6.2D.6.2D.6.2D.6.2

요구사항과 기대사항을 기초로 하여 조정 검토자 권한 승인을 위한 체크리스트를 개발, ,

한다.

문서 일관성 검증문서 일관성 검증문서 일관성 검증문서 일관성 검증D.6.3D.6.3D.6.3D.6.3

문서작성의 일관성 절차를 구현하고 문서 체크리스트를 완성시킨다 제품 실행 기능성. , ,

요구사항 설계 등과 관련된 문서작성 회의를 포함한다 그리고 유용성 실험 수행도 포함한, .

다.

문서 히스토리문서 히스토리문서 히스토리문서 히스토리D.6.4D.6.4D.6.4D.6.4

모든 문서는 수정 히스토리를 포함해야 한다 이는 언제 수정이 되었는지 승인이 되었을. ,

때 누가 수정을 승인했고 수정된 내용의 요약을 기술한다 만약 변화가 회의나 사용자의 비.

평이었다면 승인된 내용의 요약은 회의 상세사항 제목 날짜 등등 이나 사용자 비평에 해, ( , )

당하는 우리의 응답 식별자를 참조할 수 있다.

문서 승인문서 승인문서 승인문서 승인D.7D.7D.7D.7

문서 재검토문서 재검토문서 재검토문서 재검토D.7.1D.7.1D.7.1D.7.1

- 140 -

프로젝트의 검토 프로세스에 기초하여 검토 및 갱신을 위한 문서를 제출한다 비평을 재, .

검토 하고 문서의 다음 버전을 위해 그 비평에 대해 구현 거부 하거나 수정을 한다 문서, , .

재검토 또는 문서 승인 프로세스를 반복한다.

문서작성 프로젝트 승인문서작성 프로젝트 승인문서작성 프로젝트 승인문서작성 프로젝트 승인D.7.2D.7.2D.7.2D.7.2

필요한 정보를 수집하고 프로젝트 승인을 위해 분배한다 문서작성 프로젝트 승인을 위.

해 문서 매니저에게 문서를 제출한다, .

문서의 고객 승인문서의 고객 승인문서의 고객 승인문서의 고객 승인D.7.3D.7.3D.7.3D.7.3

문서의 품질 체크를 수행한다 필요에 따라 고객을 조정한다 고객의 비평을 받고 문서. .

저자에게 그것들을 분배한다.

고객 비평 해결책고객 비평 해결책고객 비평 해결책고객 비평 해결책D.7.4D.7.4D.7.4D.7.4

모든 고객들의 비평을 검토하고 문서의 다음 버전을 위해 그 비평을 구현 거부 또는- ,

수정을 한다.

만약 고객이 문서를 승인했다면 알맞은 프로젝트 관리자에게 공지를 하고 문서의 상태-

를 갱신 한다.

문서 생산문서 생산문서 생산문서 생산D.8D.8D.8D.8

문서 생산문서 생산문서 생산문서 생산D.8.1D.8.1D.8.1D.8.1

전달매체 배달 요구사항에 기초하여 생산을 위한 문서를 준비한다 문서 전달매체는 패키.

지화 한다 보안 안전 분배 요구사항에 기초하여 표시와 분배를 한다 문서 저장 프로세스. , , .

를 위해 복사본을 만든다 문서의 상태를 갱신 한다. .

문서 저장문서 저장문서 저장문서 저장D.9D.9D.9D.9

문서 저장문서 저장문서 저장문서 저장D.9.1D.9.1D.9.1D.9.1

사용자에게 보냈던 모든 문서 전달매체의 주 복사본을 저장 한다 가능한 한 모든 전달매.

체는 읽기 기능만을 가능하게 한다.

문서 검색문서 검색문서 검색문서 검색D.9.2D.9.2D.9.2D.9.2

문서는 읽기만 가능 또는 수정기능 상태로만 표시된다.

데이터 관리데이터 관리데이터 관리데이터 관리D.9.3D.9.3D.9.3D.9.3

데이터 관리 프로세스를 식별한다.

- 141 -

문서 종료문서 종료문서 종료문서 종료D.9.4D.9.4D.9.4D.9.4

문서 종료를 결정한다 새로운 기준선에 의해 교체되는 문서의 기준선 항목을 포함한다. .

문서 유지문서 유지문서 유지문서 유지D.10D.10D.10D.10

문서 변경 통제문서 변경 통제문서 변경 통제문서 변경 통제D.10.1D.10.1D.10.1D.10.1

고객에게 첫 번째 문서를 배포한 후에 문서 변경 통제 절차를 구현한다 문서는 문서, .

변경 통제 프로세스의 사용을 통해 유지된다 문서 유지를 위해서 어떤 추천되는 변경은 작.

업 요청으로 시작되며 작업 요청은 변경 통제 게시판의 입력이 된다 변경 통제 게시판의.

개발과 함께 문서 변경은 출판된 항목 이전에 호환성을 보장하기 위해 대응하는 산출물에,

비교된다 문서 변경 통제의 주요 목적은 오직 승인된 변경만이 문서에 반영하는 것이다. .

- 142 -

부록 시스템 수명주기 표준 프로세스와 발주관리 표준 프로세스E.

연계방안

연계방안연계방안연계방안연계방안E.1E.1E.1E.1

그림 참조< >

세부 매핑 구조세부 매핑 구조세부 매핑 구조세부 매핑 구조E.2E.2E.2E.2

시스템 수명주기 표준 프로세스와 발주관리 표준 프로세스와의 명확한 비교를 위해 개4

의 프로세스 그룹을 구성

계약 그룹a) (Agreement Group)

프로젝트 관리 및 지원 그룹b) (Project Management and Support Group)

개발 그룹c) (Development Group)

후행 그룹d) (Downstream Group)

계약 그룹계약 그룹계약 그룹계약 그룹E.3E.3E.3E.3

구성구성구성구성E.3.1E.3.1E.3.1E.3.1

계약 그룹은 획득 및 공급과 관련된 프로세스를 포함

비교비교비교비교E.3.2E.3.2E.3.2E.3.2

- 143 -

시스템 수명주기 표준 프로세스시스템 수명주기 표준 프로세스시스템 수명주기 표준 프로세스시스템 수명주기 표준 프로세스 발주관리 표준 프로세스발주관리 표준 프로세스발주관리 표준 프로세스발주관리 표준 프로세스

프로세스 획득 프로세스 획득

활동 획득계획수립 활동 획득준비

활동 요구사항 준비 활동 제안요청서 준비

활동 공급자와 정보교환 활동 계약 및 변경

활동 공급자 선택 활동 공급자 관리

활동 공급자와 계약 협상 활동 인수 및 종료

활동 계약이행 평가 활동

활동 최종산출물 확인 활동

활동 대금 지불

프로세스 공급 프로세스 공급

활동 획득자 식별 활동 제안요청서 검토

활동 요구사항 평가 활동 제안서 준비

활동 요청사항 대응책 준비 활동 계약 및 변경

활동 계약 협의 활동 사업수행계획수립

활동 계약 체결 활동 실행 및 통제

활동 계약 이행 결과 평가 활동 검토 및 평가

활동 최종산출물 인도 활동 납품 및 종료

활동 대금 수령

활동 최종산출물 책임 이관

프로젝트 관리 및 지원 그룹프로젝트 관리 및 지원 그룹프로젝트 관리 및 지원 그룹프로젝트 관리 및 지원 그룹E.4E.4E.4E.4

구성구성구성구성E.4.1E.4.1E.4.1E.4.1

프로젝트 관리 및 지원 그룹은 전사 프로젝트 정보전략계획 정보화기획 관리 기반구, , , , ,

조 인적자원 프로세스 개선 프로세스를 포함,

비교비교비교비교E.4.2E.4.2E.4.2E.4.2

시스템 수명주기 표준 프로세스시스템 수명주기 표준 프로세스시스템 수명주기 표준 프로세스시스템 수명주기 표준 프로세스 발주관리 표준 프로세스발주관리 표준 프로세스발주관리 표준 프로세스발주관리 표준 프로세스

프로세스 프로젝트 계획 프로세스 프로세스 관리

프로세스 프로젝트 평가 프로세스 활동 관리준비

프로세스 프로젝트 통제 프로세스 활동 관리계획 수립

프로세스 위험관리 활동 관리 실행 및 통제

활동 검토 및 평가

활동 종결

활동

활동

프로세스 의사결정 프로세스 문제해결

프로세스 형상관리 프로세스 형상관리

프로세스 정보관리 프로세스 문서화

프로세스 시스템 수명주기 프로세스 관리 프로세스 프로세스 개선

프로세스 자원관리프로세스 기반구조

프로세스 인적자원

- 144 -

개발 그룹개발 그룹개발 그룹개발 그룹E.5E.5E.5E.5

구성구성구성구성E.5.1E.5.1E.5.1E.5.1

개발 그룹은 기술 프로세스와 개발 운영 유지보수 및 지원프로세스를 포함, ,

비교비교비교비교E.5.2E.5.2E.5.2E.5.2

시스템 수명주기 표준 프로세스시스템 수명주기 표준 프로세스시스템 수명주기 표준 프로세스시스템 수명주기 표준 프로세스 발주관리 표준 프로세스발주관리 표준 프로세스발주관리 표준 프로세스발주관리 표준 프로세스

프로세스

그룹기술 프로세스 개발

프로세스 이해당사자 요구사항 정의 프로세스

프로세스 요구사항 분석 프로세스 활동 시스템요구사항분석

프로세스 아키텍쳐 설계 프로세스 활동 시스템구조설계

프로세스 구현 프로세스

활동 소프트웨어요구사항분석

활동 소프트웨어설계

활동 소프트웨어상세설계

활동 소프트웨어코딩 및 단위시험

활동 소프트웨어 통합

활동 소프트웨어자격시험

프로세스 통합 프로세스 활동 시스템 통합

프로세스 검증 프로세스 활동 시스템자격시험

프로세스 전환 프로세스 활동 소프트웨어설치

프로세스 확인 프로세스 활동 소프트웨어인수지원

- 145 -

시스템 수명주기 프로세스와 발주관리 프로세스 연계시스템 수명주기 프로세스와 발주관리 프로세스 연계시스템 수명주기 프로세스와 발주관리 프로세스 연계시스템 수명주기 프로세스와 발주관리 프로세스 연계○○○○

핵심핵심핵심핵심 수명주기수명주기수명주기수명주기 프로세스프로세스프로세스프로세스핵심핵심핵심핵심 수명주기수명주기수명주기수명주기 프로세스프로세스프로세스프로세스

개발개발개발개발 프로세스프로세스프로세스프로세스

기술기술기술기술 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹기술기술기술기술 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹

개발개발개발개발 프로세스프로세스프로세스프로세스

이해당사자요구사항정의

이해당사자요구사항정의

시스템시스템시스템시스템 요구사항요구사항요구사항요구사항 분석분석분석분석시스템시스템시스템시스템 요구사항요구사항요구사항요구사항 분석분석분석분석

요구사항분석

요구사항분석

아키텍처설계

아키텍처설계

시스템시스템시스템시스템구조구조구조구조 설계설계설계설계

시스템시스템시스템시스템구조구조구조구조 설계설계설계설계

S/WS/WS/WS/W요구사항요구사항요구사항요구사항분석분석분석분석

S/WS/WS/WS/W구조구조구조구조설계설계설계설계

S/WS/WS/WS/W상세상세상세상세설계설계설계설계

S/WS/WS/WS/W코딩코딩코딩코딩 및및및및단위시험단위시험단위시험단위시험

S/WS/WS/WS/W통합통합통합통합

S/WS/WS/WS/W자격자격자격자격시험시험시험시험

구현구현 통합통합

시스템시스템시스템시스템통합통합통합통합

시스템시스템시스템시스템통합통합통합통합

검증검증

시스템시스템시스템시스템자격자격자격자격시험시험시험시험

시스템시스템시스템시스템자격자격자격자격시험시험시험시험

전환전환

S/WS/WS/WS/W설치설치설치설치

S/WS/WS/WS/W설치설치설치설치

S/WS/WS/WS/W인수인수인수인수지원지원지원지원

S/WS/WS/WS/W인수인수인수인수지원지원지원지원

확인확인 운영운영

운영운영운영운영 프로세스프로세스프로세스프로세스

(운영준비/시험,시스템운영,사용자지원)

계약계약계약계약 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹계약계약계약계약 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹

획득프로세스획득프로세스획득프로세스획득프로세스

프로젝트프로젝트프로젝트프로젝트 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹프로젝트프로젝트프로젝트프로젝트 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹

전사전사전사전사 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹전사전사전사전사 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹

조직조직조직조직 수명주기수명주기수명주기수명주기 프로세스프로세스프로세스프로세스조직조직조직조직 수명주기수명주기수명주기수명주기 프로세스프로세스프로세스프로세스

지원지원지원지원 수명주기수명주기수명주기수명주기 프로세스프로세스프로세스프로세스지원지원지원지원 수명주기수명주기수명주기수명주기 프로세스프로세스프로세스프로세스

개념단계개념단계개념단계개념단계 개발단계개발단계개발단계개발단계 생산단계생산단계생산단계생산단계 운용운용운용운용

정보전략계획정보전략계획정보전략계획정보전략계획정보전략계획정보전략계획정보전략계획정보전략계획

공급공급공급공급 프로세스프로세스프로세스프로세스

시스템

시스템

시스템

시스템

수명주기

수명주기

수명주기

수명주기

프로세스

프로세스

프로세스

프로세스

소프트웨어

소프트웨어

소프트웨어

소프트웨어

발주관리

발주관리

발주관리

발주관리

프로세스

프로세스

프로세스

프로세스

- 146 -

시스템 수명주기 프로세스와 발주관리 프로세스 연계 방안시스템 수명주기 프로세스와 발주관리 프로세스 연계 방안시스템 수명주기 프로세스와 발주관리 프로세스 연계 방안시스템 수명주기 프로세스와 발주관리 프로세스 연계 방안○○○○

기술기술기술기술 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹기술기술기술기술 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹

개발개발개발개발 프로세스프로세스프로세스프로세스

이해당사자요구사항정의

이해당사자요구사항정의

요구사항분석

요구사항분석

아키텍처설계

아키텍처설계

S/WS/WS/WS/W요구사항요구사항요구사항요구사항분석분석분석분석

S/WS/WS/WS/W구조구조구조구조설계설계설계설계

S/WS/WS/WS/W상세상세상세상세설계설계설계설계

S/WS/WS/WS/W코딩코딩코딩코딩 및및및및단위시험단위시험단위시험단위시험

S/WS/WS/WS/W통합통합통합통합

S/WS/WS/WS/W자격자격자격자격시험시험시험시험

구현구현 통합통합 검증검증 전환전환 확인확인 운영운영

계약계약계약계약 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹계약계약계약계약 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹

프로젝트프로젝트프로젝트프로젝트 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹프로젝트프로젝트프로젝트프로젝트 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹

전사전사전사전사 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹전사전사전사전사 프로세스프로세스프로세스프로세스 그룹그룹그룹그룹

개념단계개념단계개념단계개념단계 개발단계개발단계개발단계개발단계 생산단계생산단계생산단계생산단계 운용운용운용운용

시스템

시스템

시스템

시스템

수명주기

수명주기

수명주기

수명주기

프로세스

프로세스

프로세스

프로세스

소프트웨어

소프트웨어

소프트웨어

소프트웨어

발주관리

발주관리

발주관리

발주관리

프로세스

프로세스

프로세스

프로세스

- 147 -

후행 그룹후행 그룹후행 그룹후행 그룹E.6E.6E.6E.6

구성구성구성구성E.6.1E.6.1E.6.1E.6.1

계약 그룹은 운영 유지보수 및 페기와 관련된 프로세스를 포함,

비교비교비교비교E.6.2E.6.2E.6.2E.6.2

시스템 수명주기 표준 프로세스시스템 수명주기 표준 프로세스시스템 수명주기 표준 프로세스시스템 수명주기 표준 프로세스 발주관리 표준 프로세스발주관리 표준 프로세스발주관리 표준 프로세스발주관리 표준 프로세스

프로세스 운영 프로세스 운영

활동 운영준비

활동 시스템운영

활동 운영시험

프로세스 유지보수 프로세스 유지보수

활동 유지보수준비

활동 유지보수 분석

활동 시스템유지보수

활동 유지보수검토 승인/

활동 소프트웨어이전

프로세스 폐기 활동 소프트웨어폐기

- 148 -

부록 B

ISO/IEC 12207 & ISO/IEC 15288

개정 제안 분석(revision)

- 149 -

- 150 -

부록 B ISO/IEC 12207 & ISO/IEC 15288

개정 제안 분석(revision)

서론1

시스템 공학 분야 중 시스템 수명주기 프로세스는 소프트웨어 수명주기프로세스와 밀접한

관계를 갖는다 그러나 시스템 수명. ISO/IEC 15288 - System Life Cycle Process(

주기 프로세스 소프트웨어 수명주), ISO/IEC 12207 - Software Life Cycle Process(

기 프로세스 와 같은 기존의 표준들에서 사용하는 용어와 기술하는 상세화 정도 가) (Level)

서로 상이하여 이를 함께 이용하는데 많은 문제가 발생하였다.

에서 제안한ISO/IEC JTC1/SC7 ‘New Work Item Proposal-Revision of

ISO/IEC 15288-Systems and Software Engineering-System Life Cycle

와Processes’ ‘New Work Item Proposal-Revision of ISO/IEC 12207

연구 보Systems and Software Engineering-Software Life Cycle Processes’

고서는 각각 수명주기 프로세스인 와ISO/IEC 15288 - System Life Cycle Process

를 바탕으로 하는 공공부문 사업ISO/IEC 12207 - Software Life Cycle Process SW

발주 관리 표준 프로세스 지침과의 연계 및 통합을 위한 방안을 제시함으로서 호환성과,ㆍ

일관성을 보장하고 사용자들이 보다 쉽고 확장시킬 수 있도록 도와줄 것이다 연구 보고서.

에서는 시스템 수명주기 프로세스 및 소프트웨어 프로세스 수명주기를 각각 간단히

및 로 약칭하고 소프트웨어 수명주기 프로세스의 수정보완인15288:2002 12207:1995

버전을 라 약칭하였다Amendment 12207 AMD .

과 의 연계 및 통합 방안2 15288 12207

및 를 연계 및 통합함으로써 수명주기 전반에 걸친 호환성과15288:2002 12207:1995

일관성을 유지할 수 있으며 사용자들은 이를 이용하여 필요에 따라 쉽게 확장 시킬 수 있

다 연구보고서에서는 표준 및 표준을 대체로 호환하도록 하였. 12207:1995 15288:2002

으며 수명주기에서 지원하지 않던 프로세스 평가 를 추가로 지SW (Process Assessment)

원한다 또한 최대한 일관성 있는 용어와 개념을 사용하도록 하였다. , . ISO/IEC

및 를 연계 및 통합시키는데 있어서 가능한 단순한 모델을 이15288:2002 12207:1995

용하였다 이런 단순한 모델을 사용함으로써 다음과 같은 장점을 가진다 첫째 한 번에 완. . ,

- 151 -

전한 연계 및 통합 하려는 어려움을 피할 수 있다 둘째 프로세스의 통합과 통합된 아키텍. ,

처의 문서화를 연기할 수 있다 셋째 와 의 현재까지 경험을 이. , 12207:1995 15288:2002

용할 수 있다 넷째 사용자 커뮤니티에서 받아들일 수 있도록 서서히 발전시킬 수 있는 기. ,

회를 제공한다 현재 존재하는 표준에 최소한의 변경을 위해 아래 사항을 적용하였다. .

공통용어 사용➀

이용 가능한 공통 프로세스 이름 사용➁

가이드라인에 따름SWG5➂

통합12207 AMD➃

평가 목적을 위한 프로세스 레퍼런스 모델 정보 추가➄

표준 기술의 상세화 비교 분석표준 기술의 상세화 비교 분석표준 기술의 상세화 비교 분석표준 기술의 상세화 비교 분석2.12.12.12.1

와 그리고 의 아키텍처 비교는 아래 그림과12207:1995 12207 AMD 15288:2002

같다 는 프로세스 활동 작업 리스트 순서로 상세. 12207:1995 , (Activity), (Task), (List)

화 된다 는 프로세스 컴포넌트 프로세스(Detail) . 12207 AMD , (Component Process)

순서로 상세화 된다 는 프로세스 활동 노트 순서로 상세화 된다. 15288:2002 , , (Note) .

Process Process Process

Activities

ComponentProcessActivities

Tasks

(Some) Lists Notes

Different name,but the samelevel of detail.

Same name,but not the same

level of detail.

preamble PurposeOutcomes

PurposeOutcomes

PurposeOutcomes

12207:1995 12207:Amd 15288Increasing Level of Detail

의 활동은 의 컴포넌트 프로세스와 이름은 다르지만 같은 상12207:1995 12207:AMD

세화 수준 으로 기술한다 또한 의 활동은 의 활동과 이(Level) . 12207:1995 15288:2002

름은 갖지만 동일한 상세화 수준으로 기술하지 않는다.

연구에서 제안하는 방법은 각각의 이름과 기술 수준을 반영한 아래 그림과 같이 프로세

스 컴포넌트 프로세스 활동 작업 노트 순으로 상세화 수준을 갖는 모델이다, , , .

- 152 -

Process

Activities

ComponentProcess

Tasks

Notes

PurposeOutcomes

PurposeOutcomes

Proposed

Increasing Level of Detail

이렇게 제안하는 이유는 의 컴포넌트 프로세스는 의 활동과, 12207 AMD 12207:1995

매우 유사하기 때문이다 이러한 개념은 아래 그림처럼 나타낼 수 있으며 기술의 상세화를.

위해 붙여진 이름은 중요한 고려 요소가 아님을 알 수 있다 연구 보고서에서는 활동과 목.

적 그리고 결과물 을 더해 간단히 컴포넌트 프로세스라고 명명 하였(Purpose) (Outcome)

다.

ActivityPurpose

OutcomesActivity

Purpose

Outcomes

Component Process

또한 연구에서 제안한 과 을 각각 과 로 구분하였다12207 15288 12207R 15288R .

- 153 -

2.2 12207R2.2 12207R2.2 12207R2.2 12207R

에서 목적 과 결과물 을 갖는 각각의 프로세는 컴포넌트 프12207R (Purpose) (Outcome)

로세스 혹은 활동으로 분해 되며 각각의 컴포넌트 프로세스는 고유의 목적과 결과물을 갖는

다 그 아래에는 작업 노트 순서로 상세화 수준 정도가 증가한다 또한 부록. , . PRM

은 목적과 결과물 정보를 수집한다 연구에서 제안한 모델은 아래와 같(Annex) . 12207R

으며 가독성 을 위해 컴포넌트 프로세스의 결과물은 생략할 수 있다(Readability) .

2.3 15288R2.3 15288R2.3 15288R2.3 15288R

에서 목적 과 결과물 을 갖는 각각의 프로세는 활동들로 구15288R (Purpose) (Outcome)

성되며 그 아래에는 작업 노트 순으로 상세화 수준이 증가한다 또한 부록, . PRM (Annex)

은 목적과 결과물 정보를 수집한다.

Process

Activities

ComponentProcess

Tasks

Notes

P+O

P + O

12207R

Process

Activities

Tasks

Notes

P + O

15288R

PRM Annex PRM Annex

- 154 -

표준과 및 과의 관계표준과 및 과의 관계표준과 및 과의 관계표준과 및 과의 관계2.4 15288R 12207R2.4 15288R 12207R2.4 15288R 12207R2.4 15288R 12207R

현재 표준인 과 제안한12207 AMD, 12207:1995, 15288:2003 12207R, 15288R

과의 관계는 아래 그림과 같다 에서 프로세스는 의 프로세스와. 12207 AMD 12207:1995

같고 이는 에 그대로 반영되고 각 프로세스의 목적과 결과물 또한 에 반, 12207R 12207R

영된다 의 컴포넌트 프로세스는 의 활동과 같고 이는. 12207 AMD 12207:1995 12207R

의 컴포넌트 일부 프로세스와 일부 활동에 반영된다 의 컴포넌트 프로세스의. 12207 AMD

일부 목적은 의 컴포넌트 프로세스의 목적이 되며 나머지 다른 목적과 결과물은12207R

의 부록에 반영된다 의 작업은 의 작업에 반영되며12207R PRM . 12207:1995 12207R

의 리스트는 의 노트에 반영된다12207:1995 12207R .

의 프로세스와 각 프로세스의 목적과 결과는 의 프로세스 및 목적15288:2003 15288R

과 결과에 반영되고 부록의 목적과 결과물에도 반영된다 에는 활동이라는PRM . 15288R

상세화 정도 레벨이 프로세스 아래에 추가된다 이는 과 상세화를 정도를 맞추기 위. 12207

해 추가시킨 것이다 의 활동과 노트는 각각 의 작업과 노트에 그대. 15288:2003 15288R

로 반영된다.

프로세스들이 갖는 각각의 관계는 아래와 같이 가지 경우로 나누어진다3 .

첫째 관계는 한 프로세스가 다른 프로세스의 일부분임을 표시한다, 'is-part-of' . SW

- 155 -

상세 설계는 구현의 관계이며 이 관계는 프로세스와 컴포넌트 프로세SW ‘is-part-of'

스와의 관계이다 또한 활동 역시 프로세스와 관계를 갖는다. ’is-part-of' .

둘째 관계는 프로세스들 간의 관계로 한 프로세는 다른 프로, 'is-specialiaztion-of' ,

세스의 구체화된 프로세스임을 나타낸다 그 예로서 구현은 구현과. , SW

관계를 갖는다‘is-specialiaztion-of' .

셋째 관계로 한 프로세스는 다른 프로세스를 진행하는데 필요한 역, ‘contribute-to'

할을 해 주는 프로세스 관계이다 설치는 이전 과 관. SW (Transition) ‘contribute-to'

계를 갖고 활동 또한 프로세스와 관계를 갖는다‘contribute-to' .

구조 그룹구조 그룹구조 그룹구조 그룹2.5 (Structure Group)2.5 (Structure Group)2.5 (Structure Group)2.5 (Structure Group)

과 을 연계 및 통합하기 위해서 개발 후행단계12207 15288 (Development),❶ ❷

유지보수 운영 폐기 프로젝트관리와 지원 전사 계약(Downstream - , , ), , ,❸ ❹ ❺

기타 그룹으로 총 개의 프로세스의 그룹을 지어 관리한다 단 이러한(Agreement) 6 . ,❻

그룹은 구조적으로 중요한 의미를 갖는 것은 아니며 단지 연구에서 관리를 위한 것일 뿐이

다.

개발 그룹(Development Group)❶

개발 그룹은 의 개발 프로세스와 에서 개발과 관련된 기술 프로세스12207 15288

를 포함한다 주요 고려사항은 소프트웨어와 시스템 프로세스들(Technical Processes) .

간의 의사소통이 가능한 상호운영성 이며 이러한 접근방법은 소프트웨어(Interoperability)

와 시스템 프로세스간에 필요한 부분만 최소한의 관계를 지어 의사소통하는 것이다 현재.

및 의 개발 그룹은 아래와 같다12207:1995, 12207 AMD 15288 .

- 156 -

Amd1 moved this to supply and Amd2 generalized it.

SW acceptance supportAValidationP

SW installingCPSW installationATransitionP

The amendment merged two kinds of testing

SW testingCPSys qualification testingAVerificationPSys integrationCPSys integrationAIntegrationP

The amendment merged two kinds of testing

SW testingCPSW qualification testingASW integrationCPSW integrationASW constructionCPSW coding and testingASW designCPSW detailed designA

The amendment merged these two

SW designCPSW architectural designASW requirements analysisCPSW requirements analysisA

ImplementationPSys architectural designCPSys architectural designAArchitectural designPSys requirement analysisCPSys requirements analysisARequirement analysisP

Amendment added elicitation

Requirements elicitationCPStakeholder requirement definition

P

Process implementation is like a “strategy”

Process implementationADevelopmentPDevelopmentP

Notes12207:Amd12207:199515288

연구에서는 아래 그림과 같은 개발 그룹을 제안하였다 이러한 개발 그룹이 및. 12207

에 미치는 영향은 다음과 같다15288 .

Contributes-toSW InstallationPContributes-toSW acceptance supportP

Transition

SW qualification testingCPSW integrationCPSW coding and testingCPSW detailed designCPSW architectural designCPSW requirements analysisCP

Fow now, these remain specific to software. Later we can rewrite them to create to specialization relationships. Also, we would reverse the Amendments merger of the testing processes and the design processes.

SW Impl Strategy (was Process Impl).AIs-specialization-ofSW ImplementationPImplementation

Validation

Contributes-to[SW] Sys Qualification TestingPVerificationIs-specialization-of[SW] Sys IntegrationPIntegration

[SW] Implementation (See below)PImplementation (See below)Is-specialization-of[SW] Sys Architectural designPArchitecture designIs-specialization-of[SW] Sys Requirements analysisPRequirement analysisIs-specialization-of[SW] Sys Requirements elicitationPStakeholder requirements definition

User would be allowed to use 15288 instead.

(System Context)Notes12207R15288R

제안한 개발그룹이 에 미치는 영향은 프로세스의 목적과 결과물에 미미한 수정이12207

예상되며 무시해도 좋을 정도이다 제안한 개발그룹이 에 미치는 영향은 첫째 현재. 15288 ,

개발 프로세스는 위의 그림처럼 두 가지 그룹으로 나누어지며 둘째 사용자들은 원할 경우, ,

시스템 문맥 을 위하여 을 사용할 수 있다 셋째 현재의 활동들(System Context) 15288 . ,

은 목적과 결과물을 가지고 기술을 가진 프로세스가 될 수 있다 넷째 수정 보완 버젼의. ,

- 157 -

몇 가지 목적과 결과물은 재표현 되어야 한다.

하위 그룹(Downstream Group)❷

판매부분 그룹은 유지 운영 폐기 에 관련된 프(Maintenance), (Operation), (Disposal)

로세스를 포함한다 주요 고려사항은 호환성 이며 기존에 있는 프로세스의. (Compatibility)

변경을 최소화 하며 접근 방법은 첫째 공통으로 관여하는 관심사에 대해 간결하게 기술한,

다 둘째 필요시 시스템과 소프트웨어 고유의 관심사를 해결하기 위해 프로세스의 서브 클. ,

래스 를 제공한다 현재의 판매부분 그룹은 아래 그림과 같다(Sub-class) . .

MaintenanceCustomer supportOperational use

Operation12207 Amd 1

CPCP

P

PP

P

DisposalAmendment seems broader.MaintenancePMaintenanceAmendment seems broader.User supportA

System operationAOperational testingAProcess implementationAOperationPOperation

Notes12207:199515288 Processes

연구에서는 아래 그림과 같은 하위 그룹을 제안한다 수정 보안 버전의 추가적인 운영.

프로세스를 위한 동기는 명확하지 않은 상태이므로 이 부분에 대해서는 좀 더 연구가 필요

하다 유지보수의 경우 소프트웨어 유지보수는 시스템 유지보수의 특정한 부분이므로.

와 함께 호환성을 유지해야 한다 폐기의 경우 에서는 폐기 프로세스가 필요14764 . 12207

하지만 의 폐기 프로세스는 에서 사용하기에는 그 범위가 소프트웨어에서 필15288 12207

요한 정도를 벗어난다 그러므로 보다 단순한 폐기 프로세스가 필요하다. .

Is-specialization of. User would be allowed to use 15288 instead.[SW] DisposalPDisposalIs-specialization-of[SW] MaintenacePMaintenanceIs-specialization of. User would be allowed to use 15288 instead.[SW] OperationPOperation

Notes12207R15288R

제안한 개발그룹이 에 미치는 영향은 첫째 새로운 폐기 프로세스가 추가된다 둘12207 , .

째 존재하는 유지보수 프로세스의 작업은 다른 활동으로 이동할 것이다 셋째 유지보수와, . ,

운영의 어떤 작업은 소프트웨어 운영과 유지보수가 시스템 수준 프로세스의 특정한(Level)

경우임을 명백히 하기위해 재표현 될 것이다 제안한 개발그룹이 에 미치는 영향은. 15288

거의 없으므로 무시해도 좋다.

- 158 -

(Merge or leave separate?)[SW] Configuration Management

P[SW] Configuration management

PConfiguration management

Review and evaluationAProject assessment

[SW] ValidationP[SW] Validation processP[SW] VerificationP[SW] Verification processP

For now these remain specific to software.

[SW] Quality AssuranceP[SW] Quality assuranceP

Reconcile into a single supporting process

DocumentationPDocumentationPInformation management

(Supporting process)

Recharacterize as "trade-off analysis" or "decision analysis" (distinct from product evaluation), label as a supporting process, and

add to 12207.

Decision-making

Relabel as supporting process and use purpose and outcomes from 15939. Add to both 12207 and 15288. Will require rebinning some activities and tasks.

MeasurementC

Relabel as supporting process and use purpose and outcomes from 16085

Risk managementCRisk managementTreated in Enterprise groupTreated in Enterprise groupTreated in Enterprise groupTreated in Enterprise groupC

Joint ReviewPJoint review processP

ClosingClosureA

ControllingProject controlExecutionExecution and ..

… controlA

PlanningPlanningAProject planningInitiatingInitiation and scope defnA

In both 15288 and 12207, five processes (or five activities) similar to PMBOK process groups.

This implies some additional processes in 15288 and some rebinning in 12207.

Name processes: Project Initiation,

Planning,

Execution, Assesment & Control, and Project Closure .

Project ManagementC[Project] ManagementP

Organizational management

C

Product evaluationPRelabel as supporting, use purpose and outcome from Amd, add to 12207 and 15288.

UsabilityP

Problem ResolutionChange management

PProblem resolution process

PAuditPAudit processP

PMBOK

CP

Organizational alignmentManagement

12207 Amd 1Treated in Enterprise group

Approach12207:199515288 Process

프로젝트관리와 지원 그룹(Project Management and Support Group)❸

프로젝트관리와 지원 그룹은 의 프로젝트관리 프로세스 의 지원 프로세스12207 , 12207

및 의 프로젝트 프로세스에 관련된 프로세스를 포함한다 주요 고려사항은 첫째 소15288 . ,

프트웨어와 시스템 프로세스들 간의 의사소통이 가능한 상호운영성 둘(Interoperability)

째 일반적인 프로젝트 관리 원칙과 명확한 관계를 갖는 문맥 호환성, (Contextual

셋째 기업 전사 프로세스와 명확한 관계를 갖는 기업 전사 프로세스 관Compatibility) , ( ) ( )

계이다 접근 방법은 소프트웨어와 시스템 프로세스간 상호운영을 위해 필요한 최소한의 관.

계만 갖도록 만들고 에 지원 프로세스 개념 을15288 (Supporting Process Concept)

추가한다 제안한 개발그룹이 에 미치는 영향은 첫째 새로운 프로세스가 추가된다. 12207 , .

둘째 기존에 존재하던 작업의 이동이 예상되며 그로인해서 문서의 수정 및 변화가 생길 것,

이다 제안한 개발그룹이 에 미치는 영향은 첫째 지원 프로세스의 새로운 클래스가. 15288 ,

생성되고 둘째 새로운 프로세스가 생성되며 셋째 존재하는 결과물과 활동의 이동이 예상, , ,

된다.

기업 전사 그룹( ) (Enterprise Group)❹

기업 전사 그룹은 의 하부조직 개선( ) 12207:1995 (Infrastructure), (Improvement),

훈련 프로세스와 관련된 프로세스 그리고 의 하부조직 개선 인(Training) , 12207 AMD , ,

적자원 및 훈련에 조직의 정렬 조직의 관리 품질 관리 및 지식관리를 더한 프로세스와 관, ,

- 159 -

련된 프로세스를 포함한다 또한 의 기업 전사 프로세스와 관련된 프로세스도 포함. 15288 ( )

한다 주요 고려사항은 기업 전사 에 놓여있는 가정사항을 최소화한 경제성 이며. ( ) (Economy)

추가적으로 고려할 사항은 품질관리 프로세스를 통한 과 관계를 형성하는 것이ISO 9001

다.

EnterpriseProcess

EnterpriseProcess

ProjectProcessProject

Process

Project

Enterprise

OutcomesOutcomes

Project Boundary

프로젝트 프로세스의 어떤 결과물은 조직에 자극 을 주며 기업 전사 프로세스(Stimuli) , ( )

의 결과물은 프로젝트에 반응 한다 기업 전사 그룹을 위한 접근 방법은 첫째(Response) . ( ) ,

완전한 프로세스를 기술하지 않는다 이것은 의 권한 밖에 있다 둘째 기업 전사 의. SC7 . , ( )

시스템 혹은 소프트웨어 프로젝트 요구사항을 최소화 하는 결과물 을 제공한다(Outcomes) .

셋째 결과물은 주제 에 속하는 범주로 이동할 수 있다 가능한 범주는 하부조, (Subject) . 1.

직과 환경 수명주기 프로세스 정의와 개선 인적자원 관리 및 훈련 재정자원관리 품2. 3. 4. 5.

질관리 조직개편 지식관리이다 및 에 미치는 영향은 거의 없으6. 7. . 12207:1995 15288

며 이미 존재하는 결과물 활동 그리고 작업은 이동 할 수 있다 에 미치는, , . 12207 AMD

영향은 다음과 같다 첫째 결과물은 프로세스가 될 수 없다 그러므로 평가 할 수 없으며. , .

부록은 평가가 가능하게 추가적인 내용을 제공할 수 있다.

계약체결 그룹(Agreement Group)❺

계약체결 그룹은 획득 과 공급 과 관련된 프로세스를 포함한다(Acquisition) (Supply) .

주요 고려사항은 획득과 공급 프로세스들 간의 의사소통이 가능한 상호운영성

이다 계약체결 그룹에서 발생하는 문제점은 의 활동들이(Interoperability) . 12207:1995

서로 의사소통하는데 아주 좋지만 수정 보완본 에서 소개된 컴포넌트 프로세(Amendment)

- 160 -

스는 그렇지 않다는 것이다 아래 그림에는 계약체결 그룹을 정리해 놓은 것이다. . 15288

또는 에는 특별한 사항은 없으나 에는 소프트웨어 상세 기술이12207 AMD 12207:1995

포함된다 는 발주자 및 공급자간에 효과적인 대화 창구를 가지고 있으며. 12207:1995

또한 역시 발주자 및 공급자간에 상당히 좋은 대화 창구를 가지지만15288 12207 AMD

는 좋지 않은 편이다.

Product accept

Support

Product accept

Support

Transfer

responsibility

Product releaseAcquire

acceptance

Product releaseCustomer

acceptance

Deliver and

Complete

Accept & completeDeliverConfirm acceptance

Assess

Supplier

Monitoring

Supplier

Monitoring

Execute and

control

Supplier

Monitoring

ExecuteAssess execution

Planning

Contract

Agreement

Contract

Agreement

Contract

Agreement

ContractContract prep &

update

Negotiate

agreement

Negotiate

agreement

Supplier

Selection

Supplier

Monitoring

Select supplier

Prepare

response

Evaluate

request

Communicate

request

Prepare

Response

RFP preparationFind acquirePrepare

Request

Supplier

tendering

Prepare acqSupplier

tendering

Prepare acqInitiationInitiationPlan

SupplySupplySupplySupplyAgreementAgreementAgreementAgreementSupplySupplySupplySupplyAgreementAgreementAgreementAgreementSupplySupplySupplySupplyAgreementAgreementAgreementAgreementSupplySupplySupplySupplyAgreementAgreementAgreementAgreement

Harmonization Prop WD1Harmonization Prop WD1Harmonization Prop WD1Harmonization Prop WD112207 12207 12207 12207 AmdAmdAmdAmd12207:199512207:199512207:199512207:199515288152881528815288

Move toTransition

계약체결 프로세스를 위한 전략은 첫째 한 쌍의 프로세스, (A single pair of

는 시스템과 소프트웨어 모두를 위해 작동해야 하며 둘째 와processes) , 12207:1995

의 효율적인 대화 창구를 유지하고 셋째 의 컴포넌트 프로세스를 보존15288 , 12207 AMD

하도록 해야 한다 가능한 해결책은 아래 그림과 같다. .

- 161 -

ClosureClosure

Product/service delivery

Acquire acceptance

Contract execution

Supplier monitoring

Contract agreement

Contract agreement

(None)Supplier selection

Supplier tendering

Advertise acq

(None)Prepare acq

SupplySupplySupplySupplyAcquisitionAcquisitionAcquisitionAcquisition

Harmonization Prop WD1Harmonization Prop WD1Harmonization Prop WD1Harmonization Prop WD1 (with (with (with (with additions)additions)additions)additions)

기타 그룹(Left-overs Group)❻

는 시스템적인 소프트웨어 재사용을 위한 프로세스를 가지고 있다 이러한12207 AMD .

재사용은 도메인 공학 자산 관리 재사용(Domain Engineering), (Asset Management),

프로그램 관리 이다 생산 라인 관리(Reuse Program Management) . (Product Line

는 어떤 특화된 프로세스와 함께 구별되는 프로젝트로서 특화될 수 있다 접Management) .

근 방법은 단기 장기 로 나눌 수 있으며 단기의 경우(Short-term), (Long-term) PRM

부록에 프로세스를 포함하며 장기의 경우 생산 라인 관리를 기술하는 식별 가능한 애드온

표준 을 기록한다(Add-on) (Standard) (Write).

결론 및 추가 작업3

현재 의 수준은 만족할 만한 상태이며 은 가지 형태로 나눌 수 있다 첫, 15288 12207 3 .

째 활동과 프로세스 집합의 작업를 수행하는 형태 둘째 활동과 증거를 제공하는 작업, ,

를 갖는 결과를 획득하는 형태 셋째 조정 이(Task Providing Evidence) , (Tailoring)

사용되는 형태이다.

이 받는 일반적인 영향은 다음과 같다 첫째 프로세스 전문12207 . , (Process

은 목적과 결과물에 의해 교체되거나 보완될 것이다 둘째 어떤 활동은 컴포Preambles) . ,

넌트 프로세스로 새로 이름 지어질 것이며 목적과 결과물이 해당 컴포넌트 프로세스에 붙여

질 것이다 셋째 어떤 작업은 다른 활동으로 옮겨갈 것이다 넷째 위험관리나 측정. , . ,

처럼 부가적인 지원 프로세스가 더해질 것이다 다섯째 리스트를 노트로(Measurement) . ,

바꾸는 기회를 찾아볼 필요가 있다 여섯째 의 활동들 사이에 관계를 무너뜨리지 않. , 12207

도록 충분히 검증해야 한다.

가 받는 일반적인 영향은 다음과 같다 첫째 대부분의 내용 은12207 AMD . , (Content)

- 162 -

부록으로 이전할 것이다 둘째 어떤 목적과 결과물은 수정될 것이다 셋째 어떤 컴PRM . , . ,

포넌트 프로세스는 추가되거나 삭제 변경 혹은 양도 될 것이다, , (Devolved) .

추가적인 작업으로는 첫째 및 에서 사용되는 용어 구별과, 15288, 12207 12207 AMD

추가적인 용어의 사용 해결 둘째 의 어느 작업 목록이 노트로 변하고 어느 작업이, 12207

리스트로 남을지 결정 셋째 와 의 관계가 존, 'contribute-to' ‘is a specialization of'

재할 때 충돌 을 제거하는 것 넷째 기업 전사 에 프로젝트에 의해 필요로 하는, (Conflict) , ( )

결과물을 제공하도록 프로젝트 프로세스 결과물이 적당한지 확인하는 것이다.

연구에서 제안한 간단한 조화 모형을 좀 더 보완하기 위해 남아 있는(Harmonization)

것은 다음과 같다 첫째 시스템과 소프트웨어의 공학의 원칙을 사용한 강한 통합. (Strong)

화가 필요하다 둘째 과 의 다른 기술 상세화를 적용한 해결책이 필요하. , 12207R 15288R

며 셋째 프로세스의 클래스 서브클래스의 계층도를 완성하는 것이다, / .