프로젝트 범위 관리

프로젝트 범위 관리

 

프로젝트 범위 관리 프로세스들

 

1.     범위 관리 계획을 개발하기 ( 계획 )

어떻게 프로젝트 범위가 정의되고, 확인되며, 통제될 것인가를 서술하는 범위 관리 계획을 생성한다

è  산출물 : 범위 관리 계획 ,요구사항 관리 계획

è  도구 및 기법 : 전문가 판단, 회의

è  투입물 : 프로젝트 관리 계획, 프로젝트 헌장, 기업 환경 요소, 조직 프로세스 자산

 

2.     요구사항을 수집하기 ( 계획 )

프로젝트 목표를 충족시키기 위해서 이해관계자들의 필요를 정의하고 기록한다.

è  산출물 : 요구사항 문서, 요구사항 관리 계획, 요구사항 추적 행렬

è  도구 및 기법 : 인터뷰, 포커스 그룹, 촉진된 워크숍, 집단 창의성 기법, 집단적 의사결정 기법들, 설문지와 서베이, 관찰, 프로토타입

è  투입물 : 프로젝트 헌장, 이해관계자 등록부

 

3.     범위를 정의하기 ( 계획 )

프로젝트와 제품에 대한 상세한 서술을 개발한다.

è  산출물 : 프로젝트 범위 기술서, 프로젝트 문서(갱신된)

è  도구 및 기법 : 전문가 판단, 제품 분석, 대안 확인, 촉진된 워크숍

è  투입물 : 프로젝트 헌장, 요구사항 문서, 조직 프로세스 자산

 

4.     WBS를 생성하기 ( 계획 )

프로젝트 인도물들과 프로젝트 작업들을 작고, 좀 더 관리하기 쉬운 구성 요소들로 분할한다.

è  산출물 : WBS , WBS 사전, 범위기준선, 프로젝트 문서(갱신된)

è  도구 및 기법 : 분해

è  투입물 : 프로젝트 범위 기술서, 요구사항 문서, 조직 프로세스 자산

 

5.     범위를 입증하기 ( 모니터링 및 통제 )

완성된 프로젝트 인도물들을 공식적으로 수용받는다

è  산출물 : 수락된 인도물 , 변경 요구 , 프로젝트 문서(갱신된)

è  도구 및 기법 : 인스펙션

è  투입물 : 프로젝트 관리 계획, 요구사항 문서, 요구사항 추적 행렬, 확인된 인도물들

 

6.     범위를 통제하기 ( 모니터링 및 통제 )

프로젝트와 제품의 범위의 상태를 모니터링하고 범위 기준선에 대한 변경을 관리한다.

è  산출물 : 작업 성과 측정 ,조직의 프로세스 자산 , 변경 요구 ,프로젝트 관리 계획, 프로젝트 문서

è  도구 및 기법 : 편차 분석

è  투입물 : 프로젝트 관리 계획, 작업 성과 정보, 요구사항 문서, 요구사항 추적 행렬, 조직 프로세스 자산

 

---

프로젝트 범위 관리

1.     프로젝트를 성공적으로 완수하기 위해 필요한 모든 작업을 포함하고 있고, 또한 필요한 작업만을 포함하고 있음을 보장

2.     프로젝트에 무엇이 포함되고 포함되지 않았는가를 정의하고 통제

 

범위

1.     제품 범위 ( product scope ) : 제품 , 서비스 또는 결과를 특징짓는 형태 및 기능

2.     프로젝트 범위 ( project scope ) : 명세된 형태 및 기능 , 서비스 또는 결과의 인도를 위해 성취될 필요가 있는 작업

 

 

범위 관리 계획

1.     상세한 프로젝트 범위 선언을 준비하기 위한 프로세스

2.     상세한 프로젝트 범위 선언으로부터 WBS(work breakdown structure)을 준비하기 위한 프로세스

3.     WBS가 어떻게 유지관리되고 승인될 것인가를 규정하는 프로세스

4.     완성된 프로젝트 산출물에 대한 공식적 수락이 어떻게 획득될 것인가를 규정하는 프로세스

5.     상세한 프로젝트 범위 선언에 대한 변경 요청이 어떻게 처리될 것인가를 통제하기 위한 프로세스 , 이 프로세스는 통합된 변경 통제를 수행하기 프로세스와 직접적으로 연계된다.

 

