[Software Engineering] 3. Project Management

📕 목차

1. Project Management
2. Software Cost Estimation
3. Top down techniques
4. Bottom up techniques
5. Mathematical Estimation techniques
6. Scheduling
7. Risk Analysis
8. Project Organization

1. Project Management

📌 Definition

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

📌 The 5 Phases of project management

1️⃣ Initation & Conception

비지니스 니즈 및 목표, 개발 필요성 등 식별
- 문제 정의
  - SW 개발의 첫 작업
  - 무엇(what)을 개발할 것인지 명확히 정의
  - 개발 범위(scope) 결정
- 문제 정의를 위한 필요 사항
  - 개발하고자 하는 영역의 배경 지식
  - 문제를 파악하기 위한 현재 운영 중인 시스템 사용
  - 실무 담당자와 면담하여 자료 수집 & 분석
타당성 예비 조사 수행 (feasibility analysis)
- 경제적 타당성 (Economic feasibility)
  - 경영자(Manager) : 투자 효율성에 관심
  - 분석가(Analyst) : 투자 대비 효과 검토 후 경영자에게 정확한 정보 제공 (시장 분석을 통한 시장성 확인)
- 기술적 타당성 (Technical feasibility)
  - 현재 기술로 사용자 요구 기능을 구현할 수 있는가?
  - 하드웨어 성능이 개발에 지장이 없는가?
  - 개발자의 기술력에 문제가 없는가?
- 법적 타당성 (Lega feasibility)
  - 개발용 SW와 tools가 법적으로 문제가 없는가?
  - 지적 소유권(Intellectual Property Right)과 프로그램 보호법(Computer Program Protection Act)이 강화된 최근 민감한 문제

2️⃣ Planning

이해 관계자들과 협력하여 모든 것을 제한된 시간과 예산 내에서 완료할 수 있도록 방안 구상
프로젝트 범위 설정, 일정 및 비용 예측, 산출물, 팀 구성 (R&R)
소프트웨어 개발 계획
- 비용(cost), 기간(schedule), 자원(resource) 계획 필요
- 계획이 없으면, 일정 지연(schedule delay), 비용 초과(over budget), 품질 저하(quality deterioration) → 유지보수(maintenance) 비용 증가

3️⃣ Execution

수행 계획서에서 정의한 일정에 따라 SW 개발 활동 수행
예산·타임라인·자원·변화·위험·품질·미팅 관리

4️⃣ Monitoring & Control

개발 활동 진척도 관리 및 산출물 품질 모니터링
일정 대비 SW가 올바르게 개발되고 있는지, 사용자 요구사항을 충족시키고 있는지 점검

5️⃣ Closure

전체 작업 종료 단계
프로젝트를 이해 관계자에게 전달 및 보고 등
회고 미팅(Retrospective Meeting), 종료 보고서 작성

📌 Cause of Failure

📌 Plan

비용(Cost) 관리
- SW 개발에 소요되는 기간과 비용 예측
일정(Schedule) 관리
- 요구 사항 복잡도, 개발자 규모 및 기술 수준, 팀 구성 형태, 리스크 정도 등을 고려
- 어떤 Process Model을 선정할 것인가?
- 어떤 Baseline을 정의할 것인가? (어떤 변경 사항에 대해 모든 관련자들이 합의를 거쳐 변경 사항을 결정한 다음 후곳 작업을 수행하기 위한 출발점)
위험(Risk) 관리
- 발생 가능한 위험들을 사전 예측하고 예방 및 완화하기 위한 계획 수립

2. Software Cost Estimation

📌 Difficulties in Predicting SW Dev Cost

가전제품, 건축 공사와 달리 사람(개발자)이 중심
개발자의 능력에 따른 생산성 차이 → 기간과 품질에 영향
다양한 개발 프로세스로 인한 표준화/자동화 어려움 → 다양한 생산성과 품질

∴ 명확한 개발비 산출 어려움

📌 Factors Affecting SW Dev Costs

