작업분할구조도(WBS:Work Breakdown Structure)(1) 범위관리 2010/03/19 16:13

http://blog.naver.com/jtum/50084957807

프로젝트를 수행하다보면 종종 "프로젝트의 범위는 어디까지인가?", "이것도 해야하는 것인가?"라는 질문을 많이 갖게 됩니다. 프로젝트 팀원에서 부터 프로젝트관리자까지 종종 프로젝트가 납품해야 할 것이나 해야할 일을 누락하는 경우를 볼수 있습니다. 이것은 프로젝트가 체계적으로 관리되지 못하고 있다는 것을 의미하며, 구체적으로 해야할 일을 명확하게 정의하지 않은 경우 발생하는 것입니다.즉, 요구사항을 명확히 해석하여 그에 대응하는 작업을 규정하였고, 이를 수시로 점검하였다면 과업의 누락은 발생하지 않게되는 것입니다.

이때, 프로젝트에서 해야할 일들을 체계적으로 정의하는 도구로 작업분할구조도를 사용합니다. WBS는 MS 프로젝트에서도 사용하는 기본양식입니다.

본회에서는 WBS의 정의와 구조에 대해 설명하겠습니다.

1. WBS는 무엇인가?

사전적인 의미로는 프로젝트의 범위와 최종산출물을 세부요소로 분할한 계층적 구조도라고 정의하며, 다음과 같은 역활을 수행합니다.

1.1 WBS의 역활

1) 프로젝트에서 수행할 업무 식별을 위한 툴

흔희 프로젝트의 시작은 요구사항 분석부터라고 합니다. 그러나, 대부분의 개발팀원들은 요구사항분석을 개발과정의 일부로써 프로젝트가 시작한 후에 하는 것으로 알고 있으며, 프로젝트의 시작은 개발자들이 모두 구성된후 kick-off meeting을 하는 것으로 잘못알고 있습니다. 정확한 프로젝트의 시작은 프로젝트 관리자의 임명에서 시작합니다. 즉, 임명된 프로젝트의 주관리자가 있어야 프로젝트의 모든 예산을 수립하는데, 이러한 예산은 요구사항에 근거한 작업범위로 산출하게 되는 것이며, 작업의 종류와 범위는 PM이 WBS에 근거하여 업무를 식별한 후에야 파악이 가능하게 됩니다.

2) 프로젝트의 일정과 원가, 자원요구사항 식별을 위한 툴

대충대충산정하여 프로젝트를 수행하는 경우, 예상못한 작업으로 인해 많은 낭패를 경험한 적이 있을 것입니다. 이것은 누락된 작업이 일정에 차질을 주었고, 지연된 일정을 만회하기 위해 더 많은 공수를 투입하는 비용지출의 결과를 불러오게 됩니다. 이를 예방하기 위해 WBS는 프로젝트의 작업에 대한 일정/원가를 산정하는 기초자료를 제공합니다.

3) 작업에 자원을 배정하기 위한 툴

어떤 일을 누가 무엇을 가지고 할지를 정해야 하는 것을 도와 줍니다. 즉, 직무할당표 (RAM:Responsiability Assign Matrix )도 사용되기도 하지만 작업에 대한 자원 즉, 공수를 배정하는 것은 WBS가 적격입니다.

4) 프로젝트의 생산성 통제를 위한 툴

WBS가 프로젝트의 생산성을 통제할수 있다는 것은 아닙니다. 다만, 통제의 기반이되는 작업의 종류와 규모를 나열하기에 생산성을 예측하고 프로젝트 중간에 변경이 발생하면 이를 통제할수 있다는 것입니다. 즉, 범위의 변경은 WBS의 변경으로 통제되는 것입니다.5) 고객, 프로젝트 팀 등 Stakeholder와의 의사소통을 위한 툴

WBS는 아래그림처럼 구조도로 표현되기도 하고 표로 표현되기도 하여, 프로젝트의 모든 인원이 각 작업에 대한 세부작업과 담당자를 쉽게 식별할수 있도록 표현하고 있습니다.  따라서, 이 자료는 범위변경 즉, 요구사항의 변경발생시 가장먼저 체크해보아야 할 사항중 하나로 사용될 만큼 고객과 의사소통의 수단이 되는 것입니다. 또한, 이후에 또 설명하겠지만, PWBS, CWBS등으로 나뉘어 계약적/후의 결정된 작업을 구분하는 계약서의 일부역활을 담당하기도 합니다.

1.2 WBS에 대한 오해

WBS는 업무나 결과물을 시간적으로 나열하는 것이 아닙니다. 단지, 전체업무를 점차적으로 작은 업무로 쪼개놓아 세부적으로 식별한 결과물입니다. 흔히들 MS project가 WBS를 이용하기에 일정관리를 WBS로 해야 한다는 둥 애기하기 쉬운데, 정확히 얘기하면, 일정관리는 Project plan으로 하는 것이며, MS project가 이를 지원하는 도구이고, WBS는 일정의 기초가 되는 작업을 세분화하는 기법인 것입니다.

모든 작업은 프로젝트의 요구사항에 기반하여 정의하므로, 개발 및 관리업무 모두를 빠짐없이 기술해야 합니다.

WBS(2) 범위관리 2010/04/08 16:13

http://blog.naver.com/jtum/50086182931

지난 시간에 이어 WBS의 구조에 대해 상세히 살펴보기로 합니다.

2. WBS의 구조

2.1 계층적 분할

WBS의 계층구조를 구체적으로 살펴보면 다음과 같습니다.

윈도우의 폴더구조와 마찬가지로 푀상위에 프로젝트가 배치되면서 하위레벨로 내려가면서 보다 구체적인 작업으로 분할되는 구조를 가집니다. 위 그림에서 보듯이 프로젝트의 주요산출물별로 세부 부속산출물을 정의하고 이에따른 인력배치와 수행작업을 정의합니다. 따라서, 레벨3에서의 변경(예: 요구사항변경)이 발생하면 얼마나 많은 작업이 조정되어야 할 지를 예측할수 있게 되는 것입니다.

2.2 관점 분할

WBS는 2.1에서 예를 든것과 같이 산출물 중심으로 작성할수 도 있으며, 관점에 따라 다양하게 분할할수 있습니다.

• SDLC(Software Development Life Cycle)별 : SDLC별로 진행상태를 측정하기 위해 사용하는 것으로 주로 공정관리를 하기 편리합니다. 그러나, 산출물이 정확하게 도시되기 어렵고, 짧은 주기에 반복적으로 SDLC가 수행되는 Agile같은 경우에는 적합하지 않은 방법입니다.

• 지역별 : 프로젝트가 여러지역에 걸쳐 수행되면서 지역별 산출물이 종합되는 경우 많이 사용하는 기법입니다. 예를들면 울산의 공장제품이 생산되고 수원에서 이를 판매하는 경우, 제품생산과 판촉상황을 지역별로 종합관리하게 되는 경우입니다.

• 시스템별 :  대형시스템을 수행하는 경우 서브 프로젝트로 분할하여 수행하기도 합니다. 측, 학교전산시스템구축의 경우, 학사관리/수강관리/졸업관리등을 서브프로젝트로 정의하여 관리할 수 있습니다.

• 부서별 : 지역별 관리와 비슷한 개념이나 OBS(Oganization Breakdown Structure)라고 불리웁니다. 부서별 고유 업무와 세부업무를 정의하고 상호 소통해야 할 부분등을 정의하는 것입니다.

2.3분할의 적정성

하위로 분할이 진행되어 세부작업을 도출하는 작업은 산출물 중심의 분할과 프로젝트의 각종 활동적인 관점의 phase중심의 분할을 같이 해야 합니다. 차짓 산출물 중심으로 하다보면 구체적인 활동이 없는 모순이 발생할수 있기 때문입니다.  만약. 산출물 중심으로만 선정하게 된다면 구체적인 활동에 대한 관리는 느슨하게 하는 전략을 구사해야 합니다. 즉, 관리자는 구체적인 활동은 모르지만 결과를 중시하겠다는 전략일 경우를 말합니다.

WBS의 최종 분할단계는 상세작업이 관리가 가능한 수준인 Work package까지라고 PMBOK은 설명합니다. WP의 관리가능한 수준은 다음의 특징을 가지는 경우입니다.  

• 범위, 일정, 원가 추정이 가능한 정도 까지 : 개별활동 또는 부속산출물의 일정/원가등이 추정가능한 정도• 프로젝트에서 수행해야하는 모든 업무가 빠짐없이 정의 : 누락업무는 일정과 비용관리에 치명적입니다.• 완료/진척을 판단할수 있는 측정기준이 있어야함 : 작업의 종료/시작여부를 판별할수 있는 근거가 있어야

합니다.• 중복되지 않아야함• 소수의 인력이 수행할수 있는 수준(1~2명) : 개인별 작업할당이 주요 목적입니다. 여러사람이 동시에 같

은 작업을 하는 경우라도 개개인은 서로 다른 부분을 맡게 되므로 이를 분할하여 정의합니다.보통 2주단위로 WP을 정의하라고 하였지만, Agile을 적용하는 경우에는 빠른 반복수행이 실시되므로 1-2일단위로 WP가 정의됩니다. 방법론과 프로젝트의 성격에 따라 WP의 규정치를 정의해야 하겠습니다.

1%-10% 법칙 : 프로젝트의 규모를 고려한 적정 WP수준 산정Ex)   3개월 기간의 프로젝트 : 90일의 달력상의 기간  = business day 65일

적정 WP수준 : 0.65일(65일의 1%) ~ 6.5일(65일의 10%)

WBS(3) 범위관리 2010/04/22 16:13

http://blog.naver.com/jtum/50087010496

이번회에서는 WBS의 전개에 대해 살펴보기로 합니다.

3. WBS의 전개

