NIPA-0097.hwp

Transcription

1 시스템수명주기프로세스프레임워크보고서

2 목 차 1. 서 론 1.1 필요성 시스템공학의정의 시스템공학의발전과정주요연구내용 시스템공학과소프트웨어공학 시스템공학프로세스 시스템개발단계화 시스템공학표준 시스템공학관련표준현황 2.1 MIL-STD-499 시리즈 EAI IEEE 시스템공학표준비교 시스템공학표준채택 / 활용현황 3.1 개요 미국 일본 유럽 ISO/IEC 표준및가이드분석 4.1 ISO/IEC 시스템공학 - 시스템수명주기프로세스표준 ISO/IEC TR 시스템공학 -ISO/IEC 적용가이드 시스템수명주기프로세스프레임워크설계방안 5.1 시스템수명주기프로세스프레임워크 시스템수명주기프로세스와발주관리지침연계방안 참고문헌 52 부록 A : 시스템수명주기프로세스프레임워크 부록 B : ISO/IEC & ISO/IEC 개정제안분석 - 2 -

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 표준채택공지 23 < 그림 3-2> 미국방성의 ISO/IEC TR 표준채택공지 24 < 그림 3-3> 미국방성의 Defense Acquisition System 지시문서 24 < 그림 3-4> 미국의 IEEE Std 표준 25 < 그림 3-5> 록히드마틴의 LM-IEP 표준개념 26 < 그림 3-6> ISO/IEC 을기초로한비용분석개념 26 < 그림 3-7> 일본표준규격협회표준화조사연구개발성과보고서 27 < 그림 3-8> ISO/IEC 기반영국국방부의획득정책 / 프로세스프레임워크 28 < 그림 3-9> ISO/IEC 기반스웨덴프로세스아키텍처 28 < 그림 3-10> 호주/ 뉴질랜드 ISO/IEC 표준 29 < 그림 4-1> ISO/IEC 표준프로세스구조 34 < 그림 4-2> ISO/IEC 과 의관계 36 < 그림 4-3> 국제표준의사용개념 39 < 그림 5-1> 시스템수명주기프로세스연관관계 46 < 그림 5-2> 프로세스활동구성 47 < 그림 5-3> 표준과제안방법과의비교 47 < 그림 5-4> 시스템수명주기프로세스와발주관리지침연계방안

4 표목차 < 표 3-1> 호주/ 뉴질랜드 ISO/IEC 표준 29 < 표 4-1> ISO/IEC 표준제정경과 32 < 표 4-2> ISO/IEC 과 의관계 36 < 표 4-3> 단계, 단계의목적및중요결정게이트 37 < 표 4-4> 기술보고서추진경과 38 < 표 5-1> 시스템수명주기프로세스프레임워크설계방안 44 < 표 5-2> 시스템수명주기프로세스구성

5 1. 서 론 - 1 -

6 1. 서론 1.1 필요성 과거로부터현재까지소프트웨어가하드웨어의비중을능가하기시작하면서소프트웨어 관점에서의개발표준이지속적으로발전되어왔다. 현재국내외적으로 ISO/IEC 12207이 대세라할정도로소프트웨어개발표준으로자리잡고있다. 이미정통부에서는 ISO/IEC 을기반으로국내실정에적합한소프트웨어개발표준을 2년간의연구를통하여 공공부분 S/W 발주관리표준프로세스지침 이라는명칭으로완료한상태이다. 한편시 스템공학관점에서볼때시스템( 하드웨어 ) 을작동시키기위한소프트웨어는시스템의한 구성품으로써다루어질수밖에없다. 예를들면 KTX와같은고속열차를만드는프로젝트 에서고속열차자체를만드는하드웨어공학과소프트웨어를만드는공정이조화가되도록 함께고려되어져야할것이다. 그외에도시스템공학은휴먼웨어를포함한많은고려사항이 필요하다. 소프트웨어의관점이아닌하드웨어의관점에서볼때비행기, 전투기, 고속열차등주요 하드웨어의생명은하드웨어안에서작동하는소프트웨어가핵심이라는것은이제상식적인 사실이다. 그러므로하드웨어제조공정을함께고려한소프트웨어개발공정의관리는더욱 중요해지며, 이러한맥락에서본연구에서는정통부가선도적차원에서시스템공학의중요 성을인식하고 ISO/IEC 기반으로하여국내에적용할수있는시스템공학수명주기 프로세스프레임워크를설계하였다. 본보고서의 2장에서살펴본바와같이 ISO/IEC 역시미국방부의표준인 MIL-STD-499 시리즈에서발전하여 EIA 632, IEEE 1220 등을거쳐 ISO/IEC 로발전하였다. 각표준의특성들이제각기있지만소프트웨어수명주기프로세스 표준인 ISO/IEC 도개발관점의미국방부의표준에서발전하여획득에서부터폐 기까지의수명주기를망라한표준으로발전하였듯이 발전하여왔다. ISO/IEC 15288도똑같은개념으로 본연구는이와같은노력의일환으로시스템공학의개념을정의하고기존의관련표준 들을분석한후, 최근제정된 ISO/IEC 을기반으로국내환경에적합한시스템공 학프레임워크를개발하는데목적이있다. 본연구의결과를기반으로프레임워크가확정되 면프레임워크를실현하기위한후속지침의개발이지속적으로필요할것이다. 또한본연 구는 ISO/IEC 을기반으로개발된공공기관발주관리지침과연계하여효과적이고 효율적인시스템획득을지원하는프레임워크의개발을염두에두었다

7 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) 프로세스라고할수있다. 시스템공학피드백루프는시스템의필요성과목적을이해하고이를분명하게정의한다 음, 이를충족시킬수있는대안을도출하고최적형상을선택하는과정이다. 이를바탕으로 시스템설계와통합을수행하고요구시스템을개발해간다. 반복적인과정이란우선이해된 - 3 -

8 목표와정의된시스템요건을상호비교절충하여대안형상을도출하는활동을말한다. 이를 위해시스템설계및통합과정에서반복적인인터페이스통제, 그리고통합시스템의실제특 성시험결과와요건/ 목표를비교한다음요구특성과시스템특성및데이터를반복적으로 조정하여최적형상을선택하게된다. 반복적인활동을통한궁극적인목적은보다효과적이고효율적인방법으로고객이제시 한요건을충족시키도록함에있다. 결국누가더빨리, 더적은노력으로요건을보다좋 은시스템으로충족시키느냐하는점이시스템공학의기본목표라고할수있다. 1.3 시스템공학의발전과정 시스템공학접근방법은 19세기산업혁명과 2차세계대전을거치면서 1950년대기존시 스템의최적화와시스템을분석하기위해시작된운영분석 (operations research) 활동에 서비롯된다 년대에들어와시스템의효율적인개발관리방법으로분업화전문화가 도입되었다. 이와함께효과적인개발관리방법으로수석엔지니어 (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) 이구축되었다. 이러한기법을널리모든산업분야에확산하고그적용사례를함께공유하 기위하여시스템엔지니어모임을조직하게되었다 년범세계적인시스템공학표준을제정한후미국국내의시스템엔지니어전문가 모임으로 NCOSE를조직하였고 1995년에이를국제적인모임으로 INCOSE가설립되었 다. 21 세기로접어들면서시스템공학은시스템형태별모델로발전되기시작했다. 그리고 여러가지시스템공학컴퓨터지원도구, CASE 를이에적용함으로써모델기반시스템공 학(MBSE: Model Based Systems Engineering) 기법이태동되기시작했다. 나아가모 델기반획득MBA: Model Based Acquisition) 기법, 모델링및시뮬레이션기법, 그리고 - 4 -

9 동시공학 (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) 은컴퓨터프로그램의절차와이에관련된문 서를개발하고관리하는데필요한과학적이고체계적인절차를말한다. 이러한소프트웨어 공학절차는하드웨어공학절차와함께연동되어있다. 특히하드웨어시스템에내장되어 있는소프트웨어개발절차는아래그에서와같이시스템개념설계이후하드웨어개발절차 와유사하다. 이는요건계획, 요건분석, 설계, 코딩, 운용및유지보수단계로구성되어있 다. 하드웨어와함께개발된소프트웨어는통합시험을거쳐설계검증및확인이이루어진 다. 사용중에문제가발생되면각각의정비절차를통해보완하고이를통합해서시험한다

10 < 그림 1-1> 소프트웨어공학과시스템공학 한편, 소프트웨어시스템을개발하는수명주기모델로서폭포수모델(waterfall model), 진화적모델(evolutionary model), 나선형모델(spiral model) 등이있으며, 이는시스템공학모델과동일하다. 날이갈수록소프트웨어요구가증가하고있어소프트 웨어비용또한급속하게증가하고있다. 따라서시스템공학과소프트웨어공학은불가분 의관계로함께통합발전되고있다. 1.5 시스템공학프로세스 기본프로세스 시스템공학프로세스 (SEP: Systems Engineering Process) 란통합팀에의해순차 적이며하향식(top-down) 방법으로적용하는포괄적이고반복및순환적으로문제를해결 하는프로세스를말한다. 이러한프로세스는고객의요구와요건을시스템제품과프로세스 규격서로변환하며의사결정권자에게필요한정보를생성하여제공하게된다. 이를시스템공학아키텍처 (architecture) 라고하며이는사용자및고객요구사항을시 스템엔지니어로하여금하드웨어, 소프트웨어, 시험, 생산성, 프로그램관리자, 로지스틱 스, 교육훈련, 인력및인사, 신뢰성, 안전성, 정비성, 그리고각종환경관련엔지니어등으 로구성된통합팀에의해시스템규격서(system specification) 를생성하는프로세스이 다. 이와같이한레벨에서생성된자료는다음개발레벨의입력자료로제공된다. 따라서 기본적인프로세스는한번에한레벨씩순차적으로적용되고, 각각의개발레벨에따라추 - 6 -

11 가적인세부내용과정의가제시되어진다. 시스템공학프로세스과정에서형성되는아키텍처는시스템을보다쉽게기술하고공통 적으로이해하기위하여만들어진다. 아키텍처라는용어는일반공학분야에서여러가지 의미로사용된다. 여기서는시스템을만들기위하여하부시스템을어떻게결합해야하는지 에대한설명으로이해하면된다. 이러한목적을달성하기위하여기능적(functional), 물 리적(physical), 및시스템(system) 아키텍처를사용하고있다. 기능적아키텍처는할당 기능(allocated function) 과성능요건 (performance requirement) 을식별하기위해 이를구조화한아키텍처이다. 물리적아키텍처는시스템이하부시스템과구성품으로분해 되어지는구조를나타낸다. 이는구체적으로시스템을구성하고이는형상제품 (configuration item) 으로나타난다. 시스템아키텍처는시스템을운용하고지원하는데 필요한모든제품과생산및건설, 배치, 운용, 유기, 폐기, 교육훈련및검증에필요한모 든수명주기프로세스를포함하고있다 시스템공학프로세스정의 시스템공학프로세스는모든개발단계동안하향식(top-down) 이며포괄적으로운용되 어야한다. 뿐만아니라문제해결을위하여반복적이고순환적인과정을적용함으로써다음 과같은목적을이루어간다. 첫째, 필요성과요건을시스템제품(product) 과프로세스 (process) 규격서로변화해간다. 이는개발단계가진행됨에따라보다높은가치(value) 를지는규격서로구체화되어간다. 둘째, 의사결정권자에게필요한정보(information) 를 생성해준다. 셋째, 한단계에서다음단계로옮겨가기위해필요한모든입력자료를제공 하게된다. 이러한목적을달성하기위한프로세스를도식하면아래그림과같다. 기본적으 로시스템공학프로세스에입력하상과출력사항으로되어있다. 시스템공학프로세스는 요건분석 (requirement analysis), 기능분석및할당(functional analysis and allocation), 요건루프 (requirement loop), 조합(synthesis), 설계루프 (design loop), 검증(verification), 및시스템분석및통제(system analysis and control) 로구성되 어있다

12 < 그림 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) 를기술한규격서로서이는성능요건이 - 8 -

13 논리적으로무엇을수행하는지를설명해준다. 즉, 요구시스템이무엇을수행해야하고, 어 떠한방법으로수행할수있는지그리고하위레벨기능과어떠한차이점이발생하고있는지 를설명해준다. 따라서기능분석및할당프로세스는향후물리적인해결방안을최적화하 기위해필요한정보를제공해주는데있다. 상기두가지프로세스를통해요건이보다구체화되고세분화되어대상시스템의기능을 보다분명하게제시하게된다. 이와같이식별된기능은반드시요건을추적할수있어야 한다. 기능분석및할당프로세스를통해제기된문제점은요구분석과정으로피드백되어요 건이충족될때까지반복수행한다. 이를요건루프 (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) 등성능을기반으로한진도관리 가포함된다. 이러한시스템분석및통제의목적을달성하기위해서는다음사항을지켜야 한다. 대안을결정하기에앞서시스템효과도, 수명주기별자원, 위험및고객요건에미치는 영향을평가해야한다

14 SE 프로세스결과물에입각하여규격서요건과각종의사결정이이루어져야한다. SE 프로세스는입력에서출력까지반드시추적성이유지외어야한다. 개발일정과획득시기는상호협조적으로지원되어야한다. 시스템에필요한기술요구사항은시스템공학활동에포함되어있어야한다. 기능과성능에영향을주는고객요건은타당성, 일관성, 기대성및실현가능성이있어 야한다. 제품과프로세스의설계요건은도출된기능및성능요건을추적할수있어야한다. 프로세스의출력은각프로세스단계에적합한규격서, 의사결정사항, 시스템및형상품 목아키텍처, 및각종기준이포함된다. 일반적으로이는제품형상이나제품을개발하는데 필요한모든프로세스를기술하거나통제하는데이터를말한다. 1.6 시스템개발단계화 일반적으로시스템개발단계화는세가지의분명한레벨또는단계를거쳐진행되고있 다. 1 단계는개념연구를통하여시스템개념을기술하는개념레벨의시스템기획단계이다. 2 단계는시스템성능에대한요건항목으로나타내는시스템레벨단계이다. 3단계는하부시스 템과구성품의제품성능을기술하고생산단계에서의제품상세규격을설정하는하부시스템 / 구성품레벨단계이다. 시스템공학프로세스는일반적으로형상기준 (configuration baseline) 이라고불리는 기술서(description) 를만들기위하여시스템개발단계별, 시스템레벨별한단계씩적용 해가는프로세스이다. 따라서각각의개발레벨과이와연관된형상기준을설정해간다. 예 를들어이러한형상기준을살펴보면다음과같다. 형상기준은시스템기획을수립하기위 한개념연구단계에서정의된시스템레벨규격을기술한개념설계기능기준 (functional baseline), (allocated baseline), 예비시스템설계단계에서하부시스템과구성품의성능을기술한할당기준 그리고하부시스템과구성품의상세규격을기술하기위해정의된 제품기준 (product baseline) 으로점진적으로시스템이구체화되어간다. 이러한기준상호 간에기본적인관계를나타내기위하여미국방성에서는아래그림과같은획득수명주기프 로세스를사용하고있다

15 < 그림 1-3> 미국방성시스템획득수명주기프로세스 그림에서삼각형은각종기준을통제하기위하여기준통제의사결정점을나타내며, 의사 결정수단은기술검토 (technical review) 및감리(audit) 활동을통해검증되어진다. 시스 템계층구조레벨에따라개발하려면상위레벨형상기준이설정된다음후속개발이이루어 져야한다. 기술검토와감리활동은기준면에서다음단계개발준비완료여부를확인하기위 해사용되는절차이다. 이러한검토및감사프로세스는시스템의성숙정도를평가하는활 동으로서각종의사결정프로세스를지원하는데중요한역할을한다. < 그림 1-4> 시스템공학표준상속도 1.7 시스템공학표준 1960 년대이래시스템공학프로세스의표준에대한필요성이제기되어왔다. 위그림은 바로이러한요구를충족시키기위하여시스템공학표준과이와밀접하게연계되어있는 소프트웨어공학표준의발전유래를보여주고있다 년에처음으로제정된군사표준 MIL-STD-499 는그후군사표준과함께미국 방성표준으로발전시키기위하여꾸준하게노력해왔다. 드디어 MIL-STD-499B 로기안 되었으나미국방성획득정책변화에따라표준으로변경되지못한채사장되었다. 미국가표

16 준원(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 로제정되어오늘날까지사용되어오고있다

17 시스템공학관련표준현황

18 2. 시스템공학관련표준현황 시스템공학과관련된표준이나모델들이개발되기시작한지는그리오래되지않았다 년에처음으로개발된 MIL-STD-499 시리즈가있었지만, 이표준은미국방시스 템의획득에초점을둔표준이었기때문에다른산업분야에널리활용되지는못했다. 그러 나 MIL-STD-499B 가발간되지못하면서다양한산업영역에적용할수있는시스템공학 표준을개발하려는노력들이 1994 년부터시작되었다. 이러한노력들은 EIA 632, IEEE 1220, ANSI/EIA 632와같은표준들을거치면서현재최초의국제표준으로서 ISO/IEC 발간된것이다. 이들표준이외에도 SECAM, EIA 731, CMMI 등과같은다양한 프로세스평가모델들이존재하지만본장에서는제외한다. 2.1 MIL-STD-499 시리즈 < 그림 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) 이 외의국방표준에대한미국방부의폐지방침에따라정식표준으로발간되지는못했다

19 그러나 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) 을 구성하여개발한표준으로서, 시스템공학과관련된거의모든프로세스들을고려하기위해 대상범위를확장하고또국방및항공우주부문에국한하지않고다른모든분야에도적합 하도록표준을개발하였다

20 < 그림 2-3> ANSI/EIA 632 > 표준 다. 이러한특징은 EIA/IS 632 및 ANSI/EIA 632 프로세스구성도로부터쉽게알수있 계획프로세스 기술프로세스 평가프로세스 통제프로세스 계획, 지시 & 상태 획득 & 공급 공급프로세스획득프로세스 요구사항 결과물 & 피드백 획득요청 시스템설계 요구사항정의프로세스 해결방안정의프로세스 설계 제품구현 구현프로세스 이전프로세스 시스템제품 제픔기술평가 시스템분석프로세스 요구사항논증프로세스 시스템검증프로세스 최종제품논증프로세스 < 그림 2-4> ANSI/EIA 632 프로세스관계도