프로그래머 자질
- 주니어보다 시니어 개발자가 생산성이 더 크다.
SW 복잡도
- Application 개발 < Utility 개발 < System Program 개발
SW 크기
- 참여 인력 증가 → 개발 기간↑, 복잡도↑
- 생산성 = LOC(SW size) / Effort(MM)
가용 시간
- 인력/자원이 증가해도 정상적인 계획에서 최대 75%가 줄일 수 있는 한계 (The Mythical Man-Month)
요구되는 신뢰도 수준
- 요구 신뢰도↑ → 개발 비용↑
프로그래밍 언어 수준
- 고급 언어가 저급 언어보다 5~10배 생산성 증가

📌 SW Cost Estimate 기법

정확한 예측을 위한 노력
학계에서 많은 연구들이 진행
즉흥적인 예측보다 과거 데이터 이용 및 분석이 필수적
경영진보다는 PM의 예측값이 보다 정확
검토 회의를 통해 예측값 보정
범위를 나누어 예측하고, 상세한 수준에서 다시 예측하는 것도 중요

📌 Types

하향식 산정 기법 (Top down techs)
- 전문가 판단 기법 (Expert judgement)
- 델파이 기법 (Delphi technique)
상향식 산정 기법 (Bottom up techs)
- 소스 코드 라인 수(LOC) 기법
- 개발 단계별 노력(effect per task) 기법
수학적 산정 기법 (Mathematical techs)
- COCOMO (COnstructive COst MOdel)
- Putnam model
- FP (Function Point)

3. Top down techniques

📌 전문가 판단 기법 (Expert judgement)

경험이 많은 전문가가 개발 비용 산정 → 신뢰성↑
짧은 시간에 개발비를 산정하거나 입찰에 응해야 하는 경우
수학적 계산 방법보다 경험에만 의존할 경우 부정확할 수 있다.

📌 델파이 기법 (Delphi technique)

전문가 판단 기법의 단점 보완
전문가가 산정한 비용에 대해 다른 전문가들의 의견이 일치하는 지 확인 과정 추가

4. Bottom up techniques

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

원시 코드 라인 수의 비관치, 낙관치, 중간치를 측정 후 예측치를 구해 비용 산정
- 낙관치 : 한 모듈의 가장 이상적인 경우 라인 수
- 비관치 : 한 모듈의 가장 최악의 경우 라인 수
- 중간치 : 한 모듈의 보통의 경우 라인 수
- LOC = (낙관치 + 4*중간치 + 비관치)/6

📌 개발 단계별 노력(Effort per task) 기법

M/M(Man-Month)을 SW Life cycle의 각 단계에 적용하여 단계별로 산정
- 코딩만 대상으로 산정하는 LOC보다 정확한 보완 기법
개발하려는 SW LOC를 예측하여 구현 단계에 대한 M/M 산정
실제론 요구 분석, 설계 등의 단계에서도 많은 인력과 자원이 필요

5. Mathematical Estimation techniques

📌 COCOMO (COnstructive COst MOdel)

💡 SW 규모(LOC)를 예측한 후 SW 종류에 따라 각 비용 산정 공식에 대입하여 비용 산정

1️⃣ 가중치 (M/M 계산)

\(M/M = a*(KDSI)^{b}\)
- 상수 a : 단순형(2.4), 중간형(3.0), 내장형(3.6)
- 상수 b : 단순형(1.05), 중간형(1.12), 내장형(1.20)
단순형 프로젝트 (Organic)
- 복잡도와 난이도가 비교적 높지 않은 업무용 SW
- 중소 규모 크기 (size ≤ 50 KDSI)
중간형 프로젝트 (Semidetached)
- OS, Database 관리 프로그램
- 규모와 복잡도가 중간급 (size ≤ 300 KDSI)
내장형 프로젝트 (Embedded)
- 자동화 기기, 전자 제품과 같은 HW와 밀접하게 관련된 SW
- (size ≥ 300 KDSI)

2️⃣ 보정 계수 (P/M 계산)