일반적으로 WBS는 프로젝트 시작시 작성하는 것으로 알고 있는데, 이것은 잘못된 것입니다. WBS는 제안시에 제안서의 부록으로 작성하고, 계약 후 수정된 범위에 따라 WBS를 수정한 후, 프로젝트 진행중에 간간히 갱신해야 합니다. 이를 WBS의 전개(evolution)라고 합니다.  

3.1 PWBS(Proposed WBS)

WBS와 같은 구조이나 수록된 내용은 제안시에 제안한 내용들이 수록되어 있습니다. 즉, 제안시에 제시하는 모든 업무에 대한 WBS로써 수록되는 내용은 제안서에서 제안하고 있는 모든 프로덕트와 업무에 대해 기술되어야 합니다.  따라서, 사용자의 목표에 이상적으로 일치하는 내용이 다수 수록되어 있습니다. PWBS는 제안서의 부록으로 반드시 첨부되어야 하는 사항입니다. 만약, 누락되어 있는 경우에는 계약시 발생할수 있는 변경요구에 대해 시간/일정/비용적인 측면으로 검토하기 어렵습니다.

3.2 CWBS(Contract WBS)

비용적인 측면과 환경적인 변경등 내외부의 영향으로 인해 계약시 변경된 PWBS의 버전입니다.  Real WBS라고도 합니다. 그 이유는 PWBS는 제안금액에 의한 업무이나, 모든 PJT가 제안과 동일하게 계약하는 경우가 없으므로 CWBS가 제안된 것에 대한 변경버전이 되며, 이것이 프로젝트 기간동안 수행해야할 모든 업무, 즉 범위가 되겠습니다. PWBS가 작성되어 있지 않다면, 프로젝트 시작후 이것을 작성하게 되므로 PM 및 프로젝트 팀원들은 한동안 실제적으로 프로젝트를 시작하지 못하는 것 뿐만 아니라, 생각지도 못한 업무가 발견되어 비용의 증가가 발생하는 등 프로젝트가 실패로 가기 쉽습니다.

3.3 PWBS와 CWBS의 연관성 추적

위 그림에서 보듯이 계약전까지는 PWBS만 존재합니다. 계약후에는 PWBS중 계약된 것만으로 CWBS를 구성하고, 개발과정의 각단계에서 이에 대한 변경분을 추가하는 형태로 작성합니다. 계약내용이나 범위내용이 변경되면 이를 다시 변경유지관리하는 것입니다. 즉, 형상관리관점에서 베이스는 CWBS가 되는 것입니다. 그림에서는 Approved program WBS라고 표현하는 것이 CWBS입니다. 간혹, 발주자가 제안서의 WBS를 제시하고 수행내역이 다르다고 항의하는 경우가 있는데, 이것은 PM이 CWBS를 제시하지 않기에 발생하는 오류이므로 계약후에는 CWBS를 반드시 작성하여 제시해야 합니다. 계약협상시 제시하는 것도 좋은 방법입니다.이를 토태로 사용자의 변경요구시 모든 사항은 변경추가분으로 반영하면 됩니다.

즉, 아래그림처럼 CWBS는 PWBS의 부분집합인 셈이죠.

WBS(4) 범위관리 2010/07/23 18:32

http://blog.naver.com/jtum/50092838129

이번회부터는 WBS작성에 대해 살펴보기로 합니다.

4. WBS의 작성

막상 WBS를 작성하려보니 어디서부터 시작하고 어떻게 해야할지 막막함을 느끼시는 분들이 많으실 것 입니다.WBS는 "프로젝트의 모든 활동(일)"을 정의하는 것이므로 활동에 대한 설계프로세스가 필요한 것입니다. 무작정 시작하다가는 작성하기 어렵다고 포기하거나 누락되는 것이 많아 흐지부지되는 경우가 많습니다. 다음의 프로세스는 미군의 WBS작성표준을 인용한 것인데, 비교적 체계적인 바 추천합니다.

4.1 WBS요소 나열

프로젝트의 모든 활동은 프로젝트의 목표와 일치되어야 합니다. 따라서, 가장 처음 해야 할 것은 프로젝트의 목표와 부합하는 활동과 산출물을 모두 나열합니다. 이를 위해 다양한 기법이 동원될 수 있는데, 브레인 스토밍기법으로 포스트잇에 활동이나 산출물을 기록하여 벽에 붙이는 방법이 전팀원이 참여할수 있는 좋은 방법입니다. 이 단계에서는 모든 요소를 나열하는 것이므로 어떠한 Categorizing이 수행되는 것이 아닙니다.프로젝트에서 사용될 테스트툴이나 관리기법 등등이 모두 남김없이 도출되어야 합니다.Fishbone diagram은 초반부터 활동과 산출물에 대한 그룹화를 전제해야 하므로 현 단계에서는 배제해야 할 기법입니다. 

일반적으로 대부분의 시스템에 적용되는 공통요소는 아래와 같습니다.

• integration, assembly, test, and checkout efforts• systems engineering and program management• training• data• system test and evaluation• peculiar support equipment• common support equipment• operational and site activation• industrial facilities• initial spares and repair parts

프로젝트의 목표에 맞게 적절히 테일러링하여 가감 적용하면 되겠습니다.

4.2 WBS설계

두번째 단계에서는 WBS를 구체화하는 과정으로써 전반적인 개념설계에서 상세한 WBS Dictionary구성으로 설계과정은 진행됩니다. 

4.2.1 개략설계

프로젝트의 기본적인 흐름을 정의합니다. 즉, 분석/설계/개발/시험등의 활동수준으로 상위레벨에 대한 정의를 하는 것입니다. 각 단계의 진입기준/전출기준(Entrance/Exit Criteria)과 활동의 범위등을 정의합니다. 예전의 waterfall방식이라면 개발과정이 명확하게 구분되지만 Agile기법은 반복적인 개발주기가 적용되므로 반복됨에 따른 진화적인 단계설정이 필요합니다. 측, 최초반복이후 두번째 반복에서는 어느 선까지를 구체화할 것인지를 정의해야 하는 것입니다.

4.2.2 WBS요소의 선택

앞서정의된 구성요소들을 개략설계에서 정의한 단계와 연관짓습니다. 이과정에서 categorizing이 자연스럽게 됩니다. 만약, 남는 구성요소가 있다면 이는 개략설계가 미완성이거나 WBS의 설계자가 경험미숙으로 적절히 선택

하지 못하고 있음을 의미합니다. WBS는 경험있는 PM이 멘토하는 것이 매우 도움이 됩니다. 남는 경우에는 개략설계를 추가로 수행하여 상위레벨을 추가합니다. 반대로 연관되는 요소가 없는 것은 다음단계에서 상세화할 수 있으므로 문제사항은 아닙니다.

4.2.3 상세설계

상위단계의 WBS와 구성요소를 상세화하는 것으로써 보다 세부적인 구성단위까지 분할하는 것을 말합니다.예를 들면, 아래그림과 같이 프로젝트의 목표가  "자판기 커피먹기"라면 이에 대한 상세단계로 "이동", "찾기", "결제"가 정의되는 것입니다. 이들은 다시 보다 세분화된 요소로 분할됩니다.  

이동수단으로 자전거/자동차등이 보다 구체화되었습니다. 이과정에서 자판기의 결제수단은 동전만이 아닌 카드도 가능하기에 "결제"로 활동명이 정정되고 세부요소이 추가되었습니다.

이동수단인 자동차에는 앞서 정의된 구성요소중 교육과 정비를 위한 요소가 배치되었습니다.

개발단계는 이보다 훨씬 복잡하고 다단계로 나뉘게 됩니다. 분할되는 단계의 정도에 제한을 두지 마시기 바랍니다. 앞서 WBS의 특성에서 언급한 바와 같이 이 과정은 반복적으로 수행되는 것이며, 최소단위로 분할하는 것이 목표입니다. Agile기법인 경우는 16시간 이상의 작업은 분할할 것을 요구합니다. 작게 분할하면 할수록 팀원개개인에 대한 작업할당은 명확해집니다.

4.2.4 WBS Dictionary구성

작성된 각 WBS항목은 재활용을 위해 Dictionary로 구성되어야 합니다. 즉, 고유ID와 구체적인 설명이 첨부되어야 합니다. 그 이유는 제안시 작성되는 PWBS에서 계약시 작성하는 CWBS를 산출하는 경우, 이에 대한 ID와 설명이 있으면 재구성하기 쉽기때문입니다. 또한, 이후 비슷한 프로젝트를 구성시 앞서 정의한 활동을 재활용할수 있기에 더욱 필요한 작업입니다. 이것은 프로젝트종료시 Lessons Learned가 되는 항목이기도 합니다.

다음회에서는 WBS작성에서 피해야 할 사항과 WBS작성의 남은 단계를 설명하겠습니다.

WBS(5) 범위관리 2010/09/03 15:34

http://blog.naver.com/jtum/50095536526

4.2.5 WBS작성에서 피해야 할 사항

앞서 WBS요소의 나열과 선택을 통해 적절한 WBS요소를 이용하요 WBS를 작성하였습니다. 그러나, 작성하는 과정에서 상당히 아리송한 경우를 겪게됩니다. 요소가 명확하지 않아 두리뭉실 선정하였는데, 이것이 나중에 프로젝트의 불랙홀이 되는 것이죠. 열심히 작성했는데, 왜 이런일이 벌어질까요?

WBS작성에서 피해야 할 사항을 포함했기 때문이죠. 한번 살펴봅시다.

1> 프로젝트의 산출물이 아닌 것은 요소에 포함시키지 말라.