21 특히 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 표준 Trial Use에대한 2년간의적용경험을바탕으로 1999년 1월에배포된 IEEE 1220 Full Use는 MIL-STD-499B 나 EIA/IS 632 보다아주상세한수준으로기술되었으며, 소프트웨어와하드웨어를포함한시스템개발과시스템의수명주기를고려한프로세스의개 발을위해전사조직 (enterprise) 이수행해야할총체적인기술활동들을정의한다. IEEE 1220 Full Use 의프로세스구성도는아래그림과같다

22 프로세스입력 요구사항요구사항분석분석 요구사항기준선 요구사항요구사항검증검증 요구사항 & 제약사항충돌 (conflict) 요구사항거래 & 효과 (impacts) 요구거래연구 & 평가 기능기능분석분석 기능검증기능검증 종합종합 설계설계검증검증 검증된요구기준선 기능적아키텍처 검증된기능적아키텍처 물리적아키텍처 검증된물리적아키텍처 분해와요구사항할당대안 분해 / 할당거래 & 효과 (impacts) 설계솔루션요구사항 & 대안 설계솔루션거래 & 효과 (impacts) 통제통제 프로세스결과 시스템기능거래연구 & 평가분석설계거래연구 & 평가 < 그림 2-6> 시스템공학프로세스 (SEP) 2.4 시스템공학표준비교 본절에서는앞서소개한대표적표준들의특성을비교하도록한다. 먼저각표준들의공 통점을살펴보면다음과같다. 첫째, 표준들은 " 무엇을해야하는지(what should be done)" 에대해서만기술하고있으며, " 어떻게해야하는지(how to do it)" 에대해서는 언급하고있지않다. 경우에따라서는 " 무엇" 이 " 어떻게" 로해석되는경우도있지만, 이것 은단지관점의차이일뿐이다. 오늘날표준들은이러한문제점을해결하기위해방법론이 나도구보다는프로세스와프로세스에관련된활동과과업에더욱많은초점을둔다. 둘째, 표준들은시스템의수명주기에기반을둔다. 물론수명주기는대상산업에따라, 또 는주체( 고객, 계약자, 개발자, 사용자등) 의목적에따라매우다양하게정의될수있지만, 각표준들은표준에서가정하는바에따라수명주기를정의하고있다. 다음으로표준들간의주요차이점을아래그림을통해살펴보았다

23 < 그림 2-7> 시스템공학표준비교 EIA/IS 632는 MIL-STD-499B 의비군용(demilitarized) 버전이기때문에, 대부분 의내용을그대로계승하고있다. 따라서두표준간의차이점은그리크지않다. 이두표 준의경우시스템개발을위한접근방법을정의하고있으며, 프로세스의상세수준면에서도 타표준들과비교했을때중간수준에해당한다. IEEE 1220 의경우에도시스템개발을위해수행해야할활동과과업에대해다루고있 지만, MIL-STD-499B 나 EIA/IS 632보다는훨씬상세한수준에서프로세스를다루고 있다. ANSI/EIA 632 는이들표준들보다는좀더상위수준에서프로세스를다룬다. 총 13개 의표준과 34 개의요구사항으로구성되어있으며, 개발단계뿐만아니라그이전의개념화 단계에서개발이후의전수단계까지그범주를확대하고있다. 끝으로 ISO/IEC 의 경우최상위수준의표준으로서, 시스템공학프로세스뿐만아니라경영(management or business) 프로세스까지언급하고있다

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

25 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 System Engineering-A guide for the application of ISO/IEC 을발행하였다. 이처럼시스템수명주기표준이공식적으로발표되고활용되기시작한것은불과 2~3년 에불과하다. 따라서실제본표준에서제시하고있는시스템수명주기의단계와프로세스 들을활용하여해당되는관리분야또는프로젝트에적용하고그효과를나타내기에는아직 시기상조이다. 반면에 1996 년부터시스템수명주기프로세스에대한논의가항공및우주 산업, 군수산업과같은거대시스템기업들이시스템수명주기에관심을갖고참여하였고, 미국의국제시스템공학협의회 (INCOSE, International Council on System Engineering) 및미표준기구인 IEEE Computer Society(CS) 에서도적극적으로참여 하여의견을반영함으로써활용성에대한기대는높다고할수있다. ISO/IEC 의활용현황은본표준이시스템및소프트웨어공학분야의다양한 국제표준에있어서하위또는특정분야의표준들에대해기본적인상위표준 (Principle Standard) 이고공식적인표준이발행되고적용하는기간이짧아서표준적용에대한효과 측정은어렵다고볼수있다. 따라서현재본표준을적용하거나채택, 활용하는수준에서 현황을살펴보고자한다. 3.2 미국 미국은시스템공학, 특히소프트웨어집중적인시스템에대한수명주기프로세스에대해 민간뿐만아니라정부차원에서도가장활발히적용하고활용하고있다. 특히항공산업, 우 주산업, 대형무기사업을정부차원에서관리하거나민간차원에서프로젝트를진행하면서

