[소프트웨어분석및설계🛠️] 2장 프로젝트 관리

출처 : 강의 교안, 시스템분석설계 with 애자일 (생능출판사, 최은만)

1. 프로젝트 관리의 개넘

✏️ SW 개발 프로젝트 실패 원인

- 부족한 소프트웨어 마인드

: 소프트웨어는 하드웨어와 다르게 물리적으로 존재하지 않으므로 언제든지 변경 가능하다?

- 업무 증가와 일정 지연 등의 이유로 공학 기법 적용을 미룸

- 부족한 프로젝트 관리 기술

: 소프트웨어 개발 기술의 고도화, 다양한 응용 도메인으로 프로젝트 수행 시 고려해야 할 요소가 기하급수적으로 증가

 

1.1 프로젝트 관리 (management)

1) 프로젝트 관리

- SW 개발 프로젝트는 최소의 비용으로 최고의 품질을 유지하는 SW를 성공적으로 개발하는 것이 목표

- SW 개발 프로젝트 관리를 어렵게 하는 요인

• 보이지 않는 소프트웨어
• 빠르게 변하는 기술
• 조직마다 다른 프로세스

1.2 프로젝트 관리 단계

1️⃣ 계획 수립

• 프로젝트 목표의 이해와 문서화
• 스케줄, 예산, 기타 자원 요구사항 등 개발

2️⃣ 자원 개발

• 공간, 컴퓨터 자원, 관련 자료 및 인적 자원의 확보

3️⃣ 실행

• 계획의 이행

4️⃣ 모니터링

• 프로젝트 진척도 체크
• 계획과의 편차를 해결하는 대책 강구

 

🌟 프로젝트 계획 수립

• 목표 설정 : 달성 목표와 수행되어야 할 기본 작업(WBS), 산출 결과물과 승인 조건, 가정과 제약 조건, 산출물과 점검 일정
• 일정 계획 (Scheduling) : 개발 프로세스를 이루는 소작업(activity)를 파악하고 순서와 일정을 정하는 작업
• 비용 추정 : 전체 소프트웨어 개발 비용 예측 (estimation)
  • 정확한 비용 예측은 매우 어려움 ➡️ 비용의 예측은 어렵기 때문에 작업이 완료되기 위해 필요한 노동의 양인 노력(effort)의 값으로 추정
  • 알려지지 않은 요소가 산재하고 원가 계산이 어려움

 

2. 프로젝트 관리 기법

2.1 일정 관리 기법

1) 일정 관리 기법

- 요구사항의 복잡도, 개발자 규모 및 기술 수준, 팀 구성 형태, 개발 중에 발생 가능한 리스크 정도 등을 고려하여 계획

- 기본 입력 사항

• 어떤 프로세스 모델을 선정하였는가?
• 어떤 베이스라인(baseline)을 정의할 것인가?

🌟 베이스라인

: 어떤 변경이 발생했을 때 모든 관련자의 합의를 거쳐 변경 사항을 결정한 다움 후속 작업을 수행하기 위한 출발점

 

2) 작업 분할도 (WBS : Work Breakdown Structure)

- 프로젝트의 전체 목표를 중간의 세부 목표들로 쪼개어 나타낸 작업 목록

- 프로젝트에서 수행해야 하는 모든 종류의 작업을 식별해서 트리(tree) 형태로 표현

- 식별된 작업(task) : 추정 가능한 양의 작업, 독립적으로 이루어질 수 있다고 판단될 때까지 분할

- 엑셀, MS Project 와 같은 도구를 사용하여 작성

- 문서화 작업, 프로젝트 리뷰와 같은 작업들도 반드시 태스크로 식별

- 일정계획은 WBS를 기초로 하여 정의

1️⃣ 작업 사이의 의존관계 파악

2️⃣ PERT를 이용한 여유 시간 계산

3️⃣ 소요 자원의 할당

 

(1) PERT/CPM 차트

- 불확실한 프로젝트의 일정, 비용 등을 합리적으로 계획하고 관리하는 기법

- PERT (Project Evaluation & Review Technique)

• 1958년에 개발
• 규모가 크고 복잡한 프로젝트를 보다 수월하게 계획할 수 있도록 설계된 프로젝트 관리 체계

- CPM (Critical Path Method)

• 프로젝트 전반에 관한 개요를 제공하며, 모든 것을 완료하는 데 필요한 총 시간을 산정
• CPM 네트워크를 작성하여 젠체 프로젝트에 소요되는 시간을 계산

- CPM 네트워크

• 작업을 나타내는 노드와 작업 사이의 선후 의존관계를 나타내는 간선으로 구성된 네트워크
• 네트워크의 박스에는 작업의 시작일과 완성일을 표시
• 가장 이른 시작일 (EST, Earlist Starting Time)과 가장 늦은 시작일(LST, Latest Starting Time)을 파악할 수 있음.
• CPM 네트워크에서 작업의 여유시간 = LST - EST
• 일부 노드는 이정표(milestone)로 지정할 수 있다.
• 임계 경로 (critical path) : 가장 소요기간이 긴 경로

