Ch.3 프로젝트 관리와 계획
[참고 사이트]
* 소프트웨어자산뱅크 사이트
- http://www.swbank.kr (개발 도우미 링크 참고)
* NIPA 소프트웨어공학 포털
- http://www.sw-eng.kr
3.1 프로젝트 범위
소프트웨어 개발 프로젝트 계획은 대상 업무나
문제의 범위를 정의하는 것으로 시작
- 사용자 입장에서 사용자가 이해하는 용어를 사용
- Stateme of Work (SOW) 문서
: 교재 그림 3-2
: 보조 자료 project_plan_guide.pdf 3절
- 시스템의 목표 및 제약 조건
: 개발 산출물에 대한 목표 + 개발 과정에 대한 목표
- 프로세스 모델
- 자원 계획
3.2 노력 추정
소프트웨어 개발 비용은 주로 인력 비용
- 인원 수(MM)와 작업 기간
노력 추정 방법
- 개인적인 경험
- 모델 기반
: 프로그램 규모를 기준 (3.2절)
: 소요 기간을 기준 (3.3절)
노력 추정의 불확실성
- 시스템에 대한 파악이 되지 않은 초기 단계일 수록
불확실하게 추정할 수 밖에 없다.
프로그램 규모 기반 노력 추정 방법
- B. Boehm의 COCOMO (Constructive Cost Model)
: 프로젝트 경험에 의한 모델
: 특정 소프트웨어 회사에 비의존적인 모델
: COCOMO-81과 COCOMO-II
(두번째 버전은 소프트웨어 개발의 단계, 개발 방법을 고려한
더 정교하게 정의한 모델)
- 일반적인 노력 추정을 위한 공식
: A x SIZE^B x M
A : 개발 소프트웨어의 유형에 관한 상수
예) 표3.1
SIZE : LOC 또는 FP
B : 규모와 복잡도에 따른 노력의 증가 비율 (1~1.5)
M (Multiplier) : 프로젝트에 영향을 주는 기타 다른 요소를 고려한 factor
예) 개발 구성원의 특성, 프로젝트의 성격,
제품의 성격, 컴퓨터 시스템의 특성 등
- 프로그램 규모 기반 추정 방법의 문제점
: 크기를 미리 파악하기 어렵다
: B와 M의 숫자는 다소 주관적임
: 서로 다른 프로그래밍언어를 사용할 때 소프트웨어의 크기 숫자가 달라짐
: 프로젝트 수행 경험에 대한 자료가 축적되어 있어야만 모델에서 사용하는
상수를 정확하게 정의할 수 있는데, 그러한 프로젝트 수행 경험 데이터를
축적하는 기관이 드물다.
- COCOMO-II 모델 (3.2.3절)
: 소프트웨어 개발 단계에 따라 또는 개발 방법에 따라
서로 다른 방법을 차별 적용 (표3.3, 표3.4) - 소스 코드가 없는 단계에서 노력 추정
: 예제3.2 노력 추정 계산
- 기능 점수(Function Point)
: LOC를 대체하는 프로그램 크기 추정 방법
(특히 개발 초기에 LOC를 예측하기 어려움)
: 개발 목표 소프트웨어의 기능은 미리 예측하기 비교적 쉬움
(입력, 출력, 질의, 파일, 인터페이스 등)
: FP = GFP x PCA
: E(Effort) = FP / Productivity
: 각 기능 점수를 일괄적으로 적용하지 않고 복잡도에 따라 세분화
: 예제 3.3 (COCOMO-II 기준)
: 예제 3.4 (국내 소프트웨어공학센터 www.sw-eng.kr 에서 정의한 기준)
(국내 SW 생산성은 이 센터에서 발간한 백서를 참고)
3.3 일정 계획
- 소프트웨어 규모와 투입 인력의 총량을 결정 (~3.2절)
- 상세한 일정을 정함(3.3절)
: 개발 프로세스를 이루는 소작업들을 파악하고 순서와 소요 기간을 정함
- WBS (Work Breakdown Structure)
: 프로젝트 업무를 계층적으로 정리한 목록
- CPM (Critical Path Method)
: 작업의 의존성과 소요 기간
: Critical path network : 프로젝트를 완수하기 위한 최소의 기간
: Slack time (slack: not tight; loose)
: 장점
1) 관리자 일정 계획 작성에 도움
2) 작업 사이의 관계를 쉽게 파악, 최장 경로를 파악
3) 병행 작업을 계획할 수 있음
4) 다른 일정 계획안을 시뮬레이션할 수 있음
5) 프로젝트 일정을 점검하고 관리할 수 있음
: CPM 관련 도구
http://sporkforge.com/sched/critical_path.php
- Gantt Chart
: 프로젝트 일정을 보여주는 막대차트
: 각 세부 업무의 시작과 종료일을 표시 (slack time도 표시)
: 진행 사항과 개발자 개별 일정을 파악하기 쉬움
(그림 3.8과 그림 3.9)
- 애자일 프로세스의 계획
: 스크럼 방식의 백로그 (그림 3.10)
3.4 팀 구성
- 소프트웨어 조직 구성에 영향을 주는 요소
: 장기 프로젝트 vs. 단기 프로젝트
1) 경험이 많은 사람과 적은 사람이 혼합되어
경험자는 도전적인 업무를 진행하고
초보자는 경험자로 부터 배우면서 프로젝트를 진행
2) 프로젝트 후반부에 새로운 인력을 투입하다고 해서
투입된 인원 수 대비 비례해서 효율을 높이기 어렵다.
프로젝트 참여자의 이직이 적도록 유도할 필요가 있다.
: 구성원 사이의 의사 교류
1) 작은 팀은 단결력이 높을 수 있으나 복잡하고 대규모 일을 할 수 없음
: 소프트웨어 모듈의 결합도가 높다면
1) 많은 의사 교환이 원활한 팀 구성 필요
: 관리자는 일정, 예산 제한, 품질 등 요소를 고려하여 팀 구성
- 책임 프로그래머 팀
: 구성
1) 책임 프로그래머는 요구 분석과 설계, 중요한 부분의 코딩 및
중요한 기술적 판단을 내린다.
2) 라이브러리안(Librarian)
3) 보조 프로그래머
: 관리자의 명령에 따라 일하는 방식
: 중앙 집중형으로 한 사람에 의해 통제 가능한 소규모 문제에 적합
- 에고레스 팀
- 계층적 팀 구성
e.g.) LiMo 개발 팀 구성
1) 기능 별 2~3명 (+ 특별 능력 LG Soft India 엔지니어)
2) 테스팅 팀
3) SDK 개발팀 (LG Russia 엔지니어)
4) Radio, 펌웨어 담당 외부 엔지니어
- 회사 조직 구성 사례
두 가지 유형 사례
1) 기능별 조직을 구분
예: 무선통신 모뎀 담당 조직, UI 조직, SW 플랫폼 조직
2) 프로젝트별 조직 구분
예: 국내 KT향 출시 신형 스마트폰 개발 프로젝트
개발 이슈를 보완한 사업부 조직
1) 사업부) 회사 내의 작은 회사
예: LG전자 지주회사에서 매년
LG전자내 가전사업부에 일정 돈을 투자하면
가전사업부에서 해당 년도 사업으로 돈을 벌어 지주회사에 갚음
2) CTO (Chief Technical Officer) cf. CEO (Chief Executive Officer)
CTO 산하 조직의 여러 사업부의 개발 이슈를 보완하는 조직
가전사업부와 휴대폰을 개발하는 사업부 모두 소프트웨어 개발이 필요.
CTO내 SW지원 조직에서 가전사업부와 휴대폰 개발 사업부의 SW개발을 모두 지원.
- 데브옵스(DevOps)
1) 개발과 운영을 단일 조직 진행
2) 최근 SaaS (Software as a Service) 형태의 소프트웨어를 개발할 때
기술과 시장의 빠른 변환에 대응하는 방법으로 활용하고 있는 팀 구성
SaaS 사례) 구글 Docs, Gmail
보통 개발자가 개발한 SW 패키지를 받아 운영자가 설치하고 운영하는 반면
SaaS는 운영자/사용자가 웹에 접속하면 바로 사용할 수 있기 때문에
별도의 설치와 운영 과정이 필요 없다.
3.5 위험 관리
- 위험 요소를 파악해서 계획에 반영하여 위험이 발생했을 때
그 영향을 최소화하는 활동
- 소프트웨어 개발은 많은 불확실한 요소가 있기 때문에 중요
e.g.) 휴대폰 리콜 대비 보험
- 위험 관리 5가지 요소
1) 위험 파악
2) 위험 분석과 위험 우선순위화
3) 위험 해결과 위험 모니터링
3.6 계획서 작성과 도구
- 계획서 샘플 (보조 자료)
- 프로젝트 관리 도구
: Redmine
: Excel document
: MS-Project