26 시스템공학및시스템수명주기프로세스의필요성을절실히느끼고표준및관련활동에 매우적극적이다 공공분야 미국의공공분야에있어서시스템공학및관련프로세스를가장적극적으로활용하고있 는국방성(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 표준채택공지 2004 년 3월에는가이드인 ISO/IEC TR 을공식적으로채택하고활용할것을 권고하였다. 이권고는 ISO/IEC 15288:2002 의표준문서를적절하게사용하고표준의 효과적인사용을평가하는데사용할수있음을밝히고있다

27 < 그림 3-2> 미국방성의 ISO/IEC TR 표준채택공지 또한미군의모든획득에관련한최상위의지시문서인국방획득체계 (DoD Directive ) 및국방획득체계시행(DoD Instruction ) 에대한가이드로제시하고있 는국방획득가이드북 (Defense Acquisition Guidebook) 4장에서시스템공학및프로 세스에대한가이드를제시하고있으며, 주요한시스템공학표준으로 ISO/IEC 15288, EIA 632 및 IEEE 1220 을제시하고있으며, 이표준간에깊이와수준이상이함에따라 서적절한조합을통해활용할것을명시하고있다. < 그림 3-3> 미국방성의 Defense Acquisition System 지시문서 또한미해군의무기및정보체계연구개발을담당하는 SPAWAR(Space and Naval

28 Warfare) 사령부는프로젝트관리정책(Project Management Policy, SSCSDINST A, 202, 30 November 2004) 웨어개발을위한시스템및소프트웨어표준으로 고있다. 지침상에보다효율적인시스템개발및소프트 ISO/IEC 의참고할것을명시하 미국방성의경우다양한미군의획득에있어서특히, 대형무기체계또는정보시스템도 입에있어서이를관리하고통제하기위한수단으로시스템수명주기프로세스표준을제시 하고활용하고있다 민간분야 국가표준기구 우선미국의표준기구인 IEEE Computer Society(CS) 에서 2004년 12월 ISO/IEC 15288:2002 를미국표준인 IEEE Std 로발행하였다. 미국의표준으로발 행하면서 IEEE에서는 ISO 표준의전체내용을그대로수용하면서단지부록 E(Annex E) IEEE 표준들과의관계 를추가하여기존의 IEEE 12207, 1220 등과같은표준들 과의관계를부가하여표준으로발행하였다. < 그림 3-4> 미국의 IEEE Std 표준 프로세스개선분야 (Lockheed Martin) 미국의대표적인방산기업인록히드마틴은항공기, 미사일을비롯해군의정보시스템분야 선도하는기업이다. 이기업은복잡하고광범위한시스템개발을위해시스템공학및프로 세스에많은노력을기울이고있으며, 시스템구축의품질향상, 생산성향상, 예측성향상, 고객만족을위해꾸준히프로세스개선을수행하고있다. 특히다양한표준을수용한

29 LM-IEP(Lockheed Martin-Integrated Engineering Process) 표준을개발하여적 용하고있으며, 이자체표준에시스템공학프로세스표준으로 ISO/IEC 과 IEEE 1220 을포함하고있다. LM CPSs ANSI/EIA-632 ISO 9001:2000 CMMI V1.1 ISO/IEC LM Hardware Process Standard ISO/IEC IEEE 1220 Common Source Standards Industry Stds Government Stds Domain Specific Standards LM-IEP Standard EPI Process & Methods Industry Stds Government Stds Project Specific Standards CPS Corporate Policy Statement EPI Engineering Process Improvement In LM-IEP V2.0 issued 1/03 Reference Only Informative only Organizational Standard Process Project Defined Process Integrated Processes Integrated Methods Integrated Work Products Tailored OSP < 그림 3-5> 록히드마틴의 LM-IEP 표준개념 비용분석분야 (Univ. of Southern California) Southern California 비용예측모델 대학의소프트웨어공학센터에서시스템공학활동을기초로한 COSYSMO(Constructive System Engineering Cost Model) 을개발 함에있어서다양한수준의시스템공학활동을식별하기위하여 ISO/IEC 과 ANSI/EIA 632 표준을활용하고있다. 소프트웨어공학센터는 2005년 4월 2005 NASA Cost Analysis Symposium 발표를통해비용분석을위한작업분해도및단계식별을위 해시스템수명주기프로세스표준을활용하고있다고명시하고있다

30 # Requirements # Interfaces # Scenarios # Algorithms Size Drivers Effort Multipliers COSYSMO Effort - Application factors -8 factors - Team factors Calibration -6 factors WBS guided by ISO/IEC < 그림 3-6> ISO/IEC 을기초로한비용분석개념 3.3 일본 일본은수명주기프로세스분야에매우적극적으로참여하고있다. ISO/IEC 소 프트웨어수명주기프로세스표준의경우도 1998 년 SLCP-JCF 98( 표준번호 : JIS X 0160) 이라는명칭으로일부감사기능을추가하여일본표준으로제정하였다. 이후시스템 수명주기프로세스표준인 ISO/IEC 이 2002 년 11월에공식적으로발표되면서 2003 년 3 월부터자국의표준화작업에착수하였다 년 2 월일본표준위 (JSC) 의정보 기술전문위원회에서표준번호 JIS X 0170 으로승인하였고, 동년 6월에공식적으로발행 하였다. < 그림 3-7> 일본표준규격협회표준화조사연구개발성과보고서, 유럽 영국

31 영국국방부(UK MoD) 의효율적인획득을위하여획득관리시스템 (AMS, Acquisition Management System) 을운영하고있으며, 또한국방획득에있어주요책임, 위험등에 대해도움을주기위하여획득정책및프로세스프레임워크 (Acquisition Policy and Process Framework, APPF) 를마련하였다. 이프레임워크는국방부에서 ISO/IEC 표준을공식적으로채택하고이표준을기반으로시스템수명주기프로세스에대한 범주와하위범주를바탕으로해서 APPF 를마련하였다. 이프레임워크는모든프로세스에 대하여웹상으로하이퍼링크를통해관련활동에대한내용과정책그리고전문가에대한 정보를제공하고있다. < 그림 3-8> ISO/IEC 기반영국국방부의획득정책 / 프로세스프레임워크 스웨덴 스웨덴은 2003 년 5월에 ISO/IEC 을자국의표준인 SS-ISO/IEC 15288:2003 으로승인하였으며동년 6 월에공식적으로발행하였다. 특히스웨덴의경우 스웨덴의국방연구기관인 련하여 FMV에서획득관련한관리분야의시스템공학프로세스와관 ISO/IEC 을기반으로관리프로세스를수립하여활용하고있다

32 < 그림 3-9> ISO/IEC 기반스웨덴프로세스아키텍처 뉴질랜드 뉴질랜드는 2003 년에 ISO/IEC 을자국의표준인 Australian/New Zealand Standard(AS/NZS) 15288:2003 으로공식적인표준채택을하였다. < 그림 3-10> 호주 / 뉴질랜드 ISO/IEC 표준 ISO/IEC 의각국채택및활용현황을표로정리하면다음과같다

33 < 표 3-1> 호주 / 뉴질랜드 ISO/IEC 표준 국가명기관채택시기비고 미국방부 2003년 5월 2004 년 12 월 ISO/IEC 15288을 IEEE Std 로발행 IEEE 미국 Lockheed Martin 자체시스템공학표준에포함 Southern California 2005년 4월 NASA Cost Analysis Symposium 일본 표준규격협회 2002년 6월 영국 국방부 Acquisition Policy and Framework 운영 스웨덴 FMV 2003년 5월 뉴질랜드 2003년

34 ISO/IEC 가이드구조분석 표준및

35 4. ISO/IEC 표준및가이드구조분석 4.1 ISO/IEC 시스템공학-시스템수명주기프로세스표준 표준제정경과 ISO/IEC Systems Engineering Systems Life Cycle Processes 는시스 템공학에대한최초의국제표준이다 년 6월실시된 FDIS(Final Draft International Standard, 국제표준최종초안 ) 에대한투표(ballot) 에서국제표준으로서 의발간이승인되었으며, 표준의성숙도에대한평가에서도총 5점중 4.7점을받아국제 표준으로발간되기에충분한것으로평가되었다. 동시적이며통합된형태로서하드웨어와소프트웨어를모두포함하는시스템공학표준이 존재하지않던 1994 년에처음으로 ISO/IEC 에대한개발계획이수립되었다. 총 18개국이참여한표준화프로젝트는 1996 년 7 월초안의개요(draft outline) 가배포된 이후 5 차례의표준초안 (working draft) 발간과 4 차례의분과위원회초안(committee draft) 발간을거쳐, 2002년 3 월최종국제표준안을발간하였다. 국제표준으로발간되기까 지총 10번의개정을거치면서 3800 개이상의의견(comments) 이해결되었다. ISO/IEC 의개발을담당하고있는조직은 ISO/IEC 의합동기술위원회 (Joint Technical Committee) 인 JTC1 산하의분과위원회 (subcommittee) SC7 Software and System Engineering 으로서시스템공학과소프트웨어공학에대한프로세스, 지원도 구그리고지원기술에대한표준화를담당하는조직이다. SC7은다시 12개의작업반으로 나뉘어지는데, 이중에서 WG7 Life Cycle Management 가 ISO/IEC 의표준화 를담당한다. 이작업반은소프트웨어수명주기프로세스에대한국제표준인 ISO/IEC Information Technology Software Life Cycle Processes 를개발하기도하 였다

36 < 표 4-1> ISO/IEC 표준제정경과 문서코드 일자 WG 7 N 년 7월 23일초안개요 설명 WG 7 N 년 1월 21일 N121 의개정( 문서코드와일자확인개정) WG 7 N 년 2월 30일 N131의개정2( 문서코드와일자확인개정) WG 7 N 년 11월 6일 WD1(Working Draft 1) WG 7 N 년 11월 6일 WD2(Working Draft 2) WG 7 N 년 7월 5일 Pre-WD3(Pre-Working Draft 3) WG 7 N 년 9월 6일 WD3(Working Draft 3) WG7 N 년 2월 16일 WD4(Working Draft 4) WG7 N 년 4월 30일 WD5(Working Draft 5) WG7 N 년 7월 8일 CD1(Committee Draft 1) WG7 N 년 1월 21일 CD2(Committee Draft 2) WG7 N 년 9월 1일 CD3(Committee Draft 3) 초안 1 WG7 N 년 1월 9일 CD3(Committee Draft 3) 최종 WG7 N 년 6월 25일 HoD 검토를위한 FCD(Final Committee Draft) 초안1 WG7 N 년 7월 22일 FCD(Final Committee Draft) ISO/IEC 15288: 년 11 월 01 일 First edition 발표 표준적용분야 ISO/IEC 의목적은시스템의수명주기와잘정립된프로세스들그리고관련용 어에대한공통된체계를정립하는것이다. 이들프로세스는시스템수명주기의각단계를 관리하고수행하기위해전체시스템수명주기동안적용될수있으며, 이는고객만족달성 이라는궁극적목표를갖는모든관련부문의참여를통해이루어진다. 또한표준에서는조 직이나프로젝트에서사용되는수명주기프로세스의정의, 관리및개선을지원하기위한 프로세스를함께제공하며, 조직이나프로젝트는시스템을획득하거나공급하고자할때이 체계를활용할수있다. 이표준에서의시스템은하나이상의하드웨어, 소프트웨어, 관련 프로세스, 절차, 설비그리고자연적으로발생하는개체등으로구성된모든시스템을대상 으로한다. ISO/IEC 이적용가능한대표적인산업영역으로는다음을꼽을수있다. - 항공우주 (Aerospace) - 통신(Telecommunications)

37 - 수송시스템 (Transportation systems) - 국방시스템 (Military systems) - 조선(Ship building) - 경제및행정시스템(Finance and Administrative systems) - 정보기술시스템(Information Technology systems) 표준의구성및프로세스 표준의구성 본표준의구성은총 6장과 4 개의부록으로구성되어있다. 1장에서 4장까지는표준에 대한범위, 목적, 적용, 제한사항및용어등에대해서기술하고있으며, 5장에서는 25개의 시스템수명주기프로세스, 123개의프로세스성과및 208개의활동에대해서기술하고 있다. 마지막으로 6 장에서는시스템수명주기의단계에대하서기술하고있다. 부록에서는 프로세스조정(Tailoring), 수명주기단계, 소프트웨어수명주기표준인 ISO/IEC 과의관계를설명하고있으며, 마지막으로시스템및구조에대한설명을기술하고있다 표준프로세스 시스템생명주기프로세스전체구성 수명주기프로세스들은다음그림과같이계약(Agreement) 프로세스, 전사 (Enterprise) 프로세스, 프로젝트 (Project) 프로세스, 기술(Technical) 프로세스의 4가 지프로세스그룹으로구성된다. 각생명주기프로세스는수명주기어느때에나요구될경 우시작될수있으며, 그사용에있어명확한순서없다. 또한특정수명주기프로세스가 다른수명주기프로세스와동시에실행될수도있으며특정수명주기프로세스가시스템구 조의계층적재현시특정레벨에적용가능하다. 시스템수명주기프로세스에대한설명에 서프로세스가표시되고프로세스그룹이사용된순서가시스템수명주기에서프로세스활 용의연속에서특정한우선순위를의미하지는않으며프로세스그룹은표준에사용된기본 개념들을반영한다

38 기업프로세스 Enterprise Environment Management Investment Management System Life Cycle Processes Management Resource Management Quality Management 계약체결프로세스 Acquisition Supply 프로젝트프로세스 Project Planning Project Assessment Project Control Decision Making Risk Management Configuration Management Information Management 기술프로세스 Stakeholder Requirements Definition Requirements Analysis Architectural Design Implementation Integration Verification Transition Validation Operation Maintenance Disposal < 그림 4-1> ISO/IEC 표준프로세스구조 계약 (Agreement) 프로세스 프로세스들은획득자와공급자 조직사이의계약을체결하는데반드시필요한활동들 을정의하며, 계약프로세스는획득프로세스, 공급프로세스, 시스템수명주기프로세스 관리프로세스, 자원관리프로세스, 품질관리프로세스들로구성된다. 전사 (Enterprise) 프로세스 시스템제품또는서비스를획득하고공급하는전사프로세스는프로젝트의개시, 지원, 제어를통해조직의성능을관리하는것으로, 프로젝트를지원하고조직의목표와수립된 계약체결의충족을보장하는데반드시필요한자원과인프라를제공한다. 전사프로세스는 전사환경관리프로세스, 투자관리프로세스, 시스템수명주기프로세스관리프로세스, 자원관리프로세스, 품질관리프로세스들로구성된다. 프로젝트 (Project) 프로세스 프로젝트프로세스는프로젝트계획을수립및발전시키고, 계획에대한실제성과와진행을평가하고충족될때까지프로젝트의실행을제어하는데사용된다. 개별프로젝트프로세스는프로젝트계획또는예측하지못한사건에서필요한경우수명주기내에서언제든지프로젝트의계층구조의어떠한수준으로도시작하며, 프로젝트의위험요소와복잡성에따라엄격함과형식성의수준과함께프로젝트프로세스에적용된다. 프로젝트프로세스는

39 프로젝트계획프로세스, 프로젝트평가프로세스, 프로젝트통제프로세스, 의사결정프로 세스, 위험관리프로세스, 형상관리프로세스, 정보관리프로세스들로구성된다. 기술 (Technical) 프로세스 기술프로세스는시스템에대한요구를정의하고그요구를효과적인제품으로전환하고 제품의일관된재생산을가능하게하고, 필요할경우에, 제품을사용하고요구되는서비스 를제공하고, 이러한서비스의공급을유지하고, 제품이서비스로부터폐기된경우그제품 을폐기하기위해사용된다. 또한사업과프로젝트기능이시스템이익을최적화시키고기 술적의사결정과활동의의해발생하는시스템위험요소를감소시킬수있도록해주는활 동들을정의하며, 이러한활동들은제품과서비스가적시성과가용성, 비용효율성, 기능성, 신뢰성, 사용가능성, 그리고획득및공급조직들에의해요구되는다른품질들을포함하 고, 제품과서비스가보건, 안전성, 보안성, 환경요소들을포함하는사회의기대또는규정 된요구사항과일치하도록지원한다. 기술프로세스는이해관계자요구사항정의프로세스, 요구사항분석프로세스, 아키텍처설계프로세스, 실행프로세스, 통합프로세스, 검증프 로세스, 전환프로세스, 확인프로세스, 운영프로세스, 유지보수프로세스, 폐기프로세스 들로구성되어있다. 부록 ISO/IEC 부록은총 A-D까지총 4 개로구성되어있다. 구성은조정프로세스, 수명주기단계, ISO/IEC 과의관계그리고시스템개념을다루고있다. 각부록의 내용을주요내용을간단하게요약하면아래와같다. 부록 A : 조정프로세스 (Tailoring Process) 조정프로세스는수명주기모델이단계와단계가시스템구축에기여하는것의형태로정 의되며, 제품또는서비스공급을위한계약체결이행에영향을주는개별수명주기단계가 기술되고, 변경또는신규시스템수명주기프로세스가정의된다. 부록B : 수명주기단계 수명주기모델링에사용되는시스템수명주기프로세스내하부구조를구축하는데사용된 며개념설계단계 (Concept Stage), 개발단계 (Development Stage), 생산단계 (Production Stage), 운용단계 (Utilization Stage), 운용지원단계 (Support Stage), 폐기단계 (Retirement Stage) 등 6 단계로구성되어있다

40 프로젝트프로세스 Project Planning Project Assessment Project Control Decision Making Risk Management Configuration Management Information Management Stakeholder Requirements Definition Requirements Analysis Architectural Design 기술프로세스 Implementation Validation Transition Verification Integration Operation Maintenance Disposal Hardware Fabrication Software Creation Refer to ISO/IEC 12208:1995/AMD,1:2002 Operator Training 기업프로세스 Enterprise Environment Management Investment Management System Life Cycle Processes Management Resource Management Quality Management 계약체결프로세스 Acquisition Supply < 그림 4-2> ISO/IEC 과 의관계 부록 C : ISO/IEC 과 의관계 시스템수명주기를구축하고있는 ISO/IEC 을설명하고있다. 시스템요소가 개발될때시스템요소의특성에대응되도록적절한표준이적용된다. SW에서구현되는시 스템요소는 ISO/IEC 12207:1995/AMD.1:2002 의프로세스가적용된다. ISO/IEC 15288:2002 최종발표표준에서는삭제되었으나 2001 년도 FCD(Final Committee Draft) 에는다음과같이 과의프로세스수준이비교되어있다. < 표 4-2> ISO/IEC 과 의관계 ISO/IEC ISO/IEC 12207:1995/AMD.1:2002 Enterprise Environment Management Process Investment Management Process System Life Cycle Process Management Process Management Process, Improvement Process Infrastructure Process Supply Process System Life Cycle Process Management Process, Enterprise Environment Process Management Process, Improvement Process Acquisition Process Stakeholder Requirement Definition Process Supply Process Risk Management Process Information Management Process Requirement Analysis Process Architectural Design Process Implementation Process Integration Process Transition Process Transition Process Operation Process Maintenance Process Acquisition Process Development Process, Usability Process Supply Process Acquisition Process, Asset Management Process Documentation Process, Asset Management Process Development Process Development Process, Usability Process Development Process Development Process Development Process Training Process Operation Process Maintenance Process

41 ISO/IEC ISO/IEC 12207:1995/AMD.1:2002 Disposal Process Configuration Management Process Project Assessment Process Quality Management Process Verification Process Validation Process Project Assessment Process Enterprise Environment Management Process Project Assessment Process Decision Making Process Project Assessment Process Project Planning Process Project Assessment Process Project Control Process Resource Management Process Resource Management Process Implementation Tailoring Process Maintenance Process Configuration Management Process Quality Assurance Process Management Process Verification Process Validation Process, Usability Process Joint Review Process Audit Process Audit Process Problem Resolution Process, Development Process, Reuse Program Management Process Product Evaluation Process Management Process, Supply Process, Development Process Management Process Management Process, Problem Resolution Process Infrastructure Process Human Resource Management Process Domain Engineering Tailoring Process 부록 D : 시스템개념, 수명주기개념에대한기술 < 표 4-3> 단계, 단계의목적및중요결정게이트 수명주기단계개념설계단계개발단계생산단계활용단계지원단계폐기단계 목적이해당사자요구사항식별개념탐색실행가능한해결책제안시스템요구조건상세기술해결책기술서작성시스템축조시스템요건검증및요구검증시스템생산검사및시험평가사용자요구사항을만족하는시스템운영지속적인시스템능력제공시스템의보관문서화 또는폐기 결정게이트 - 결정대안 - 다음단계실행 현단계지속 전단계로복귀 프로젝트활동보류 프로젝트종료 4.2 ISO/IEC TR 시스템공학-ISO/IEC 적용가이드 목적 이기술보고서는 ISO/IEC 시스템수명주기프로세스표준( 이후부터는국제표 준이라한다) 의실행을위한가이드라인을제공한다. 대형및소형시스템, 대형및소형

42 프로젝트팀을필요로하는시스템, 그리고신규또는기존시스템에적용이가능하다. 본 가이드에포함된지침들은국제표준의부록 A와본기술보고서 4절의지침을이용하여시 스템크기, 프로젝트인력, 그리고시스템형태에알맞게조정될수있다. ISO/IEC TR 은국제표준의실행을지원하는 ISO 문서뿐만아니라국제표준의실행효율성을평 가하기위한 ISO 문서들과의링크를제공한다. ISO/IEC TR 은국제표준을실행할때고려될수있는요소들을상세히설명하 고있다. 또한설명은국제표준이적용될수있는다양하고이해하기쉬운방법들을통하여 이루어진다 ISO/IEC TR 사용전숙지사항 ISO/IEC TR 을적용하기위해서는사용자가 ISO/IEC 의가용성, ISO/IEC 에대한친숙성, 관련조직및프로젝트정책에대한친숙성, 프로젝트관 리및시스템공학, 시스템라이프사이클모델에대한일반적이해등과같은조건을구비 하고있어야한다 기술보고서추진경과 < 표 4-4> 기술보고서추진경과 문서코드 일자 설명 WG 7 N 년 9월 1일 WD1 (Working Draft 1) WG 7 N 년 1월 10일 WD2 (Working Draft 2) WG 7 N 년 8월 6일 WD3 (Working Draft 3) WG 7 N 년 1월 1일 PDTR (Proposed Draft TR) WG 7 N 년 1월 11일 PDTR (Proposed Draft TR) ISO/IEC TR System engineering- A guide for application of 2003 년 11 월 15 일 19760:2003 ISO/IEC 15288(System life cycle processes) ISO/IEC TR 의구성 구성 ISO/IEC TR 시스템공학 표준적용을위한가이드(System engineering-a guide for the application of ISO/IEC 15288) 는 2003 년 11월 15 일에발표되었다. 총 8 장으로구성되어있으며, 1장에서 3장까지는본기술보고서의범

43 위와목적, 참고문헌및표준들의전후관계를기술하고있다. 4장에서는 표준사용을위한사용개념및프로세스에대한조정을다루고있으 며, 5 장에서는시스템, 프로젝트, 시스템수명주기의개념을설명함으로써전반적인표준의 개념을설명하고있다. 6장과 7장에서는수명주기에따른국제표준프로세스의적용에대 해기술하고있다. 마지막으로 8 장에서는조직에의한적용을다룬다. 부록은 3개로구성되 어있으며, 본표준과다른표준과의관계, 시스템설계에영향을주는요인, 표준프로세스 적용을위한요지를기술하고있다 주요내용 본기술보고서는각조직의업무특성, 업무전략, 그리고제품또는서비스를위한가 용기술들에의해운영된다. 이들변수들은활용가능한사업기회들에제약요소들을제공 한다. 기회를활용하기위해조직은조직프로젝트의수행과직무상의조직관리를위한정 책과프로세스를수립한다. 이러한정책과프로세스들의수립을지원하고조직이필요로하 는자원들을결정하기위해조직의특정표준화프로세스와하나이상의라이프사이클모 델들을제공할목적으로국제표준을사용할수있다. 조직 Social Responsibilities Business strategy 사업의특성 Domain of products Regulatory considerations 제약사항 ISO/IEC ISO/IEC 시스템시스템수명주기수명주기프로세스프로세스단계단계 범위조정 기업 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> 국제표준의사용개념

44 - 40 -

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

46 - 42 -

47 5. 시스템수명주기프로세스프레임워크설계 5.1 시스템수명주기프로세스프레임워크 프레임워크설계방안 시스템수명주기프로세스프레임워크의내용은기본적으로가장최근의국제표준인 ISO/IEC 의내용을기반으로작성하였다. 2002년에공표된시스템공학-시스템 수명주기프로세스구성은총 6장과 4 개의부록으로구성되어있다. 1장에서 4장까지는 표준에대한범위, 목적, 적용, 제한사항및용어등에대해서기술하고있으며, 5장에서 는 25 개의시스템수명주기프로세스, 123 개의프로세스성과(outcome) 및 205개의활 동에대해서기술하고있다. 하지만 ISO/IEC 은해당하는프로세스의목적, 활동, 성과를서술식으로기술함 에따라기본적인시스템수명주기의내용과구성을제시하기위한프레임워크성격에맞 지않는부분이있으며, 사용하는용어또한 ISO/IEC 또는 IEEE 에서 사용하고있는용어와달라우리나라에서그대로번역하여사용하는데어려움이있다. 따라서본프레임워크에서는프로세스의구성을목적, 활동, 산출물로하면서내용을최 대한간략하게구성하고자하였다. 목적부분은전체의내용을간략하게기술하고, 활동부 분의경우는최대한명사형태로간략하게작성하여기존발주관리표준프로세스와동일 한형태의활동을갖도록하였다. 산출물은현재성과형태로서술식으로기술하고있는 내용을본문의내용을기초로산출물로제시하였다. 산출물에대한제시는 ISO/IEC 표준본문에서기술하고있는내용과더불어소프트웨어공학프로세스테크놀로 지(Software Engineering Process Technology, SEPT) 에서출판한 시스템문서 관리계획을위한템플릿 (Template For a System Documentation Management Plan) 에서기술하고있는산출물을전부수용하였고, 공공부분발주관리표준프로세스 지침을만들면서얻은경험을토대로하여각프로세스와활동에필요한추가적인산출물 들을제시하였다. 시스템수명주기프로세스프레임워크설계의기본원칙을다시한번요 약하면다음과같다. ISO/IEC 의프로세스및활동을전부수용함

48 음. ISO/IEC 의성과(outcome) 를성과의취지를고려하여산출물로대체하였 산출물은 Template For a System Documentation Management Plan의산 출물을전부수용하고각프로세스와할동에필요한추가산출물제시하였음. 부록에다음과같은사항들을추가하였음. - 프로세스 / 활동-산출물매트릭스 산출물의목적을설명하는산출물기술서추가 산출물을작성하기위한문서작성절차 시스템수명주기프로세스와발주관리프로세스의연계방안 < 표 5-1>> 시스템수명주기프로세스프레임워크설계방안

49 프레임워크구성 1 장배경 2 장개요 3 장참조문서 4 장용어 5 장시스템수명주기프로세스프레임워크 부록 A 목적 활동 산출물 수명주기단계 부록 B 프로세스별활동- 산출물매트릭스 부록 부록 C D 산출물기술서 문서작성절차 참조문서 - ISO/IEC 장~4장 - 공공부문소프트웨어발주관리표준프로세스지침, ISO/IEC 장(P.5 ~ P.39) - ISO/IEC 장 Purpose - ISO/IEC 장 Activities - Template For a System Documentation Management Plan, SEPT, ISO/IEC Annex D D.2 Life Cycle Concepts(P.56) - ISO/IEC TR Approaches(P.34) - Template For a System Documentation Management Plan, SEPT, Evidence Product Checklist for ISO/IEC Standard System Engineering-System Life Cycle Process, SEPT, Template For a System Documentation Management Plan, SEPT, Evidence Product Checklist for ISO/IEC Standard System Engineering-System Life Cycle Process, SEPT, Template For a System Documentation Management Plan, SEPT, 2004 부록 E - New Work Item Proposal-Revision of ISO/IEC 시스템수명주기표준 Systems and Software Engineering-Software 프로세스와 발주관리 Life Cycle Processes, ISO/IEC JTC1/SC7, 2005 표준프로세스연계 - 공공부문소프트웨어발주관리표준프로세스지침, 프레임워크수준및구성 본시스템수명주기프로세스프레임워크의구성은총 5장과 5개의부록으로구성되어있 다. 1장에서 4 장까지는표준에대한범위, 목적, 적용, 제한사항및용어등에대해서기술 하고있으며, 5장에서는 25 개의시스템수명주기프로세스, 205개의활동및 166개의산 출물을기술하고있다. 부록에서는수명주기단계(Life Cycle Stages), 산출물, 문서작성 절차, 시스템수명주기표준프로세스와발주관리표준프로세스비교및시스템수명주기 표준과발주관리표준과의활용방안에대해서기술하고있다

50 < 표 5-2> 시스템수명주기프로세스구성 프로세스그룹 프로세스 활동 산출물 계약 구분 전사 프로젝트 기술 합계 4개 25개 205개

51 5.1.3 프레임워크프로세스연관관계 프로세스간의연관관계는 4 개의계약, 전사, 프로젝트, 기술로프로세스그룹을중심으로 하여상호간에요구되는인터페이스사항을보여준다. 본프레임워크에서는 ISO/IEC 의기술프로세스를개발프로세스와운영/ 유지보수프로세스로구분하였다. 그림에 서와같이주로개발프로세스산출물내지는결과를바탕으로프로젝트프로세스에서개발 프로세스를관리를하며, 전사프로세스를통해시스템수명주기프로세스의정책또는절 차를정의한다. 5.2 계약프로세스 5.5 기술프로세스 승인된 산출물 획득프로세스획득요구 / 계약공급 / 산출물타당한솔루션공급프로세스요구사항 5.4 프로젝트프로세스작업지시프로젝트계획프로세스계획갱신계획 / 요구사항 개발프로세스이해당사자요구사항정의프로세스요구사항분석프로세스아키텍처설계프로세스 프로젝트통제프로세스 대안제공 구현프로세스 프로젝트의사결정프로세스 통합프로세스 정책 / 절차 위험관리프로세스 재지시 검증프로세스 형상관리프로세스 전환프로세스 지원 / 보고 / 검토 프로젝트평가프로세스 5.3 전사프로세스 평가 전사환경관리프로세스 투자관리프로세스 시스템수명주기프로세스관리프로세스 자원관리프로세스 작업산출물 확인프로세스운영 / 유지보수프로세스운영프로세스유지보수프로세스폐기프로세스 품질관리프로세스 < 그림 5-1> 시스템수명주기프로세스연관관계

52 5.1.4 프로세스활동구성 아래의프로세스활동구성도는 ISO/IEC 에서술식으로기술되어있는활동 (Activity) 을명칭화하여도식한것이다. ISO/IEC 의프로세스와활동을기술한 형식으로으로표현함으로써전체적인프로세스와활동을보다쉽게파악할수있으며, 다 른표준과의구성및내용을비교할수있도록하였다. 5.3 전사프로세스 전사환경관리프로세스사업분야계획수립수명주기정책 / 절차를준비역할 / 책임 / 권한정의사업기준을정의수명주기모델의주기적검토정책 / 절차공유 자원관리프로세스자원지원항목결정 / 제공인적요소외자원확보인력유지 / 관리참여인력동기부여다수프로젝트의관리인터페이스통제 5.4 프로젝트프로세스 프로젝트계획프로세스프로젝트목표 / 제약사항식별책임 / 권한구조수립프로젝트범위정의인프라 / 서비스정의과업분할구조 (WBS) 작성외부프로젝트와연계한획득정의프로젝트일정정의 / 유지기술관리계획수립 / 시행프로젝트성과척도정의성과척도 / 연관자료정의프로젝트비용정의및예산계획프로젝트품질계획수립프로젝트평가프로세스 시스템수명주기프로세스관리프로세스시스템수명주기프로세스수립테일러링정책 / 절차수립 품질관리프로세스품질관리정책 / 표준 / 절차수립품질관리목적 / 목표수립 프로젝트상태평가품질보증수행프로젝트팀평가지원인프라적정성 / 가용성평가 프로젝트진척평가관리및기술적검토 / 신기술관찰데인터분석및권고주기적보고서제공 방법 / 도구식별평가척도수립프로세스실행관찰프로세스개선기회식별프로세스 / 방법 / 도구개선 책임권한정의고객만족 / 결과보고서평가주기적품질계획검토품질개선상태관찰 프로젝트통제프로세스요구및변경사항관리교정활동수행예방활동수행 변화관리계약변경활동수행계약교정활동수행 문제해결활동수행 프로젝트승인 의사결정프로세스 의사결정전략정의 대안활동결과평가 투자관리프로세스 의사결정과정참여 결과기록 / 추적 / 평가 / 보고 투자계획수립 보고 / 검토회일정명시 환경 / 요구사항식별 처리결과기록유지 프로젝트책임 / 권한정의 프로젝트평가 의사결정전략선정및성공척도식별 예측산출물식별자원할당프로젝트인터페이스식별 프로젝트조정프로젝트지연 / 취소 위험관리프로세스위험접근방법수립위험식별 / 정의 위험취급전략결정위험수용한계정의 위험확률결정 위험취급활동식별 위험평가 위험관련의사소통 위험우선순위부여 위험기록유지 5.2 계약프로세스 형상관리프로세스형상관리전략정의형상통제항목식별 < 그림 5-2> 프로세스활동구성

53 5.2 시스템수명주기프로세스와발주관리지침연계방안 ISO/IEC 과 ISO/IEC 통합방안제안분석 본연구에서제안한시스템수명주기프로세스와공공부분 S/W 방안에관련하여과제수행기간동안다양한접근을시도했다. 발주관리지침과의연계 그중에서도캐나다에서 ISO/IEC 과 ISO/IEC 을통합하기위해제안한방법을벤치마킹하여적용 하려는시도를해보았다. 이제안에서는 ISO/IEC 15288과 ISO/IEC 12207이사용하는용어와기술하는상 세화정도(Level) 가서로상이하여이를함께이용하는데많은문제가있음을인식하고, 공통용어사용, 이용가능한공통프로세스이름사용, AMD 통합등을통해 15288:2002 및 12207:1995 를연계및통합함으로써수명주기전반에걸친호환성과 일관성을유지하며최대한일관성있는용어와개념을사용하도록하였다. 약하면다음과같다. 현재표준인 이를간단히요 AMD, 12207:1995, 15288:2003 과제안한 12207R, 15288R 과의관계는아래그림과같다. < 그림 5-3> 표준과제안방법과의비교

54 12207 AMD에서프로세스는 12207:1995 의프로세스와같고, 이는 12207R 에그대 로반영되고각프로세스의목적과결과물또한 12207R 에반영된다 AMD의컴 포넌트프로세스는 12207:1995 의활동과같고이는 12207R 의컴포넌트일부프로세스 와일부활동에반영된다 AMD의컴포넌트프로세스의일부목적은 12207R 의 컴포넌트프로세스의목적이되며나머지다른목적과결과물은 12207R 의 PRM 부록에 반영된다 :1995 의작업은 12207R 의작업에반영되며 12207:1995 의리스트는 12207R 의노트에반영된다 :2003 의프로세스와각프로세스의목적과결과는 15288R 의프로세스및목적 과결과에반영되고 PRM 부록의목적과결과물에도반영된다 R 에는활동이라는 상세화정도레벨이프로세스아래에추가된다. 이는 과상세화를정도를맞추기위 해추가시킨것이다 :2003 의활동과노트는각각 15288R 의작업과노트에그대 로반영된다 시스템수명주기프로세스와발주관리지침연계방안 캐나다에서제안한방법대로시스템수명주기프로세스와발주관리지침을연계하기위해 서는다음과같은제한점이있다. 첫째는 ISO/IEC 을그대로가감없이수용하는 것을기본원칙으로했다. 그러므로시스템수명주기프로세스를기반으로발주관리지침을 용어의통일프로세스, 활동등의조화를통한접근을시도할경우는기존에개발된발주관 리지침의많은변경이요구된다. 이방법은현재시점에서불가능하다는결론에도달했다. 두번째로는발주관리지침을기반으로시스템수명주기프로세스를통합시키는방안이있울 수있다. 이방법은발주관리지침을수정없이활용할수는있으나 ISO/IEC 을그 대로수용한다는기본원칙에위배된다. 그러므로본연구에서는다음그림과같이시스템 수명주기프로세스를 ISP/IEC 기반으로그대로사용하면서소프트웨어개발부분 을발주관리지침의 S/W 요구사항분석, S/W 구조설계, S/W 상세설계, S/W 코딩및단 위시험, S/W 통합, S/W 자격시험부분만을활용하는방향으로결론을맺었다. 이방법이 국제표준을그대로수용하면서발주관리지침을활용할수있는현재시점에서의최적대안 이라는것이본연구수행팀의제안이다

55 개념단계 개발단계 생산단계 운용 전사프로세스그룹 프로세스 시스템수명주기 계약프로세스그룹이해당사자요구사항아키텍처요구사항정의분석설계 개발프로세스 구현 프로젝트프로세스그룹 기술프로세스그룹 통합 검증 전환 확인 운영 발주관리프로세스 소프트웨어 S/W 요구사항분석 S/W 구조설계 S/W 상세설계 S/W 코딩및단위시험 S/W 통합 S/W 자격시험 < 그림 5-4> 시스템수명주기프로세스와발주관리지침연계방안 참고문헌

56 - 52 -

57 6. 참고문헌 ISO/IEC Systems engineering-system life cycle processes : INTERNATIONAL STANDARD, ISO/IEC TR Systems engineering - A guide for the application of ISO/IEC 15288(System life cycle processes), ISO/IEC 12207:1995/AMD1:2002 Amendment to ISO/IEC 12207:1995/AMD2:2004 Amendment to MIL-STD-499A(USAF) MILITARY STANDARD Engineering Management, IEEE 1220 Standard for Application and Management of the Systems Engineering Process, EIA-632 Processing for Engineering a System, 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 Integrated Logistics Support Guide, DSMC, Fort Belvoir, VA

58 Risk Management; Concepts and Guidance, DSMC, Fort Belvoir, VA ANSI/AIAA G , Guide for the Preparation of Operational Concept Documents MIL-STD-498, "Software Development and Documentation", December IEEE/EIA , "Software Life Cycle Processes", March IEEE/EIA , "Software Life Cycle Processes - Life Cycle Data", April IEEE/EIA , "Software Life Cycle Processes - Implementation Considerations", April

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

60 - 56 -

61 부록 A 시스템수명주기프로세스프레임워크 1. 배경 1.1 현실태및문제점 2002 년부터정통부에서는소프트웨어수명주기인 ISO/IEC 을기반으로국내현 실에적합한공공기관발주관리지침을개발하여정통부에서제도화하려는시도중에있다. 이와더불어소프트웨어가단독으로동작하는관점에서벗어나시스템차원에서의소프트웨 어작동을포함하는시스템공학의중요성이대두되어현재국제표준인 ISO/IEC 을기반으로국내현실에맞는시스템공학수명주기의프레임워크를개발하려하고있다. 이보고서는그러한연구의일환으로시스템공학의개념을정의하고기존의관련시스템 공학표준들을분석한후, 최근의 ISO/IEC 을기반으로국내환경에적합한시스 템공학프레임워크를개발하는데그목적이있다. 금년프레임워크가확정되면지속적으로 프레임워크를실현할수있는후속지침의개발이필요할것이다. 또한 ISO/IEC 을 기반으로개발된공공기관발주관리지침과의연계로효과적이고효율적인시스템획득을 지원하는프레임워크의개발을염두에두고있다. 1.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 System Engineering-A guide for the application of ISO/IEC 을발행하였다. 이처럼시스템수명주기표준이공식적으로발표되고활용되기시작한것은불과 2~3년 에불과하다. 따라서실제본표준에서제시하고있는시스템수명주기의단계와프로세스 들을활용하여해당되는관리분야또는프로젝트에적용하고그효과를나타내기에는아직

62 시기상조이다. 반면에 1996 년부터시스템수명주기프로세스에대한논의가항공및우주 산업, 군수산업과같은거대시스템기업들이시스템수명주기에관심을갖고참여하였고, 미국의국제시스템공학협의회 (INCOSE, International Council on System Engineering) 및미표준기구인 IEEE Computer Society(CS) 에서도적극적으로참여 하여의견을반영함으로써활용성에대한기대는높다고할수있다. ISO/IEC 의활용현황은본표준이시스템및소프트웨어공학분야의다양한 국제표준에있어서하위또는특정분야의표준들에대해기본적인상위표준 (Principle Standard) 이고공식적인표준이발행되고적용하는기간이짧아서표준적용에대한효과 측정은어렵다고볼수있다. 2. 개요 2.1 목적 본표준은사람이만드는시스템의수명주기를기술하는데사용되는보편적틀을구축하 고있다. 본표준은시스템수명주기와관련된프로세스집합과그와관련된용어를정의하 고있다. 프로세스는시스템구조계층내어떤수준에서도적용될수있다. 프로세스의선 택된집합은시스템수명주기단계를관리하고실행하는데수명주기동안계속사용될수 있다. 이는고객만족달성의궁극적목적을갖고있는모든이해당사자참여를통하여완수 된다. 본표준은조직또는프로젝트내에서활용되는수명주기프로세스의정의, 통제및개선 을지원하는프로세스를제공한다. 조직과프로젝트가시스템을획득하거나공급할때본 표준이정한수명주기프로세스를활용할수있다. 2.2 적용 본표준은시스템의개념설계, 개발, 생산, 활용, 지원및폐기를포함한시스템수명주기 모든과정에적용되고, 조직내부또는외부에서완성되는시스템의획득과공급에도적용 된다. 본표준의수명주기프로세스는시스템과그구성요소에대하여동시적이며반복적이 고순환적으로적용될수있다. 시스템의목적, 응용영역, 복잡성, 규모, 신규성, 적응성, 양, 위치, 수명기간및진화등

63 때문에시스템의광범위한다양성이존재한다. 본표준은모든인위적시스템의수명주기를 구성하는프로세스를기술하고있다. 그러므로본표준은특정시스템의하나, 대량생산시 스템및개조, 적응형시스템에적용된다. 본표준은시스템획득자과공급자모두의역할을하는조직에대하여도적용된다. 여기 에는자기스스로 책임과의무를부과한단일이해당사자또는다수이해당사자의상황에 도적용될수있다. 이해당사자는같은조직또는다른조직일수도있으며, 그와같은상 황은비공식적계약체결에서부터공식적계약체결에까지광범위하다. 본표준이정한프로세스는비즈니스환경, 즉방법, 기법, 도구, 훈련된전문인력구축의 기초로활용될수있다. 이는프로세스의성공적실행의결과로발생되는프로세스성과와 프로세스목적으로특징지워지는프로세스기준모델을제공한다. 그러므로본표준은 ISO/IEC TR 에서규정한지원프로세스평가의기준모델로활용될수있다. 또한국제표준은다음형태중의하나또는그이상의방법으로활용되어질수있다. - 조직에의한활용 : 바람직한프로세스환경을구축하는데도움을준다. 조직에의하여 활용되는프로세스는방법, 절차, 기법, 도구및훈련된전문가의하부구조에의하여지 원될수있다. 조직은프로젝트를실행하고관리하며, 수명주기단계를통하여시스템을 발전시키는데하부구조환경을사용할수있다. 국제표준은국제표준조건대비공표되 고구축된환경의적합성을평가하는데사용된다. - 프로젝트에의한활용 : 제품과서비스를제공하기위하여구축된환경의요소를선정하 고구조화하고활용하는데도움을준다. 국제표준은공표되고구축된환경대비프로젝 트적합성평가에사용된다. - 획득자및공급자에의한활용 : 프로세스및업무활동과관계된계약을이끌어내는데 도움을준다. 계약을통해서국제표준에있는프로세스와업무활동이선택되고협상되 며합의되며실행된다. 국제표준은계약을하는데있어서지침서로사용된다. 3. 참조문서 ISO/IEC Systems engineering-system life cycle processes : INTERNATIONAL STANDARD, ISO/IEC TR Systems engineering - A guide for the application of ISO/IEC 15288(System life cycle processes), ISO/IEC 12207:1995/AMD1:2002 Amendment to ISO/IEC 12207:1995/AMD2:2004 Amendment to

64 MIL-STD-499A(USAF) MILITARY STANDARD Engineering Management, IEEE 1220 Standard for Application and Management of the Systems Engineering Process, EIA-632 Processing for Engineering a System, 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 Integrated Logistics Support Guide, DSMC, Fort Belvoir, VA Risk Management; Concepts and Guidance, DSMC, Fort Belvoir, VA ANSI/AIAA G , Guide for the Preparation of Operational Concept Documents MIL-STD-498, "Software Development and Documentation", December IEEE/EIA , "Software Life Cycle Processes", March IEEE/EIA , "Software Life Cycle Processes - Life Cycle Data", April IEEE/EIA , "Software Life Cycle Processes - Implementation Considerations", April 용어 부록참조 5. 시스템수명주기프로세스프레임워크

65 5.1 개요 시스템의복잡성이전례없는수준에까지증가하고있다. 이는시스템을만들고이용하 는조직에어려움을가중시키기도하지만새로운기회를부여하기도한다. 특히최근의시 스템은대부분소프트웨어를포함하고있으며심지어시스템구축비용의상당부분을정보 시스템구축에활용하고있다. 이러한측면에서휴먼웨어, 하드웨어, 소프트웨어등을총망 라하는시스템공학의프로세스, 활동및산출물에대한식별은성공적인시스템구축에필 수요소이다. 이에따라시스템수명주기프로세스프레임워크는시스템공학국제표준을기 초로해당하는프로세스를제시하고이에대한이해를돕기위한내용으로구성된다

66 프레임워크구성 1장배경 2장개요 3장참조문서 4장용어 5장시스템수명주기프로세스프레임워크목적 부록 A 수명주기단계 활동 산출물 부록 B 프로세스별활동-산출물 매트릭스 부록 부록 부록 C D 산출물기술서 문서작성절차 참조문서 - ISO/IEC 장~4장 - 공공부문소프트웨어발주관리표준프로세스지침, ISO/IEC 장(P.5 ~ P.39) - ISO/IEC 장 Purpose - ISO/IEC 장 Activities - Template For a System Documentation Management Plan, SEPT, ISO/IEC Annex D D.2 Life Cycle Concepts(P.56) - ISO/IEC TR Approaches(P.34) - Template For a System Documentation Management Plan, SEPT, Evidence Product Checklist for ISO/IEC Standard System Engineering-System Life Cycle Process, SEPT, Template For a System Documentation Management Plan, SEPT, Evidence Product Checklist for ISO/IEC Standard System Engineering-System Life Cycle Process, SEPT, Template For a System Documentation Management Plan, SEPT, New Work Item Proposal-Revision of ISO/IEC Systems and Software E 시스템수명주기표준프로세 Engineering-Software Life Cycle 스와발주관리표준프로세스 Processes, ISO/IEC JTC1/SC7, 2005 연계 - 공공부문소프트웨어발주관리표준프로세스지침, 프레임워크설계방안 시스템수명주기프로세스프레임워크의내용은기본적으로가장최근의국제표준인 ISO/IEC 의내용을기반으로작성하였다. 2002년에공표된시스템공학-시스템 수명주기프로세스구성은총 6장과 4 개의부록으로구성되어있다. 1장에서 4장까지는 표준에대한범위, 목적, 적용, 제한사항및용어등에대해서기술하고있으며, 5장에서 는 25 개의시스템수명주기프로세스, 123개의프로세스성과및 205개의활동에대해

67 서기술하고있다. 하지만 ISO/IEC 은해당하는프로세스의목적, 활동, 성과를서술식으로기술함 에따라기본적인시스템수명주기의내용과구성을제시하기위한프레임워크성격에맞 지않는부분이있으며, 사용하는용어또한 ISO/IEC 또는 IEEE 에서 사용하고있는용어와달라우리나라에서그대로번역하여사용하는데어려움이있다. 따라서본프레임워크에서는프로세스의구성을목적, 활동, 산출물로하면서내용을최 대한간략하게구성하고자한다. 목적부분은전체의내용을간략하게기술하고, 활동부분 의경우는최대한명사형태로간략하게작성하여기존발주관리표준프로세스와동일한 형태의활동을갖도록하였다. 산출물은현재성과형태로서술식으로기술하고있는내용 을본문의내용을기초로산출물로제시하였다. 산출물에대한제시는 ISO/IEC 표준본문에서기술하고있는내용과더불어소프트웨어공학프로세스테크놀로지 (Software Engineering Process Technology, SEPT) 에서출판한 시스템문서 관리계획을위한예시 (Template For a System Documentation Management Plan) 에서기술하고있는산출물의명칭을참고하여작성하였다. 따라서이러한프레임워크설계방안에따라본보고서에서는향후별도의프레임워크분 리를용이하게하기위하여 5.2절에서 5.10절까지의내용을프레임워크에맞게구성하였 다. 특히 ISO/IEC 표준과의호환성을위하여프로세스를기술하는 5.2절부터 5.5 절은표준과동일한프로세스와번호체계를따랐다. 또한 5.6부터 5.10절까지의내용을향 후표준의부록의내용을담았다. < 시스템수명주기프로세스구성 > 구분합계 프로세스그룹 프로세스 활동 산출물 계약 전사 프로젝트 기술 개 25개 205개 프레임워크수준및구성 본표준의구성은총 5장과 5 개의부록으로구성되어있다. 1장에서 4장까지는표준에 대한범위, 목적, 적용, 제한사항및용어등에대해서기술하고있으며, 5장에서는 25개의 시스템수명주기프로세스, 208개의활동및 91 개의프로세스산출물을기술하고있다. 부 록에서는수명주기단계(Life cycle Stages), 프로세스산출물, 문서작성절차, 시스템

68 수명주기표준프로세스와발주관리표준프로세스비교및시스템수명주기표준과발주관 리표준과의활용방안에대해서기술하고있다 프레임워크프로세스연관관계 프로세스간의연관관계는 4 개의계약, 전사, 프로젝트, 기술로프로세스그룹을중심으로 하여상호간에요구되는인터페이스사항을보여준다. 5.2 계약프로세스 5.5 기술프로세스 승인된 산출물 획득프로세스획득요구 / 계약공급 / 산출물타당한솔루션공급프로세스요구사항 5.4 프로젝트프로세스작업지시프로젝트계획프로세스계획갱신계획 / 요구사항 개발프로세스이해당사자요구사항정의프로세스요구사항분석프로세스아키텍처설계프로세스 프로젝트통제프로세스 대안제공 구현프로세스 프로젝트의사결정프로세스 통합프로세스 정책 / 절차 위험관리프로세스 재지시 검증프로세스 형상관리프로세스 전환프로세스 지원 / 보고 / 검토 프로젝트평가프로세스 5.3 전사프로세스 평가 전사환경관리프로세스 투자관리프로세스 시스템수명주기프로세스관리프로세스 자원관리프로세스 작업산출물 확인프로세스운영 / 유지보수프로세스운영프로세스유지보수프로세스폐기프로세스 품질관리프로세스

69 5.1.3 프로세스활동구성 아래의프로세스활동구성도는 ISO/IEC 에서술식으로기술되어있는활동 (Activity) 을명칭화하여도식한것이다. ISO/IEC 의프로세스와활동을기술한 형식으로으로표현함으로써전체적인프로세스와활동을보다쉽게파악할수있으며, 다 른표준과의구성및내용을비교할수있도록하였다. 5.3 전사프로세스 전사환경관리프로세스사업분야계획수립수명주기정책 / 절차를준비역할 / 책임 / 권한정의사업기준을정의수명주기모델의주기적검토정책 / 절차공유 자원관리프로세스자원지원항목결정 / 제공인적요소외자원확보인력유지 / 관리참여인력동기부여다수프로젝트의관리인터페이스통제 5.4 프로젝트프로세스 프로젝트계획프로세스프로젝트목표 / 제약사항식별책임 / 권한구조수립프로젝트범위정의인프라 / 서비스정의과업분할구조 (WBS) 작성외부프로젝트와연계한획득정의프로젝트일정정의 / 유지기술관리계획수립 / 시행프로젝트성과척도정의성과척도 / 연관자료정의프로젝트비용정의및예산계획프로젝트품질계획수립프로젝트평가프로세스 시스템수명주기프로세스관리프로세스시스템수명주기프로세스수립테일러링정책 / 절차수립 품질관리프로세스품질관리정책 / 표준 / 절차수립품질관리목적 / 목표수립 프로젝트상태평가품질보증수행프로젝트팀평가지원인프라적정성 / 가용성평가 프로젝트진척평가관리및기술적검토 / 신기술관찰데인터분석및권고주기적보고서제공 방법 / 도구식별평가척도수립프로세스실행관찰프로세스개선기회식별프로세스 / 방법 / 도구개선 책임권한정의고객만족 / 결과보고서평가주기적품질계획검토품질개선상태관찰 프로젝트통제프로세스요구및변경사항관리교정활동수행예방활동수행 변화관리계약변경활동수행계약교정활동수행 문제해결활동수행 프로젝트승인 의사결정프로세스 의사결정전략정의 대안활동결과평가 투자관리프로세스 의사결정과정참여 결과기록 / 추적 / 평가 / 보고 투자계획수립 보고 / 검토회일정명시 환경 / 요구사항식별 처리결과기록유지 프로젝트책임 / 권한정의 프로젝트평가 의사결정전략선정및성공척도식별 예측산출물식별자원할당프로젝트인터페이스식별 프로젝트조정프로젝트지연 / 취소 위험관리프로세스위험접근방법수립위험식별 / 정의 위험취급전략결정위험수용한계정의 위험확률결정 위험취급활동식별 위험평가 위험관련의사소통 위험우선순위부여 위험기록유지 5.2 계약프로세스 형상관리프로세스형상관리전략정의형상통제항목식별

70 5.2 계약프로세스 개요 내/ 외부조직의계약을체결하기위한요구사항을기술하며다음과같은프로세스로구성 된다. a) b) 획득프로세스 공급프로세스 획득프로세스 목적 획득프로세스의목적은획득자의요구사항에부합하는제품또는서비스를확보하는것 이다. a) b) c) d) e) f) g) h) 활동 획득계획수립 요구사항준비 공급자와의사소통 공급자선정 공급자와계약협상 계약이행평가 최종산출물확인 대금지급 산출물 a) 획득계획서 b) 대금지급계획서 c) 공급자성과관리계획서 d) 시스템인수계획서 e) 계약서 f) 시스템인수전략계획서

