[소프트웨어공학] 2. Project Planning

Project planning (프로젝트 계획)

: 계획 수립 --> 자원 획득 --> 실행 --> 모니터링

• 프로젝트 계획
  : 작업을 여러 부분으로 나누어 팀 구성원에게 할당하고, 발생할 수 있는 문제를 예상하고, 해당 문제에 대한 잠정적 해결방안을 준비한다.
• 프로젝트 계획의 이용
  - 프로젝트가 어떻게 진행될 것인가를 프로젝트 팀과 고객이 소통할 때
  - 프로젝트 진행 상황을 평가할 때

 

Planning stages

1. 제안 단계: 소프트웨어 시스템을 개발/공급하는 계약을 얻기 위해 입찰할 때
2. 프로젝트 시작 단계 동안: 누가 프로젝트에서 일할 것인지, 프로젝트를 어떻게 작업들로 나눌 것인지, 자원을 어떻게 할당할 것인지 등에 대한 계획을 수립한다.
3. 프로젝트 내내 주기적으로: 개발하는 동안 얻은 경험, 새로운 정보를 반영하여 계획을 수정한다.

 

Proposal planning (제안 단계)

• 소프트웨어에 대한 완전한 요구사항이 없다.
• 제안 단계에서 계획의 목적: 고객에게 시스템의 가격을 책정하는데 사용될 정보를 제공한다.

 

Software pricing

: 개발자가 소프트웨어 시스템을 만들기 위해 들어가는 비용을 파악하기 위해, 소프트웨어 가격을 추정해야 한다.

--> 하드웨어/소프트웨어, 출장/교육 및 노력의 비용을 고려한다.

• 개발 비용과 고객에게 청구되는 가격과의 관계는 단순하지 않다. 조직적, 경제적, 정치적, 비즈니스적 고려 사항이 폭넓게 고려되어야 한다.

 

Factors affecting software pricing

• 시장 기회: 개발 조직은 소프트웨어 시장의 새로운 영역에 진입하기 위해 가격을 낮게 책정할 수 있다.
  <-- 더 많은 이윤에 대한 기회, 경험
• 계약 조건
• 요구사항 변동성: 요구사항 변경에 대해 높은 가격을 부과할 수 있다.
• 재정 건전성: 재정적 문제를 가진 기업들은 계약을 수주하기 위해 가격을 낮게 책정할 수 있다.
• 비용 추정의 불확실성: 어떤 조직이 자신의 비용 추정에 대해 확신하지 못한다면, 비상 상황에 대비하여 정상적인 이윤보다 많게 가격을 책정할 수 있다.

 

Plan-driven development (계획 주도/계획 기반 개발)

: 개발 프로세스가 상세하게 계획된 소프트웨어 공학 접근법 (전통적인 방식)

• 프로젝트 계획: 수행될 작업들, 그것을 담당할 사람들, 개발 일정, 작업 산출물을 기록하는 것
  --> 목적: 관리자들이 프로젝트 의사결정을 지원하고, 진행 상황을 측정하는 수단

 

Plan-driven development (계획 주도/계획 기반 개발) - pros and cons

▷ 장점

• 초기의 계획 수립이 조직의 이슈들(투입 가능한 직원, 다른 프로젝트 등)을 고려할 수 있게 한다.
• 잠재적인 문제들, 종속성들을 프로젝트가 시작하기 전에 발견할 수 있다.

▷ 단점

• 소프트웨어가 개발되고 사용되는 환경에 대한 변화때문에 많은 초기의 결정들을 수정해야 한다.

 

Project plans

▶ 계획 주도 개발 프로젝트

• 프로젝트 계획 --> 작업을 수행하기 위해 프로젝트에서 이용 가능한 자원들, 작업 분할, 일정을 설정해야 한다.

▷ 계획 상세:

• 소개
• 프로젝트 조직
• 리스크 분석
• 하드웨어/소프트웨어 자원 요구사항
• 작업 분할
• 프로젝트 일정
• 모니터링, 보고 기법

 

Project plan supplements

• 품질 계획: 프로젝트에서 사용될 품질 절차, 표준을 서술한다.
• 검증 계획: 시스템 검증을 위해 사용될 접근법, 자원, 일정을 서술한다.
• 형상 관리 계획: 사용되는 형상 관리 절차, 구조들을 서술한다. (예: 소스코드 수정/관리/배포)
  **형상 관리: 소프트웨어의 변경사항을 체계적으로 추적/통제하는 것
• 유지보수 계획: 유지보수 요구사항, 비용, 노력을 예측한다.
• 인력 개발 계획: 프로젝트 팀 구성원의 기술, 경험을 개발할 방법을 기술한다.

 

The project planning process

: 프로젝트 시작 단계에서 최초의 프로젝트 계획을 만들 때 시작하는 반복적인 프로세스

▷ 프로젝트 계획의 변경은 필연적이다.

• 프로젝트 동안 시스템, 프로젝트 팀에 대한 더 많은 정보를 얻게 됨에 따라 요구사항, 일정, 리스크 변경 등을 반영하기 위해 정기적으로 계획을 갱신해야 한다.
• 비즈니스 목표를 변경하면 프로젝트 계획도 변경된다.

The Project Planning Process

 

Project scheduling (프로젝트 일정 관리)

: 프로젝트의 내용을 분리된 작업들로 구성 --> 각각의 작업이 실행되는 시기, 방법을 결정하는 프로세스

• 각각의 작업을 완료하는데 필요한 시간, 노력을 추정하고, 식별된 작업을 수행할 인원을 예상해야 한다.
• 각각의 작업을 완료하는데 필요한 자원들(서버에 필요한 디스크 공간, 특수한 하드웨어를 확보하는데 걸리는 시간, 출장 예산 등)도 고려해야 한다.

 

Project scheduling activities

• 작업을 병행적으로 구성하여, 인력을 최적으로 활용한다.
• 작업들 간 종속성을 최소화한다. <-- 한 작업이 다른 작업이 완료될 때까지 기다리는 것으로 인한 지연을 방지한다.
• 프로젝트 관리자의 경험, 상식에 의존한다.

 

Milestones & Deliverables

• 마일스톤(milestones): 중간 산출물
  --> 진행 상황을 평가할 수 있는 일종의 지점 (예: 테스트를 위한 시스템 인계)
• 산출물(deliverables): 최종 산출물
  --> 고객에게 전달되는 작업 산출물 (예: 시스템 요구사항 문서)

 

The project planning process

The Project Planning Process

 

Scheduling problems

• 문제의 난이도와 그에 따른 솔루션 개발 비용을 추정하는 것은 어렵다.
• 생산성은 작업을 수행하는 사람 수에 비례하지 않는다.
• 늦은 프로젝트 중간에 사람을 추가하면 커뮤니케이션 오버헤드로 인해 더 늦어지게 된다.
• 예상치 못한 일이 항상 발생한다. 계획에서는 항상 비상 상황을 예상해야 한다.

 

Schedule representation

▶ 그래픽 표기법 --> 프로젝트를 작업으로 분류한 것을 보여준다.

• 바 차트(간트 차트): 달력 기반으로 일정을 보여준다.
• 액티비티 차트: 작업 종속성, 임계 경로(critical path)를 보여준다.
  **임계 경로(critical path): 액티비티 차트에서 가장 긴 경로를 고려함으로써, 프로젝트를 완료하는데 필요한 최소 시간을 추정할 수 있다.

임계 경로(critical path)

 

Tasks, Durations, Dependencies

Tasks, Durations, Dependencies

 

그래픽 표기법