설계문서, CPU등 명확한 산출물은 WBS의 구성요소가 됩니다. 그러나, 설계/테스트 등 기능적요소는 산출물이 명확하지 않기 떄문에 WBS의 구성요소로 선정하지 말아야 합니다. 혹자는 설계 결과물은 설계문서로 정의하면 되는데, 무엇이 문제인가?라고 할수 있지만 세부적인 활동으로 분할할 경우, 최하위에서는 무엇이 산출물이 될지 명확하게 정의할수 있으며, 이것이 정식산출물로 제시되는 것이라면 WBS에 포함되나, 단순한 작업내역에 지나지 않는다면, 해당작업을 필요로 하는 product생산과정에 포함시키고 독자적인 작업으로 설계하지 말아야 합니다. 예를 들면, 시스템설계>주시스템설계>주컴포넌트설계>모듈설계 = 산출물? 여기서 산출물이 정확한 설계문서가 된다면 OK, 없다면 포함시키지 말아야 합니다. 

2> 개발과정은 요소에 포함시키지 말라.

프로젝트의 진행단계(분석/설계/개발 등)는 WBS에 포함시키지 않습니다. 작업을 세분화하기 어렵기 때문이죠. 사실, SCRUM의 경우, 분석/설계/개발이 짧은 주기로 반복되는 데, 이것을 일일이 기술하기 곤란하죠? 

3> 반복적 작업은 포함시키지 말라.

Rework, retesting 등 별도의 요소로 기록하지 말고, 해당작업시 일부과정으로 기술하기 바랍니다. 특히, 매월보고등 반복적으로 수행하는 행위는 WBS에 기술하지 않습니다.

4> 비용절감 작업은 포함시키지 말라.

비용을 절감하기 위한 관리황동 및 보증작업은 해당 작업에 영향을 받는 산출물에 모두 포함시킥고 별도로 기술하지 않습니다. 그래서, 품질활동이 수반된다면 10-30%의 품질비용을 추가하는 이유가 여기에 있는 것입니다.

5> 개발조직은 포함시키지 말라.

WBS는 해야될 작업을 명확하게 설계하고 이에 대한 담당자를 배정하기 위한 기초자료입니다. 따라서, 작업을 명학하게 정의하기 전에는 담당자를 고려하지 않습니다. 즉, 무엇이 필요할지 모르는데, 물건부터 사는 오류를 범하지 말자는 것이죠. 개발을 위해 구성된 조직을 토대로 WBS를 구성하는 것은 구성원중심의 작업을 나열하게 됩니다. 따라서, 정확한 작업을 정의할수 없게 됩니다. 조직이 먼저 구성되면 WBS는 완성하기 어렵습니다. 그이유는 조직 편향적인 작업을 정의할수 있기 떄문입니다.

6> 직접비용 작업은 포함시키지 말라.

비용을 직접적으로 산정할 수 있는 작업(재료구입/출장//장비지원 등)은 별도의 작업으로 기술하지 말고, 연관된 산출물에 포함하여 산정합니다.

7> 작업명은 구체적인 명칭을 사용하라.

WBS는 명확하게 작성해야 하므로 시스템의 구체적인 이름이 있다면 이것을 이용하고 불명확하거나 익명을 사용하는 것은 삼가해야 합니다. 

(O) 주시스템설계>1부속설계>101Part설계

(X) 시스템설계>파워설계> : 어떤 시스템설계인지? 어느 파워를 설계한다는 것인지?

8> 간접비용 작업은 포함시키지 말라.

임대/수리/연구비용등 제품생산을 위한 활동에 수반된 간접비용 작업은 별도의 작업으로 기술하지 말고, 연관된 산출물에 포함하여 산정합니다.

9> 소프트웨어 비용은 산출물에 포함한다.

산출물을 생산하기 위해 작성된 소프트웨어 작업은 산출물생산작업에 포함시킵니다. 예를들면, 산출물을 위해 소트웨어로 툴을 제작하였다면 이것은 산출물작성 작업의 하부작업으로 배치하야 선정해야 하며, 별도의 작업으로 기술하지 말아야 합니다.

위와 같은 사항을 살펴보면 다음과 같은 의문이 발생하게 될것입니다. 산출물의 형태를 모르는 초기단계에서 어떨게 작업을 구체적으로 정의할수 있는가? 조직을 포함시키지 않고 어떻게 작업 담당자를 할당하는 가? 등이죠.

이런 질문은 WBS 프로세스에 아직 익숙하지 않기에 발생하는 것입니다. WBS는 처음작성한 후 변경되지 않는 것이 아닌 조금씩 구체화해야 하는 것입니다. 초기단계에서는 개념적인 설계가 수행되고, 분석/설계과정등을 통해 구체적인 산춤물의 모습이 정의됩니다. 또한, 개발조직은 단계별로 변경되어야 합니다. 물론, SCRUM에서는 이러한 변경이 담당자단위로 행해지기에 조직의 개념은 별로 존재하지 않습니다. 프로젝트 제안초기에 반복적인 작업을 통해 산출물을 구체화하는 경우에는 구체적인 작업을 예상할수 있습니다.

4.3 WBS후속작업

WBS는 프로젝트의 제안초기에 작성되는 것이며, 이것을 이용하여 입찰/계약을 한다고 앞서 설명드린바 있습니다. 작성된 WBS를 이용하는 후속 작업은 다음과 같습니다.

4.3.1 WBS제안

작성된 WBS에 회사의 산정기준을 적용한 비용산정후 이에 대한 구체적인 제안을 수행합니다. 가급적 세부적으로 분할된 작업별로 비용을 산정하기 바랍니다. 향후 협상 또는 계약시 선정된 작업별로 비용을 변경 또는 포함시켜야 편리하기 때문입니다. 제안시 수반되는 작업인 계획/교육등도 모두 해당되는 제품산출작업의 일부로 WBS에 포함하여 산정해야 합니다.

4.3.2 WBS계약

계약에는 제안된 WBS를 토대로 재수정한 계약WBS가 작성되어 첨부됩니다. 이것은 SOW(Statements of Work),즉 작업목록으로 정의됩니다. SOW는 주로 산출물 목록을 말합니다. WBS의 요약본인 셈입니다. 당연히, 계약이후부터는 형상관리를 통해 WBS는 변경관리를 수행해야 합니다.

4.3.3 WBS관리

프로젝트 수행중에 하는 관리를 말하며, 진척관리를 통해 작업의 진척상황에 따라 추가작업을 정의하거나 세분화는 과정을 말합니다. 수행중에도 끊임없이 WBS는 세분화되고 통합되는 진화의 과정을 거칩니다. 이러한 변경은 Lessons Learned로 남아 향후 미래프로젝트 수행의 밑거름이 됩니다.

WBS(6) 범위관리 2010/09/17 14:42

http://blog.naver.com/jtum/50096337983

5. WBS작성예

지금까지 설명한 것을 토대로 실제 작업을 한번 해보겠습니다. 실제로 벌어지는 작업을 순서적으로 설명하겠습니다. 약간 반복되는 것이 있지만, 복습이라고 생각하기 바랍니다.

5.1 Contract WBS와 SubContrct WBS

 Proposal WBS에서 Contract WBS를 선정하여 관리하며, 만약, 하청업자가 있는 경우에는 WBS를 연관하여 작업을 관리해야 합니다. 그렇지 않다면, 해당작업은 누락되기 쉽습니다.

5.2 작업의 할당

조직과 작업이 교차되는 단계입니다. 정의된 작업을 누가 담당할 것이고 어느정도의 노력이 들어갈 것인지에 대해 검토합니다. 각각의 작업단위에서 비용관리가 발생하므로 Cost Account라고 합니다. CA는 복수개의 WP로 구성될 수 있습니다.

5.3 작업의 분할과 상세화

할당된 조직에서 각 작업을 상세하게 분할합니다. 그래야 정확한 비용이 산정될수 있고, 작업이 명확하게 정의될수 있습니다. 각 CA별로 분석/설계등의 개발단계가 적용됩니다. SCRUM이나 RAD와 완전히 일치하는 개념이죠? WBS가 구시대의 유물이라고 혹평하시는 분은 이런 단계를 간과하신 것입니다. WBS는 쉽지 않은 작업이지만 반복하여 연습하면 누구나 숙달하여 작성할수 있고, 쉽게 관리할수 있습니다.

구체적인 작업들은 다시 WP에서 언급하듯이 관리가능할 정도로 구체화합니다. 아래와 같이 CSCI 즉 형상관리에서 Checkin-out하는 구성요소가 도출될때까지 작업은 진행되는 것입니다. 아래와 같은 다단계 분할은 당연히 발생하는 것입니다. 다단계로 도출되는 작업에 대한 실제 사례를 다음회에서 설명하겠습니다. 

5.4 기타작업의 추가

지금까지 요구사항에서 WBS를 추출하고 이를 토대로 SOW와 계약WBS를 작성하였습니다. 작성된 WBS에 추가적으로 실제 프로젝트관리를 위해 필요한 작업들을 추가하고 일정을 추가하여 프로젝트 계획을 완성하는 것입니다. 범위관리에서는 WBS만 만들기에 여기서는 SOW까지만 설명하였습니다. 통합관리에서 프로젝트계획서작성을, 그리고 일정관리에서 프로젝트일정 작성에 대해 설명하겠습니다.

WBS(7) 범위관리 2010/09/17 15:03

http://blog.naver.com/jtum/50096339012

6. WBS작업 정의 사례

5.3에서 언급한 구체적인 작업정의 사례를 소개하겠습니다. 이것은 실제 작업에 투입되었던 것으로써 대형프로젝트의 시스템설계작업에 대한 것입니다. 시스템설계팀에서 직접 작업한 것을 그대로 올린 것이며, 모든 프로젝트가 반드시 이것과 같지 않으니 참고하시기 바랍니다. 이것은 WP가 아니며, WP정의전에 작업을 명확하게 정의하기 위한 설계자료입니다. 이러한 과정을 거쳐 최종적으로 WP가 정의됩니다.

6.1 요구사항 분석절차

여기서 요구사항은 시스템차원의 전반적인 요구사항을 의미하는 것입니다. 즉, 하드웨어/소프트웨어를 총 망라한 요구사항입니다. 시스템적인 요구사항을 어떻게 분석하는 지 세부적인 절차를 샘플로 제시하였습니다.

[그림 1] 요구사항 분석 절차

4.1.3.1 요구 분석조직은 체계가 무엇을 수행할 수 있는 지, 체계가 정량적으로 적절한 조건 하에서 얼마나 잘 수행되는가, 체계가 수행되는 환경, 사용자/체계 인터페이스 요구사항, 물리적/미적 특징, 설계 제한사항 등을 규명하기 위한 목적으로 요구 분석을 실시한다. 시장 수요, 요구사항, 제한사항은 사용자의 기대, 프로젝트 제한사항, 외부 제한사항, 그리고 고수준 체계 요구사항로부터 도출된다. 이들은 요구사항 베이스라인에서 문서화된다. 요구사항 베이스라인은 체계공학의 나머지 활동들을 통제하며 해결되어야 할 문제를 정의한다. 요구사항 분석과 관련된 작업은 [그림 1]에 식별되어 있다. 조직은 4.1.3.1.1~4.1.3.3.4에서 정의된 입력자료를 평가 및 분석해야 한다. 이는 비용, 스케쥴, 성능, 위험요소 식별, 기능적 성능 요구사항 정의, 불일치 사항을 규명하기 위함이다.

4.1.3.1.1 요구사항 식별조직은 체계에 대한 사용자 기대사항을 정의하고 정량화한다. 사용자 기대사항은 마케팅, 사용자 주문, 시장 기회, 사용자와의 직접 대화, 혹은 상위체계 요구사항으로부터 도출된다. 사용자 기대사항은 다음과 같다.a) 체계가 수행할 수 있는 것(기능 요구사항)b) 각 기능이 얼마나 잘 수행될 수 있는지(성능 요구사항)c) 체계의 산출물이 운영될 자연적/유도된 환경d) 제한사항(예산확보, 비용/가격 목표, 일정, 기술, 재사용 항목, 설계 특징, 등등)

