세티의 Lonely Star

프로세스는 '결과를 만들어내는 일종의 행위' 인데 이런 프로세스는 주로 프로젝트를 수행하는 사람에 의해 수행됩니다.
프로젝트의 프로세스는 크게 2가지의 범주를 가집니다.

• 프로젝트 관리 프로세스
• 생산지향 프로세스

프로젝트는 사람이 수행하고, 사람이 수행한 결과로 생산물이 나오게 됩니다.
따라서 프로젝트 수행시 프로젝트 관리 프로세스와 생산지향 프로세스는 서로 밀접하게 관련되어 작용합니다.

각각의 프로세스에 대해 알아보겠습니다.

{ 프로젝트 관리 프로세스 }
이 프로세스는 5개의 프로세스 그룹으로 구성되어 있습니다.

• 착수 프로세스(Initiating processes)
• 계획 프로세스(Planning processes)
• 실행 프로세스(Executing processes)
• 통제 프로세스(Controlling processes)
• 종료 프로세스(Closing processes)

(이미지 출처 : http://www.shravan.org/)

 

착수 프로세스에서는 주로 착안, 기안, 시작과 같은 것들을 고민합니다. 다시말해 수행할 프로젝트가 시작되어야 한다는 것을 인식하고 그에 맞는 준비를 하는 단계 입니다.
계획 프로세스에서는 프로젝트에 요구된 내용을 만족시키기 위해 실현가능한 계획을 수립하고, 그것을 지속적으로 관리해 나가는 단계 입니다.
실행 프로세스에서는 앞서 준비된 계획들을 실행하기 위해 필요한 인력과 자원을 조정하는 단계 입니다.
통제 프로세스에서는 지속적인 모니터링을 통해 프로젝트를 컨트롤 합니다. 주로 컨트롤 되는 것들은 프로젝트의 목표, 프로젝트의 보장, 프로젝트의 진도 측정, 새로운 요구나 시장변화를 수정하고, 적용하는 단계 입니다.
종료 프로세스에서는 프로젝트의 결과에 대해 승인을 받고, 정리하는 단계 입니다.

위의 각 프로세스에서 만들어지는 결과물은 다음 프로세스를 위한 자료로 사용되며, 그것을 통해 서로 연결되어 실행됩니다.

(이미지 출처 : http://www.inca.no/)

각 프로세스 그룹을 조금더 상세하게 뜯어보면 그 안에는 세분화된 개별적인 프로세스가 또 존재합니다.
아래는 각 프로세스 그룹에 대한 상세 프로세스 입니다.

착수 프로세스의 세부 프로세스

• Initiation

계획 프로세스의 세부 프로세스

• Core Processes
• Scope Planning
• Scope Defiition
• Activity Definition
• Activity Sequencing
• Activity Duration Estimating
• Schedule Development
• Resource Planning
• Cost Estimating
• Cost Budgeting
• Project Plan Development
  
• Facilitating Processes
• Quality Planning
• Oragnizational Planning
• Staff Acquisition
• Communication Planning
• Risk Identification
• Risk Quantification
• Risk Response Development
• Procurement Planning
• Solicitation Planning

실행 프로세스의 세부 프로세스

• Project Plan Execution
• Scope Verfication
• Quality Assurance
• Team Development
• Information Distribution
• Solicitation
• Contract Administration

관리 프로세스의 세부 프로세스

• Overrall Change Control
• Scope Change Control
• Schedule Control
• Cost Control
• Quality Control
• Performance Reporting
• Risk Response Control

종료 프로세스의 세부 프로세스

• Administrative Closure
• Contract Close-out

 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

프로젝트 관리자에게 있어 일반적인 관리 기술은 매우 중요하다고 할 수 있는데 그 이유로 프로젝트 관리 기술을 쌓는 토대를 제공하기 때문이다.

1. Leading
1. 지휘와 관리가 모두 필요함.
2. 지휘에 필요한 것
1. 방향 설정 : 미래의 비전, 그리고 그것을 달성하기 위한 필요한 전략
2. 타인과 공조 : 회사내에서 비전을 달성하는데 필요한 말과 행동
3. 동기부여와 사상고취 : 변화에 대한 장애(정치적, 관료적, 자원의 부족 등)를 극복하도록 격려
4. 프로젝트에서는 다양한 사람들의 리더십이 발휘되어야 한다.(프로젝트 리더십, 기술적 리더십, 팀 리더십)
2. Communicating
1. 정보의 교환을 포함
2. 명확하고 모호하지 않으며, 완전하게 정보를 전달할 책임이 있음(전달자 -> 수신자)
3. 의사소통의 차원
1. 문서, 구두, 듣기, 말하기
2. 내부적인 것과 외부적인 것
3. 공식적인 것과 비공식적인 것
3. Negotiating
1. 협약 또는 계약에 이를수 있도록 하기 위해 타인과 협의하는 것을 의미.
2. 협상은 직접적이거나 간접적(도움)이거나 해야 가능하다.
1. 도움을 받는 협상의 2가지 형태
1. 조정
2. 중재
3. 협상은 프로젝트에서 문제, 시기, 수준등에서 발생하며, 다음 항목의 모든 것에서 협상이 발생한다.
1. 범위, 비용, 일정 목적
2. 범위, 비용, 일정 변경
3. 계약 내용, 조건
4. 할당
5. 자원
4. Problem Solving
1. 문제 해결
1. 문제 정의와 의사결정 조합 <----> 리스크 관리
2. 문제 정의는 다음으로 구분된다.
1. 원인
2. 징후
3. 문제는 내부적이거나 외부적일 수 있고, 또 기술적, 관리적, 대인관계 등이 될 수 있다.
2. 의사결정
1. 해결을 위해 문제를 분석하고, 하나를 선택하는 의미
2. 결정을 하거나 얻는다.
3. 결정이 이루어지고 나면 그 결정은 실행되어야 한다.
4. 의사결정도 시간적 요소가 있으므로 너무 빠르거나 또는 늦어지면 최선의 결정이 안된다.
5. Influencing the Oragnization
1. "일을 잘하는 능력" => 참여한 조직의 공식적, 비공식적 구조 모두를 이해.
2. 힘과 정책 역학의 이해를 필요.
1. 힘 - 행동에 영향을 주고, 사상의 과정을 변화시키고, 저항을 극복하고 할수 없는 일을 할 수 있도록 하는 잠재적인 능력
2. 정책 - 갈등과 불일치를 창조적으로 이용

위의 사진은 뭔가 결속력이 강하고, 외부 충격에 매우 단단한 느낌을 준다.
팀도 마찬가지라고 본다. 관리기술을 가진 팀 매니저는 팀의 능력을 결속력있고, 강하고 단단하게 만들어 팀의 능력을 극대화하고 그것을 자원으로 원하는 결과를 도출해 내겠지만 그 반대로 팀 매니저가 관리기술이 없거나 또는 자신의 팀은 놔두고 엉뚱한 팀에가서 관리기술을 보여준다거나 또는 한 두가지(술과 정치)에 너무 집착한다면 그것은 팀이나 팀원 모두에게 있어 하나의 비극이 될수도 있다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

산업에서 운영이 아닌 업무의 대부분은 프로젝트 성격의 업무일 것입니다.
(그것이 서비스업이든 제조업이든 말입니다.)
운영이 아닌 단발성이면서 유니크한 업무는 대부분이 프로젝트라고 정의될만 할텐데요.
프로젝트를 하게되면 팀을 조직하고, 업무를 정의 및 분석하고, 새로운 일인 만큼 프로세스를 만들게 됩니다.
일은 프로세스의 특성을 정의하기 위해 사용되는데 프로세스의 특성은 주요 프로세스 단위를 설계하는데 사용하며, 여기서 얻어진 정보는 프로세스 단위 및 보조적인 시설물의 특성을 정의하는 엔지니어링 설계의 기초가 됩니다.

아래의 그림은 IEEE에서 제공하는 소프트웨어 엔지니어링 프로세스 이미지 입니다.
링크를 클릭해서 들어가면 소프트웨어 엔지니어링 프로세스에 대한 보다 자세히 소개된 내용을 볼 수 있습니다.




프로세스 엔지니어링 논문
1. Object - oriented Process Engineering for Decentralized Organizations

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이전 블로그(http://blog.naver.com/nashira7)에서 옮겨왔습니다.
작성일 : 2005년 11월 05일
옮긴일 : 2008년 12월 22일

목적 - 설계하고자 하는 업무에서 현재사용자가 하는 일이 무엇이고, 비즈니스 요구 사항이 무엇인

         지에 대해 이해허여 업무를 정의하는 데 있다.

 

대표적인 산출물 - 시나리오(AS-IS(현재상황) 뿐만 아니라 TO-BE(청사진) 의 모습을 구분)

 

주요 설계모델 산출물

- Business Context Diagram

- Workflow Process Model

- Use Case Scenario/Elemenatary Process

 

Business Context Diagram

- 개발할 시스템을 기준으로 외부의 모든 요소들과의 관계에 대한 총체적인 괌점을 생성

- 개발할 시스템에 관계된 외부적 변화 요소에 대해 시스템이 어떻게 변경되어야 하는지에 대한

  최초의 접점을 제공

- 이벤트 중심적(비즈니스)이 특징

 

[작성방법]

- 모든 외부(사용자, 프로세스, 시스템, 연관)와의 상호작용을 입/출력 형태로 주고받는 주요 내역

  들을 기술.

- 시스템이나 비즈니스 도메인의 관점에서 내부적으로 처리해야 할 모든 일들에 해당하는 외부

  이벤트들을 포함.

 

Workflow Process Model

- Business Context Diagram으로 부터 정의된 개발 업무의 내부 프로세스를 크게는 부서별 업무

  단위부터 시작하여 작게는 EP(Elementary Process) 단위 까지 각 단계를 Level Down 방식으로

  해나간다.

- 각 프로세스들을 서브 프로세스들로 분해

- 이벤트 지향적 워크플로

 

[작성방법]

- Business Context Diagram 상에 나타난 모든 외부(사용자, 프로세스, 시스템 연관)와의 상호

  작용 사항을 유지하며 단위 프로세스까지 Level-down하여 기술

- 첫 단계는 부서별로 나누어 프로세스를 정의

- 레벨 다운은 3단계까지 한다.

- 최소의 단위는 Use Case(한 사람이 쉬지 않고 한번에 처리하는 일의 단위) 단위이다.

- 하위 프로세스는 별도의 색으로 표시하는 것이 좋다.

 

Use Case Scenario

- Workflow Process Model 마지막 단계에 기술된 각 Elementary Process 들에 대해 각각 상세한

  업무 절차 및 프로세스 로직을 기술

- 모든 설계의 기본

- 사용할 용어의 기준을 정하는 것이 중요.

 

[작성방법]

1. 사전 준비 사항

- 이전 Use Case 들이 수행 완료됨에 따라 발생된 입력 원본 준비

 

2. 업무 처리절차

- 원본으로 부터의 입력 항목들에 의거하여 순서에 입각한 구체적이고 명확한 비즈니스 로직을

  전개

- 출력 항목을 생성 및 편집

- 등록, 변경, 취소 Use Case에 대해 각각 별도의 Use Case로 구분하여 작성

- 외부와의 인터페이스 부분에 대한 참조사항은 비고란에 기술

- 어떤 기준을 가지고 데이터를 처리하는지 구체적으로 기술

- 최대한의 속성과 값을 도출하여 기술

- 일반적인 명사를 최대한 구분하여 구체적인 내용으로 기술

- 육하원칙에 준하여 기술

- 업무 절차상 예외사항을 모두 기술

- 3자가 쉽게 이해하게 기술

 

3. 사후 처리사항

- 연속되는 타 Use Case가 정상적으로 수행되도록 출력의 전달 및 통보와 같은 필요한 행위에 대

  해 기술한다.

 

개념설계(Conceptual Design) 검증사항

- 논리 설계를 위한 유일한 입력으로서 업무 처리절차 중 빠진 부분이 없어야 한다.

- 각 단위 업무절차에서 다른 프로세스를 유발시키는 예외 처리사항이 빠지지 말아야 한다.

- 현업무 담당자의 업무내용에 대한 확인이 필요하다.

- Business Context Diagram에 표현된 외부 이벤트와 관련된 업무가 모두 기술되어야 한다.

- 누구나 이해하기 쉬워야 한다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.