3. 프로젝트 관리

Project management

프로젝트 목표를 효율적이고 효과적으로 달성하는 데 필요한 내적 환경 요소들을 준비하고 유지하는 활동

 

project management의 5단계

1. Initiation & conception(문제 정의)
2. planning
3. launch & execution
4. monitoring & control
5. project closure

1. Initiation & conception(문제 정의)

1-1) 비즈니스 니즈 및 목표, 개발 필요성 등 식별

 

개발의 첫 작업

무엇을 개발할 것인지 정의

개발 범위 결정

 

문제 정의를 위한 필요 사항: 배경지식, 운영 중인 시스템, 실무 담당자와 면담/자료수집 후 분석

 

1-2) 프로젝트 타당성에 대한 예비 조사 수행(feasibility analysis)

경제적 타당성: 경영자 - 투자 효율성/ 분석가 - 투자 대비 효과

기술적 타당성: 

법적 타당성

 

2. Planning

프로젝트 범위 설정, 일정 및 비용 예측, 산출물, 팀 구성(R&R포함)

제시간에 예산 내에서 완료할 수 있도록 하는 방안

 

계획에는 비용,기간,자원 계획 필요

계획 없이 개발시 일정 지연, 비용 초과, 품질 저하 발생 -> 유지보수 비용 증가

 

3. Project execution

프로젝트 수행 계획서에서 정의한 일정에 따라 소프트웨어 개발 활동을 수행

 

4. Project monitoring and control

일정 대비 소프트웨어가 올바르게 개발되고 있는지, 사용자 요구사항 만족시키고 있는지 점검

 

5. Project closure

전체 작업 종료, 프로젝트를 이해 관계자에게 전달 및 보고.

회고미팅, 종료 보고서 작성

---

프로젝트 관리 방안

비용 관리

개발에 소요되는 기간과 비용을 예측

일정 관리

요구사항의 복좝도 ㅋㅋㅋ, 개발자 규모 및 기술 수준, 팀 구성 형태, 리스크 정도 등을 고려하여 계획

어떤 프로세스 모델을 선정했는지, 어떤 Baseline을 정의할 것인지(어디서부터 개발?) 고려

위험 관리

발생 가능한 위험들을 사전 예측하고 예방 및 완화하기 위한 계획 수립

 

---

개발 비용 산정(Cost estimation)

사람(개발자)이 중심이므로 명확한 개발비 산출이 어려움

 

개발 비용에 영향을 주는 것

• 프로그래머 자질
• 소프트웨어 복잡도
• 소프트웨어 규모
• 가용 시간(잘못된 생각: "인력/자원 증가는 개발 기간 단축"=> 아님)
• 신뢰도 수준
• 언어 수준(고급언어가 저급언어보다 5~10배 생산성 증가)

---

개발 비용 산정 타입

• 하향식 산정 기법
• 상향식 산정 기법
• 수학적 산정 기법

하향식 산정 기법

전문가 판단 기법

: 전문가가 개발 비용을 산정-> 신뢰성 높음

짧은 시간에 개발비를 산정해야 할 때 많이 사용

수학적 계산 방법보다 부정확할 수 있음

 

델파이 기법

여러명의 전문가를 모으고, 전문가 의견이 일치하는 것으로 비용 결정

 

상향식 산정 기법

세부 작업 단위별로 비용 산정 후 전체 비용 합산

수학적 계산 방법보다 부정확할 수 있음

 

원시 코드 라인 수(LOC) 기법

: 원시 코드 라인수의 비관치(라인 수를 가장 많게 생각할 때), 낙관치(라인수를 가장 적게 생각할 때), 중간치 측정 후 예측치를 구해 비용 산정. 

LOC estimation: (낙관치+ 4*중간치 + 비관치)/6

 

 

개발 단계별 노력(effort per task) 기법: 생명주기 단계별로 노력(MM)을 산정

코딩만 대상으로 하는 LOC보다 더 정확하다.

 

수학적 산정 기법

COCOMO

:보엠이 제안한 것으로 원시 코드 라인 수에 의한 비용 산정 기법이다.

SW규모(LOC) 예측 후, SW규모에 따라 공식에 대입하여 비용 산정(M/M)

산정결과는 man-month로 나타난다.

비용견적의 유연성이 높다.

1. 가중치 부여

2. 보정 계수 반영

3. 총 개발 기간 산정

 

단순형 프로젝트(50KDSI 이하), 중간형(300KDSI이하), 내장형(300KDSI이상)

노력 조정 수치(EAF: Effort Adjustment Factor) = 필요한 각 항목에 승수 값을 모두 곱한 값.

(제품 특성,하드웨어 특성, 개발자 특성, 프로젝트 특성이 포함)

 

단계별로 값을 예측한 후 인건비 예측하는 COCOMO2도 있음.

 

Putnam 기법

: 생명주기 전 과정에 사용될 노력의 분포를 가정해주는 비용 산정 기법

 

Function Point(FP:기능 점수) 기법

: FP는 소프트웨어 시스템이 가지는 기능을 정량화한 것이다.

기능 점수를 구한 후 이를 이용해 비용 산정

프로그래밍 언어에 독립적

소프트웨어의 기능의 크기, 얼마나 복잡한가를 상대점수로 표현

기능(입,출력, 데이터베이스 테이블,인터페이스, 조회 등)의 수.

원시코드가 작성되기 전이라도 계산할 수 있다.

 

규모를 측정하는 방법

• 기능적 요구 사항이 중심이 되는 측정 방법
• 사용자 관점의 요구 기능을 정량적으로 산정
• 개발 기술, 방법, 품질은 고려하지 않음
• 언어와 무관
• 전체 단계에서 사용 가능

SW 기능 분류

데이터기능 - 내부 논리 파일(IEF) / 외부 연계 파일(EIF)

트랜잭션 기능 - 외부 입력(EI) / 외부 출력(EO) / 외부 조회(EQ)

 

미조정 기능점수(UFP: Unadjusted Function Point)

- Data FP + Transaction FP

 

보정 전 개발 원가

미조정 기능 점수(UFP) * 기능 점수당 단가

 

보정 후 개발 원가

보정 전 개발 원가 * 보정 계수

(1. 연계복잡성 수준 2. 성능요구 수준 3. 운영환경 호환성 4. 보안성 수준)

 

이윤은 개발원가의 25%를 초과하지 않아야 함

직접경비: 개발사업에 소요되는 직접적인 경비. 

 

소프트웨어 개발비 = 보정후 개발원가 + 이윤 + 직접경비

 

기능점수(FP)기법의 장점

: 사용자의 요구 사항만으로 기능을 추출하여 측정.

개발 방법/팀과 무관

계획/분석/설계/구현 단계 등 모든 개발단계에서 사용

 

단점

: 높은 분석 능력 필요

기능 점수 전문가 필요

내부 로직 위주의 소프트웨어에는 다소 부적합

 

정확한 예측을 위한 노력

학계에서 많은 연구 진행

과거의 데이터 이용 및 분석이 필수적

경영진들의 예측보다는 실제 PM의 예측값이 정확

검토회의를 통해 예측값 보정

범위를 나누어 예측하고, 상세한 수준에서 예측하는 것도 중요.