사용자 기대사항 정의는 체계 설계 및 성능에 미치는 영향 및 인간 공학(지식, 기술, 능력, 가용성, 신뢰도, 등등)에 미치는 영향을 분석한 것과 일관성이 유지되어야 한다.

4.1.3.1.2 제약사항-내부 제약사항

a) 이전 개발단계에서 승인된 규격과 베이스라인b) 갱신된 공학적/기술적 계획c) 팀 구성 및 구조d) 자동화 도구 사용가능성과 사용 승인e) 통제 체계f) 기술 진보를 측정하기 위한 기준

-외부 제약사항a) 선행된 기술 검토회에서 결정된 지시사항 b) 조직의 일반 규격, 기준, 지침c) 정책과 절차d) 업무 기술e) 확정된 수명주기절차의 내용f) 기술적 노력을 위한 물리적, 재정적, 인적 자원의 할당

4.1.3.1.3 외부 제약사항 정의a) 국내외 법규 및 규정b) 기술 수준c) 산업 규격, 표준, 지침d) 인력 관련 규격, 표준, 지침e) 인력 가용성, 채용, 선발f) 경쟁 상품 품질

4.1.3.2.1 운용 시나리오 식별조직은 체계 산출물의 예상된 사용의 범위를 가늠할 수 있는 운용 시나리오를 식별한다. 각 운용 시나리오에 대해 조직은 환경 및 타 체계(인력 업무 순서, 타 체계/플랫폼/산출물과의 물리적 상호연결)과의 예상되는 상호작용을 정의한다.

4.1.3.2.2 효용측정방안 식별조직은 전반적인 사용자 기대사항과 만족사항을 반영하는 체계 효과 측정을 정의한다. 주된 MOE로서 성능, 안전성, 운용성, 사용성, 신뢰성, 유지보수성 등등이다.

4.1.3.3.1 체계범위 식별a) 어떤 체계 요소가 통제 대상인지, 어떤 요소가 통제 대상이 아닌지b) 통제 대상 체계 요소, 외부/상위 수준 요소, 타체계요소들간의 예상되는 상호 작용

4.1.3.3.2 인터페이스 식별조직은 외부/상위 수준과 그리고 타 체계와의 기능적, 설계 인터페이스를 정의한다.

4.1.3.3.3 운용환경 식별조직은 각각의 운용 시나리오에 대해 이용환경을 정의한다. 체계 성능에 영향을 미치는 모든 자연적/유도된 환경적 요소들이 식별되어야 한다. 체계는 치명적 사고나 사망을 야기하고, 사망, 부상, 급성 혹은 만성 질환, 장애를 일으키며 체계수명주기를 지원하는 인력의 작업능률을 감소시키는 인력이나 기계의 오류나 파손 가능성을 최소화하기 위해 이를 입증하는 요소들을 정의한다. 구체적으로 보면 날씨 상황, 기온 범위, 위상관계, 생물학적, 시간적, 그외 모든 환경적 요소들을 고려하여 체계를 운용할 지역 및 상태로 상정한다. 하드웨어, 소프트웨어, 인력에 미치는 영향은 체계의 업무수행 능력과 수명주기절차에 미치는 영향에 대해 중점적으로 다루어야 한다.

4.1.3.3.4 수명주기 활동개념 정의-인력

체계 수명주기 절차를 지원하기 위한 인력 수를 결정하기 위해 요구된 업무와 그와 관련된 작업량을 정의한다.

-인사체계 수명주기 절차를 지원하는 인력과 관련된 업무 수행에 필요한 경험, 적성, 지식, 기술 및 능력을 평가하고 결정한다.

-교육 훈련체계 수명주기 절차를 지원하기 위해 필요한 지식과 직무 기술을 인력 및 팀에게 제공하기 위해 교육, 현장 훈련 등을 식별하고 개발해야 한다.

-인간 공학체계 수명주기 절차를 지원하는 인력의 인지적, 물리적, 감각적 특징을 식별하여야 한다.

-안전성중대한 위험(사망, 상해 등)을 초래하거나 체계를 운영, 관리, 지원하는 인력의 업무능력을 저하시킬 수 있는 체계 설계상의 특징을 설명할 수 있어야 한다.

4.1.3.4.1 기능요구사항 식별체계가 무엇을 할 수 있는지(기능적 요구사항)을 정의하기 위해 기능 배경 분석(4.1.3.6.1)을 수행한다. 식별된 기능은 그것이 어떻게 잘 수행되어야 하는지 정의하고, 성능 요구사항을 규명하기 위해 사용된다. 기능 배경 분석을 통해 식별된 기능들은 설계 대한을 식별하고 평가하기 위한 토대을 제공하기 위해 기능 분할과정을 통해 분해된다. 체계의 모든 요구사항은 기능적 및 성능적 면을 포함한다.

4.1.3.4.2 성능요구사항 식별체계의 각 기능에 대해서 성능 요구사항을 정의한다. 성능 요구사항은 MOE를 만족시키기 위해 기능적 요구사항들이 어떻게 잘 수행되어야 하는지를 기술한다.이러한 성능 요구사항은 기능 분할 과정에서 부기능으로 할당되는 MOP이며 종햡 설계시 도출되는 설계 방안이 측정되는 판단기준이다. 수용 가능한 성능 범위를 결정하는 MOE 각각에 대해 몇몇개의 MOP가 존재한다.

4.1.3.5.1 운용상태 및 모드 식별개발중인 체계 산출물에 대한 다양한 운용 모드를 정의한다. 운용 모드를 결정짓는 상태(환경적, 형상적, 운용적 등)를 정의한다.

4.1.3.5.2 기술성능평가 방안 정의체계 성능을 가장 잘 나타낼 수 있는 TPM을 식별한다. TPM의 선택은 충족되지 않았을 때 비용적, 시간적, 성능적 위험을 초래하는 MOP로 한정되어야 한다. TPM 활동은 정기적으로 성과 및 계획 대비 진척상황을 측정하기 위해 SEM으로 통합된다.

4.1.3.5.3 설계특성 식별개발중인 체계 산출물에 대한 설계 특성을 식별하고 규정한다. 대안 분석을 통해 어떤 설계 특성을 제한하고 어떤 설계 특성을 변경시켜야 할지 결정한다.

4.1.3.5.4 인간공학요소 식별개발중인 체계의 운영에 영향을 미치는 인간행동 고려사항(공간 한계, 기후 한계, 시선 움직임, 인간 공학, 인지 한계 등)을 식별하고 정의한다. trade-off 분석을 통해 어떤 인간행동 요소를 제한하고 어떤 인간행동 요소를 변경시켜야 할지 결정한다.

-요구기준선 설정4.1.3.1.1에서 4.1.3.5.4까지의 작업의 산출물은 세가지 관점(운용적, 기능적, 설계)에서 기록되고 이들은 요구사항 기준을 이루게 된다. 운용적 관점은 체계 산출물이 어떻게 사용자들을 위해 동작하는지를 기술한다. 이는 누가 체계를 운용하고 지원하는지, 어떤 상태에서 어떻게 잘 운영되는지를 확립한다. 기능적 관점은 운용적 관점에서 기술된 동작을 통해 체계가 수행하는 것을 기술한다. 설계 관점은 산출물 개발의 설계 고려사항을 기술하고 장비간, 장비와 인간간의 설계 인터페이스에 대한 요구사항을 확립한다.세가지 관점은 다음과 같은 사항을 포함한다.

a) 운용적 관점1) 운용 요구 기술2) 체계 운영 분석 결과3) 운용 순서/시나리오(이용 환경, MOE, 산출물이 어떻게 사용되어야 하는지를 포함함)4) 산출물이 반응해야 하는 상황/이벤트5) MOE를 포함한 운용적 제한사항6) 임무 및 기술 요구사항이 포함된 인력 역할7) 교육훈련 요구사항8) 안정성을 보장하기 위해 어떠한 운용이 필요한지를 식별9) MOE, 중대한 MOP, 기존 산출물/서비스를 포함하는 수명주기절차 개념10) 타 체계, 플랫폼, 인간, 산출물과의 운영적 인터페이스11) 체계 경계