노력조정 수치(EAF; Effort Adjustment Factor) = 필요한 각 항목에 승수 값을 모두 곱한 값
- 개발하려는 SW에 요구되는 신뢰도가 높고(1.15), 매우 복잡하며(1.30), 소프트웨어 공학 기술을 거의 사용하지 않고(1.24), 요구되는 개발 일정이 매우 촉박하고(1.10), 다른 요소들은 보통(1.00)일 경우
- EAF = 1.15 * 1.30 * 1.24 * 1.10 = 2.04
노력 조정 수치가 반영된 노력 PM = M/M * EAF
- \(PM = 3.0 * (KDSI)^{1.12} * EAF = 3.0 * 60^{1.12} * 2.04 = 600.179\)

3️⃣ 총 개발 기간 (TDEV: Total DEVelopment time)

\(TDEV = 2.5 * PM^{유형 상수}\)
- 개발하려는 SW KDSI가 60, Semidetached이며, 노력 조정 수치(EAF)가 2.04라면 노력(E)=600.179이다. 이떄 총 개발 기간은?
- TDEV = 2.5 * PM^(0.35) = 2.5 * (600.179)^(0.35) = 23.461(개월)

✒️ COCOMO2

솔직히 COCOMO 방식을 보고 첫 소감은 "와, 이렇게도 계산할 수 있구나"가 아니라, "이걸 어떻게 하는데...?"라는 의문에 가까웠다.

다행히 나만 그런 의문을 가진 것은 아니었는지, 설계 이전에 LOC를 산정하는 것이 너무 어렵다고 판단하여 나온 버전이 COCOMO2.

COCOMO2는 기존 폭포수 모델에 기반한 COCOMO와 달리, 단계별로 값을 예측한 후 인건비를 예측하는 과정을 거친다.

📌 Putnam 기법

💡 SW Life cycle 전 과정에 사용될 노력(effort)의 분포를 가정해 주는 비용 산정 기법

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

💡 기능 점수(FP)를 구한 후 이를 이용해 비용 산정

개발 시 비용 산정, 유지보수 비용 산정, 개발 시 필요한 자원 산정
특징
- SW size 측정
- 기능적 요구 사항이 중심
- 구현 관점이 아닌 사용자 관점의 요구 기능을 정량적 산정
- 측정의 일관성 유지를 위해 개발 기술, 개발 방법, 품질 수준 등은 고려하지 않음
- SW 개발에 사용되는 언어와 무관
- SW Life cycle 전체 단계에서 사용 가능
데이터 기능 (Data Functional Type)
- 회원 입력 정보 보관을 위한 내부 논리 파일 (ex. 회원 정보)
- 회원 가입 시, 회원의 주소를 검색하기 위해 사용되는 우편 번호 찾기의 외부 연계 파일 (ex. 우편번호 정보)
트랜잭션 기능 (Transaction Functional Type)
- 입력(Input), 출력(Output), 조회(Inquiry)
- 내부 논리파일 유지(EI) : 회원가입, 회원 정보 수정, 회원 탈퇴(삭제)
- 사용자에게 정보 제공 추가 처리 로직 없음(EQ) : 회원 정보 조회, 우편 번호 찾기
- 사용자에게 정보 제공 추가 처리 로직 포함(총 개수 계산 포함)(EO) : 회원 목록 조회

🟢 pros

실제 구현 방법과 무관하게 사용자 요구 사항만으로 기능 추출하여 측정
객관적인 요구 사항만으로 측정 (개발 방법, 개발 팀과 무관)
모든 개발 단계에서 사용 가능

🔴 cons

높은 분석 능력 필요 (요구 사항으로부터 기능을 도출하는 상당한 분석 능력 요구)
기능 점수 전문가 필요 (해당 방법을 잘 사용 가능한 전문가 요구)
내부 로직 위주 SW에는 다소 부적합 (사용자가 알 수 있는 기능으로 측정하므로, 내부 로직 위주의 SW 측정에는 부적합)

🟡 데이터 기능 점수 계산 (Data Functional Type)