71 g) 요구사항정의서 h) 제안요청서 i) 고객- 공급자합의서 j) 획득전략서 k) 공급자선정계획서 l) 협약서(charter) m) 합의서(correspondence) 공급프로세스 목적공급프로세스의목적은획득자에게합의된요건을만족하는제품또는서비스를제공것이다 활동 a) 획득자식별 b) 요구사항평가 c) 요청사항대응책준비 d) 계약협의 e) 계약체결 f) 계약이행결과평가 g) 최종산출물인도 h) 대금수령및통보 i) 최종산출물책임이관 산출물 a) 제안서 b) 계약서 c) d) e) f) g) 사업수행계획서 시스템개발계획서 인수확인서 검증결과보고서 확인결과보고서 h) 품질관리결과보고서

72 i) 합동고객공급자감리검토계획서 j) 협력업체관리계획서 k) 요청응답서 5.3 전사프로세스 개요 전사프로세스는프로젝트착수, 지원및통제를통하여제품또는서비스를획득하고공급하기위한조직의능력을관리하며다음과같은프로세스로구성된다. a) b) c) d) e) 전사환경관리프로세스투자관리프로세스시스템수명주기프로세스관리프로세스자원관리프로세스품질관리프로세스 전사환경관리프로세스 목적 전사환경관리프로세스목적은본국제표준범위에서조직의사업에요구되는정책과 절차를정의하고유지하는것이다. a) 활동 사업분야계획수립 b) 시스템수명주기정책/ 절차를준비 c) 역할/ 책임/ 권한정의 d) e) 사업기준정의 시스템수명주기모델의주기적검토 f) 정책/ 절차공유