b) 기능적 관점1) 체계 산출물이 무엇을 수행해야 하는지를 기술하는 기능적 요구사항2) 성능 요구사항(정성적, 정량적, 시간적)3) 목표 달성을 위한 기능적 선후관계4) TPM 판단기준5) 외부, 상위단계, 외부체계, 플랫폼, 인간과의 기능적 인터페이스 요구사항6) 운영 모드7) 진화적 성장을 위한 기능적 능력

c) 설계 관점1) 기 승인된 규정 및 기준선2) 외부체계, 플랫폼, 인간과의 설계 인터페이스3) 안정성, 교육, 지식, 기술, 체계 기능을 수행하기 위해 필요한 능력 등을 포함하는 인간 체계 공학 요소4) 운영자 및 지원인력의 특징5) 정보 표시 및 운영자 통제의 특징6) 설계 제한, 기술 제한, 인간 능력 제한 등을 포함한 체계 특성7) 설계 제약사항8) 계획된 성장을 위한 설계 능력

WBS(8) 범위관리 2010/09/23 14:37

http://blog.naver.com/jtum/50096629739

6.2 기능 분석절차

방법론을 조금 공부하신 분은 벌써 눈치채셨을 것입니다. 이 샘플은 구조적접근방식을 적용한 작업절차입니다. 그래서 기능분석이라는 단계가 있는데, 이것을 이제는 안쓰는 낡은 것이라고 간주하지 마시기 바랍니다. 요즘사용하고 있는 Agile이나 RAD에서도 이러한 절차를 다른 모습으로 수행하고 있습니다. 성능기준선이나 Side effect분석등이 이것에 해당되는 것입니다. 

[그림 2] 기능 분석 절차기능 분석

다음의 두 가지 연관된 목표를 달성하기 위해 기능적 분석을 실시한다.a) 요구사항 분석에서 정의된 문제점을 더욱 상세히 기술하기 위해b) 체계 기능을 체계 설계 요소(부체계, 컴포넌트, 부품)에 의해 만족되도록 하위수준 기능으로

분할하기 위해

이것은 승인된 요구사항 기준을 기능적 아키텍쳐로 변화시킴으로서 완성된다. 기능적 아키텍쳐는 체계 기능을 부기능으로 분할한 후 기능을 배열하고 부기능의 선후관계를 기술할 것이다. 기능적 분석은 설계 방안을 고려하지 않고 수행되어야 한다. 통합설계(6.5)을 통해 생성된 부기능 그룹은 산출물 및 부체계 방안을 정의하는 지침과 기준을 정한다.

기능 배경 분석

체계 목표 달성을 위해 필요한 자극(입력)에 대한 반응(출력)을 결정하기 위하여 각 체계 기능을 분석한다.

4.1.3.6.1 기능적 활동 분석다양한 상황하에서 체계의 기능적 행동을 이해하기 위하여 그리고, 기능적 아키텍처의 무결성을 평가하기 위해 분석이 수행된다.모델을 과부하 상황과 과부하 외 상황에 노출시키는 운영 시나리오를 이용하는 기능 모델 시뮬레이션이 분석에 포함되어야 한다.

4.1.3.6.2 기능적 인터페이스 식별체계 기능이 부기능으로 분해되면서 상호작용을 하는 기능사이의 인터페이스가 생성된다. 조직은 이러한 인터페이스를 식별하고 그들의 초기/종료 상태, 입/출력과 같은 기능적 상호작용을 정의해야 한다.

4.1.3.6.3 성능요구 사항 할당성능 요구사항은 할당될 수 있는 집합으로 나누어지거나 기능으로 직접 할당될 수 있다. 직접 할당될 수 없는 요구사항은 연료 용량, 엔진 효율, 차량 저항과 같이 적당한 공학적 기법과 분석을 통하여 도출된 성능 요구사항으로 변환되어야 한다. 조직은 체계 성능 요구사항을 기능 할당하는 것을 문서화하여 추적가성을 제공하고 향후 변화를 용이하게 한다.

² 기능 분할조직은 다음과 같은 것을 정의하기 위해 체계를 부기능으로 분할한다.

a) 대체 부기능 정리 및 순서b) 기능적 인터페이스c) 성능 요구사항

기능적 분할의 정도는 체계가 무엇을 달성해야 하는가를 명확히 이해하는데 달려 있다. 균형잡힌 부기능 그룹를 선택하기 위하여 그리고 성능 요구사항을 부기능에 할당하여 기응 아키텍쳐가 체계 요구사항을 만족시킴을 보장하기 위하여 Trade-off 분석과 위험 분석이 이루어 진다.

² 부기능 정의기능은 기능적 행동, 운영의 상태 및 모드, 데이터 흐름 통제 상태 등등의 관점에서 분해된다. 균형잡힌 부기능 세트를 보장하기 위해 대안 정리 및 부기능의 일련화가 연구되어야 한다. 조직은 중복 정도를 결정하기 위해 부기능 배열을 분석한다. 안전성, 신뢰성 및 다른 요구사항에 특별히 요구되지 않는 중복된 기능은 제거된다. 조직은 최선의 기능 아키텍쳐를 선택하고 그것을 문서화하여 통합된 DB에 저장한다.

4.1.3.7.1 기능별 상태 및 모드 식별조직은 부기능으로 하여금 다른 행동을 취하게 하는 상태 및 모드를 식별하고 정의하기 위해 기능적 아키텍쳐를 분석한다. 이 분석은 부기능의 시작과 종료 상태 사이의 상태 및 모드의 전이를 포함한다.

4.1.3.7.2 기능 우선 순위 식별조직은 각각의 운영 시나리오에 대한 기능적 시간대(timeline)을 식별하기 위해 부기능 연속성과 행동을 분석한다. 기능적 시간대을 지원하면서 각각의 부기능에 대한 실행시간의 범위와 정상/비정상 성능을 초래하는 상태가 식별된다.

4.1.3.7.3 자료 및 통제흐름 식별조직은 각각의 운영 시나리오에 대한 부기능 간의 데이터 흐름을 식별하기 위해 부기능 연속성과 행동을 분석한다. 이러한 데이터 흐름은 DFD나 연관된 객체지향 도해로부터 획득된다.

4.1.3.7.4 기능실패 모드 및 영향 식별조직은 실패 영향을 정의하고 오류감지 및 복구 기능에 대한 요구를 식별하기 위하여 잠재적 기능 실패 모드를 분석하고 우선순위를 부여한다. 각각의 운영 시나리오에 대한 체계 유효성 분석을 지원하기 이해 기능적 신뢰 모델이 확립된다. 안전, 성능, 환경면에서의 심각한 위험을 의미하는 실패는 체계의 영향을 완전하게 이해하기 위해 모델링된다.

4.1.3.7.5 안전감시 기능 식별개인적 상해, 재산적 피해, 환경적 파괴를 야기시킬수 있는 기능적 위험을 식별하기 위해 조직은 부기능 및 부기능 집합을 분석한다. 위험한 운영 상황을 감시하고 운영 자에게 위험을 경고하는 추가적인 기능 요구사항이 파생되고 정의된다.

- 기능적 구조 설정성능 요구사항(이로부터 통합설계를 통해 설계 방안이 결정됨)의 할당을 정의하기 위해 조직은 개발의 수준에 적절한 기능 아키텍쳐를 확립한다. 통합설계에 앞서 기능적 아키텍쳐는 그것이 승인된 요구사항 기준을 충족시킨다는 것을 검증해야 한다.

WBS(9) 범위관리 2010/09/24 14:57

http://blog.naver.com/jtum/50096684826

6.3 종합설계절차

방법론을 조금 공부하신 분은 시스템분석>시스템설계으로 전걔되는 절차를 이해하실 것입니다. 이과정에서 시스템의 전반적인 수명주기와 유지관리를 위한 결정을 수행하고 이것을 바탕으로 설계를 완성하게 됩니다. 이과정은 시스템전반적인 것에 매우 큰 영향을 끼치는 중요한 단계입니다. 이과정을 소홀히해서 완성된 시스템의 수명주기가 단축되는 경우를 많이 보았습니다. 시스템은 구축되는 것도 중요하지만 어떤 시스템을 만드는지 결정하는 것도 중요합니다. 

[그림 3] 종합설계 절차

종합설계 방안조직은 설계 방안을 정의하고 검증된 기능 아키텍쳐 요구사항을 만족시키는 서브체계를 식별하기 위해 통합설계를 수행한다. 통합설계는 기능적 아키텍쳐를 체계 요소의 정리 및 분해, 인터페이스, 설계 제한사항을 제공하는 설계 아키텍쳐로 변화시킨다. 통합의 액티비티는 선호하는 방안의 선택 또는 대안에 순위를 부여하는 것, 관련된 비용, 일정, 성능, 위험을 이해하는 것을 포함한다. 대안을 평가하기 위해 필요하다면 체계 분석(4.1.2.1)이 사용된다. 이를 통해 위험을 식별, 평가, 정량화하여 적절한 위험 최소화 방안을 선택하고, 비용, 일정, 성능 효과를 이해할 수 있다. 서브체계 요구사항이 정의되면 수명 주기 절차에 대한 요구사항, 제약사항이 완성된다. 통합을 정의하는 작업은 [그림 3]에 식별되어 있다.

4.1.4.1.1 기능할당 및 집군화

조직은 승인된 기능적 아키텍처의 공통된 기능과 하위기능들을 논리적인 기능적 요소로 나눈다. 이러한 정리는 체계요소를 설계할 수 있도록 하는 방식으로 이루어진다. 설계 요소로의 배치는 기능적 요소가 기존의 또는 새로이 개발될 요소들에 의해 달성될 수 있을 때 이루어진다. 만약 기능적 요소가 그것의 배치에 있어 분리를 필요로 한다면 기능적인 분리는 이루어진다. 이는 기능적 요소가 하드웨어와 소프트웨어 그리고 인간 사이에서 그것의 배치를 충분히 허용할 때 이루어진다. 요구사항의 추적가성은 모든 기능들이 체계의 요소에 배치되도록 설정되고 기록된다. 각 체계 요소는 최소한 하나의 기능을 수행한다.