요구사항

1.     프로젝트 요구사항 : 비즈니스 요구사항, 프로젝트 관리 요구사항, 인도 요구사항 등을 포함할 수 있다.

2.     제품 요구사항 : 기술적 요구사항, 안전 요구사항, 성능 요구사항 등을 포함할 수 있다.

 

요구사항 관리 계획

1.     어떻게 요구사항 활동들이 계획되고, 추적되고, 보고될 것인가

2.     형상 관리 ( Configuration management ) 활동들

3.     요구사항 우선순위 결정 프로세스

4.     사용될 제품 매트릭스와 그것을 사용하는 근거

5.     추적 구조 ( traceability structure )

 

요구사항 문서

1.     비즈니스 필요 또는 포착되어야 할 기회

2.     추적traceability을 위한 비즈니스 및 프로젝트 목표

3.     적절한 방법의 기능적 요구사항

4.     비기능적 요구사항

5.     품질 요구사항

6.     수용 기준

7.     비즈니스 규칙

8.     다른 조직 부문에 대한 충격

9.     수행 조직 내외의 다른 주체애 대한 충격

10.  유지 및 훈련 요구사항

11.  요구사항 가정 및 제약들

 

조달에 대한 요구사항 문서

1.     조달 계획을 수립하는 동안에 고려해야 할, 프로젝트에 대한 주요 정보

 

프로젝트 범위 서술서

1.     제품 범위 서술 (product scope description)

2.     제품 인수 기준 (product acceptance criteria)

3.     프로젝트 인도물 ( product deliverables )

4.     프로젝트 제외물 ( project exclusions )

5.     프로젝트 제약 ( project constraints )

6.     프로젝트 가정 ( project assumptions )

 

작업 패키지의 분할 ( decomposition )

1.     인도물들과 관련된 작업들을 식별하고 분석하기

2.     WBS의 구조를 만들고 조직화하기

3.     상위 WBS 수준들을 하위 수준의 상세한 구성 요소들로 분할하기

4.     확인 코드들 identification codes을 개발하고 , WBS 구성 요소들에 할당하기

5.     작업이 필요하고 동시에 충분하다는 수준으로 분할되었다는 것을 입증하기

 

WBS 구조

1.     프로젝트 생애주기의 단계들을 분할의 첫 번째 수준으로 사용하고, 제품과 프로젝트 인도물들을 두 번째 수준으로 삽입하기

2.     주요 인도물들을 분할의 첫 번째 수준으로 사용하기

3.     계약 작업과 같은 프로젝트 팀의 외부에서 수행될 수 있는 하위 프로젝트들을 사용하기 . 이 때에는 판매자가 계약 작업의 일환으로 해당 작업에 대한 WBS를 개발한다.

 

---

요구사항 밝히기 기법 : 집단 창조성 기법

 

아이디어 창출 ( idea generation ) 단계의 원칙

1.     비판이나 토론을 허용하지 않는다.

2.     상상력을 최대한 발휘한다

3.     가능한 많은 아이디어를 생성한다

4.     아이디어를 변형,발전시키고 통합한다.

 

아이디어 축약 (idea reduction) 과정의 순서

1.     가지치기 : 더 이상 고려할 필요가 없는 아이디어들은 제거한다.

2.     이이디어 묶기 : 비슷한 아이디어끼리 묶는다.

3.     특징 정의 : 필요하다면 각 아이디어에 대해서 그 아이디어를 제안한 사람이 간단하게 설명하도록 한다.

4.     우선순위 정하기

 

브레인스토밍의 기능

1.     참석한 모든 집단의 참여를 촉진한다

2.     다른 사람의 아이디어에 무임승차를 할 수 있게 한다

3.     촉진자 또는 서기가 논의된 모든 것에 대한 기록을 작성한다

4.     전형적으로 어떤 제기된 문제에 대해서든지 매우 폭넓은 해결책들이 제시된다

5.     틀에 박히지 않은, 일반적인 제약에 얽매이지 않은 생각을 장려한다.

 

진행 절차

1.     소개 및 설명

2.     조용히 아이디어 만들기

3.     아이디어 공유하기

4.     집단 토의

5.     투표와 순위 매기기

 

장점

1.     집단 상호작용 ( group interaction ) 으로부터 파생되는 다음과 같은 두 문제점을 해결해준다

