[CS][소프트웨어공학] SW 개발 프로젝트 관리 기법(일정/비용/위험 관리), SW 개발 프로젝트 조직 유형

 

 

[1] SW 개발 프로젝트 실패 원인

• 부족한 SW 마인드 : 언제든 변경이 가능하다는 오만함
• SW 공학 기술의 활용 미흡 : 공학 기법 적용을 미룸
• 부족한 프로젝트 관리 기술 : 수행 시 고려해야 할 요소가 기하급수적으로 증가

 

 

 

[2] SW 개발 프로젝트 관리

• SW 개발 프로젝트의 목표
  • 최소의 비용으로 최고의 품질을 유지하는 SW를 성공적으로 개발하는 것
• 프로젝트 관리의 목적
  • 작업 수행에 필요한 여러 가지 자원, 인력, 비용, 재료, 기술 등을 가장 효과적으로 사용하여 프로젝트의 목표를 달성하는 것
• SW개발 프로젝트 관리를 어렵게 하는 요인
  • 보이지 않는 SW, 빠르게 변하는 기술, 조직마다 다른 프로세스

 

 

 

[3] SW 개발 프로젝트 관리 단계

1. 계획 수립
   • 프로젝트 목표의 이해와 문서화
   • 스케줄, 예산, 기타 자원 요구사항 등 개발
2. 자원 획득
   • 공간, 컴퓨터 자원, 관련 자료 및 인적 자원의 확보
3. 실행
   • 계획의 이행
4. 모니터링
   • 프로젝트 진척도 체크
   • 계획과 편차를 해결하는 대책 강구
   • 문제 찾기

 

 

 

[4] SW 개발 프로젝트 계획

• 목표 설정
  • 달성 목표
  • 수행되어야 할 기본 작업 (WBS)
  • 산출 결과물과 승인 조건
  • 가정과 제약조건
  • 산출물
  • 점검 일정
• 일정 계획 (scheduling)
  • 개발 프로세스를 이루는 소작업(activity)을 파악하고 순서와 일정을 정하는 작업
• 비용 추정 : 소프트웨어 개발 비용 예측(estimation)
  • 정확한 비용 예측은 매우 어려움
  • 알려지지 않은 요소가 산재하고 원가 계산이 어려움

 

 

 

[5] SW 개발 프로젝트 관리 기법

• 일정 관리 : WBS, PERT, 간트차트
• 비용 관리 : 비용 예측은 어렵기 때문에 작업이 완료되기 위해 필요한 노동의 양인 effort 값으로 추정, COCOMO, 기능점수 산정법, 전문가 판단 등
• 위험 관리

 

 

 

[5.1] 일정 관리 기법

• 요구사항의 복잡도, 개발자 규모 및 기술 수준, 팀 구성 형태, 개발 중에 발생 가능한 리스크 정도 등을 고려하여 계획한다.
• 기본 입력 사항
  • 어떤 프로세스 모델을 선정하였는가
  • 어떤 베이스라인을 정의할 것인가
    • 베이스라인 : 어떤 변경이 발생했을 때 모든 관련자의 합의를 거쳐 변경 사항을 결정한 다음 후속 작업을 수행하기 위한 출발점/합의시점으로 각 단계별로 생성한다.
• WBS (Sork Breakdowm Structure, 작업 분할도)
  • 프로젝트의 전체 목표를 중간의 세부 목표들로 쪼개어 나타낸 작업 목록
  • 프로젝트에서 수행해야 하는 모든 종류의 작업을 식별해서 Tree 형태로 표현된다.
  • Task : 식별된 작업, 추정 가능한 양의 작업, 독립적으로 이루어질 수 있다고 판단될 때까지 분할한다.
  • 엑셀, MS Project로 주로 작성한다.
  • 문서화 작업, 프로젝트 리뷰와 같은 작업들도 반드시 task로 식별해야 한다.

• 일정계획은 WBS를 기초로 하여 정의한다.
  1. 작업 사이의 의존 관계 파악 (무조건 있는 것은 아니며 개발 순서 때문에 해야 하는 일이다. 동시에 할 수 있는 일을 찾아 시간 줄이기가 필요하다. )
  2. PERT를 이용한 여유 시간 계산
  3. 소요 자원의 할당

 

 

 

[5.1.1] PERT/CPM 차트