73 산출물 a) 조직비전정의서 b) 조직사업전략계획서 투자관리프로세스 목적투자관리프로세스목적은조직의목표를만족시키기위해충분하고적합한프로젝트를착수하고유지하는것이다. 투자관리프로세스는조직자금과자원의적절한투자를위임하고선정된프로젝트착수하는데필요로하는권한을재가하는것이다. 투자관리프로세스는조직이정당하다고확인한프로젝트의지속적인자격조건검토를수행하거나또는정당화확인, 지속적투자를위한방향이재조정되는것이다. a) 활동 투자계획수립 b) 프로젝트책임/ 권한정의 c) d) e) 예측산출물식별 자원할당 프로젝트인터페이스식별 f) 보고/ 검토회일정명시 g) h) i) 프로젝트권한부여 프로젝트평가 프로젝트조정 j) 프로젝트지연/ 취소 산출물 a) 투자관리계획서 b) 비용대효과분석서 시스템수명주기프로세스관리프로세스 목적시스템수명주기프로세스관리프로세스의목적은효과적인시스템수명주기프로세스가조직에서활용가용하도록보증하는것이다. 시스템수명주기프로세스관리프로세스는조

74 직의목적및방침과일관성이있고, 개별프로젝트의특성을충족하기위하여견실한방법 으로정의되고, 채택되고유지되고있으며, 활용되고있는효과적이며검증된방법과도구 가적용될수있도록하는시스템수명주기프로세스를제공한다. a) 활동 시스템수명주기프로세스수립 b) 테일러링정책/ 절차수립 c) 방법/ 도구식별 d) e) f) 평가척도수립 프로세스실행관찰 프로세스개선기회식별 g) 프로세스 / 방법/ 도구개선 산출물 a) 시스템수명주기프로세스관리계획서 b) 시스템수명주기정의계획서 c) 프로세스평가계획서 d) 프로세스개선계획서 자원관리프로세스 목적 자원관리프로세스의목적은프로젝트에자원을제공하는것이다. 자원관리프로세스는 시스템수명주기전기간동안조직및프로젝트목표달성을지원하기위하여프로젝트에필 요한재원, 재료및서비스를제공한다. 이것은시스템수명주기프로세스실행을위한자 격이있는교육받고숙련되고경험이있는인력의공급을포함한다. 자원관리프로세스는 자원, 정보및기술의효과적인조정과공유를확실히한다 활동 a) 자원지원항목결정/ 제공 b) 인적요소외자원확보 c) 인력유지/ 관리 d) 참여인력동기부여 e) 다수프로젝트의관리인터페이스통제

75 산출물 a) 자원관리계획서 b) 기반구축계획서 c) 훈련계획서 품질관리프로세스 목적품질관리프로세스의목적은제품, 서비스및시스템수명주기프로세스의실행결과가기업조직품질목표를만족하고고객만족을달성하는것을확실하게하는것이다 활동 a) 품질관리정책/ 표준/ 절차수립 b) 품질관리목적/ 목표수립 c) 책임/ 권한정의 d) 고객만족 / 결과보고서평가 e) f) 주기적품질계획검토 품질개선상태관찰 산출물 a) 품질관리계획서 b) 품질진척보고서 c) 품질목표서 d) 시스템품질계획서 5.4 프로젝트프로세스 개요 프로젝트프로세스는프로젝트계획을수립하고발전시키는데, 계획대비프로젝트의실질적성과와진도를평가하는데, 프로젝트구현을통한프로젝트실행을통제하는데사용되며다음과같은프로세스로구성된다

76 a) 프로젝트계획프로세스 b) 프로젝트평가프로세스 c) 프로젝트통제프로세스 d) 프로젝트의사결정프로세스 e) 위험관리프로세스 f) 형상관리프로세스 g) 정보관리프로세스 프로젝트계획프로세스 목적 프로젝트계획프로세스목적은효과적이고실행가능한프로젝트계획을만들어내고의 사소통하는것이다. 프로젝트계획프로세스는프로젝트의범위및기술적업무활동을결 정하고, 프로세스출력물, 프로젝트과업및인도물품을식별하고, 성과척도와프로젝트과 업완수에요구된자원을포함한프로젝트과업수행에필요한일정을수립하는것이다 활동 a) 프로젝트목표/ 제약사항식별 b) 프로젝트범위정의 c) 작업분할구조 (WBS) 작성 d) 프로젝트일정정의/ 유지 e) f) 프로젝트성과척도정의 프로젝트비용정의및예산계획 g) 책임/ 권한구조수립 h) 기반/ 서비스정의 i) 외부프로젝트와연계한획득정의 j) 기술관리계획수립/ 시행 k) 성과척도 / 연관자료정의 l) 프로젝트품질계획수립 산출물 a) 프로젝트관리계획서 b) c) 프로젝트계약관리계획서 프로젝트변경관리계획서 d) 프로젝트재정관리계획서

77 e) f) 프로젝트통제계획서 프로젝트품질보증계획서 g) 감리계획서 h) I) j) k) l) 공학계획서 소프트웨어개발계획서 시스템안전계획서 시스템보안계획서 종합시험계획서 m) 작업분할구조도 (WBS) n) 문서화계획서 o) 변환계획서 p) 프로젝트계획서 q) 프로젝트팀구조와운영역할계획서 r) 프로젝트일정 s) 브리핑자료 프로젝트평가프로세스 목적프로젝트평가프로세스목적은프로젝트의상태를결정하는것으로프로세스는주기적으로주요이벤트에서요구조건, 계획및전체적인사업계획대비진도및성과를평가하는것이다. 중요한변동이발견되었을경우정보는관리조치를위하여의사소통되어야한다. a) b) c) 활동 프로젝트상태평가 품질보증수행 프로젝트팀평가 d) 지원인프라적정성/ 가용성평가 e) 프로젝트진척평가 f) 관리및기술적검토/ 감리/ 검사수행 g) 주요프로세스 / 신기술관찰 h) 데이터분석및권고 i) 주기적보고서제공

78 산출물 a) 프로젝트평가계획서 b) 프로젝트평가결과보고서 c) Trade-off 분석보고서 프로젝트통제프로세스 목적프로젝트통제프로세스목적은프로젝트계획실행을지시하는것이며, 추정된예산내에서계획및일정에따라프로젝트를수행하고기술적목표를만족을확실하게하는것이다. 프로젝트통제프로세스는프로젝트업무활동을다른프로젝트또는기술적프로세스로부터식별된편차와변동을시정하기위하여적절하게재조정하는것이포함된다. 재조정에는가능할경우재기획이포함된다 활동 a) 요구및변경사항관리 b) 교정활동수행 c) 예방활동수행 d) 문제해결활동수행 e) 변화관리 f) 계약변경활동수행 g) 계약교정활동수행 h) 프로젝트승인 a) b) c) d) 산출물 프로젝트통제계획서 프로젝트변경보고서 요구사항상태보고서 프로젝트진척보고서 e) 문제해결계획서 f) 교정조치보고서 g) 편차보고서 의사결정프로세스

79 목적의사결정프로세스의목적은가장효과적인대안을선택하는과정이다. 프로세스는구체화되고바람직하거나최적화된결과에도달하기위하여, 요구성격및근원이무엇이던간에시스템수명주기동안에마주치는의사결정요구에응답하는것이다. 대안활동은분석되어야하며활동경로는선택되고지정되어야한다. 결정과이의사유는향후의사결정을지원하기위하여기록되어야한다. a) b) 활동 의사결정전략정의 의사결정과정참여 c) 환경/ 요구사항식별 d) e) 의사결정전략선정및성공척도식별 대안활동결과평가 f) 결과기록/ 추적/ 평가/ 보고 g) 처리결과기록유지 a) 산출물 의사결정계획서 b) Trade-off c) 분석보고서 의사결정결과보고서 d) 의사결정전략서 위험관리프로세스 목적 위험관리프로세스목적은품질, 비용, 일정또는기술적특성변화에따른불확실한사 건의영향을줄이는것이며프로세스는전체수명주기동안각위험에대하여적절한처리 또는수용의형태로대응하는위험을식별하고평가하고처리하고모니터링하는것이다. a) 활동 위험접근방법수립 b) 위험식별/ 정의 c) d) 위험확률결정 위험평가 e) 위험우선순위부여

80 f) 위험취급전략결정 g) 위험수용한계정의 h) 위험취급활동식별 i) 위험관련의사소통 j) 위험기록유지 산출물 a) 위험관리계획서 b) c) d) 위험해결활동계획서 위험분석보고서 위험상태보고서 e) 위험관리서 f) 위험관리요약서 g) 시스템위험분석계획서 형상관리프로세스 목적형상관리프로세스목적은프로젝트또는프로세스의식별된모든산출물의무결성을확립하고유지하는것이며관련된당사자에게이용가능하게한다 활동 a) 형상관리계획수립 b) 형상통제항목식별 c) 형상정보관리 d) 형상평가 산출물 a) 형상관리계획서 b) c) d) 형상통제결과보고서 형상정보관리보고서 형상평가결과보고서 e) 형상항목기준서 f) 형상관리전략서 g) 시스템제품배포서

81 5.4.8 정보관리프로세스 목적 정보관리프로세스목적은시스템수명주기또는사후에관련당사자에게적시에완전하 고유효한프로젝트관련정보를제공하는것이다. 정보관리프로세스는정보를생성하며, 채집하고변환하며존속하며재생하고보급하며처분하는것이다. 이것은기술, 프로젝트, 기업조직, 계약체결및사용자정보를포함한지정된정보를관리한다. a) 활동 정보항목정의 b) 권한/ 책임부여 c) 권리/ 의무/ 위임사항정의 d) 내용/ 의미/ 형태/ 매체정의 e) f) g) 정보항목확보 정보항목과이의저장기록유지 정보유지활동정의 h) 정보재생/ 배포 i) j) k) 공식문서제공 지정정보기록보관 정보폐기 a) b) c) 산출물 프로젝트정보관리계획서 정보품질분석보고서 정보품질진척보고서 d) 교훈보고서 e) trade-study 문서 f) 상태보고서 g) 문서화프로세스 h) 훈련메뉴얼 5.5 기술프로세스

82 5.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) 이해당사자요구사항정의프로세스 목적이해당사자요구사항정의프로세스의목적은정의된환경속에서사용자및다른이해당사자가필요로하는서비스를제공하는시스템요구사항을정의하는것이다. 이는시스템수명주기를통하여시스템과함께관여된이해당사자또는이해당사자계층집단과이해당사자의요구사항및희망사항을식별하는것이다. 이를시스템이갖고있는운영환경과의도된상호작용기능을표현하고, 시스템이요구사항을이행하고있다는것을확증하기위하여결과적운영서비스가요구검증되는것의기준이되는이해당사자요구조건의공통집합으로분석하고변환하는것이다 활동 a) 이해당사자식별 b) 요구사항추출 c) 제약사항정의 d) 대표집단정의

83 e) 사용자와시스템상호작용식별 f) 요구사항구체화 g) 요구조항분석 h) 요구조항문제해결 i) 이해당사자에게피드백 j) 이해당사자선임 k) 이해당사자요구사항기록 l) 이해당사자요구사항유지 a) b) c) 산출물 운영개념기술서 제품및서비스요구계획서 시스템개념계획서 d) 제품및서비스요구서 e) 안전계획서 f) 보안계획서 g) 인적요소요구서 h) 요구서 i) 안전요구서 j) 보안요구서 요구사항분석프로세스 목적 요구사항분석프로세스목적은요구되는서비스에대하여이해당사자, 의요구사항기반 의관점을서비스가납품되는데필요한제품의기술적관점으로변환하는것이다. 요구사항분석프로세스는제약요인들이허용하는범위까지이해당사자요구조건을충족 하는미래시스템의표상을구축하는것이며, 그어떤구체적실행을의미하는것은아니 다. 이는개발자의관점에서시스템이가져야하는특성과이해당사자요구조건을만족하는 정도의크기를규정하는측정가능한시스템요구조건에기인한다 활동 a) 시스템기능경계정의 b) 개별기능정의 c) 제약요인정의