(2) 간트 차트 (Gantt Chart)

- 프로젝트의 스케줄링, 예산 산정, 자원 계획을 수립하기 위해 사용하는 일정 표현 기법

- 바 (Bar) 차트 형태로 표시하며 바의 길이에 비례하여 소요 시간을 나타낸다.

- 예비 시간이나 계획 대비 진척도 관리에도 사용

- 소요자원의 할당을 통해 자원관리에도 사용

 

(3) 애자일 프로세스의 스케줄링

- 스토리카드를 주로 사용

cf) CPM 네트워크와 간트 차트는 전통적인 SW 개발 프로세스에서 사용

- 스토리카드의 내용 : 사용작스토리, 비즈니스 우선순위, 스토리 점수, 연관된 스토리 등

 

2.2 비용 관리 기법

1) 비용 관리 기법

- 소프트웨어 개발 비용의 정확한 예측이 어렵다.

- 노력(Effort) : 작업이 완료되기 위해 필요한 노동의 양

• 노력의 단위 : MM(man-month)
• 프로젝트에 투입되는 월-인원을 나타낸다.
• 프로젝트의 크기를 표현할 떄 주로 사용
• 생산성 : MM 당 생산 라인 수 (LOC/MM)

- COCOMO, 델파일 기법, Function Point

 

2) COCOMO (Constructive Cost Model)

- 규모(LOC)를 기반으로 하는 수학적 공식을 사용한다.

- 개발 소프트웨어의 유형이나 소프트웨어에 영향을 주는 요인을 고려하여 보정한다.

- 노력(E) = A × (Size)^B  × M

• A : 소프트웨어 유형에 좌우되는 상수
• Size : 개발될 소프트웨어의 원시 코드 라인수 (KLOC)
• B : 1 ~ 1.5 사이의 상수 값
• M : 보정 계수

- COCOMO 표준 산정 공식

프로젝트 유형	노력	기간
유기형	PM = 2.4 × (KDSI)1.05	TDEV = 2.5 × (PM)0.38
반결합형	PM = 3.0 × (KDSI)1.12	TDEV = 2.5 × (PM)0.35
임베디드형	PM = 3.6 × (KDSI)1.20	TDEV = 2.5 × (PM)0.32

 

• KDSI (Kilo Delivered Source Instructions) 
• PM (Person-Month) = MM
• TDEV : 프로젝트를 종료하는 데 소요되는 개월 수

- 보정계수 M

• 프로젝트에 영향을 주는 다른 요소들을 고려하여 비용 승수(cost-driver)를 결정
• 각 승수의 값을 예측된 PM 값에 곱하여 계산
• 비용 승수 : 보통 0.9 ~ 1.5 사이의 값

 

3) 델파이 기법

- 델파이 기법

• 전문가들의 의견수립, 중재, 타협의 방식으로 반복적인 피드백을 통한 하향식 의견 도출 방법으로 문제를 해결하는 기법
• 1964년 미국에서 RAND 연구소에서 개발되어 IT분야, 연구개발분야, 교육분야, 군사분야 등에서 활용

- 노력 추정을 위한 델파이 기법 적옹

: 다수의 전문가가 모여 소프트웨어의 요구사항을 기준으로 소프트웨어의 크기를 예상

 

4) 기능점수 산정법

- 코드가 작성되지 않은 단계에서 정확한 LOC의 예측은 불가능 ➡️ LOC로 생산성이나 품질을 평가하기는 곤란하다.

- 기능점수 (FP, Function Points)

• 구현되는 언어에 관계없는 메트릭(Metric)
• 소프트웨어 시스템이 제공하는 기능의 필요 정도와 복잡도를 기준으로 평가하는 방식
• 국내에서는 2012년 이후 매년 소프트웨어산업협회에서 SW사업 대가 산정 가이드 제정 공표 ➡️ IFPUG에서 정의한 FP 모델을 기준

 

2.3 위험 관리

1) 위험(risk)

- 요구사항의 빈번한 변경, 프로젝트 팀원의 부적절성과 같이 재작업, 의사소통의 증가와 같은 문제를 유발하는 요인

- 프로젝트 성과를 저하시키는 요인

- 리스크를 사전에 식별하고 관리해야 한다.

 

2) 위험 평가

- 각 위험에 대한 피해 정도, 위험 해결 방법, 이에 대한 비용들을 결정하느 ㄴ것

• 손실 발생 확률
• 손실 발생 규모
• 위험 노출(exposure)

- 영향도에 따라 평가하고 우선순위를 매긴다.

• 정량적 방법 : 리스크 확률을 고려한 영향을 비용으로 환산
• 정성적 방법 : 주관적인 판단으로 평가 (발생확률에 대한 정보가 없을 때

 

3. 기능점수를 이용한 비용산정

3.1 기능 점수 개요

1) 과거의 소프트웨어 비용 산정

- LOC(Lines Of Codes)로 소프트웨어의 규모 파악