4.1.4.1.2 설계 대안 식별조직은 4.1.4.1.1에서 확인된 기능적 요소들을 위한 다른 설계 방안을 개발한다. 이들 방안은 다음 중의 하나 이상으로 구성되어야 한다.: 하드웨어, 소프트웨어, 자료, 데이터, 설비, 사람, 기술. 4.1.4.1.3에서 4.1.4.1.14까지를 수행하면서 대안과 총체적인 대안들은 어느 설계 방안이 할당된 기능적인, 그리고 수행상의 요구사항, 인터페이스 요구사항, 설계상의 제약을 가장 잘 만족시키고, 체계 혹은 그 상위 체계의 총괄적 효율성에 기여할지를 결정하기 위해 분석된다. 이러한 임무를 완수하면서 전문 엔지니어들은 신뢰도, 활용성, 유지보수, 지원, 사용성, 안전성, 건강요소, 보안, 생존성, 전자기적 적합성, 무선의 주파수 등의 요구사항을 확실히 하기 위해 설계 엔지니어와 함께 작업을 한다. 추가적으로 수명주기 과정의 요구사항은 각 체계 대체 폼과 그 수집된 방안들에 대하여 확인되고 정의된다.

4.1.4.2.1 안전 및 환경위험요소 평가조직은 체계 자체, 체계와 그 체계 지원 체계의 수명주기 절차에 참여하는 사람들 그리고 그 환경에 일어날 수 있는 잠재적인 위험을 확인하기 위해 4.1.4.1.2의 대안과 수집된 대안들을 분석한다. 특히 체계의 안전한 작동 평가와, 제조과정, 테스트, 분배, 작동, 지원, 훈련 또는 시대에 뒤떨어지는 지난 체계 처분과 관련되어 생기는 오염물질, 위험물질, 부산물 처리에 특별한 주의가 기울여져야 한다.

4.1.4.2.2 수명 주기 품질요소 평가조직은 4.1.4.1.2의 대안들을 평가하여 그 방안에 어떤 품질적 요소(생산성, 시험가능성, 분배의 용이성, 사용성, 지원가능성, 훈련가능성, 폐기가능성)가 어느 정도 포함될 것인지를 결정한다. 추가적으로 조직은 관련된 수명주기절차가 그 절차들의 필요성, 요구사항, 제약을 확인하고 정의했는지 여부를 평가한다.

4.1.4.2.3 기술 요구사항 평가조직은 4.1.4.1.2의 대안을 평가하여 설계 방안을 효과적으로 하는데 필요한 기술적 요구사항을 결정한다. 어떤 새로운 혹은 진보된 기술을 요구사항에 맞게 도입하는 것과 관련된 위험요소는 확인되고 평가되어야 한다. 조직은 대안을 평가하여 체계를 효과적이게 하는데 필요한 인적 요구사항을 결정한다. 사람들에게 할당된 임무와 역할 작업을 분석하고 평가하여 체계의 한 부분인 개인이 요구되는 지식과 기술 능력을 보유하고 있는지를 결정해야 한다. 훈련과 인사공급체계도 각 요구사항에 맞는지 평가되어야 한다.

4.1.4.3.1 설계 및 성능 특성 정의조직은 대안 설계의 설계와 성능의 특성을 확인하고 문서화한다. 이는 인간의 물리적 인지적 일의 부담 수준을 평가하거나 측정하는 것을 포함한다. 수명 주기 질적 요소와 관련된 설계 상의 특성과 인간공학적인 요소도 확인되고 평가되어야 한다.

4.1.4.3.2 물리적 인터페이스 정의조직은 생산품, 부체계, 사람, 수명주기절차, 외부화 상위수준 체계 또한 상호작용하는 체계와 인터페이스 되는 물리적 인터페이스를 확인하고 정의한다. 설계에 영항을 주는 물리적 인터페이스는 통신, 데이터, 지원, 테스트, 제어, 도시, 연결성 또는 서브체계와 생산품, 인간, 또는 다른 연관된 체계나 상위 수준 체계 사이의 상호작용의 자원의 충족 특성을 포함한다.

4.1.4.4.1 대상 식별회사는 4.1.4.1.2의 대안을 분석하여 표준화된 최종 항목의 사용이 기술적으로나 경제적으로 가능할지를 평가한다.

4.1.4.4.2 상용제품 식별조직은 4.1.4.1.2의 대안을 분석하여 상용제품(비개발적인 하드웨어와 소프트웨어)의 가용성을 결정한다. 각 확인된 상용제품은 평가되어 가격 효과, 양, 유용성, 지원가능성, 공급자와 그 생산품의 생존가능성을 결정해야 한다.

4.1.4.4.3 구매/개발 결정조직은 생산할지 혹은 구매할지의 결정을 지원하기 위해 대안 설계들을 경제적으로 분석한다. 이러한 분석을 통해 조직이 설계 요소를 직접 생산하는 것과 공급받는 것 중 어느것이 좀더 가격면에서 효과적일지를 결정한다.

4.1.4.5.1 프로토타입 개발조직은 다음에 기초하여 모델/프로토타입을 개발한다.

a) 이용가능한 새로운 기술들을 통합하는것과 관련된 위험요소를 확인하고 감소시킨다.b) 설계 방안(하드웨어, 소프트웨어, 자료, 사람, 시설, 기술, 데이터, 서비스로 구성된)이 할당된 기능적

요구사항, 성능 요구사항, 인터페이스 요구사항, 작업 부담의 한계와 제약을 만족하는지 판단한다.c) 설계 방안이 기능적 아키텍처와 요구사항의 기본이 되는 요구사항을 만족시키는지 판단한다.

이러한 모델, 데이터 파일, 지원 문서는 관리 유지되어야 하며, 요구사항, 설계, 의사결정사항에 영향을 줄 수 있는 데이터파일이나 모델의 버전은 통합데이타베이스에 저장되어야 한다. 모델은 디지털화, 부분적이거나 완전한 것일 수도 있고 하드웨어, 소프트웨어 혹은 두 가지의 결합일 수 있다. 혹은 인간 모델이나 사람의 활동에 의한 시뮬레이션, 또는 유용성 테스트나 작업 부담 측정을 위한 모형일 수 있다.

4.1.4.5.2 오류영향 및 파급효과 평가조직은 실패 모드와 그 영향 그리고 대안 설계 실패의 중대요인을 평가한다. 각 대안의 성공적인 수행의 가능성을 평가하기 위해서는 하드웨어, 소프트웨어 그리고 대안 설계의 인력 요소가 평가되어야 하고 이력 또는 시험자료가 공급되어야 한다. 실패모드와 평가 분석(FMEA)은 설계 방안의 강점과 약점을 확인하는데 사용되야 한다. 결정적인 실패에 대해서 회사는 중대성 비율을 매김으로써 각 대안의 우선순위를 결정하는 중대 요소 분석(criticality analysis)을 수행한다. 이 분석의 결과는 중복을 피하고 자연스러운 체계퇴진을 지원하기 위한 향후 설계 작업을 위하여 사용된다.

4.1.4.5.3 시험요구 평가조직은 대안 설계의 테스트 가능성을 평가하여 운용이나 유지 고려사항을 지원할 BIT나 FIT 요구조건을 결정한다. BIT-FIT 메커니즘은 운용자, 사용자, 또는 현장 지원 엔지니어에 의해 정상적으로 유지되는 그러한 요소들을 위해 지원되어야 한다. BIT-FIT는 낮은 수준의 유지 활동을 지원하기 위하여 진단 운용을 위해 쓰일 수 있어야 한다.

4.1.4.5.4 발전적 설계 평가조직은 대안 설계를 평가하여 일단 체계가 생산되거나 시장에 나온 후에 설계 방안이 발전되거나 리엔지니어링, 새로운 기술 적용, 수행능력 강화, 기능성 증가, 혹은 다른 가격면에서 효율적이고 경쟁력 있는 개선사항을 수용할 역량을 결정한다. 어떤 체계가 발전하는 능력에 미칠 제약사항이 확인되어야 하고 그러한 제약사항을 해결하기 위한 접근방법이 분석되고 정의되야 한다. 조직은 생산품에 대해 형상관리를 수행하여 발전할 역량을 지닌 생산품이 가격면에서 효과적으로 리엔지니어링될 수 있음을 확인해야 한다. 발전하는 체계의 지원 가능성은 생산품의 발전에 따라 프로세스 발전의 지원을 포함한다. 이러한 고려사항은 예산과 훈련 요구사항 지원에 크게 영향을 받는다.

4.1.4.6 설계 구조 결정조직은 선택된 대안에 대한 설계를 완성한다. 설계 요소 사이의 (내부와 외부)인터페이스의 표시와 설명이 완성된다.

l 진보적인 개발의 개시조직은 어떤 설계 요소에 대해 위험 수준이 낮은 기술 방안이 선택되었거나 발전할 수 있는 역량이 그 요소나 연관된 요소들로 설계되었을 때 만약 필요하다면 진보적인 개발을 시작한다.

l 통합된 데이터 패키지 생산조직은 통합 데이터 패키지의 선택된 설계 요소를 문서화하는데 필요한 도면, 모형, 소프트웨어 문서, 수동절차를 완료한다.