내부 논리 파일(ILF; Internal Logical File)
- 사용자가 CRUD를 하기 위한 대상
- DB에 존재하는 Data 모임 (데이터베이스 정보)
- DB의 Table, System 내부에서 다루는 File, Class 등
- Application에 존재하는 Data를 논리적으로 모아놓은 것
- 금번 프로젝트에서 생성하여 관리하는 데이터
외부 연계 파일(EIF; External Interface File)
- 측정 대상 Application에서는 참조만 하고 다른 Application에서 유지되는 File
- 다른 Project에서 생성하였으나, 금번 Project에서 참조하는 Data
데이터 기능 점수 = (ILF 개수 * 7.5) + (EIF 개수 * 5.4)
- 7.5: 내부 논리 파일의 평균 복잡도 (Average weight for ILF)
- 5.4: 외부 연계 파일의 평균 복잡도 (Average weight for EIF)

🟡 트랜잭션 기능 점수 계산 (Transactional Function Point)

트랜잭션 기능 측정 : 외부 입력, 외부 출력, 외부 조회의 횟수 세는 것
외부 입력(EI; External Input)
- DB에 데이터를 등록·수정·삭제
외부 출력(EO; External Output)
- 계산하는 로직을 거쳐 data나 제어 정보를 사용자에게 보여주는 기능
- 수학적 계산 로직이 하나 이상 존재하며 그에 따른 파생 데이터 존재 (ex. 학생 학점 조회)
외부 조회(EQ; External Inquiry)
- 로직이 필요 없고, DB에 존재하는 데이터를 찾아 그대로 표시만 해주는 기능
트랜잭션 기능 점수 = (EI * 4.0) + (EO * 5.2) + (EQ * 3.9)
- 4.0: 외부 입력의 평균 복잡도 (Average weight for EI)
- 5.2: 외부 출력의 평균 복잡도 (Average weight for EO)
- 3.9: 외부 조회의 평균 복잡도 (Average weight for EQ)

1️⃣ 미조정 기능 점수 (UFP; Unadjusted Function Point)

Data FP + Transaction FP
단순히 기능적인 요구 사항에 대해서만 계산
여러 가지 특성에 대한 고려는 하지 않음

2️⃣ 보정 전 개발 원가 (Development Cost before adjustment)

미조정 기능 점수(UFP) * 기능 점수 당 단가(Unit cost/UFP)
- 기능 점수 당 단가 : 553,114원 (출처: SW사업대가산정 가이드, 2021)
SW 개발 전체에 대한 기능 점수

3️⃣ 보정 후 개발 원가 (Development Cost after adjustment)

보정 후 개발 원가 = 보정 전 개발 원가 * (규모 보정 계수 * 연계복잡성 수준 보정 계수 * 성능 요구 수준 보정 계수 * 운영 환경 호환성 보정 계수 * 보안성 수준 보정 계수)
- 규모 보정 계수 (scale adjustment)
  - 사업 규모 증가에 따른 생산성 변화에 대한 보정 계수 (대규모: 생산성↑, 일정 규모 이상 시 생산↓)
  - \(= 0.4057 * (log_{e}(FP)-7.1978)^{2} + 0.8878\)
    - 500FP 미만 : 1.2800 적용
    - 3,000FP 초과 : 1.1530 적용
- 애플리케이션 유형에 따른 보정 계수 (4가지)
  1. 연계 복잡성 수준
    - 대상 Application 연계 기관수가 증가함에 따른 Project 관리의 복잡성 의미
    - 연계 기관수가 많을 수록 높은 값을 가진다.
  2. 성능 요구 수준
    - 응답시간 또는 처리율에 대한 사용자 요구 수준의 복잡성 의미
    - 성능 요구 수준이 복잡할 수록 높은 값
  3. 운영환경 호환성
    - 응용 SW의 설치 운영 환경의 상이한 정도
    - 상이한 운영 환경이 요구되거나, 상이한 HW와 SW 운영환경을 지원하도록 개발되는 요구 정도가 복잡할 수록 높은 값
    - 제안 요청서에 하나 또는 그 이상의 운영 환경에 대한 요구 사항, 서버 이중화 요구 여부, Application이 운영되는 HW/SW 환경의 유사한 정도를 판단하여 측정 가능
  4. 보안성 수준
    - secure 코딩, 웹 취약점 점검, 암호화 점검, 개인정보보호 등 보안성에 대한 요구수준 의미
    - 보안성에 대한 요구 정도가 복잡할 수록 높은 값
    - 4가지 보안 요구사항은 보안과 관련된 대표적인 요구사항 4가지. 이외 보안요구 사항을 포함하여 보안 요구 사항 총 개수로 복잡도 수준 측정 가능