- 문제 : 사용한느 프로그래밍 언어마다 기능 구현을 위한 코드 라인 수가 달라진다.

 

2) 기능 점수(Function Point) 방법

- 소프트웨어의 기능과 복잡한 정도를 기준으로 규모 산정

- IFPUG 모델 : 2003년 국제표준 채택 (ISO/IEC 20926:2003)

- 현재 SW개발 프로젝트의 규모의 비용산정의 표준

- 소프트웨어 시스템의 구성요소를 2가지로 정의

• 처리 기능 (Transaction Function) : 외부입력, 외부출력, 외부질의 
• 데이터 기능 (Data Function) : 내부 논리파일, 외부 인터페이스 파일

 

3.2 기능 점수 산정 절차

1) FP 산정 절차 : IFPUG CPM(ISO/IEC 20926)

✏️ FP 산정 유형 : 개발 프로젝트, 개선 프로젝트, 유지보수 프로젝트

 

2) 범위 및 경계 선정

- 기능 점수 산출 범위

• 시스템 전체 (System)
• 응용소프트웨어 전체 (Application)
• 응용소프트웨어 일부 (Subset of Application)

- 고려사항 : 소프트웨어 획득 방식

• 자체 개발 (In-House Development)
• 외주개발 (Outsourcing Part)
• 패키지 구매 (Package Purchase)

- 대상 시스템 범주 표현

: Use Case Diagram, ER Diagram

 

3) 데이터 기능점수 산정

- 데이터 기능의 유형

• ILF (내부 논리 파일, Internal Logic File) : 시스템의 내부에서 생성되고 변경, 보관되는 파일 또는 레코드 타입
• EIF (외부 인터페이스 파일, Exteranl Interface File) : 애플리케이션 사이에서 공유하는 파일로써 참조만 하는 데이터 파일

- ILF와 EIF를 식별하여 복잡도 가중치 결정

• DET (Data Element Type) : ILF와 EIF에 유지되는 필드 중 식별 가능하고 비반복적인 필드
• RET (Record Element Type) : ILF와 EIF 안에서 식별 가능한 데이터 요소의 하위 그룹

 

4) 처리 기능점수 산정

- 처리 기능 유형

• 외부 입력 (EI, External Input) : ILF에 자료를 생성, 변경, 삭제하는 것
• 외부 출력 (EO, External Output) : 시스템이 밖으로 방출하는 자료와 제어를 의미 (보고서나 메시지 등)
• 외부 질의 (EQ, External Query) : 단순한 사용자 질의 

 

5) 예비 기능 점수 산정

- 모든 데이터 기능과 처리 기능엗 해단 복잡도가 산정되면, 예비기능 점수를 산정한다.

 

6) 조정 인자 값 산출

- 조정 인자 값 산출 과정 : 운영적, 환경적 특성을 지원하는 분석

- 14개의 조정 인자

• 데이터 통신
• 분산데이터 처리
• 성능
• 운영환경
• 트랜잭션 비율
• 온라인 데이터 입력
• 사용자 효율성
• 온라인 갱신
• 처리 복잡도
• 재사용성
• 설치 용이성
• 운영 용이성
• 다중 설치성
• 변경 용이성

- 영향도(Degree of Influence) 결정 : 각 인자에 대해 0(영향 없음) ~ 5(많음)까지 할당

- 14개의 시스템 특성에 대해 영향도가 결정되면 각 영향도의 합(TDI, Total Degree of Influence)을 구한 뒤에 조정 인자 값 VAF를 산정 

- VAF = (TDI × 0.01) + 0.65 

 

7) 최종 기능 점수 산출

: VAF 값을 예비 기능 점수에 곱해 최종 기능 점수를 구한다.

 

3.2 기능점수 간이법

1) 기능 점수 간이법

- 기능의 복잡도 판단이 어려울 경우 평균 복잡도를 사용해서 계산한다.

구분	정규법	간이법
선정 목적	상세하고 정확한 기능 점수 측정	개략적인 예측용 기능 점수 산정
측정 항목	데이터 기능과 처리 기능	데이터 기능과 처리 기능
복잡도 적용	기능별, 단위 파일별 복잡도	평균 복잡도
적용 시기	개발 수명주기 전체에서 가능하나, 상세 설계 이후 정확도가 높다.	사업 준비 단계, 제안서 작성 단계 등에서 활용 가능하다.
장점	측정 정확도가 높으며, 다양하게 활용 가능하다	신속한 측정이 가능하다.
단점	사업 초기 단계에서 적용하기 어렵다.	제한적 데이터 사용으로 정확성이 부족하다.

 

- 간이법에 의한 기능 점수 산정 절차

 

✏️ 기능 점수와 품질 척도

- 생산성 (Productivity)

: 기능 점수당 개발 시간 = (프로젝트에 투여된 총 개발 시간) / (배포된 소프트웨어의 기능 점수)

 

- 신뢰성 (Reliability)

: 신뢰성 = (소프트웨어 고장의 횟수) / (총 기능 점수 값)