[Software Engineering] Project Management

The Four P's for Management

Project Management: 제품을 현실로 만드는 데 필요한 모든 작업 관리

Process Management: 작업을 완료하기 위한 프레임워크 활동 및 소프트웨어 엔지니어링 작업 세트 관리

People Management: 성공적인 프로젝트의 가장 중요한 요소인 인간 관리

Product Management: 구축할 소프트웨어의 형상관리 및 품질관리

 

Management Activities

- Proposal Writing

계약을 따거나 작업을 수행하기 위한 제안서를 작성해야하는데 제안서에는 무엇을 어떻게 할 예정인지도 중요하지만, 왜 해야하는지에 대한 정당성도 중요하다.

 

- Personnel Selection and Evaluation

프로젝트에 적합한 인력을 배치하는 것이 불가능 할 수도 있다. 예산이 고액 급여를 받는 직원을 고용하는 데 적합하지 않을 수 있고, 회사가 필요로 하는 경험이 있는 직원이 없을 수 있다.

충분히 훈련되지 않은 직원을 뽑아야 할 때 매니저는 해당 직원의 존중, 믿음, 충성심, 헌신, 신뢰, 용기 및 감사 등도 중요하게 여겨야한다. (능력도 중요하지만 태도도 매우 중요하다.) 

 

- Project Planning and Scheduling

Project Planning은 프로젝트에서 생성된 활동, 마일스톤, 성과물을 식별하는 것과 관련이 있다. 이 단계에서는 프로젝트 목표를 향한 개발을 안내하기 위한 계획이 수립된다.

비용 추정은 프로젝트 계획을 달성하는 데 필요한 리소스를 추정하는 것과 관련된 활동이다.

 

- Project Monitoring

프로젝트 모니터링은 지속적인 활동이다. 매니저는 프로젝트 진행 상황을 추적하고 실제 진행 상황과 계획된 진행 상황 및 비용을 비교해야 한다.

대부분의 조직에는 모니터링을 위한 공식적인 메커니즘이 있지만 숙련된 관리자는 종종 프로젝트 직원과의 비공식적인 토론을 통해 진행상황에 대한 명확한 그림을 형성할 수 있다.

비공식적인 모니터링은 문제가 발생할 때마다 어려움을 밝혀 잠재적인 문제를 예측할 수 있다. (직원과 Daily discussion을 통해 특정 소프트웨어의 오류를 찾을 수 있다.)  

 

Project Planning and Scheduling

Project Planning

Project Management 활동에서 가장 시간이 많이 걸리는 활동이다. 초기 부터 시스템 제공까지 지속적인 활동을 요한다.

일정 및 예산과 관련된 주요 소프트웨어 프로젝트 계획을 지원하기 위해 다양한 유형의 계획이 개발될 수 있다.

 

Types of Project Plan

 

대부분의 Plan은 다음과 같은 Section들을 따라야 한다.

1. Introduction

2. Project Organization

3. Risk Analysis

4. Hardware and Software Resource Requirements

5. Work Breakdown

6. Project Schedule

7. Monitoring and Reporting Mechanisms

 

Work Breakdown: Milestones and Deliverables

Milestones: 소프트웨어 프로세스 활동의 인식 가능한 종료 지점. 각 마일스톤마다 보고서 등의 공식적인 산출물이 있어야하고, 그것은 반드시 큰 문서일 필요 없으며 완료된 내용에 대한 간략한 보고서일 수 있다.

Deliverables: 고객에게 전달되는 프로젝트 결과. 일반적으로 주요 프로젝트 단계가 끝날 때 제공된다. 이는 일반적으로 마일스톤이지만, 마일스톤이 반드시 Deliverable일 필요는 없다.

 

Project Scheduling

1. Project를 Task로 분할하고 각 Task를 완료하는 데 필요한 시간과 리소스를 추정한다.

2. 인력을 최적으로 활용하기 위해 Task를 동시에 구성한다.

3. 한 Task가 다른 Task를 완료될 때 까지 기다려야 하는 지연을 방지하기 위해 Task Dependency를 최소화한다.

Project Scheduling은 Project Manager의 직관과 경험에 따라 달라진다.

 

Task Durations and Depedency

Activity Network

Staff Allocation

PERT (Program Evaluation and Review Technique)

Gantt Chart

WBS (Work Breakdown Structure)

WBS는 프로젝트의 Task를 정의하고 그룹화 하는 데 사용되는 도구로, 프로젝트의 전체 작업 범위를 구성하고 정의하는 데 도움된다.

WBS의 목표는 달성하기 위해 필요한 노력의 세분화를 보여주는 트리 구조를 보여주는 것이다. 가능한 빠진 것이 없고, 겹치는 것이 없으며, Level of Detail이 어느정도 일치해야한다. 또한 계획된 행동 보다는 계획의 결과로 작성해야한다. 그리고 상식적으로 의미가 있어야한다.

WBS coding scheme

WBS element는 계층 구조를 나타내기 위해 순차적을 번호가 매겨지는 것이 일반적이다.

Risk Management

Risk management는 프로젝트 관리의 주요 업무 중 하나로 점차 인식되고 있다. 개발 중인 소프트웨어의 품질과 프로젝트 일정에 영향을 미칠 수 있는 위험을 예상하고 이러한 위험을 피하기 위한 조치를 취하는 것이 포함된다.

 

Risk에는 3가지 관련 범주가 있다.

1. Project Risk: 프로젝트 일정이나 리소스에 영향을 미친다.

2. Product Risk: 개발중인 소프트웨어의 품질이나 성능에 영향을 미친다.

3. Business Risk: 소프트웨어를 개발하거나 조달하는 조직에 영향을 미친다.

 

Risk의 예시

 

Risk Management Process

1. Risk Identification: Project, Product and Business Risk를 식별

2. Risk Analysis: 해당 Risk의 가능성과 결과를 분석

3. Risk Planning: Risk를 피하거나 영향을 최소화 하기 위한 대응책 수립

4. Risk Monitoring: 식별된 Risk를 정기적으로 평가 -> 가능성과 영향의 변화를 관찰

 

Risk Analysis

각 Risk를 가능성과 심각성(결과 및 파장, 영향력)의 곱으로 평가한다.

 

Risk Planning

Risk를 피하거나 영향을 최소화 하기 위한 대응책 수립

Avoidance Strategies: Probability -> 0

Minimization Strategies: Effect -> 0

Contingency Plans: 플랜 B 수립

 

Risk Monitoring

식별된 Risk를 정기적으로 평가 -> 가능성과 영향의 변화를 관찰

각 Key risk는 관리 현황 미팅에서 논의

Risk Indicators(전조현상)은 다음과 같은 예시들이 있다.