84 d) 기술/ 품질정의 e) 요구사항 / 기능구체화 f) g) h) 요구사항통합성분석 요구사항추적성제시 요구사항유지 a) b) 산출물 요구사항명세서 인터페이스요구사항명세서 c) 기능상세계획서 d) 기능상세서 e) 규정및표준요구서 f) 시스템요구사항명세서 아키텍쳐설계프로세스 목적아키텍쳐설계프로세스목적은시스템요구조건을만족시키는해결책을종합하는것이다. 아키텍쳐설계프로세스는관리할수있고개념적이며궁극적으로실현가능한규모의분리된분제의집합으로써표현된해결책영역을요약하고정의한다. 시스템의기술적및상업적요구조건과위험과일관성을갖는상세수준에서하나이상의실행전략을식별하고조사한다. 이로부터아키텍쳐설계해결책은시스템을구성하는시스템요소들의집합으로부터형상화되는요구조건형태로정의된다. 위프로세스결과로부터나오는구체화된요구조건은실현된시스템요구검증과조합및요구검증전략수정의기초가된다. a) 활동 아키텍쳐설계정의 b) 시스템기능분할/ 할당 c) d) 아키텍쳐설계분석및설계기준설정 시스템요구사항결정 e) H/W와 S/W 요소결정 f) 대안설계해결책평가및상세수준모델링 g) 외부시스템과의인터페이스정의/ 문서화 h) 물리적설계구체화 i) 아키텍쳐설계정보기록

85 j) 아키텍쳐설계와시스템요구사항간상호추적성유지 산출물 a) 아키텍처설계명세서 b) 인터페이스설계기술서 c) 시스템방법론도구및기술계획서 d) 시스템상세설계명세서 e) 시스템수명주기적용프로세스 f) 시스템수명주기활동및작업매핑문서 g) 시스템방법론도구및기술서 구현프로세스 목적구현프로세스목적은명세화된시스템요소를생산하는것이다. 이프로세스는구체화된거동, 인터페이스및구현제약요소를선택된구현기술의실행기법에따라시스템요소를창조하는제조활동으로전환한다. 시스템요소는선택된구현기술에적합한재료및/ 또는정보를처리를통하고적절한기술적전문분야또는학문을사용하여만들어지거나채택된다. 이프로세스결과는요건검증을통한아키텍쳐설계요구조건과요구검증을통한이해당사자요구조건을만족시키는시스템요소이다. a) b) 활동 구현전략수립 제약사항식별 c) 시스템항목구현/ 채택 d) 계약만족증거기록 e) 포장/ 보관 산출물 a) 구현계획서 b) 구현결과보고서 통합프로세스 목적

86 통합프로세스목적은아키텍쳐설계와일관성을갖도록시스템을조립하는것이다. 통합프로세스는시스템요구조건에서명시된제품을만들기위해온전하거나부분적시스템형상을형성하는시스템요소를조합한다 활동 a) 조합순서와전략정의 b) 제약사항식별 c) 관련시스템과재료확보 d) 시스템항목확보 e) 기준순응보장 f) 시스템항목통합 g) 통합정보기록유지 산출물 a) 통합계획서 b) 통합결과보고서 c) 운영/ 설치매뉴얼 d) 문제해결보고서 검증프로세스 목적검증프로세스목적은규정된설계요구조건이시스템에의하여이행되었는가를확인하는것이다. 이프로세스는시스템구현과정의부적합또는부적합에영향을주는프로세스를바로잡는교정활동실행에요구된정보를제공한다. a) b) 활동 검증전략정의 검증계획정의 c) 잠재제약사항식별/ 공유 d) e) f) 검증준비확인 검증수행 검증자료생성 g) 검증분석/ 기록/ 보고 결과물

87 a) 검증계획서 b) c) 검증결과보고서 문제해결보고서 d) 측정절차계획서 e) 시험및평가서 f) 추적문서 g) 검증전략서 h) 검증전략요약서 전환프로세스 목적 전환프로세스목적은운영환경에서이해당사자요구조건으로명시된서비스를제공하는 능력을갖추는것이다. 이프로세스는적절한기반시스템, 즉계약체결서에서정의된운용 시스템, 지원시스템, 운용자훈련시스템, 사용자훈련시스템과함께요건검증된시스템을 설치한다. a) b) c) 활동 전환전략준비 운용장소준비 시스템납품 d) 설치/ 접속 e) f) g) h) 설치시험 시스템활성화 서비스시연 설치관련사항기록유지 a) b) c) 산출물 전환계획서 전환결과보고서 문제해결보고서 d) 설치계획서 e) 책임전환계획서 f) 제품또는서비스전달계획서 g) 책임전환서

88 h) 시스템인수서 i) 시스템할당서 j) 시스템설치서 k) 전환전략서 확인프로세스 목적확인프로세스목적은시스템을사용할때시스템이제공하는서비스가이해당사자요구조건을수용한다는객관적증거를제시하는것이다. 이프로세스는비교영향평가를수행하여이해당사자요구조건이올바르게정의되었다는것을확증한다. a) b) c) d) e) f) 활동 확인전략정의 확인계획준비 확인준비보장 확인수행 확인자료생성 부분적확인수행 g) 확인자료분석/ 기록/ 보고 산출물 a) 확인계획서 b) c) 확인결과보고서 문제해결보고서 d) 확인서 e) 확인전략서 f) 최종시험보고서 운영프로세스 목적운용프로세스목적은서비스를제공하기위하여시스템을사용하는것이다. 이프로세스는직원에게시스템운용을할당하고서비스및운용자- 시스템성능을모니터한다. 서비스

89 를유지하기위하여계약체결, 문제를식별해내고분석한다. 이해당사자요구조건및조직의제약요소와연관된운용상 활동 a) 운영전략준비 b) 관련서비스확보 c) 운용자배치 d) 시스템활성화 e) 재료소모 f) 운용상태관찰 g) 시스템관찰 h) 고장식별활동수행 i) 시정요구조치결정 j) 인간원인문제교정 k) 지속적사용자의사소통 산출물 a) 운영계획서 b) c) 운영결과보고서 문제해결보고서 d) 사용자메뉴얼 e) 운영전략서 유지보수프로세스 목적유지보수프로세스목적은서비스를제공하는시스템의능력을유지시키는것이다. 유지보수프로세스는서비스를전달하고분석을위한문제점을기록하며, 교정적응완벽한 예방활동을하는시스템능력을모니터하고복구된능력을확인한다 활동 a) 유지보수전략준비 b) 제약사항정의 c) 시스템요소및서비스확보 d) 문제보고서및사고기록작성

90 e) 교정절차서작성 f) 교정활동수행 g) 물류활동만족확인 h) 예방정비수행 i) 고장식별활동수행 j) 유지보수활동기록유지 a) b) c) 산출물 유지보수계획서 유지보수결과보고서 문제해결보고서 d) 유지보수요구서 e) 유지보수전략서 f) 시스템위험식별및분석서 g) 시스템위험부담식별요약서 h) 예방정비서 폐기프로세스 목적 폐기프로세스목적은시스템개체의실존을끝나게하는것이다. 이프로세스는최종상 태조건이부여되어있고최초또는받아들일수있는환경으로복귀토록되어있는시스템 및그모든폐기제품을활동성을잃게하고분해하고제거한다. 이프로세스는규제계약체 결 조직제약요소및이해당사자요건에따라시스템요소와폐기제품을환경적으로건전 한방법으로파괴저장하거나 또는교정한다. 폐기와관련된기록이요구될경우운용자및 사용자의건강, 환경의안전이모니터될수있도록기록을유지한다. a) 활동 폐기전략정의 b) 제약사항공유. c) d) e) f) 시스템또는서비스확보 시스템비활성화 인력철수및운용지식기록 시스템을관리가능한요소해체 g) 시스템제거

91 h) 시스템보관규정화 i) 시스템파기 j) 폐기확인 k) 시스템수명주기전과정에대한정보보관 산출물 a) 폐기계획서 b) c) 폐기결과보고서 문제해결보고서 d) 폐기전략서 e) 폐기보고서

92 부록 A. 수명주기단계(Life cycle Stages) A.1 서론 수명주기단계는수명주기모델링에사용되는시스템수명주기프로세스내하위구조를 구축하는데사용되며아래의 6 단계로구성된다. a) 개념단계(Concept Stage) b) 개발단계(Development Stage) c) 생산단계(Production Stage) d) 운용단계(Utilization Stage) e) 지원단계(Support Stage) f) 폐기단계(Retirement Stage) A.2 개념단계 A.2.1 목적개념단계는새로운사업기회에대한영향을평가하고예비시스템요구조건및타당한설계해결책을개발하는목적으로실행한다. A.2.2 활동 a) 이해관계자요구사항식별 b) 개념탐색 c) 실행가능솔루션제안 A.3 개발단계 A.3.1 목적 개발단계는획득자요구조건을만족하고생산시험평가운용지원 및폐기될수있는목 적시스템개발을위해수행한다. A.3.2 활동

93 a) b) c) d) 시스템요구사항정교화솔루션기술서작성시스템구축시스템검증및확인 A.4 생산단계 4.1 목적생산단계는제품을생산하고제조하며, 제품을시험평가하고필요할경우관련된지원기 반시스템을생산하는것을실행한다. 4.2 활동 a) b) 시스템생산 감사및시험 A.5 운용단계 A.5.1 목적 활용단계는제품운용, 의도된환경에서서비스를제공, 지속적운용효과성확증을위하 여실행된다. A.5.2 활동 a) 사용자요구사항을만족하는시스템운용 A.6 지원단계 A.6.1 목적 지원단계는물류, 정비, 지속적인목적시스템운용및지속가능한서비스를제공하기위 하여실행한다. A.6.2 활동 a) 지속적시스템능력유지

94 A.7 폐기단계 A.7.1 목적 폐기단계는목적시스템및관련된운용지원 서비스제거방법을제공과폐기시스템자체 를운용지원하기 위하여실행한다. A.7.2 활동 a) 시스템을저장, 기록또는처분

95 부록 B. 프로세스별활동-산출물메트릭스 활동과산출물에대한 CRUD(Create, Read, Update, Delete) 매트릭스를작성하여 각활동에대하여어떤산출물이생성, 읽고( 참조), 수정, 삭제되는지에대해서일목요연하 게표시하였다. B.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

96 B.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

97 B.3 전사환경관리프로세스 < 활동> < 산출물> a) 조직비전정의서 b) 조직사업전략계획서 a) 사업분야계획수립 C C b) 시스템수명주기정책/ 절차를 준비 R c) 역할/ 책임/ 권한정의 R d) 사업기준정의 R e) 시스템수명주기모델의 주기적검토 U f) 정책/ 절차공유 R R

98 B.4 투자관리프로세스 < 활동> < 산출물> a) 투자관리계획서 b) 비용대효과분석서 a) 투자계획수립 C b) 프로젝트책임/ 권한정의 R c) 예측산출물식별 R d) 자원할당 e) 프로젝트인터페이스식별 f) 보고/ 검토회일정명시 g) 프로젝트권한부여 h) 프로젝트평가 C i) 프로젝트조정 j) 프로젝트지연/ 취소 R

99 B.5 시스템수명주기프로세스관리프로세스 < 활동> < 산출물> a) 시스템수명주기프로세스관리계획서 b) 시스템수명주기정의계획서 c) 프로세스평가계획서 d) 프로세스개선계획서 a) 시스템수명주기프로세스 수립 C b) 테일러링정책/ 절차수립 C R c) 방법/ 도구식별 R d) 평가척도수립 R e) 프로세스실행관찰 C f) 프로세스개선기회식별 R g) 프로세스 / 방법/ 도구개선 C

100 B.6 자원관리프로세스 < 활동> < 산출물> a) 자원관리계획서 b) 기반구축계획서 c) 훈련계획서 a) 자원지원항목결정/ 제공 C b) 인적요소외자원확보 C c) 인력유지/ 관리 R C d) 참여인력동기부여 R e) 다수프로젝트의관리 인터페이스통제 U

101 B.7 품질관리프로세스 < 활동> < 산출물> a) 품질관리계획서 b) 품질진척보고서 c) 품질목표서 d) 시스템품질계획서 a) 품질관리정책/ 표준/ 절차 수립 C C b) 품질관리목적/ 목표수립 R C c) 책임/ 권한정의 R d) 고객만족 / 결과보고서평가 e) 주기적품질계획검토 C R R f) 품질개선상태관찰 U R

102 B.8 프로젝트계획프로세스 < 활동> a) 프로젝트 < 산출물> 목표 / 제약사항식별 a) 프로젝트관리계획서 C b) 프로젝트계약관리계획서 c) 프로젝트변경관리계획서 d) 프로젝트재정관리계획서 e) 프로젝트통제계획서 b) 프로젝트범위정의 U C R c) 작업분할구조 (WBS) 작성 d) 프로젝트일정 e) 정의 / 유지프로젝트성과척도 정의 f) 프로젝트비용정의 및예산계획 f) 프로젝트품질보증계획서 g) 감리계획서 h) 공학계획서 I) 소프트웨어개발계획서 j) 시스템안전계획서 k) 시스템보안계획서 l) 종합시험계획서 m) 작업분할구조도 ( W B S) C n) 문서화계획서 o) 변환계획서 p) 프로젝트계획서 C q) 프로젝트팀구조와운영역할계획서 R C C C C U C C C C C U R U C g) 책임 / 권한구조수립 R R R R R h) 기반 / 서비스정의 R r) 프로젝트일정 s) 브리핑자료 i) 외부프로젝트와 연계한획득정의 j) 기술관리계획 수립 / 시행 k) 성과척도 / 연관자료 정의 l) 프로젝트품질계획 수립 R R R R R

103 B.9 프로젝트평가프로세스 < 활동> < 산출물> a) 프로젝트평가계획서 b) 프로젝트평가결과보고서 c) T r a d e- o f f 분석보고서 a) 프로젝트상태평가 C b) 품질보증수행 R c) 프로젝트팀평가 R d) 지원인프라적정성/ 가용성 평가 R e) 프로젝트진척평가 R f) 관리및기술적검토/ 감리/ 검사수행 R g) 주요프로세스 / 신기술관찰 R C h) 데이터분석및권고 R C i) 주기적보고서제공 R

104 B.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

105 B.11 의사결정프로세스 < 활동> < 산출물> a) 의사결정계획서 b) T r a d e- o f f 분석보고서 c) 의사결정결과보고서 d) 의사결정전략서 a) 의사결정전략정의 C C b) 의사결정과정참여 R R c) 환경/ 요구사항식별 R R d) 의사결정전략선정및 성공척도식별 R R e) 대안활동결과평가 C f) 결과기록/ 추적/ 평가/ 보고 R C g) 처리결과기록유지 R

106 B.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

107 B.13 형상관리프로세스 < 활동> < 산출물> a) 형상관리계획서 b) 형상통제결과보고서 c) 형상정보관리보고서 d) 형상평가결과보고서 e) 형상항목기준서 f) 형상관리전략서 g) 시스템제품배포서 a) 형상관리계획수립 C C C b) 형상통제항목식별 R C c) 형상정보관리 C C d) 형상평가 C

108 B.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

109 B.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

110 B.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

111 B.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 항간상호추적성유지

112 B.18 구현프로세스 < 활동> < 산출물> a) 구현계획서 b) 구현결과보고서 a) 구현전략수립 C b) 제약사항식별 R c) 시스템항목구현/ 채택 R d) 계약만족증거기록 C e) 포장/ 보관 R

113 B.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

114 B.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

115 B.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

116 B.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

117 B.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

118 B.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

119 B.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

120 부록 C. 산출물기술서 프로세스그룹명프로세스명산출물수 5.2 계약프로세스 획득프로세스 공급프로세스 11 C.1 획득프로세스 a) 획득계획서 자원획득에관해무엇을, 언제, 어떻게수행하는지에대해작업(Task)/ 활동 (Activity) 을기술한다. 여기에는자원에대해 개발 또는 구입 에관한사항을포 함한다. b) 대금지급계획서 벤더에대한지불방법에대해무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활 동(Activity) 을기술한다. c) 공급자성과관리계획서 공급자의성과감시에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동 (Activity) 을기술한다. d) 시스템인수계획서 시스템과시스템의인수에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동(Activity) 을기술하며인수기준을포함한다. e) 계약서 둘이상의이해당사자간에동의한계약을기술한다. f) 시스템인수전략계획서 시스템의인수에대한전략적계획에대해서무엇을, 언제, 어떻게관리하는지에대한작 업(Task)/ 활동(Activity) 을기술한다

121 g) 요구사항정의서 시스템요구사항의정의에대해서무엇을, 언제, 어떻게정의하고관리하는지에대한작 업(Task)/ 활동(Activity) 을기술한다. h) 제안요청서 가능한입후보자에게정보를얻기위한공식적인요청을기술한다. i) 고객공급자합의서 고객과공급자사이의계약에대한정보를기록한다. j) 획득전략서 발주전략에대한정보를기록한다. k) 공급자선정계획서 공급자의선정에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동 (Activity) 을기술한다. l) 협약서(charter) 프로젝트의범위와제품을식별하고헌장은프로젝트를지원을위해핵심당사자사이에 서명된다. m) 합의서(correspondence) 해당프로젝트에의해제공되는양자간합의사항을기록한다. C.2 공급프로세스 a) 제안서 벤더가어떻게사용자요구사항을충족시킬지에관한문서로서비용, 일정, 정보관리를 포함한다. b) 계약서 둘이상의이해당사자간에동의한계약을기술한다. c) 사업수행계획서 사업수행의계획에대해서무엇을, 언제, 어떻게정의하고관리하는지에대한작업

122 (Task)/ 활동(Activity) 을기술한다. d) 시스템개발계획서 시스템개발계획에대해서무엇을, 언제, 어떻게정의하고관리하는지에대한작업 (Task)/ 활동(Activity) 을기술한다. e) 인수확인서 시스템의인수확인에대한정보를기록한다. f) 검증결과보고서 시스템에대한검증결과를보고한다. g) 확인결과보고서 시스템의이상유무에대한확인결과를보고한다. h) 품질관리결과보고서 시스템의품질및상태를보고한다. i) 합동고객공급자감리검토계획서 공급자가제공한품목에대해서감리와검토를수행하기위한계획을식별한다. j) 협력업체관리계획서 협력업체에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동 (Activity) 을기술한다. k) 요청응답서 요청응답에대한정보를기록한다