2.     어떤 구성원들은 비판 받는 것이 두려워서 아이디어를 제시하는 것을 꺼릴수 가 있다.

3.     어떤 사람은 집단들 내에 갈등을 조성하는 것을 피하려 할 수 있다.

4.     차이를 최소화하고 상대적으로 균등한 참여를 보장함으로써 이러한 문제들을 해결한다.

5.     시간을 절약한다.

6.     다수의 아이디어를 생성하며, 따라서 의사결정의 질을 높이고 종종 덜 구조적인 집단적 방법들에서는 느낄 수 없는 완결되었다는 느낌을 만들어 낸다.

 

단점

1.     한 번에 오직 한 문제만을 다룰 수 있다.

2.     참여하는 구성원들 간에 어느 정도의 유사성이 있어야한다.

3.     모든 사람들이 내포된 형식성에 어느 정도의 편안함을 느껴야 한다

4.     준비를 위해 많은 시간이 든다. 즉흥성이 없다. 설비들이 준비되고 잘 계획되어야 한다

5.     의견들이 투표 과정에서 수렴하지 않을 수도 있고, 아이디어들의 융합이 제한될 수도 있고, 프로세스가 너무 기계적으로 느껴질 수도 있다.

 

효과적인 경우

1.     어느 구성원들이 다른 사람들에 비해서 목소리가 특히 클 때

2.     어떤 구성원들이 조용할 때 , 더 잘 생각할 때

3.     어떤 구성원들이 참가하지 않을 것이라는 우려가 될 때

4.     해당 집단이 쉽사리 다량의 아이디어를 만들어내지 않을 때

5.     모든 또는 일부 구성원들이 팀에 새로 들어왔을 때

6.     이슈가 논쟁의 소지가 많고 치열한 갈등이 있을 때

 

이 방법의 절차 (델파이 방법)

1.     촉직자가 설문지를 개발하고 참여자를 선정한다

2.     설문지를 이용하여 참여자들의 의견을 확인한다

3.     설문 조사의 결과를 분석한다.

4.     만약 참여자들 간에 의견 일치가 이루어지지 않았다면, 조사 결과를 참여자들에게 통보하고 설문 조사를 다시 한번 수행한다

5.     전문가들 간에 의견 일치가 이루어질 때까지 3~4를 반복한다.

 

친화도

1.     각각의 아이디어를 카드나 포스트잇에 적는다.

2.     카드 하나를 선택하여 가장 관계가 깊다고 판단되는 집단에 추가한다.

3.     모든 카드가 분류될 때까지 단계를 반복한다.

 

회의 진행의 기본 원칙은

1.     합리적인 분류법이 무엇인가에 대해 토론하지 않으며, 독특한 관점이 존중되는 환경을 만든다

2.     신중한 생각보다 스피드가 중요하며 , 시간을 낭비하지 말고 각자 생각하는 대로 신속히 반응하도록 한다.

 

집단 심층 면접

1.     양방향 포커스 그룹

2.     복수 중재자 포커스 그룹

3.     경쟁적 중재자 포커스 그룹

4.     응답자 중재 포커스 그룹

5.     고객 참여 포커스 그룹

6.     소 포커스 그룹

7.     전화 포커스 그룹

8.     온라인 포커스 그룹

 

---

요구사항을 밝히기 위한 고객과 개발자의 공동 작업

 

요구사항 워크숍

 

1.     요구사항 워크숍의 기능

è  이 프로젝트의 성공이라는 하나의 공통된 목표에 헌신하는, 효율적인 팀을 구성하는 데 도움을 준다.

è  모든 이해관계자들이 발언을 한다

è  응용프로그램이 무엇을 해야 하는가에 대한 이해관계자들과 개발자 팀 간의 합의를 도출해 낸다.

è  프로젝트 성공을 저해하는 정치적 쟁점을 노출시키고 해결한다

è  기능 수준에서의 초기 시스템 정의가 즉시 사용가능하다

 

2.     촉진자의 기능

è  전문적이고 객관적인 모임의 분위기를 조성한다

è  정시에 모임을 시작하고 종료시킨다

è  모임의 규칙을 확립하고 집행한다

è  모임의 목표와 의사일정을 소개한다

è  모임을 관리하고 팀이 궤도를 벗어나지 않도록 한다