l 설계 아키텍처 확립조직은 설계 방안과 인터페이스를 문서화하기 위해 개발수준에 적합한 설계 아키텍처를 확립한다. 설계 아키텍처는 체계 요소들 중에 할당된 기능적, 성능적 요구사항 만족을 포함하는 요구사항 추적가성, 할당 도표를 포함한다. 설계 아키텍처의 정의는 할당 아키텍처에 걸쳐 요구사항의 추적가성을 제공하기 위한 trade-off분석, 설계 원리, 중요 결정들과 함께 통합 데이터베이스에 저장되어야 한다. 설계 검증은 아키텍처가 승인된 요구조건과 검증된 기능적 아키텍처를 둘 다 만족시킴을 보여줘야 한다.

WBS(10) 범위관리 2010/09/29 13:37

http://blog.naver.com/jtum/50096968475

6.4 시스템분석절차

6.3과 순서가 뒤바뀐 것 같습니다만 시스템분석의 세부작업입니다. 앞서 말씀드린바와 같이 이모든 것을 모두 프로젝트에 적용하는 것이 아닌 적절히 프로젝트에 맞게 테일러링해야 합니다.

[그림 4] 체계 분석 절차4.1.2.1 체계 분석

조직이 체계 분석을 수행하는 이유는 다음과 같다. : 요구사항 분석동안 확인된 불일치사항을 해결, 기능적 요구사항을 분해, 기능분석동안의 이행요구사항을 할당, 대안 설계 방안의 효과 입증, 제작기간 동안 최고의 설계 방안 선택, 체계 효과 평가, 체계 엔지니어링 과정의 총체적인 위험 요소를 관리하기 위함이다. 체계 분석은 조화된 요구사항을 확립하고 조화된 설계를 마감하는데 정확한 정량적 근거를 제공한다. 체계 분석의 주요 활동은 [그림 4]에 나타나 있다. trade-off 분석이 이루어지지 않았다 할지라도 체계의 총체적인 유효성 평가는 완성될 수 있다.

4.1.2.1.1 요구사항 불일치 평가조직은 요구사항 사이의 상충과 요구분석 동안 확인된 제약사항을 평가하여 필요한 시기에 대체할 수 있는 기능적, 수행상의 요구사항을 확인한다. 요구사항 trade-off 분석과 평가는 위험과 비용, 일정, 수행시 미칠 영향을 고려해서 할당된 일련의 요구사항과 제약사향을 확인하기 위해 이루어진다.

4.1.2.1.2 기능 대안 평가

조직은 기능 분석 동안 기능의 분해와, 성능 요구사항을 하부기능에 할당하기 위해서 하위기능 배치의 가능한 대안을 조사한다. 기능적인 trade-off 분석과 조사를 통해 위험과 비용, 일정, 수행시 미칠 영향을 고려하여 할당된 각 기능의 하부기능과 이행시 요구사항 할당을 확인하게 된다.

4.1.2.1.3 설계 대안 평가조직은 설계종합과젱에서 식별된 디자인 대안으로부터 기능의 집군의 유효성과 할당을 평가한다. 설계 trade-off 분석과 평가는 위험, 비용, 일정, 수행시 미칠 영향을 고려하여 할당된 설계 trade-off를 확인하기 위해 이루어진다.

4.1.2.1.4 위험 요소 식별조직은 위험요소를 확인하여 프로젝트가 성공적으로 수행되게 하기 위해 요구사항분석, 기능분해 결과 얻어진 하위기능 배치, 하위기능의 기능 요소로의 배치, 제작과정에서 얻어진 설계 결정사항 그리고 설계 아키텍처의 설계 요소로부터 요구사항과 제약사항을 평가한다. 이러한 평가는 전체 수명주기를 통해 이루어져야 한다. 위험요소의 확인은 다음 사항을 이해하기 위한 형태로 이루어진다.

a) 위험 상태의 발발과 그러한 가능성을 야기하는 환경b) 위험 상태가 발발한다면 위험요소가 인지될 수 있는 방법c) 위험요소가 가격과 일정 수행도에 영향을 미치는 방법

체계의 성공적인 개발에 미치는 중요도에 기초하여 위험요소의 우열을 확인한다. 위험을 줄이기 위한 활동을 확립하고 감시하며 수용 불가한 위험을 덜기 위해, 개발단계에 따라 받아들일 만한 위험수준을 확인한다.

4.1.2.2 대안 적용 방안 선정조직은 대안 분석의 수행 범위를 정의해야 한다. trade-off 분석은 다음과 같이 이루어질 수 있다.

a) 판단적 – 분석가나 설계가의 판단에 기초하여 선택이 이루어지며 엄격한 원칙적인 연구를 요구하지는 않으며 따라서 결과가 매우 중요하지는 않다. 비교적 우위에 있는 대안이며 좀더 근본적인 접근을 할만한 시간이 없을 때 이루어진다. (SEP의 업무를 수행하는 데 있어 이루어지는 대부분의 대안 분석은 지적형태(지식에 근거한)이다.

b) 비공식 – 공식 대안 분석과 같은 방법론을 따르지만 공식적으로 문서화 되지않고 사용자 입장에서는 덜 중요하다.

c) 공식 – 기술적 검토에서 검토된 결과를 가지고 공식적으로 수행된다.

비공식과 공식 대안 분석에서는 목적과 수행, 데이터 수집의 요구사항, 활동일정, 결과분석 그리고 기대되는 결과가 완전히 정의된다. 각 대안 분석은 경쟁되는 여러 대안 중에서 사용자의 요구, 체계의 효과, 비용에 맞는 설계, 수용 가능한 수준의 위험이내에서 수명주기의 비용목적을 만족하는 대안을 선택할 목적으로 이루어진다.

4.1.2.3 대안분석 실시조직은 다음에 대한 대안 분석을 완수하기 위해 4.1.2.3.1에서 4.1.2.3.4까지를 적당 수준으로 이행한다.a) 불일치사항을 완화하고 사용자/시장의 필요, 요구, 제약을 만족시킬 수 있는 요구사항 분석b) 기능의 하위기능으로의 세분화를 지원하고 이행 요구조건을 할당하기 위한 기능 분석c) 설계 결정사항 지원을 종합

공식, 비공식 대안 분석은 각 대안에 적합한 자료를 산출하기 위해, 통제되는 조건하에서 이루어진다. 대안 분석 결과는 각 대안이 체계에 미치는 영향이나 기술적인 노력을 정량화 하기 위해 기록되고 분석된다. 이러한 결과는 어떠한 대안을 선택할 것인지 결정하기 위해 성공기준과 비교 평가 된다.

4.1.2.3.1 수명주기 비용 분석조직은 대안 분석이나 체계 유효성 평가에서 고려된 대안 체계에 대한 접근에서 조직과 사용자가 소비한 비용을 분석한다. 수명주기 분석은 다음 사항을 제공한다.a) 대안 분석결정을 지원하기 위한 필수적인 가격 정보를 제공한다.b) 체계의 효과분석에 필수적인 가격정보를 제공한다.c) 개발, 제조, 테스트, 배포, 운용, 지원, 교육, 폐기에 필요한 비용을 포함한다.d) 확정된 비용목표, 그러한 가격에 대한 현재의 평가, 그러한 비용의 알려진 불확정성을 포함한다.e) 제안된 변경사항이 수명주기 비용에 미치는 영향을 확인한다.

4.1.2.3.2 비용 효과 분석조직은 다음과 같은 목적으로 체계의 유효성과 수명 주기 비용 사이의 관계를 분석한다.a) 수행능력이 비용에 미치는 영향을 결정한다.b) 기능에 대한 대가로 추가되는 비용을 이해한다.c) 업무 수행 목적과 요구사항 식별을 지원한다.d) 기능에의 업무 할당을 지원한다.

체계와 비용 유효성 분석은 수명주기 품질 요소를 체계 생산품 설계에 포함시키고 수명 주기 절차에 대한 기능적인, 임무 수행 상의 요구사항을 정의하는 과정을 지원하기 위해 개발, 시험, 배포, 운용, 지원, 훈련, 처분의 수명주기 절차에 대해 이루어진다. 이러한 분석 결과는 대안 분석 대안들을 평가하고 체계의 효과를 평가하기 위해 사용된다.

4.1.2.3.3 환경 영향 분석조직은 체계의 구현에 관련되어 안전성과 환경적인 영향을 식별한다. 적용 가능한 환경에 대한 법률과 규제를 확인하고 이러한 것들이 어떤 대안에 의해서도 함께 통합됨을 확인해야 한다. 조직은 환경적 영

향과 안전성 분석을 완수하여 체계 생산품에 대한 영향과 그에 의한 영향, 그것들의 수명주기 절차가 환경이나 개개인에 미치는 영향을 결정한다. 환경에 위험요인으로 판명된 자재나 부산물의 사용은 피해야 한다. 가능하지 않다면 위험 물질이나 부산물의 적당한 처리와 저장 그리고 폐기에 대한 예방책이 제공되어야 한다. 이러한 분석의 결과는 대안 분석 근거(recommendation)와 체계 효율성의 평가에 영향을 준다.

4.1.2.3.4 위험 요소 계량화

조직은 바람직하지 않은 결과의 가능성에 노출되었을 때를 고려하여 체계나 대안에 대해 확인된 위험 요소의 영향을 정량화 한다. 체계 유효성 평가에 있어 기 개발된 체계 구조의 각 요소들을 평가하여 무엇이 잘못될 수 있는지를 결정하고 만약 문제가 발생하면 체계에 어떤 영향을 미칠지를 결정한다. 대안분석을 통해 수명 주기 비용, 체계와 비용 유효성, 환경요소 분석에서 얻은 위험 수준들은 우선순위가 정해지며 대안 분석 근거(recommendaation)의 일부로 보고된다.