123 프로세스그룹명프로세스명산출물수 전사환경관리프로세스 전사프로세스 투자관리프로세스 프로세스 시스템수명주기프로세스관리 자원관리프로세스 품질관리프로세스 4 4 C.3 전사환경관리프로세스 a) 조직비전정의서 공급자가제공한품목에대해서감리와검토를수행하기위한계획을식별한다. b) 조직사업전략계획서 조직의업무에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동 (Activity) 을기술한다. C.4 투자관리프로세스 a) 투자관리계획서 시스템획득의투자관리에대해서무엇을, 언제, 어떻게정의하고관리하는지에대한작 업(Task)/ 활동(Activity) 을기술한다. b) 비용대효과분석서 시스템의비용대효과분석결과를요약보고한다. C.5 시스템수명주기프로세스관리프로세스 a) 시스템수명주기프로세스관리계획서 시스템수명주기개발에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활 동(Activity) 을기술한다. b) 시스템수명주기정의계획서

124 시스템의수명주기처리에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동(Activity) 을기술한다. c) 프로세스평가계획서 프로세스실행가능성, 효율성, 효과성에대해서무엇을, 언제, 어떻게평가하는지에대 한작업(Task)/ 활동(Activity) 을기술한다. d) 프로세스개선계획서 프로세스개선에대해서무엇을, 언제, 어떻게보장하는지에대한작업(Task)/ 활동 (Activity) 을기술한다. C.6 자원관리프로세스 a) 자원관리계획서 자원에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동(Activity) 을 기술한다. 이계획은프로젝트일정과자원계획을정의한다. b) 기반구축계획서 프로젝트의기반구조관리를위해무엇을, 언제, 어떻게관리하는지에대해작업(Task)/ 활동(Activity) 을기술한다. c) 훈련계획서 훈련대해서무엇을, 언제, 어떻게수행하는지에대한작업(Task)/ 활동(Activity) 을 기술한다. C.7 품질관리프로세스 a) 품질관리계획서 산출물과프로세스품질에대해서무엇을, 언제, 어떻게보장하는지에대한작업 (Task)/ 활동(Activity) 을기술한다. b) 품질진척보고서 품질을관리하기위한시스템정보를기록한다. c) 품질목표서

125 프로젝트의품질목표에대한정보를기록한다. d) 시스템품질계획서 시스템의품질에서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동 (Activity) 을기술한다. 프로세스그룹명프로세스명산출물수 프로젝트계획프로세스 프로젝트평가프로세스 프로젝트통제프로세스 프로젝트프로세스 프로젝트의사결정프로세스 위험관리프로세스 형상관리프로세스 정보관리프로세스 8 C.8 프로젝트계획프로세스 a) 프로젝트관리계획서 프로젝트에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동 (Activity) 을기술한다. b) 프로젝트계약관리계획서 프로젝트의계약에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동 (Activity) 을기술한다. c) 프로젝트변경관리계획서 프로젝트의변경에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동 (Activity) 을기술한다. d) 프로젝트재정관리계획서 프로젝트의재정에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동 (Activity) 을기술한다

126 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) 작업분할구조에대한정보를기록한다

127 n) 문서화계획서 시스템의문서화계획에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활 동(Activity) 을기술한다. o) 변환계획서 유지보수단계에서부터생산시스템까지의변경사항에대해무엇을, 언제어떻게이동 하는지에대해작업(Task)/ 활동(Activity) 을기술한다. p) 프로젝트계획서 프로젝트계획의모든것들에대해서무엇을, 언제, 어떻게관리하는지에대한작업 (Task)/ 활동(Activity) 을기술한다. q) 프로젝트팀구조와운영역할계획서 프로젝트팀의구조와운영에대해서무엇을, 언제, 어떻게관리하는지에대한작업 (Task)/ 활동(Activity) 을기술한다. 이것은조직의보고구조에대해상세히정의하고역 할과책임에대해명확히정의한다. r) 프로젝트일정 프로젝트의일정에대한정보를기록한다. s) 브리핑자료 프로젝트를위한간결한정보를기록한다 프로젝트평가프로세스 a) 프로젝트평가계획서 프로젝트평가계획에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동 (Activity) 을기술한다. b) 프로젝트평가결과보고서 프로젝트의평가결과를보고한다. c) Trade-off 분석보고서 Trade-off 분석결과를보고한다

128 C.10 프로젝트통제프로세스 a) 프로젝트통제계획서 프로젝트통제계획에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동 (Activity) 을기술한다. b) 프로젝트변경보고서 프로젝트의변경사항을기록유지하며요약보고한다. c) 요구사항상태보고서 프로젝트의요구사항에대한상태및처리결과를보고한다. d) 프로젝트진척보고서 프로젝트일정에따른진척결과를보고한다. e) 문제해결계획 문제점들에대해서무엇을, 언제, 어떻게관리및해결하는지에대한작업(Task)/ 활동 (Activity) 을기술한다. 관리에대한주의를끌어내기위해문제점들을어떻게분류할지 정의한다. f) 교정조치보고서 교정활동의결과를보고한다. g) 편차보고서 시스템의외부환경으로인한편차결과와상태를보고한다. C.11 의사결정프로세스 a) 의사결정계획서 의사결정에대한전략정보에대해서무엇을, 언제, 어떻게관리하는지에대한작업 (Task)/ 활동(Activity) 을기술한다. b) Trade-off 분석보고서 Trade-off 분석결과를보고한다

129 c) 의사결정결과보고서 의사결정에대한정보와그결과를보고한다. d) 의사결정전략서 C.12 위험관리프로세스 a) 위험관리계획서 위험에대해서무엇을, 언제, 어떻게절차화(process) 하는지에대한작업(Task)/ 활동 (Activity) 을기술한다. b) 위험해결활동계획서 의사결정해결에대한전략정보에대해서무엇을, 언제, 어떻게관리하는지에대한작업 (Task)/ 활동(Activity) 을기술한다. c) 위험분석보고서 위험분석한결과를보고한다. d) 위험상태보고서 위험상태조사결과를보고한다. e) 위험관리서 위험관리를구현하기위한요구사항에대한정보를기록한다. f) 위험관리요약서 식별된위험, 관련된해결책결과, 프로젝트의마무리에서노출된위험에대한정보를기 록한다. g) 시스템위험분석계획서 시스템의위험요소에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동 (Activity) 을기술한다. C.13 형상관리프로세스

130 a) 형상관리계획서 형상관리에대해무엇을, 언제, 어떻게관리하는지에대해작업(Task)/ 활동(Activity) 을기술한다. b) 형상통제결과보고서 형상통제활동결과를보고한다. c) 형상정보관리보고서 형상정보관리활동결과를보고한다. d) 형상평가결과보고서 형상평가결과를보고한다. e) 형상항목기술서 형상품목기준선에대한정보를기록한다. f) 형상관리전략서 형광관리전략에대한정보를기록한다. g) 시스템제품배포서 배포된시스템의형상정보를기록하며알려진문제를포함한다. C.14 정보관리프로세스 a) 프로젝트정보관리계획서 프로젝트의정보관리에대해무엇을, 언제, 어떻게관리하는지에대해작업(Task)/ 활동 (Activity) 을기술한다. b) 정보품질분석보고서 정보에대한품질을정도를보고한다. c) 정보품질진척보고서 정보에대한품질향상정도를보고한다. d) 교훈보고서

131 프로젝트의교훈결과에대한정보를기록한다. e) trade-study 문서 trade-study 에대한정보를기록한다. f) 상태보고서 프로젝트의상태정보를주간, 월간보고한다. g) 문서화프로세스 프로젝트문서화관리방법론을구현하기위해사용된프로세스를문서화하다. h) 훈련매뉴얼 훈련을어떻게수행할지기술한다. 프로세스그룹명프로세스명산출물수 5.5 기술프로세스 이해당사자요구사항정의 프로세스 요구사항분석프로세스 아키텍쳐설계프로세스 구현프로세스 통합프로세스 검증프로세스 전환프로세스 확인프로세스 운영프로세스 유지보수프로세스 폐기프로세스 5 C.15 이해당사자요구사항정의프로세스 a) 운영개념기술서 시스템의운영에대한정보를기록한다. b) 제품및서비스요구계획서

132 산출물또는서비스를위한프로젝트요청사항에대해서무엇을, 언제, 어떻게관리하는 지에대한작업(Task)/ 활동(Activity) 을기술한다. c) 시스템개념계획서 시스템의개념에대해서무엇을, 언제, 어떻게정의하는지에대한작업(Task)/ 활동 (Activity) 을기술한다. d) 제품및서비스요구서 제품또는서비스요청에대한정보를기록한다. e) 안전계획서 시스템안전요구사항에대해서무엇을, 언제, 어떻게만족시키는지에대한작업 (Task)/ 활동(Activity) 을기술한다. f) 보안계획서 제품과프로젝트보안요구사항에대해서무엇을, 언제, 어떻게만족시키는지에대한작 업(Task)/ 활동(Activity) 을기술한다. g) 인적요소요구서 인적요소를기본으로하는요구사항에대한정보를기록한다. h) 요구서 인적요소를기본으로하는요구사항에대한정보를기록한다. i) 안전요구서 시스템의안전요구사항에대한정보를기록한다. j) 보안요구서 시스템과프로젝트의보안요구사항에대한정보를기록한다. C.16 요구사항분석프로세스 a) 요구사항명세서 요구사항에대한정보를기록한다

133 b) 인터페이스요구사항명세서 인터페이스요구사항에대한정보를기록한다. c) 기능상세계획서 시스템의기능요구사항에대해무엇을, 언제, 어떻게정의, 관리, 나열하는지에대해작 업(Task)/ 활동(Activity) 을기술한다. d) 기능상세서 상세기능요구사항에관한정보를기록한다. e) 규정및표준요구서 제품에영향을주는규정과표준에대한정보를기록한다. f) 시스템요구사항명세서 시스템요구사항에대한정보를기록한다. C.17 아키텍쳐설계프로세스 a) 아키텍처설계명세서 구조요구사항과시스템의설계에대한정보를기록한다. b) 인터페이스설계기술서 모든레벨에서시스템인터페이스에대한정보를기록한다. c) 시스템방법론도구및기술계획서 시스템의방법, 도구, 기술에대해서무엇을, 언제, 어떻게관리하는지에대한작업 (Task)/ 활동(Activity) 을기술한다. d) 시스템상세설계명세서 디자인명세가상세히된시스템에대한정보를기록한다. e) 시스템수명주기적용프로세스 프로젝트에의해사용된시스템수명주기프로세스에대한정보를기록한다. f) 시스템수명주기활동및작업매핑문서

134 시스템수명주기활동과프로젝트일정에프로젝트일정에연관되는작업에관한정보를 기록한다. 다. g) 시스템방법론도구및기술서 시스템방법, 도구, 시스템을설계하고개발하기위해사용된기술에대한정보를기록한 C.18 구현프로세스 a) 구현계획서 시스템구현을위한전략에대한정보를기록한다. b) 구현결과보고서 시스템구현에대한정보를보고한다. C.19 통합프로세스 a) 통합계획서 서브시스템을시스템에통합함에있어무엇을, 언제, 어떻게관리하는지에대해작업 (Task)/ 활동(Activity) 을기술하고통합전략에대한정보를기록한다. b) 통합결과보고서 시스템통합에대한결과를보고한다. c) 운영/ 설치매뉴얼 시스템의운영및설치에대한방법을기록한다. d) 문제해결보고서 문제점의해결결과를보고한다. C.20 검증프로세스 a) 검증계획서 시스템의검증에대해서무엇을, 언제, 어떻게관리하는지에대한작업(Task)/ 활동 (Activity) 을기술한다

135 b) 검증결과보고서 시스템의이상유무검증결과를보고한다. c) 문제해결보고서 문제점의해결결과를보고한다. d) 측정절차계획서 품질보증과명세서에기초하여프로젝트의성공을위한핵심측정사항에대해무엇을, 제, 어떻게수행하는지에대해작업(Task)/ 활동(Activity) 을기술한다. 언 e) 시험및평가서 시스템테스트와평가를수행하기위한프로세스에대한정보를기록한다. f) 추적문서 배송된시스템에대하여설계와요구사항사이의추적성에대한정보를기록한다. g) 검증전략서 검증전략에대한정보를기록한다. h) 검증전략요약서 검증작업/ 활동의결과, 구별된위험의상태, 검증의견에관한요약된정보를기록한다. C.21 전환프로세스 a) 전환계획서 시스템의전환에대해무엇을, 언제, 어떻게관리하는지에대해작업(Task)/ 활동 (Activity) 을기술한다. b) 전환결과보고서 시스템의전환결과를보고한다. c) 문제해결보고서 문제점의해결결과를보고한다

136 d) 설치계획서 시스템설치에대해무엇을, 언제, 어떻게관리하는지에대해작업(Task)/ 활동 (Activity) 을기술한다. e) 책임전환계획서 고객에게산출물또는서비스운반에대해서무엇을, 언제, 어떻게관리하는지에대한작 업(Task)/ 활동(Activity) 을기술한다. f) 제품또는서비스전달계획서 산출물또는서비스의배송에대해서무엇을, 언제, 어떻게관리하는지에대한작업 (Task)/ 활동(Activity) 을기술한다. g) 책임전환서 시스템운반을위한책임에대한정보를기록한다. h) 시스템인수서 배송된시스템과서브시스템의인수를위한프로세스에대한정보를기록한다. i) 시스템할당서 하드웨어, 소프트웨어, 인적요소에대한시스템배치에대한정보를기록한다. j) 시스템설치서 시스템설치에대한정보를기록한다. k) 전환전략서 추이전략에대한정보를기록한다. C.22 확인프로세스 a) 확인계획서 확인계획에대해무엇을, 언제, 어떻게관리하는지에대해작업(Task)/ 활동(Activity) 을기술한다. b) 확인결과보고서 시스템의확인결과를보고한다

137 c) 문제해결보고서 문제점의해결결과를보고한다. d) 확인서 시스템을확인하기위해사용했던확인방법에대한정보를기록한다. e) 확인전략서 확인전략에대한정보를기록한다. f) 최종시험보고서 시스템요구사항에대한정보를기록한다. C.23 운영프로세스 a) 운영계획서 시스템의운영에대해무엇을, 언제, 어떻게관리하는지에대해작업(Task)/ 활동 (Activity) 을기술한다. b) 운영결과보고서 시스템의운영에대한결과를보고한다. c) 문제해결보고서 문제점의해결결과를보고한다. d) 사용자메뉴얼 시스템을어떻게사용할지그리고어떻게유지하는지에관한정보를제공한다. e) 운영전략서 시스템의운영전략에대한정보를기록한다. C.24 유지보수프로세스 a) 유지보수계획서 시스템의유지보수에대해무엇을, 언제, 어떻게관리하는지에대해작업(Task)/ 활동

138 (Activity) 을기술한다. b) 유지보수결과보고서 시스템의유지보수결과를보고한다. c) 문제해결보고서 문제점의해결결과를보고한다. d) 유지보수요구서 유지보수요구사항에대한정보를기록한다. e) 유지보수전략서 유지보수전략에대한정보를기록한다. f) 시스템위험식별및분석서 시스템위험요소식별과분석결과에대한정보를기록한다. g) 시스템위험부담식별요약서 프로젝트의마지막시점에서시스템위험요소의요약에대한정보를기록한다. h) 예방정비서 예방유지보수요구사항에대한정보를기록한다. C.25 폐기프로세스 a) 폐기계획서 시스템혹은서브시스템의폐기수행에관해무엇을, 언제, 어떻게폐기관리를하는지에 대해작업(Task)/ 활동(Activity) 을기술한다. b) 폐기결과보고서 시스템의폐기결과를보고한다. c) 문제해결보고서 문제점의해결결과를보고한다

139 d) 폐기전략서 시스템또는서브시스템의폐기를위한전략정보를기록한다. e) 폐기보고서 시스템또는서브시스템의폐기의결과를보고한다

140 부록 D. 문서작성절차 D.1 프로젝트요구문서식별 D.1.1 문서관리정책 문서의개발, 유지, 분배, 관리를위한프로젝트정책을기술한다. D.1.2 계약과프로젝트분석 내용, 포맷그리고배포를포함하는문서요구사항의나열을위한계약과프로젝트계획 을분석한다. D.1.3 계약분석검증 고객에게계약분석을보내고고객승인을받는다. D.1.4 문서관리방법론검증기존재하는프로젝트문서프로세스와절차를검증한다. 문서에대해서모든품질요구사항이충족되는것을검증하기위한정보가포함된다. 표준과프로세스는식별되는데이것은문서관리방법론을보증한다. 그리고계획서안에있는항목들은식별된품질요구사항을충족시킨다. 다음은문서품질요구사항을요약한다. - 철자법과문법체크 - 포맷, 스타일과버전 - 내용일관성과및다른문서간의일관성 - 업데이트되는수정히스토리 - 수행된검토와결과 - 문서변경게시판 - 주기완성의승인 - 오직승인된변화의구현 - 알맞은기준선 - 알맞은패키지화와분배 D.1.5 문서관리방법론훈련준비 필요에따라, 자료를준비한다. 그리고문서관리방법론에대한훈련을제공하기위한 자원을식별한다

141 D.2 문서작성자식별 D.2.1 문서할당매트릭스각항목에대해서문서저자와지원인력을할당하기위해모든프로젝트주선한다. 책임을포함하며프로젝트관리자로부터지원을보장받는다. 조직의회의를 D.2.2 문서관리방법론훈련프로젝트수명주기전반에걸쳐문서방법론훈련세션을주선한다. D.3 사용자식별 D.3.1 사용자식별문서고객을식별하고각항목의화제(Topic) 에대한지식수준이나경험정도를식별한다. 또한두번째사용자나독자를식별한다. D.3.2 사용자기대식별 사용자의기대를식별한다. 여기에는특정사용자의특징에관한연구를포함한다. 만약 가능하다면핵심고객인, 문서저자, 문서교정자등으로배치되어야한다. 사용자분석에 서건의한문서의모습을기술해야한다. 특히조직, 동기, 특별한필요사항그리고특성영 역에집중해야한다. 사용자의지식수준을결정하고알맞은용어사용에동의를해야한다. D.3.3 사용자분석체크리스트 사용자분석절차에따라문서에대해체크리스트를개발한다. 여기에는사용자작업도 포함한다. 작업이수행되는데있어영향을미치는다른요소가있는지확인한다. 충족시켜 야할이해당사자의요구사항이있는지그리고문서가유용한지확인한다. D.3.4 문서의목표, 요구사항검증 고객에게제공된프로젝트문서의나열을보장하고문서를위한목적, 요구사항, 사용자 기대사항이제출된다. 문서의각아이템에대해알맞은정도의상세화가되어있는지결정 한다. 충돌되는요구사항이있는지확인한다. 할당된자원안에서문서작성을보장하도록 일정과예산을검증한다. D.3.5 문서인구통계문서저자를정의하고문서의각항목을위한사용자의인구통계정보를정의한다