📌 Example : 학사 관리 개발 원가 계산

단계	기능 (Function)			개수	평균 가중치	기능 점수
①	데이터 기능	ILF	학적·교육 과정·개설 강좌·수강 과목·성적 테이블	5	7.5	37.5
		EIF	교수 정보·학생 정보 테이블	2	5.4	10.8
	트랜잭션 기능	EI	학적 자료 CUD, 교육 과정 CUD 개설 강좌 CUD, 수강 과목 CUD 시간표 CUD, 이수 구분 변경, 성정 CU	18	4.0	72.0
		EO	유사/동일 과목 조회, 성적 조회	2	5.2	10.4
		EQ	학적 자료·교육 과정·개설 강좌·수강 과목·시간표·교수 정보·학생 정보 조회	7	3.9	27.3
	기능 점수 합		(57.5 + 25.4) + (184.0 + 25.2 + 7*3.9) = 158
②	보정 전 개발 원가		158 * 553,114원 = 87,392,012원
③	보정 계수		규모 보정(1.28), 연계복잡성(0.94), 성능(1.05), 운영환경(1.19), 보안성(1.06)
	보정 후 개발 원가		87,392,012 * (1.28 * 0.94 * 1.05 * 1.19 * 1.06) = 139,268,112원

(붉은 색은 상수값)

경영학적 관점에서 봤을 때, "가격 = 원가(=재료비+노무비+제조 경비) + 이익"
- 법적으로 이윤율은 개발원가의 25%를 초과하지 않는 범위에서 계산해야 한다.
- 직접 경비 : SW 사업에 소요되는 직접적인 비용 (12가지)
  1. 당해 SW 사업에 특별히 필요로 하는 컴퓨터 시스템 사용료
  2. 당해 SW 사업에 특별히 필요로 하는 SW tools 사용료
  3. 선투자 후정산 사업으로 추진되는 사업의 경우 지급 이자
  4. 발주자의 요구에 의한 특정 기술 도입과 관련된 전문가 비용
  5. 당해 SW 사업에 직접 필요한 여비
  6. 특수 자료비
  7. 제출 문서의 인쇄, 청사진비
  8. 자료 조사비
  9. 기자재 시험비
  10. 위탁비와 현장 운영비
  11. 모형 제작비
  12. 그 밖에 당해 SW 사업에 특별히 소요되는 직접 비용
- 소프트웨어 개발비 = 보정 후 개발원가 + 이윤 + 직접 경비

6. Scheduling

📌 Definition

Estimation 이후 작업 일정 계획 수립 단계
프로젝트 완성을 위해 수행되어야 할 작업들을 나열한 후, 연관 관계와 순서에 따라 기간 별로 표시
각 작업이 언제 완성되어야 하고, 어떤 산출물이 나오는 지 표시
R&R (Roles and Responsibilities) 정립

📌 작업 분할 구조도 (WBS; Work Breakdown Structure)

프로젝트 목표 달성을 위해 필요한 인도물(Deliverables) 산출
프로젝트 팀이 수행할 작업을 인도물 중심으로 분할한 계층 구조 체계
- 목표 달성을 위한 활동과 업무 세분화
- 프로젝트 구성 요소들을 계층 구조로 분류
목적과 용도
- 사용자와 개발자 간의 의사소통 도구
- 프로젝트 업무 내역 가시화
- R&R 명시
- 필요 인력과 일정 계획, 개발비 세우는 데 기초로 활용
- 성과 측정 및 조정 시 기준선으로 활용 가능

🟡 Waterfall model 기반 WBS 예시

📌 WBS의 표현

1️⃣ Gantt chart (Time-line chart)

프로젝트 일정을 bar chart 타입으로 표현

2️⃣ PERT chart