4.1.2.4 위험 대응 방안 선정조직은 현 개발단계와, 프로젝트에서 지정한 위험관리 정책과 일관성 있게 위험을 완화하기 위해 다양한 위험 대응 방안을 선정한다. 발생 가능성이나 그 영향 혹은 둘 다를 감소시킴으로써 완화할 수 있는 위험은 주어진 가격과 일정 등의 조건하에서 받아들여질 수 있고 위험완화를 위한 접근도 계획될 수 있을 것이다. 위험 대응방안 분석은 위험의 가능성과 영향에 대한 비용과 효과를 정량화하기 위해 이루어져야 한다. 조직은 이용 가능하고, 비용/이익 대비 가장 바람직한 수준까지 위험의 허용 수준을 감소시킬 수 있는 위험 처리 옵션을 선택해야 한다. 위험을 완화하려는 노력 이후에도 남아있는 위험들을 확인하고 정량화해야한다. 위험확인, 정량화와 처리 단계에 걸쳐 체계 구조의 하급 수준부터 원인과 그 효과의 상호작용을 이해할 수 있는 체계 수준에 이르기까지의 통합이 이루어져야 한다. 위험 감소를 위한 접근과 남아있는 위험요소는 위험감소계획에 포함되며 위험감소계획은 대안 분석 추천서와 효과평가 보고서에 포함된다. 모든 위험 감소 노력은 엔지니어링 계획에 문서화되며 다음 개발 단계를 위해 종합 계획에 통합되고, 적당한 기술적 검토로 요약된다.

4.1.2.4.1 권장대안선정조직은 결정자에게 더 나은 대안을 추천하기 위해 대안 분석 결과와 위험감소계획 정보를 이용한다. 조직은 방법론과 자료 수집 수단이 정당하고 완벽한 평가를 지원하기에 충분한지를 확인하기 위해 대안 분석을 평가해야 한다. 각각의 추천안은 형상과 비용 일정, 이행도, 위험효과의 관점에서 표현되어야 한다.

4.1.2.4.2 설계 유효성 평가조직은 평가와 분석 결과에 기초하여 현 체계 설계의 효과를 결정한다. 이러한 평가와 분석의 결과는 통합 데이터베이스에 문서화되고 적합한 기술 검토와 프로젝트 검토에 요약된다.- 통합 자료 생산

조직은 추천된 대안 대안들을 그에 따른 영향들과 함께 문서화하고 그 결과를 대안 분석을 수행하거나 요청하는 SEP 활동 내부의 결정권자에게 제시한다. 최종의 대안 선택은 바람직한 방안을 판단하기 위해 확립된 기준에 의거하여 이루어진다. 중요 대안 분석 활동, 결정, 원리 그리고 추천안들은 통합 데이터베이스에서 문서화된다.

WBS(11) 범위관리 2010/09/30 16:12

http://blog.naver.com/jtum/50097030316

6.5 통제절차

PMBOK에 나오는 통합관리의 한부분이자 변경관리에 해당하는 부분입니다.

[그림 5] 통제 절차

통제조직은 SEP활동을 관리하고 문서화할 목적으로 통제업무를 수행한다. 통제업무는 [그림 5]에 나타나 있다. 결과물과 테스트 결과, SEP활동의 수행 계획(엔지니어링 플랜, 마스터 플랜, 세부 계획) 그리고 특별사항을 가공함으로써 생겨난 기술적인 계획은 조직에 의해 조절된다. 제어 업무는 다음을 제공한다.a) 다른 활동을 수해하는데 사용된 SEP활동과 그 결과에 대한 완전한 최신의 모형 b) SEP 적용에 대한 계획과 필요한 입력물c) 생산품과 시험, 사용자지원에 대한 정보d) 기술적 검토회와 프로젝트 검토회의 결정권자에 대한 정보

4.1.2.5 기술 관리조직은 발생한 데이터와 설계 방안의 형상, 인터페이스, 위험 그리고 기술적 진보를 제어하기 위한 SEP의 업무와 활동을 관리한다. 조직은 올바른 인력배치, 설비, 장비 그리고 툴을 유지할 필요가 있다. ; 비용과 일정관리 ; 개발 활동을 요구에 맞게 재계획 ; 사용자와의 기술적 상호작용을 중재; 기술 인력과 팀 멤버의 적합한 교육 ; 기술 진보 측정 ; 이 표준의 체계 공학 업무를 달성하는 데 필요한 기술적, 사업적 특이사항 사이의 활동을 중재

4.1.2.5.1 공학자료 관리조직은 기술적인 노력에서 요구되는 기술적인 자료의 전달, 제어, 개발을 지원하기 위해 자료 관리를 수행한다. 자료 관리 활동은 적합한 데이터베이스 구축과 설계 자료와 도안, 툴, 모델을 수집하고 유지하기 위한 방법의 구축을 포함한다. 기술적 노력에 관련된 자료는 쉽게 접근 가능해야 하며 체계 수명 주기에 걸쳐 유지 되어야 한다. 자료의 무결성과 안전성을 확실히 하고 뜻하지 않은 손실이나 변경으로부터 자료를 보호하기 위해 보호 수단이 마련 되어야 한다. 조직은 자료의 수집하고 저장하며 통제에 책임을 지며 자료가 생산품 설계, 명세, 베이스 라인의 진보을 포함한 적합한 형상 관리에 유용하도록 할 책임이 있다.

4.1.2.5.2 산출물 Tailoring

조직은 다음 기능을 계획하고 완수한다.a) 제어되어야(명세, 인테페이스 제어 도안/문서, 형상 베이스 라인을 해) 할 최종항목을 확인한다.b) 공학적 변경사항 제어c) 상태 보고d) 형상 심사

형상관리와 관련된 자료는 체계 수명 주기를 통해 쉽게 접근 가능하다. 조직은 형상 제어 위원회를 설립하고 유지하여 최종 항목을 진행하고 조사하며 공학적 변경사항을 발전시킨다.

4.1.2.5.3 인터페이스 관리조직은 인터페이스 정의, 인터페이스 제어, 인터페이스 호환성 평가, 인터페이스 조화를 계획하고 수행한다. 인터페이스 관리와 관련된 자료는 체계 수명 주기에 걸쳐 쉽게 접근 가능하다. 조직은 인터페이스 변경의 승인에 대해 진행하고 평가하며 추천하기 위해 인터페이스 작업 그룹을 설립하고 유지한다.

- 위험관리조직은 프로젝트가 가격과 일정과 수행 목적을 충족시키는 능력에 있어서의 불확실성을 조직적으로 제어하기 위해 위험관리를 수행해야 한다. 조직은 기술적 노력에 직접 영향을 주는 위험 관리 부분을 수행하며 이 부분은 위험 관리 준비, 위험 평가, 위험처리 옵션 평가, 위험 제어를 포함한다. 이러한 활동은 다음과 같이 이루어진다.a) 위험 관리 준비는 다음을 포함한다. 각 개발 단계의 수용 가능한 위험수준 결정 ; 가능한 위험

의 원인 확인 ; 위험관리 툴과 기술의 확인과 평가 ; 위험 관리 활동을 수행하기 위한 팀 구성원 훈련 ; 분석과 결정이 어떤 방식으로 문서화 될지를 결정 ; 위험 관리 정보가 어떻게 수집되고 처리되며 퍼뜨릴지를 결정

b) 위험 평가는 다음을 포함한다. 불리한 영향을 초래할 수 있는 환경 식별과 상세기술 ; 그러한 영향의 가능성과 소비될 가능한 비용, 일정, 효과를 결정하기 위해 환경요인을 정량화 ; 각 개발 단계에 적합한 SBS의 각 요소에 대해 위험 평가를 수행하기 위해 위험요인의 우선순위를 정하고 통합

c) 위험처리 옵션 평가는 실행가능하고 위험을 수용 가능한 수준까지 줄일 수 있는 옵션을 결정하기 위한 평가를 포함한다. 낮은 수준의 위험 처리 옵션은 실행 가능하고 가격과 일정, 기술적 노력과 프로젝트에의 위험 사이 최적으로 균형을 제공하는 고수준 옵션에 통합되야 한다.

d) 위험 제어는 현 위험 정보를 제공하고 위험이 수용 가능한 수준 내에 있도록 하기 위한 지속적인 평가를 포함한다.

4.1.2.6.1 분석 대 검증 추적조직은 활동, 원리, 추천안, 효과를 문서화하기 위한 체계 분석과 결과와 변이, 추적활동을 문서화하기 위한 시험으로부터 자료를 모으고 분석하며 추적한다.

4.1.2.6.2 요구 대 설계 추적조직은 요구사항과 설계 변경사항을 추적하고 변경의 소스와 프로세스, 승인의 추적을 유지하기 위해 자료를 모으고 분류한다.

4.1.2.6.3 계획 대 실행 추적조직은 계획 활동을 반영하는 자료를 모으고 분류하며 엔지니어링 계획과 종합 일정 그리고 상세 일정에 대해 절차를 추적한다. 계획으로부터의 이탈된 사항과 필요한 변경사항은 미리 요청될 수 있고 승인될 때만 수행될 수 있다.

- 엔지니어링 계획에 대한 프로세스 추적조직은 계획으로부터 이탈된 사항과 필요한 변경사항을 결정하고, 변경사항과 결정사항, 수행사항을 문서화 하기 위해, 계획 활동을 반영하는 데이터를 모으고 분류하며 엔지니어링 계획과 기술적인 계획에 대해 프로세스를 추적한다.

4.1.2.6.4 산출물 대 활동 추적조직은 다음을 위해 생산품과 프로세스 도표를 수집하고 분석하며 추적한다.- 프로젝트 관리적인 면에서 요구하는 기술적인 분야 결정- 사용자 만족도와 공식 인수 정도 결정- 새로운 생산품에 대한 가격과 일정에 대한 평가 제공과 사용자에 대해 더 신속한 응답을 제공

도표는 각 개발단계 동안 미리 정해진 통제시점에서 수집, 추적 보고되어 다음 사항을 가능하게 한다.- 품질 체계의 확립과 자원의 효율적 활용 달성- 전체 체계의 품질과 생산성 평가- 계획된 목표와 목적과의 비교- 문제의 조기 감지- SEP 벤치마킹