• 불확실한 프로젝트의 일정, 비용 등을 합리적으로 계획하고 관리하는 기법
• PERT (Project Evaluation & Review Technique)
  • 규모가 크고 복잡한 프로젝트를 보다 수월하게 계획할 수 있도록 설계된 프로젝트 관리 체계
• CPM (Critical Path Method)
  • 프로젝트 전반에 관한 개요를 제공하며 모든 것을 완료하는 데 필요한 총 시간을 산정
  • CPM 네트워크를 작성하여 전체 프로젝트에 소요되는 시간 계산
• CPM 네트워크
  • 작업을 나타내느 노드와 작업 사이의 선후 의존관계를 나타내는 간선으로 구성된 네트워크
  • 네트워크 박스에는 작업의 시작일과 완성일 표시
  • EST(가장 이른 시작일)과 LST(가장 늦은 시작일)을 파악 가능
  • CPM 네트워크에서 작업의 여유시간 = LST - EST
  • 일부 노드는 이정표(milestones)로 지정 가능
• Ex. CPM 네트워크 작성을 위한 소작업 리스트
  • WBS의 각 작업에 대한 선후작업 관계와 소요시간 예측
  • 기다리고 가야 하는 규칙은 없다.

소작업	선행작업	소요기간(일)
A	-	8
B	-	15
C	A	15
D	-	10
E	B, D	10
F	A, B	5
G	A	20
H	D	25
I	C, F	15
F	G, E	15
K	I	7
L	K	10

• 임계 경로 (critical path)
  • 가장 소요기간이 긴 경로
  • 프로젝트 관리에 중요하다.
  • 최대한 단축할 수 있게 해야 전체 일정이 단축된다.

가능 경로	소요기간 (일)
S-A-M1-C-M4-I-M6-K-M8-L-X	55
S-A-M3-F-M4-I-M6-K-M8-L-X	45
S-A-M1-G-M7-J-X	43
S-B-M3-F-M4-I-M6-K-M8-L-X	52
S-B-M2-E-M7-J-X	40
S-D-M2-E-M7-J-X	35
S-D-M5-H-X	35

 

 

 

[5.1.2] 간트차트

• Gantt Chart 
  • 프로젝트의 스케줄링, 예산 산정, 자원 계획을 수립하기 위해 사용하는 일정 표현 기법
  • Bar 형태로 표시, bar의 길이에 비례하여 소요 시간을 나타낸다.
  • 예비 시간이나 계획 대비 진척도 관리에도 사용한다.
  • 소요자원의 할당을 통해 자원 관리에도 활용한다.

출처 : 위키피디아

 

 

 

[5.1.3] 애자일 프로세스의 스케줄링

• 애자일 프로세스는 스토리 카드를 주로 사용
  • 프로세스가 짧아서 간단하게 표현할 수 있다.
  • 번외로 CPM 네트워크와 간트차트는 전통적인 SW 개발 프로세스에서 사용된다.
• 스토리카드의 내용 : 사용자스토리, 비즈니스, 우선순위, 스토리 점수, 연관된 스토리 등
  • 점수가 높을수록 어렵고, 낮을수록 쉬운 것이다.
  • 우선순위는 사용자가 정하는 것이다.

스토리카드 예시

 

 

 

[5.2] 비용 관리 기법

• SW 개발 비용의 정확한 예측이 어렵기에 필요한 것
• Effort(노력) : 작업이 완료되기 위해 필요한 노동의 양
  • 이게 곧 비용이 된다.
  • 노력의 단위 : MM (man power/month)
  • 일반적인 수준에서 표시한다.
  • 프로젝트에 투입되는 "1달에 몇 명 필요한지"를 나타낸다.
  • 프로젝트의 크기를 표현할 때 주로 사용한다.
• Ex. 5MM : 1 Manpower로 5개월 소요, 3 Manpower로 1.7개월 소요
• 생산성 : MM 당 생산라인 수 (LOC/MM)
• COCOMO, 델파이 기법, Function Point

 

 

 

[5.2.1] COCOMO

• COCOMO / COCOMO 2 (Constructive Cost Model)
  • 규모(LOC)를 기반으로 하는 수학적 공식 사용한다.
  • 여기에 개발 SW 유형이나 SW에 영향을 주는 요인을 고려하여 보정한다.
  • 가장 먼저 나온 비용 산정 기법이다.
  • 노력 ∝ 규모
  • 공식은 아래와 같다.