142 D.4 데이터의원천식별 4.1 문서데이터의원천식별 문서요구사항과고객기대사항에기초하여, 문서, 데이터수집자, 이러한데이터원천의 각항목을위한데이터를식별한다. 그리고어떻게그데이터가재표현되고사용되는지식 별한다. 만약, 필요하다면고객과문서사용자간에회의를배치한다. D.4.2 문서데이터의원천확인고객에게원천리스트에대해서서명을하게함으로서고객과함께문서데이터원천을검증한다. D.4.3 데이터관리개발된또는프로젝트에서획득된데이터는프로젝트매니저나조직정책에의해결정된형상관리또는문서작성통제아래놓이게된다. D.5 문서설계와개발프로세스 D.5.1 문서작업요구저자가문서의항목에대해개발또는변경을시작하기이전에문서저자는작업을시작에대한권한을받기위하여작업요청서를완성시킨다. 작업요청서는저자의매니저와문서관리자에의해검토되며이것은저자에게요구되는것이무엇인지다른인력들이그들의역할과책임을인식하는것을보장한다. 작업요청서는문서상태에대한정보를계속추적하는데사용되기도한다. 저자부터문서관리자에게까지주간상태보고서는문제점과위험사항을포함하는문서상태를인식하는데도움을준다. D.5.2 문서식별유일한문서식별요구사항을식별한다. 여기에는버전식별에관한정보가포함되며문서식별의한부분으로서버전이어떻게문서의한부분으로만들어지는지에대한정보를포함한다. 문서작성의시스템으로서문서집합을설계한다. D.5.3 문서발주 알맞은문서의개발을위해회사이름을계약한다. 일단, 문서의한항목이회사이름에 의해승인되면문서의항목은최종검토기준선설정, 배포를위해문서관리자에게자동적

143 으로이전된다. D.5.4 문서설계요구사항과기대사항을기초로하여문서의개요와요약정보를개발한다. 와문서매니저로부터승인을받는다. 저자의매니저 D.5.5 문서매핑 문서항목에대해, 문서의데이터, 요구사항, 기대사항의매핑을통해문서추적성을개발 한다. D.5.6 문서개발 문서설계와데이터에기반하여, 문서를개발한다. 필요에따라, 문서의상태를갱신한다. D.6 문서테스트와검증 D.6.1 문서일관성절차문서의각항목과다른산출물사이내에서일관성을보장하기위해절차를개발한다. D.6.2 문서체크리스트 요구사항과기대사항을기초로하여조정, 검토자, 권한승인을위한체크리스트를개발 한다. D.6.3 문서일관성검증 문서작성의일관성절차를구현하고문서체크리스트를완성시킨다. 제품실행, 기능성, 요구사항, 설계등과관련된문서작성회의를포함한다. 그리고유용성실험수행도포함한 다. D.6.4 문서히스토리 모든문서는수정히스토리를포함해야한다. 이는언제수정이되었는지, 승인이되었을 때누가수정을승인했고수정된내용의요약을기술한다. 만약변화가회의나사용자의비 평이었다면, 승인된내용의요약은회의상세사항 ( 제목, 날짜등등) 이나사용자비평에해 당하는우리의응답식별자를참조할수있다. D.7 문서승인 D.7.1 문서재검토

144 프로젝트의검토프로세스에기초하여, 검토및갱신을위한문서를제출한다. 비평을재 검토하고, 문서의다음버전을위해그비평에대해구현, 거부하거나수정을한다. 문서 재검토또는문서승인프로세스를반복한다. D.7.2 문서작성프로젝트승인필요한정보를수집하고프로젝트승인을위해분배한다. 해, 문서매니저에게문서를제출한다. 문서작성프로젝트승인을위 D.7.3 문서의고객승인 문서의품질체크를수행한다. 필요에따라고객을조정한다. 고객의비평을받고문서 저자에게그것들을분배한다. D.7.4 고객비평해결책 - 모든고객들의비평을검토하고문서의다음버전을위해그비평을구현, 거부또는 - 수정을한다. 만약고객이문서를승인했다면알맞은프로젝트관리자에게공지를하고문서의상태 를갱신한다. D.8 문서생산 D.8.1 문서생산 전달매체배달요구사항에기초하여생산을위한문서를준비한다. 문서전달매체는패키 지화한다. 보안, 안전, 분배요구사항에기초하여표시와분배를한다. 문서저장프로세스 를위해복사본을만든다. 문서의상태를갱신한다. D.9 문서저장 D.9.1 문서저장사용자에게보냈던모든문서전달매체의주복사본을저장한다. 체는읽기기능만을가능하게한다. 가능한한모든전달매 D.9.2 문서검색문서는읽기만가능또는수정기능상태로만표시된다. D.9.3 데이터관리데이터관리프로세스를식별한다

145 D.9.4 문서종료문서종료를결정한다. 새로운기준선에의해교체되는문서의기준선항목을포함한다. D.10 문서유지 D.10.1 문서변경통제 고객에게첫번째문서를배포한후에, 문서변경통제절차를구현한다. 문서는문서 변경통제프로세스의사용을통해유지된다. 문서유지를위해서어떤추천되는변경은작 업요청으로시작되며작업요청은변경통제게시판의입력이된다. 변경통제게시판의 개발과함께, 문서변경은출판된항목이전에호환성을보장하기위해대응하는산출물에 비교된다. 문서변경통제의주요목적은오직승인된변경만이문서에반영하는것이다

146 부록 E. 시스템수명주기표준프로세스와발주관리표준프로세스 연계방안 E.1 연계방안 < 그림참조> E.2 세부매핑구조 시스템수명주기표준프로세스와발주관리표준프로세스와의명확한비교를위해 의프로세스그룹을구성 4개 a) 계약그룹(Agreement Group) b) 프로젝트관리및지원그룹(Project Management and Support Group) c) 개발그룹(Development Group) d) 후행그룹(Downstream Group) E.3 계약그룹 E.3.1 구성계약그룹은획득및공급과관련된프로세스를포함 E.3.2 비교

147 시스템수명주기표준프로세스 발주관리표준프로세스 프로세스획득프로세스획득 활동 획득계획수립 활동 획득준비 활동 요구사항준비 활동 제안요청서준비 활동 공급자와정보교환 활동 계약및변경 활동 공급자선택 활동 공급자관리 활동 공급자와계약협상 활동 인수및종료 활동 계약이행평가 활동 활동 최종산출물확인 활동 활동 대금지불 프로세스공급프로세스공급 활동 획득자식별 활동 제안요청서검토 활동 요구사항평가 활동 제안서준비 활동 요청사항대응책준비 활동 계약및변경 활동 계약협의 활동 사업수행계획수립 활동 계약체결 활동 실행및통제 활동 계약이행결과평가 활동 검토및평가 활동 최종산출물인도 활동 납품및종료 활동 대금수령 활동 최종산출물책임이관 E.4 프로젝트관리및지원그룹 E.4.1 구성 프로젝트관리및지원그룹은전사, 프로젝트, 정보전략계획, 정보화기획, 관리, 기반구 조, 인적자원프로세스개선프로세스를포함 E.4.2 비교 시스템수명주기표준프로세스 발주관리표준프로세스 프로세스 프로젝트계획프로세스 프로세스 관리 프로세스 프로젝트평가프로세스 활동 관리준비 프로세스 프로젝트통제프로세스 활동 관리계획수립 프로세스 위험관리 활동 관리실행및통제 활동 검토및평가 활동 종결 활동활동 프로세스 의사결정 프로세스 문제해결 프로세스 형상관리 프로세스 형상관리 프로세스 정보관리 프로세스 문서화 프로세스 시스템수명주기프로세스관리 프로세스 프로세스개선 프로세스 자원관리 프로세스기반구조프로세스인적자원

148 E.5 개발그룹 E.5.1 구성 개발그룹은기술프로세스와개발, 운영, 유지보수및지원프로세스를포함 E.5.2 비교 시스템수명주기표준프로세스프로세스그룹프로세스이해당사자요구사항정의프로세스 발주관리표준프로세스 기술프로세스개발 프로세스 요구사항분석프로세스 활동 시스템요구사항분석 프로세스 아키텍쳐설계프로세스 활동 시스템구조설계 활동 소프트웨어요구사항분석 활동 소프트웨어설계 프로세스 구현프로세스 활동소프트웨어상세설계활동소프트웨어코딩및단위시험 활동 소프트웨어통합 활동 소프트웨어자격시험 프로세스 통합프로세스 활동 시스템통합 프로세스 검증프로세스 활동 시스템자격시험 프로세스 전환프로세스 활동 소프트웨어설치 프로세스 확인프로세스 활동 소프트웨어인수지원

149 시스템수명주기프로세스와발주관리프로세스연계 개념단계 개발단계 생산단계 운용 전사프로세스그룹 시스템수명주기프로세스 계약프로세스그룹 이해당사자 요구사항 요구사항정의 분석 아키텍처설계 개발프로세스 구현 프로젝트프로세스그룹 기술프로세스그룹 통합 검증 전환 확인 운영 개발프로세스 운영프로세스 소프트웨어발주관리프로세스 시스템요구사항분석정보전략계획획득프로세스공급프로세스 시스템구조설계 S/W 요구사항분석 S/W 구조설계 S/W 상세설계 S/W 코딩및단위시험 S/W 통합 S/W 자격시스템시험통합 시스템자격시험 핵심수명주기프로세스지원수명주기프로세스 S/W 설치 S/W 인수지원 ( 운영준비 / 시험, 시스템운영, 사용자지원 ) 조직수명주기프로세스

150 시스템수명주기프로세스와발주관리프로세스연계방안 개념단계 개발단계 생산단계 운용 전사프로세스그룹 시스템수명주기프로세스 계약프로세스그룹 이해당사자 요구사항 요구사항정의 분석 아키텍처설계 개발프로세스 구현 프로젝트프로세스그룹 기술프로세스그룹 통합 검증 전환 확인 운영 소프트웨어발주관리프로세스 S/W 요구사항분석 S/W 구조설계 S/W 상세설계 S/W 코딩및단위시험 S/W 통합 S/W 자격시험

151 E.6 후행그룹 E.6.1 구성계약그룹은운영, 유지보수및페기와관련된프로세스를포함 E.6.2 비교 시스템수명주기표준프로세스 발주관리표준프로세스 프로세스 운영 프로세스 운영 활동 운영준비 활동 시스템운영 활동 운영시험 프로세스 유지보수 프로세스 유지보수 활동 유지보수준비 활동 유지보수분석 활동 시스템유지보수 활동 유지보수검토/ 승인 활동 소프트웨어이전 프로세스 폐기 활동 소프트웨어폐기

152 부록 B ISO/IEC & ISO/IEC 개정(revision) 제안분석

153

154 부록 B ISO/IEC & ISO/IEC 개정(revision) 제안분석 1 서론 시스템공학분야중시스템수명주기프로세스는소프트웨어수명주기프로세스와밀접한 관계를갖는다. 그러나 ISO/IEC System Life Cycle Process( 시스템수명 주기프로세스 ), ISO/IEC Software Life Cycle Process( 소프트웨어수명주 기프로세스 ) 와같은기존의표준들에서사용하는용어와기술하는상세화정도(Level) 가 서로상이하여이를함께이용하는데많은문제가발생하였다. ISO/IEC JTC1/SC7 에서제안한 New Work Item Proposal-Revision of ISO/IEC Systems and Software Engineering-System Life Cycle Processes 와 New Work Item Proposal-Revision of ISO/IEC Systems and Software Engineering-Software Life Cycle Processes 연구보 고서는각각수명주기프로세스인 ISO/IEC System Life Cycle Process 와 ISO/IEC Software Life Cycle Process 를바탕으로하는공공부문 SW사업 발주ㆍ관리표준프로세스지침과의연계및통합을위한방안을제시함으로서, 호환성과 일관성을보장하고사용자들이보다쉽고확장시킬수있도록도와줄것이다. 연구보고서 에서는시스템수명주기프로세스및소프트웨어프로세스수명주기를각각간단히 15288:2002 및 12207:1995 로약칭하고소프트웨어수명주기프로세스의수정보완인 Amendment 버전을 AMD 라약칭하였다 과 12207의연계및통합방안 15288:2002 및 12207:1995 를연계및통합함으로써수명주기전반에걸친호환성과 일관성을유지할수있으며사용자들은이를이용하여필요에따라쉽게확장시킬수있 다. 연구보고서에서는 12207:1995 표준및 15288:2002 표준을대체로호환하도록하였 으며 SW 수명주기에서지원하지않던프로세스평가(Process Assessment) 를추가로지 원한다. 또한, 최대한일관성있는용어와개념을사용하도록하였다. ISO/IEC 15288:2002 및 12207:1995 를연계및통합시키는데있어서가능한단순한모델을이 용하였다. 이런단순한모델을사용함으로써다음과같은장점을가진다. 첫째, 한번에완

155 전한연계및통합하려는어려움을피할수있다. 둘째, 프로세스의통합과통합된아키텍 처의문서화를연기할수있다. 셋째, 12207:1995 와 15288:2002 의현재까지경험을이 용할수있다. 넷째, 사용자커뮤니티에서받아들일수있도록서서히발전시킬수있는기 회를제공한다. 현재존재하는표준에최소한의변경을위해아래사항을적용하였다. ➀ 공통용어사용 ➁ 이용가능한공통프로세스이름사용 ➂ SWG5 가이드라인에따름 ➃ AMD 통합 ➄ 평가목적을위한프로세스레퍼런스모델정보추가 2.1 표준기술의상세화비교분석 12207:1995 와 AMD 그리고 15288:2002 의아키텍처비교는아래그림과 같다 :1995 는프로세스, 활동(Activity), 작업(Task), 리스트(List) 순서로상세 화(Detail) 된다 AMD 는프로세스, 컴포넌트프로세스 (Component Process) 순서로상세화된다 :2002 는프로세스, 활동, 노트(Note) 순서로상세화된다 : :Amd Process Process Process preamble Purpose Outcomes Purpose Outcomes Increasing Level of Detail Activities Component Process Purpose Outcomes Different name, but the same level of detail. Activities Tasks (Some) Lists Same name, but not the same level of detail. Notes 12207:1995 의활동은 12207:AMD 의컴포넌트프로세스와이름은다르지만같은상 세화수준(Level) 으로기술한다. 또한 12207:1995 의활동은 15288:2002 의활동과이 름은갖지만동일한상세화수준으로기술하지않는다. 연구에서제안하는방법은각각의이름과기술수준을반영한아래그림과같이프로세 스, 컴포넌트프로세스활동, 작업, 노트순으로상세화수준을갖는모델이다

156 Proposed Process Purpose Outcomes Component Process Increasing Level of Detail Purpose Outcomes Activities Tasks Notes 이렇게제안하는이유는, AMD의컴포넌트프로세스는 12207:1995 의활동과 매우유사하기때문이다. 이러한개념은아래그림처럼나타낼수있으며기술의상세화를 위해붙여진이름은중요한고려요소가아님을알수있다. 연구보고서에서는활동과목 적(Purpose) 그리고결과물(Outcome) 을더해간단히컴포넌트프로세스라고명명하였 다. Component Process Activity Purpose Outcomes Activity Purpose Outcomes 또한연구에서제안한 과 을각각 12207R 과 15288R 로구분하였다

157 R 12207R 에서목적(Purpose) 과결과물(Outcome) 을갖는각각의프로세는컴포넌트프 로세스혹은활동으로분해되며각각의컴포넌트프로세스는고유의목적과결과물을갖는 다. 그아래에는작업, 노트순서로상세화수준정도가증가한다. 또한 PRM 부록 (Annex) 은목적과결과물정보를수집한다. 연구에서제안한 12207R 모델은아래와같 으며가독성(Readability) 을위해컴포넌트프로세스의결과물은생략할수있다 R 15288R 에서목적(Purpose) 과결과물(Outcome) 을갖는각각의프로세는활동들로구 성되며그아래에는작업, 노트순으로상세화수준이증가한다. 또한 PRM 부록(Annex) 은목적과결과물정보를수집한다 R Process 15288R Process P+O P + O Component Process P + O Activities Activities Tasks Tasks Notes Notes PRM Annex PRM Annex

158 2.4 표준과 15288R 및 12207R 과의관계 현재표준인 AMD, 12207:1995, 15288:2003 과제안한 12207R, 15288R 과의관계는아래그림과같다 AMD에서프로세스는 12207:1995 의프로세스와 같고, 이는 12207R 에그대로반영되고각프로세스의목적과결과물또한 12207R 에반 영된다 AMD의컴포넌트프로세스는 12207:1995 의활동과같고이는 12207R 의컴포넌트일부프로세스와일부활동에반영된다 AMD의컴포넌트프로세스의 일부목적은 12207R 의컴포넌트프로세스의목적이되며나머지다른목적과결과물은 12207R 의 PRM 부록에반영된다 :1995 의작업은 12207R 의작업에반영되며 12207:1995 의리스트는 12207R 의노트에반영된다 :2003 의프로세스와각프로세스의목적과결과는 15288R 의프로세스및목적 과결과에반영되고 PRM 부록의목적과결과물에도반영된다 R 에는활동이라는 상세화정도레벨이프로세스아래에추가된다. 이는 과상세화를정도를맞추기위 해추가시킨것이다 :2003 의활동과노트는각각 15288R 의작업과노트에그대 로반영된다. 프로세스들이갖는각각의관계는아래와같이 3 가지경우로나누어진다. 첫째, 'is-part-of' 관계는한프로세스가다른프로세스의일부분임을표시한다. SW