우리는 혼자서 프로젝트를 통해 소프트웨어 개발을 할 수도 있지만, 사실상 대부분 팀 단위의 프로젝트를 수행한다.
팀 단위로 여러명의 개발자가 소프트웨어를 개발하게 되면, 혼자 프로젝트를 개발할 때 보다 더 많은 사항들을 고려하고, 계획하고, 관리해야한다.
이번 포스팅에서는 프로젝트의 계획에 대한 부분을 알아보도록 하자.
Project Planning
프로젝트 계획은팀원들과 고객이 소통할 때와프로젝트의 진행상황을 평가하는데에 사용한다.
프로젝트의 계획에는 다음과 같은 작업이 포함된다.
- 작업을 여러 부분으로 나누어 프로젝트 팀 구성원에게 할당
- 발생할 수 있는 문제를 예상하고 해결방안을 준비
Planning stages
언제 project planning을 해야할까?
프로젝트의 계획은 초기에 한번만 세우고 끝나는 것이 아니다. 다음과 같은 단계들에서 계속해서 프로젝트에 대한 계획을 관리해야 한다.
- 프로젝트 제안 단계(Proposal phase)
- SW시스템 개발 혹은 공급 계약을 얻기 위해서 입찰할 때
- 프로젝트 시작 단계(Startup phase)
- 누가 프로젝트에서 일할 것인지, 어떻게 작업들로 나눌 것인지, 자원을 어떻게 할당할 것인지 등에 대한 계획 수립한다
- 프로젝트 진행 단계
- 개발하는 동안 얻은 경험과 새로운 정보를 반영하여 계획을 수정한다
Proposal Phase
전체 소프트웨어에 대한 요구사항을 정의하는것이 중요하다.
실제로는 계획하는 프로젝트의 가격을 책정하여 고객에게 정보를 제공하는것에 목적이 있다.\
Software Pricing
개발자는 소프트웨어 시스템을 만들기 위해 들어가는 비용을 파악해야한다.
이때 HW, SW, 출장, 교육, 노력의 비용을 모두 고려해야한다.
소프트웨어의 비용책정에 영향을 미치는 요인들은 다음과 같다.
- 시장 기회
- 개발 조직은 SW시장의 새로운 영역에 진입하기 위해 가격을 낮게 책정할 수 있다. 이는 이후의 조직에 더 많은 이윤에 대한 기회를 제공할 수 있다
- 계약 조건
- 어떤 고객은 개발자들이 소스코드에 대한 소유권을 보유하고, 그것을 다른 프로젝트에 재사용하는 것을 허용하고 싶을 수 있다. 이 경우 개발자가 사용하는 소스코드의 가치를 낮게 책정할 수 있다.
- 요구사항 변동성
- 요구사항이 변경될 것 같으면 계약을 수주하기 위해서 가격을 낮게 책정할 것이다. 이후에는 요구사항 변경에 대해서 높은 가격을 부과할 수 있다.
- 재정 건전성
- 재정적 문제를 가진 기업의 경우 계약을 수주하기 위해서 가격을 낮게 책정할 수 있다.(폐업보다는 적더라도 이윤을 내는 것이 더 좋다.)
- ex)폐업정리, 사장님이 미쳤어요!
- 비용 추정의 불확실성
- 어떤 조직이 자신의 비용 추정에 대해서 확신하지 못하면 비상상황을 대비하여 정상적인 이윤보다 높게 가격을 책정할 수 있다.
Plan driven developement
계획 기반 개발/계획 주도 개발
대형 개발 프로젝트들의 전통적인 방식으로, 개발 프로세스를 상세히 계획하는 소프트웨어 공학 접근법이다.
관리자들은 프로젝트 의사결정을 지원하고 진행 상황을 측정하는 수단으로 계획을 사용한다
다음과 같은 부분들을 정의한다
- 수행될 작업
- 담당할 사람
- 개발 일정
- 작업 산출물 기록
장/단점
장점
- 초기의 계획 수립이 조직의 이슈들을 고려할 수 있게 한다.
- 잠재적인 문제들과 종속성들이 프로젝트가 진행중일 때가 아닌 프로젝트가 시작하기 전에 발견될 수 있다.
단점
- 개발과정에서 많은 환경 변화 때문에 초기의 결정들을 수정하는 일이 잦다.
Project plans
plan driven development에서 프로젝트의 계획은 이용 가능한 자원들, 작업의 분할, 일정을 설정해야 한다.
계획의 상세에는 다음과 같은 내용이 들어가야 한다.
- 소개
- 프로젝트 조직
- 리스크 분석
- 하드웨어와 소프트웨어 자원 요구사항
- 작업 분할
- 프로젝트 일정
- 모니터링 및 보고 기법
계획 시에는 추가적으로 다른 계획들을 세워볼 수 있다. 예시는 다음과 같다.
| 품질 계획 | 프로젝트에서 사용될 품질 절차와 표준들을 서술한다 |
| 검증 계획 | 시스템 검증을 위해서 사용될 접근법, 자원들, 일정을 서술한다. |
| 형상 관리 계획 | 사용되는 형상 관리 절차와 구조들을 서술한다. |
| 유지 보수 계획 | 유지보수 요구사항, 비용, 노력을 예측하여 기술한다. |
| 인력 개발 계획 | 팀원의 기술과 경험을 개발할 방법을 기술한다 |
Planning Process
프로젝트 계획을 세우는 과정을 알아보자.
프로젝트 계획을 수립하는 것은 반복적인 프로세스로, 계획의 변경은 필연적이다.
프로젝트의 진행으로 팀원과 시스템에 대한 정보를 얻게 됨에 따라 요구사항, 일정, 리스크 변경등을 반영해야 하는 일이 발생한다. 따라서 정기적으로 계획을 갱신해야 한다.
비즈니스 목표를 변경하면 프로젝트의 계획도 변경된다.이 경우 모든 프로젝트에 영항을 미칠 수 있으며, 아예 다시 계획을 수립해야 할 수도 있다.
Project Scheduling
프로젝트 일정 관리
Scheduling은 프로젝트 내용을 분리된 작업들로 구성하는 방법, 각각의 작업이 실행되는 시기와 방법을 결정하는 프로세스이다. 이 과정에서 각각의 작업을 완료하는데 필요한 자원(확보에 시간이 오래 걸리는 자원 등), 출장 시간, 예산 등을 모두 고려해야 한다.
즉, 프로젝트를 어떻게 나누고, 누가 언제 어떻게 작업할 것인지를 결정하는것을 프로젝트 일정관리라고 한다.
Activities
- 프로젝트에 관련된 총 업무를 분리된 작업들로 나눈다.
- 각각의 작업들을 완료하는데 필요한 시간과 자원을 추정한다.
- 작업을 병행적으로 구성하여 인력을 최적으로 활용한다.
- 한 작업이 완료되기를 기다리는 것으로 인한 시간 지연을 방지하기 위해 작업들 간의 종속성을 최소화 한다.
Milestones and Deliverables
Milestone 마일스톤
프로젝트 진행 상황을 평가(검증)할 수 있도록 하는 지점. 즉, 프로젝트의 중간중간에 확인하는 작업 산출물을 말한다.
Deliverables 산출물
고객에게 실제로 전달되는 작업 산출물을 말한다. 예를 들면 시스템 요구사항 문서가 있다.
Project Scheduling Process
프로젝트의 일정을 계획하는 과정은 다음과 같다.
Problems
프로젝트의 일정을 계획하는것은 어려운 작업이다.
- 문제의 난이도를 측정하고, 솔루션에 대한 비용 추정이 어렵다.
- 커뮤니케이션 오버헤드
- 생산성이 사람의 수에 비레하지는 않음
- 예상치 못한 일이 항상 발생
위와 같은 이유로 프로젝트의 일정을 계획하는 것은 힘들 수 있다.
Schedule Representation
일반적으로 프로젝트의 일정을 표현하기 위해서 그래픽 표기법을 사용한다.
그래픽 표기법들은 프로젝트를 작업으로 분류한 것을 보여준다. 작업은 너무 작아서는 안되고, 1~2주 정도 소요되도록한다.
| 간트 차트 | 달력 기반으로 일정을 보여준다. |
| 액티비티 차트 | 작업 종속성과 임계 경로를 보여준다. |
* 임계경로(Critical Path) : 액티비티 그래프에서 가장 긴 경로를 고려함으로써 프로젝트를 완료하는데 필요한 최소 시간을 추정할 수 있다.
'SW Engineering' 카테고리의 다른 글
| [소프트웨어 공학]01. Introduction to Software Engineering (0) | 2023.09.02 |
|---|
