3.1 프로젝트 계획 세우기
📎 소프트웨어공학적 방법으로 개발과 프로그램을 작성해서 개발의 차이점
: 관리된 절차를 따르는 것과 개발자의 전문성(능력)에 의존
SW 프로젝트 관리의 목표
1) 정해진 일정 내에 전달 (일정)
2) 주어진 예산 내에서 완성 (예산)
3) 요구한 품질을 만족 (품질)
4) 잘 기능하는 팀 유지 (팀 관리)
- 소프트웨어를 개발하는 것은 사람에 의존하기 때문에 일관성있는 팀 유지가 필요
SW 프로젝트 관리 단계의 기본적인 활동
1) 프로젝트 계획 (비용, 스케줄)
2) 팀 관리
3) 리스크 관리
프로젝트 계획서 요소
⭐️RFP (Request for proposal, 제안 요청서) : 소프트웨어 주문 고객이 작성한 문서
-> 이 문서에 맞게 프로젝트 계획서 작성
- Project scope (프로젝트 범위)
- 프로젝트의 목적, 제약사항, 조건
- ⭐️ SOW (Statement of work, 작업명세서) : 프로젝트에서 할 일을 정리
- 시스템 구성 (SW, HW)
- Project team organization (팀 구성)
- Man-month plan (비용 계획)
- 몇 명이 투입되어야 하는지
- Work schedule (일정)
- Project management
- Risk management (위험요소 관리)
- Testing plan
- Delivery/maintenance plan
3.2 Effort Estimation (비용 추정)
📎 의의
: 맞지 않을 가능성은 있지만 프로젝트 진행에 있어 가이드를 위한 기준으로 삼을만한 비용 예측
📎 방법
1) 경험 기반
2) 비용 모델 알고리즘 : 정해진 공식으로 계산
- 파라미터 : 프로젝트 크기, 기간(CPM)
- 대표적인 모델 : COCOMO (Constructive Cost Model)
COCOMO
- 잘 정의된 공식 (경험 기반과의 큰 차이)
- ⭐️ 특정 소프트웨어 벤더에 독립적
COCOMO-81
: 초기 버전
📎 기본 아이디어
Effort(Man-month) = A x SIZE^B x M
- A : 소프트웨어 타입
- SIZE : KLOC (1000x Lines of code), FP (기능점수)
- B : 소프트웨어 복잡도 (1 or 1.5)
- M : 개발하는 데 있어서 영향을 미칠 외부 요소 (개발 절차, 팀의 역량)
📎 문제점
1) SIZE를 추정 할 수 없다. (아직 개발 단계 전이므로)
2) B,M의 값을 정할 때 주관이 개입한다.
3) 프로그래밍 언어에 따라 코드의 라인이 달라진다.
4) 팀의 퍼포먼스(개발 역량 등)에 따른 비용 조절 어려움이 있다.
COCOMO-2
핵심 아이디어: 개발이 진행됨에 따라 공식을 다르게 적용하여 SIZE 정보 대체
📎 단계
1) 응용합성/프로토타입 단계 : 스크린 개수, 출력 개수, 컴포넌트의 개수를 가지고 사이즈 결정
2) 초기 설계 : 구현해야할 기능들에 점수를 매겨 총 점수로 사이즈 결정
3) 설계 이후 : LOC 예측하여 사이즈 결정
📎 MM (Man-month) 추정
⭐️ MM = 비용 / 생산성(MM)
: 프로토타입 단계에서 사용
-> 소프트웨어 개발에 필요한 총 MM
MM = FP / 생산성
: 초기 설계 단계에서 사용
-> 기능점수를 구하여 계산
📎 소프트웨어공학백서
: 국내 SW 수준을 조사해서 기록을 남긴 것
- 백서에 있는 생산성으로 MM 계산 -> 회사와 - 고객 간 타협점 역할
3.3 Project scheduling
⭐️ 기법
1) WBS (Work Breakdown Structure)
2) CPM (Critical Path Method)
3) Ghantt Chart
WBS
- 할 일들을 트리(계층적)로 표현하여 분석
- depth가 깊어질수록 구체적
CPM
- 작업 사이의 의존 관계
- 소요기간 추정
- Nodes : 작업
- Edges : 의존관계
- Critical path : 가장 소요 기간이 긴 작업
- 의존관계가 없으면 병렬 진행 가능 (상황에 맞게)
- 위의 경우 critical path는 55일 (A-C-I-K-L)
- critical path가 아닌 경로는 시작 시점 조절 가능
Ghantt Chart
-
각 기간동안 수행할 일 정리
-
gray bar는 slack time(여유 기간)
3.4 Team Organization
Software Project Team : R&R (역할분담)
- PM (Project Manager) : management
- PL (Project Leader) : technology
- Software engineer
- Tester (QA team)
- Build/release team : 버전 관리
- Technical writer : 문서 작업
협력 관점에서의 팀 구성
📎 Chief Pragrammer Team
: chief programmer와 보조역할로 구성
- 소규모
📎 Egoless Team
: 모든 구성원이 동등한 위치에서 협력하고 피드백을 주고받는 구성
- 소규모
ex) 오픈소스 소프트웨어 개발
📎 Hierarchical Team
: 현재 SW 회사들이 취하고 있는 형태
- 대규모
- 계층적
Service-level Organization : DevOps
DevOps = Development + Operations
: 개발팀과 운영팀을 합친 팀 구성
- 기술과 시장의 빠른 변환에 대응하기 위함
- SaaS 형태의 개발을 할 때 따르는 구성 ex) Gmail, 구글 Docs
Company-level Organization
📎 기능 조직
: 기능별로 팀 구성
📎 프로젝트 전담 조직
: 프로젝트 별로 팀 구성
📎 개발 이슈를 보완한 사업부 조직
: CTO 조직을 중심으로 구성
- 전체 회사 사업의 개발 이슈 지원
CEO & CTO & CDO
- CEO (Chief Executive Officer) : 최고 경영 책임자
- CTO (Chief Technical Officer) : 최고 기술 책임자
- CDO (Chief Data Officer) : 데이터 관련 총 책임자
3.5 Risk Management
- 리스크를 예측, 어떻게 대응할지에 대한 계획
- 소프트웨어는 불확실성이 높기 때문에 리스크 관리는 매우 중요한 과정
Risk Management 방법
1) Risk identification : 파악 및 나열
2) Risk analysis & Risk prioritization : 분석 & 우선순위 (발생확률,영향)
3) Risk resolution & Risk monitoring : 해결방법 & 모니터링
Risk identification
: 리스크 타입과 유형
Risk analysis
: 발생확률, 영향
Risk monitoring
: 확률이 높은 리스크에 대해 모니터링 방법 준비
- 인디케이터(지시자) 선정 -> 프로젝트 진행시 인디케이터로 데이터 수집하여 리스크의 발생여부 조사