è  의사 결정과 합의 도출은 촉진하나, 그 내용에 관여하는 것은 삼간다

è  초점이 의사 결정에 집중되도록 설비와 보급을 관리한다

è  모든 이해관계자가 참여하도록 보장하고 그들의 발언 내용이 주목받도록 한다

è  급작스럽고 비생산적인 행위를 통제한다

 

3.     경영진 정의 지침은

è  프로젝트의 목적

è  프로젝트의 범위

è  새 비즈니스 프로세스의 사용자들

è  영향을 받는 비즈니스 영역들

è  영향을 받는 시스템들

è  경영 목표들

è  비즈니스 프로세스들

è  제약들

è  자원 제약들

è  가정들

è  미해결된 이슈들

è  세션 참석자들

4.     일반적인 원칙은

è  JAD(join Application Development)의 성공을 위해서는 경영진의 참여가 필요하다

è  풀타임 참여자들이 세션 전체에 참여해야 한다

è  JAD의 성공을 위해서는 훈련된 촉진자가 필요하다

è  세션에 적절한 사람이 참여하여야 한다

è  모든 참여자들은 동등하다

è  JAD의 준비는 JAD 세션 그 자체만큼 중요하다

è  좋은 회의 일정을 만들고 그것을 지킨다.

è  세션에서 적절한 도구와 기법을 사용한다

è  기술적인 특수 용어는 최소한으로 사용한다

è  품질 높은 최종 문서를 빠르게 작성한다

 

---

WBS 작성 방법

1.     WBS와 관련된 중요한 용어

è  인도물 ( deliverable )

è  작업 패키지 ( work package )

è  통제 계정 ( control account )

 

 

2.     100% 규칙 이외의 WBS 작성 원칙

è  상호배타적인 요소들 : 두 구성 요소 간에 범위의 중첩이 있으면 안 됨

è  계획된 행위가 아닌, 계획된 결과 : 이 원칙은 사전에 방법을 너무 상세히 규정함으로써 프로젝트 참여자의 창의성을 제한하는 것을 방지한다.

 

3.     핵심 WBS 품질 속성

è  프로젝트 구성 요소들의 인도물 지향적인 분류이다.

è  프로젝트의 범위를 정의한다

è  작업을 명백하게 하고 프로젝트 범위를 모든 이해관계자와 의사소통한다.

è  범위에 의해서 정의된 작업의 100% 포함한다

è  프로젝트 관리를 포함해서, 완성되어야 할 작업의 관점에서 내부,외부,중간 산출물들을 파악한다.

è  각 수준의 분할이 부모 수준 작업의 100%를 포함하도록 구성되었다.

è  해당 작업 패키지를 인도하기 위해서 수행되어야 하는 과업들의 식별을 명확하게 지원하는 작업 패키지들을 포함한다.

è  프로젝트 범위의 도형, 문서, 또는 표 형태의 분할을 제공한다.

è  명사와 형용사(동사가 아니라)를 사용하여 정의된 구성 요소들을 포함한다 .

è  모든 인도물들을 계층적 구조로 정리한다

è  각 구성 요소에 대해서 도표나 개요 등의 표현 형식에 구애 받지 않고, 그 계층적 성격을 명확히 식별할 수 있는 코딩 체계 ( coding scheme ) 를 채택한다.

è  최소한 한 번의 분해를 포함하는 2개 이상의 수준을 갖는다.

è  해당 작업을 수행할 사람들에 의해서 작성되었다.

è  충분한 지식이 있는 주제 분야 전문가 (SME : subject matter experts) 및 기타 이해관계자 (재무 및 비즈니스 관리자와 같은)들로부터의 기술적 입력 자료에 근거해서 작성되었다.

è  프로젝트 범위가 점진적으로 명확해짐에 따라서, 범위가 기준선화될 때까지 반복적으로 진화한다.

è  프로젝트 변경 통제에 맞추어서 갱신되며, 그렇게 함으로써 프로젝트 범위가 기준선화된 이후에도 지속적인 개선을 가능하게 한다 .

 

WBS 예

 

적절히 조절해야 하는 속성

1.     충분한 수준의 분해를 달성한다

2.     모든 작업에 대해서 의사소통할 수 있는 충분히 상세한 내용을 제공한다.