PERT: Promgram Evaluation and Review Techniques
프로젝트에서 수행되어야 하는 task 의존성 관계 표현
- 원: Task
- 화살표: Task 간의 의존성
Critical Path: 각 경로 상에 있는 Task 수행 일수의 합이 가장 많은 경로

7. Risk Analysis

📌 Process

1️⃣ 위험 요소 식별 (Risk Identification)

위험 요소(Risk Factor)	위험 내용(Details)
개발자 이직	프로젝트 수행 중 개발자의 이직
요구 사항 변경	요구 사항 확정 이후의 변경 요규
발주사의 재정적 어려움	고객사의 경제적 어려움
예상을 빗나간 투입 인력	처음 예측 인력보다 더 많은 인력 필요
개발 기간 부족	처음 예측 개발 기간보다 더 많은 기간 소요
개발비 초과	처음 예측 개발비보다 많은 비용 요구

프로젝트 수행 시 발생 가능한 위험 요소 식별 단계
Brooks Low: 진행 중인 SW 개발 프로젝트에 새로운 개발 인력을 추가로 투입하면, 의사소통 채널 증가로 인해 개발 기간이 더 증가한다.

2️⃣ 위험 분석 (Risk Analysis)

위험 요소 식별 후, 위험 요소 발생 가능성과 영향력 판단 (경험 많은 개발자에게 의존)
위험 발생 가능의 척도 (risk possibility)
- 매우 낮음(< 10%), 낮음(10~25%), 보통(25~50%), 높음(50~75%), 매우 높음(> 75%)
위험 발생 확률 (risk probability)
- 상(> 80%), 중(30~80%), 하(< 30%)
영향력 (risk impact)
- 재앙, 심각함, 해결 가능함, 경미함 등
- 비용과 일정으로 분류: 상(> 20%), 중(5~20%), 하(< 5%)

3️⃣ 위험 계획 수립 (Risk Planning)

식별된 위험 요소에 대응 방안 수립

4️⃣ 위험 감시 (Risk Monitoring)

식별된 위험 요소 발생 확률과 변화 등 관리
예측 위험 실제 발생 여부 확인
실전에서 위험 대응 방안 적절성 여부 확인

8. Project Organization

📌 Roles of Project Member

프로젝트 관리자(PM)
- 프로젝트 전반에 걸친 관리 활동과 중요 이슈 해결
프로젝트 리더(PL)
- 설계·구현 등의 전반적 무결성 검증
- 팀 간의 기술적 조율, 일정 조절 및 모니터링, 프로젝트 문서 및 통합 등
프로젝트 팀장(TL)
- 프로젝트에 다수의 팀이 있을 경우, 팀을 주도적으로 이끌면서 기술적 문제 해결
프로젝트 엔지니어(PE)
- 넓은 의미: 엔지니어
- 좁은 의미: 개발자, 분석 설계자, 데이터베이스 개발자, UI 개발자 등
형상 관리자(CM)
- 개발 과정에서 Baseline 산출물 관리와 변경 요청 처리
품질 관리자(QE)
- 개발 산출물에 대한 오류 확인
- 결함 검출을 위한 리뷰
- 테스트 활동 등을 계획하고 추진
리어종 그룹(Liaison Group)
- 비지니스 그룹과의 의사소통 담당

📌 Team Structure

팀 구조 선정 전략
- 프로젝트 수행 시 비용 절감 측면에서 효과적인가?
- 팀 구성원의 이직이나 교체가 발생할 가능성이 있는가?
- 신입 엔지니어에게 프로젝트에 대한 이해나 경험을 높일 수 있는 기회를 제공하는가?
- 최신 기술 또는 특정 지식에 대하여 공유하고 전파할 수 있는가?

📌 Notion

문서 목적: 해당 문서가 왜, 어떤 목적과 내용을 포함하는지
관련 문서: 해당 문서와 관련된 공식적인 이전 baseline 산출물, 관련 표준 등
팀 구조: 집중형/분산형/계층형 팀 구조
품질 관리 적용 기법: 리뷰, 인스펙션, 테스트 등

저작자표시 비영리