• 공식에 등장하는 변수 설명은 아래와 같다.
  • A : SW 유형에 좌우되는 상수
  • size : 개발될 SW의 원시코드 라인 수 (KLOC를 기본적으로 사용한다.)
  • B : 1에서 1.5 사이의 값 (정해져 있는 상수 값이다.)
  • M : 보정계수
    • 추가 고려 요인들을 의미한다.
    • 프로젝트에 영향을 주는 다른 요소들을 고려하여 비용 승수(cost-driver)를 결정한다.
      • 비용 승수 : 비용이 발생하는 원인 or 요소, 일반적으로 0.9 ~ 1.5 사이 값
    • Ex. 프로그램의 경험이 많다면 노력 예측 값 ↓, 실시간 처리 요구가 있다면 예측 값 ↑
    • 각 승수의 값을 예측된 PM 값에 곱하여 계산

• COCOMO 표준 산정 공식
  • 프로그램의 유형에 따라서 다르다. 
    • 유기형 : 단순, Office 프로그램
    • 반결합형 : OS/네트워크 시스템
    • 임베디드형 : 제어/디바이스 간 연결 시스템
    • 사실 위 세가지로 명확하게 구분할 수 있는 기준은 없다. 따라서 여러 유형이 복합적으로 얽혀 있을 수 있다.

• 공식에 나오는 변수 설명은 아래와 같다. 
  • KDSI : Kilo Delivered Source Instructions = KLOC
    • 이전에 출시한 다른 유사한 SW를 참고하여 개발하지도 않아도 추정할 수 있다.
  • PM : Person-Month = MM
  • TDEV : 프로젝트를 종료하는 데에 소요되는 개월 수

• 예시 : 33,360 LOC로 예상되는 반결합형 프로젝트
  • 33,360 LOC = 33.36 KLOC
  • 개발노력(PM) : 3.0 x (KDSI)^1.12 = 3.0 x (33.36)^1.126 = 152.45 = 153 MM (인원/월)
  • 보정 : 비용 승수 요소 결정에 따라 scaling을 하여 곱해준다. 아래 예시는 2가지를 찾아 곱해준 것으로 기능이 더 복잡해진다.
    • 152.45 x (1.14 x 0.88) = 152.94
  • TDEV : 2.5 x (PM)^0.35 = 2.5 x (152.94)^0.35 = 14.5M(월)
  • 소요인원(N) = MM / M = 152.94 / 14.5 = 10.5 ≒ 11명
    • 11명 정도가 14.5개월 투입되면 해결할 수 있는 프로젝트다.
  • 생산성 = MM당 생산하는 LOC = LOC / MM = 33360 / 152.94 ≒ 218
    • 한 달에 218 line 생산되면 기간 안에 끝낼 수 있다.
• 문제점
  • KLOC를 잘못 추정하면 값이 완전 달라진다. 그래서 LOC를 쓰지 말자 해서 나온 것이 Function Point이다.
  • 개발할 SW의 "프로젝트 유형"을 명확하게 구분할 기준이 없다.
    • 프로젝트가 커질수록 서브 시스템으로 나뉘고 그럴수록 각각의 서브 시스템이 다른 프로젝트 유형을 가질 수 있다.

 

 

 

[5.2.2] 델파이 기법

• 전문가들의 의견 수립, 중재, 타협의 방식으로 반복적인 피드백을 통한 하향식 의견 도출 방법으로 문제를 해결하는 기법
• 1964년 미국의 RAND 연구소에서 개발되어 IT/연구개발/교육/군사 분야 등에서 활용된다.
• 노력 추정을 위한 기법이다.
• 다수의 전문가가 모여 SW의 요구사항을 기준으로 SW 크기를 예상한다.
• 오랜(n주) 회의로 합의가 필요하다.

 

 

 

[5.2.3] 기능점수 산정법 (Function Point)

• 코드가 작성되지 않은 단계에서는 정확한 LOC의 예측 불가능 하다. (COCOMO의 문제점) 따라서 LOC로 생산성이나 품질을 평가하기는 곤란하다. 그래서 등장한 것이 FP(기능 점수, Fuction Point) 이다.
• 기능에 점수를 부여하는 방법
• 구현되는 언어에 관계 없는 Metric
• 소프트웨어 시스템이 제공하는 기능의 필요 정도와 복잡도를 기준으로 평가하는 방식
  • 복잡도 : 기능마다 복잡한 정도가 다름