3.     구체적인 프로젝트 또는 조직에 의해서 요구되는 대로 추적을 하기에 적절하다

4.     통제 활동을 위해서 적절하다

5.     각 프로젝트에서 요구되는 대로, 구체적인 종류의 WBS 구성요소들이 포함할 수 있다.

6.     적당한 수준에서의 책임 할당을 가능하게 한다

7.     프로젝트 관리와 모니터링 요구사항을 충족시킬 수 있도록 간결하고, 명료하고, 논리적으로 조직된 구조를 갖는다.

 

---

 

소프트웨어 요구사항 프로세스

 

요구사항 밝히기

 

단계별 오류 발생률과 제거율

 

1.     맥락적 설계 ( contextual design )  

: 소프트웨어와 하드웨어를 정의하기 위한 여러 가지의 고객 중심적 기법들을 하나의 통합된 설계 과정으로 통합하는 방법론이다.

: 가장 널리 쓰이고 있는 소프트웨어 요구사항 밝히기 기법 중의 하나이다.

: 수평적 프로토타입 Vs 수직적 프로토타입

: 폐기용 프로토타입 Vs 진화적 프로토타입

: 아키텍처 프로토타입 Vs 요구사항 프로토타입

 

프로토타입의 역할

 

è  개발자에 의해서 구축되어 , 개발자가 요구사항을 이해하고 있는가에 대해서 확인을 받는 데 쓰일 수 있다.

è  개발자에 의해서 구축되어 , 고객이 밝혀진 것 이외의 추가적인 요구사항에 대해서 생각하는 것을 장려하기 위한 촉매로 사용될 수 있다.

è  고객에 의해서 구축되어, 요구사항을 개발자에게 의사소통하는 것을 도울 수 있다.

 

2.     맥락적 조사 ( contextual inquiry )

: 고객 중심적 시스템을 설계하기 위한, 맥락적 설계의 주춧돌이자 시작점이다.

 

3.     스토리보딩 ( storyboarding )

: 응용을 위해서 제안된 개념들에 대한 사용자들의 조기의 반응을 얻어 내는 것이다

 

4.     세 가지 기본 요소

ㄱ.   행위자

ㄴ.   무엇이 그것들에게 일어나는가?

ㄷ.   그것이 어떻게 일어나는가?

 

5.     스토리보딩 지침

ㄱ.   스토리보드에 너무 많은 시간을 투자하지 말자

ㄴ.   만약 당신이 아무것도 고치지 않는다면 , 아무것도 배우지 않는다

ㄷ.   스토리보드를 너무 좋게 만들지 말자

ㄹ.   가능한 한, 스토리보드는 상호작용적이게 만들어라

 

6.     프로토타입된 사용자 인터페이스

è  어떤 기능이 사용자에게 제공되는가?

è  각각의 기능이 언제 사용자에게 제공되는가?

è  어떤 기능이 결여되어 있는가?

 

7.     역할하기 ( role playing )

è  개발팀이 사용자의 역할을 ‘연극함’으로써 사용자의 세계를 직접 경허말 수 있게 한다

 

---

 

쓰임새 모델링

 

1.     쓰임새란?

쓰임새 모델이 이해 관계자에게 제공할 수 있는 이익

 

2.     쓰임새 모델링 절차

 

세 가지의 쓰임새

ㄱ.   기본적 쓰임새

ㄴ.   구조적 기본적 쓰임새

ㄷ.   구체적 쓰임새

 

3.     시나리오를 이용한 쓰임새 모델의 보완

 

시나리오

ㄱ.   쓰임새 모델에 사용자 중심적이고 맥락적인 측면 (상호작용의 누구, 어디서, 언제, 그리고 왜) 을 보완하는 주요 방법으로 쓰인다.

ㄴ.   시나리오는 개별적이고 단선적인 사건의 흐름을 나타낸다.

ㄷ.   현재 시스템 (as-is model) 에서의 사용 맥락을 밝히기 위한 것과 새 시스템(to-be model)에서의 사용의 세부 사항을 밝히기 위한 것이 있는 시나리오 기반 설계 ( scenario-based design ) 에서 사용자 상호작용 시나리오는, 설계자에 의해서 작성될 수 있지만 , 전형적으로 요구사항 분석 과정에서 포착되고 분석된 실생활의 에피소드에 근거한다 .