• 요즘은 이 기법을 계속 사용한다.
• 국내에서는 2012년 이후 매년 SW산업협회에서 "SW사업 대가 산정 가이드" 제정을 공표한다. IFPUG에서 정의한 FP모델을 기준으로/표준으로 한다.

 

 

 

[5.3] 위험 관리 기법

• 위험 (risk)
  • 요구사항의 빈번한 변경, 프로젝트 팀원의 부적절성과 같이 재작업, 의사소통 부재와 같은 문제를 유발하는 요인
  • 프로젝트 성과를 저하시키는 요인
• 리스크를 사전에 식별하고 관리해야 함

• Boehm(COCOMO 창시자)이 정의한 10대 위험요소
  • 인력 부족(personnel shortfalls)
  • 비현실적 일정 및 예산
  • 잘못된 기능과 특징 개발
  • 잘못된 인터페이스 개발
  • 과포장(필요하지 않은 좋은 기능 추가)
  • 계속적인 요구변경
  • 외부에 보일만한 컴포넌트 빈약
  • 외부에서 관찰 할 만한 기능의 빈약
  • 실시간 성능의 빈약
  • 낡은 기술
• 위험 평가
  • 각 위험에 대해 피해 정도, 위험 해결 방법, 이에 대한 비용들을 결정하는 것
  • 예시 : 손실 발생 확률, 손실 발생 규모, 위험 노출
• 영향도에 따라 평가하고 우선순위를 매긴다.
  • 정량적 방법 : 리스크 확률을 고려한 영향을 비용으로 환산
  • 정성적 방법 : 주관적인 판단으로 평가, 발생확률에 대한 정보가 없을 때 사용하는 방법
• 위험 요소를 해소하기 위한 방법을 강구하고 프로젝트를 실행하는 동안 이를 적용한다.
• 방법
  • 리스크를 피하기 위해 계획을 변경하기
  • 책임을 다른 기관에 맡기기
  • 프로토타이핑 만들기
  • 유능한 인재를 등용하기
  • 3자와 협업하기

 

 

 

[6] SW 개발 프로젝트 조직

• 조직의 구성은 SW 개발 생산성에 큰 영향을 미친다.
• 프로젝트 팀 조직의 정의는 아래 쟁점으로 구성된다.
  • 역할과 책임이 어디 있는가?
  • 어떤 통로로 정보가 전달되고 결정되는가?
• 프로젝트 구성원의 역할 예신느 아래와 같다.
  • 프로젝트 관리자(PM)
  • 프로젝트 팀장(TL)
  • 형상 관리자(CM)
  • 프로젝트 리더(PL)
  • 프로그램 엔지니어(PE)
  • 품질 관리자(QE)
  • 리어종 그룹(Liaison Group)
• 프로젝트 팀 구조의 유형

 

 

 

[6.1] 중앙집중형 구조

• 프로젝트에서 수행해야 할 작업 목록이 단순하거나 충분히 이해된 경우에 적합하다.
• 의사결정권이 리더에게 집중되어 있다.
• 계층적 팀 구조
• 유능한 프로젝트 리더가 필요하다.
• 문제 해결이 신속하게 이루어질 수 있다.
• 의사소통의 패턴이 매우 단순하다.

 

 

 

 

[6.2] 분산형 팀 구조

• 프로젝트의 주요 의사결정이 팀 구성원이 합의에 의해 이루어지는 민주주의적 팀 구성
  • 서로 협동하여 수행하는 Ego-less 팀
  • 자신이 일을 알아서 수행
• 의사소통 패턴이 복잡하므로 대규모 구성원을 포함하는 프로젝트에는 적합하지 않다.
• 장기 프로젝트에 적합하다.

 

 

 

 

 

[6.3] 하이브리드 팀 구조

• 중앙집중형 팀 구조와 분산형 팀 구조를 통합한 계층형 팀 구조
  • 내부는 분산형 구조로 파트가 이루어져 있고 파트와 파트 사이에서 팀장이 결정할 수 있게 하는 구조
• 프로젝트 관리자 : 각 팀의 리더와 중요한 의사결정을 하기 위한 중앙집중형 구조
• 팀 내부의 운영 : 분산형 구조를 채택하여 의사소통
• 계층이 여러 개 생기기 때문에 의사 전달 경로가 길어질 수 있다.