: 만들어진 요구사항 명세서를 기반으로 프로젝트 계획서를 작성.
[프로젝트 계획서]
: 프로젝트 참여자 모두가 프로젝트를 진행해가며 참조하는 프로젝트의 중심이 되는 문서.
- 프로젝트 계획서에는
1) 프로젝트 개발 생명주기에 맞추어 모든 작업을 테스크(Task)들과 액티비티들로 나누어야 한다.
2) 기간과 책임자를 분배해 업무 및 일정 계획이 나타나 있어야한다.
# 이미 제안서와 요구사항 문서 작성을 통해 프로젝트의 범위를 파악해둠.
[프로젝트 관리자의 업무]
: 위에서 말한 프로젝트 계획서에 있어야 하는 것들 맞추기 위해, 프로젝트 관리자가 해야하는 것들
1) 프로젝트 테스크들 파악
2) 각 테스크를 수행하기 위한 필요한 노력을 예측
3) 인적 자원 및 기타 자원을 각 테스크에 할당
4) 일정계획 수립
=> 프로젝트 참여자의 검토를 거쳐 합의 하에 채택.
[프로젝트 계획서의 역할과 중요성]
- 프로젝트를 진행하는 동안 주기적으로 통제를 기본적으로 수행. ex)주간회의, 월간회의 등
- 프로젝트와 참여자가 크고 많을수록, 프로젝트 계획서의 중요도가 커짐.
[프로젝트 팀 구성]
: 프로젝트에 알맞은 팀 구성 방법과 규모는 프로젝트의 기간과 크기에 따라 달라질 수 있다.
1. 팀장과 구성원의 2단계 구조 : 프로젝트 책임자인 팀장이 상위 단계, 나머지 참여자는 전부 다음 단계에 속하는 구조.
- 소규모 프로젝트에 적합(주로 팀장 = 책임 프로그래머)
- 팀장이 지시, 통제, 계획작성을 담당
=> 팀장의 능력에 프로젝트 성공여부 달려있음.
2. 계층적 팀 구성
: 팀의 구성이 둘 이상의 단계로 나누어진다.
- 큰 프로젝트, 많은 참여인원에 적합
- 각 그룹의 리더가 자기 바로 하위의 참여자를 책임지고 관리. 단계별 보고체계.
- 의사소통 경로를 줄일 수 있다.
+) 단계별 보고체계라 항상적 의사소통에 무리. 주월간 회의 형태로 의사소통 실시.
3. 민주적 팀 구성
: 모든 팀원이 리더. 중요 의사결정은 팀원 모두가 참여
- 현실적으로 많이 사용 X
- 팀원의 사기, 작업 만족도를 높임.
- 의사소통 시간이 길어 합의점 찾기 오래걸림.
[스케쥴링(Scheduling)]
: 프로젝트 완성을 위해 수행되어야 할 작업을 나열한 후 연관 관계와 순서에 따라 기간 별로 나타내는것.
[WBS(Work Breakdown Structure)]
: 대표적인 스케쥴링 방식
- 톱 다운(Top down) 방식으로 프로젝트 세분화해 단위 작업 파악하는 기법.
# 톱 다운(Top Down) : 하향식. 상위 단계부터 쪼개 하위 단계로 내려오며 세분화.
- 프로젝트 목표 달성후 필요한 인도물 산출 위해 프로젝트 팀이 수행할 작업을 인도물 중심으로 분할한 계층 구조 체계
= 이 방식으로 세분화된것은 각 세분화마다 인도물이 나와야된다.
- 트리구조 : 단계가 내려갈수록 작업들이 상세히 정의.
- 작업 패키지 : 최하위단에 있는 작업. 작업의 원가와 일정을 신뢰할 수 있는 정도로 산정 가능한 최소단위. # 주로 한 개발자가 개발하는데 2~3주 단위.
# WBS 예제
: 각 작업패키지마다 산출물이 나와야된다.(한 작업 패키지에 여러 산출물.
[프로젝트 산정]
: 프로젝트 수행에 필요한 규모(Size), 공수(Effort), 비용(Cost)등을 정량적으로 예측하는것.
<산정방법>
- 경험적 방법 : 노력과 시간에 대한 수식을 경험적으로 유도해 예측 #델파이 기법
- 크기 중심 방법 : 코드의 라인수로 측정 #LOC, COCOMO
- 기능 중심 방법 : 사용자 중심의 기능 크기로 결정 # 기능점수
[델파이(Delphi) 기법]
: 경험적 산정. 전문가들의 의견, 판단 종합해 예측하는 기법.
# 산정 프로세스
- 과거 경험 기반
- 서로 의견 교환해 수정
=> 충분한 경험, 스킬이 없으면 정확성이 떨어진다.
[LOC(Line of code)]
: 크기 중심 산정. 프로그램 코드 라인 수를 통해 산정.
# 산정 프로세스
1. 전체 프로그램 산정 쉽도록 모듈별로 분할 : 산정 하기 쉬운단위로 모듈로 분할
2. 모듈별로 규모 추정 및 총 규모 계산
<계산방법>
- A : 낙관적. 과거 경험 기반 보다 짧은 코드 수에 원하는 기능이 모두 구현된 것.
- B : 보통. 과거와 비슷한 경우
- C : 비관적. 과거 경험 기반 보다 많은 코드 수에 원하는 기능이 모두 구현된 것.
| LOC(EV) = ( A + 4B + C ) / 6 |
3. 경험적 데이터(생산성, LOC당 비용)를 이용해 개발 노력 및 개발 비용을 추정
# 계산방법
- 생산성(단위 : LOC / Man-Month) => 노력 추정 # Man-Month : 한 사람이 한달간 생산할 수 있는 라인 수
- LOC당 비용(단위 : a원 / LOC) => 비용 추정
- 노력 = LOC / 생산성
- 비용 = LOC / LOC당 비용
|
ex) 웹 기반 쇼핑몰 솔류션 개발 예제의 LOC 산정. <문제> - 4가지 모듈로 구성. - LOC 기법 사용. - 생산성은 620 LOC/Man-Month. - LOC당 비용은 3000원. |
|
쇼핑몰 개발 피로젝트의 개발 비용 및 노력을 추정해라. <풀이> 1) 모듈 분할 => 4개 2) 모듈별 규모 추정 => EV 계산 : 433, 487, 642, 320 3) 총 규모 계산 => EV의 합 : 1882 4) 비용 추정 => 프로젝트 비용 = LOC * LOC당 비용 = 1882 * 3000 =5646000원 => 개발 노력 = LOC / 생산성 = 1882 / 620 = 3.0M/M(Man-Month) |
[COCOMO(Constructive Cost Model)]
: LOC 기반 경험적 방법. LOC 기반으로 개발 노력, 기간을 산정.
<공식>
E = a * (KLOC)^b # 개발노력 = a * 라인수(kilo단위)^b (단위:LOC/M-Month) +)1KLOC = 1000LOC
D = c * (E)^d # 개발기간 = c * 개발노력^d (단위:Month)
# 기본 cocomo의 프로젝트 유형별 산정값> : 기본 값. 공식에 사용되는 a,b,c,d 상수
- 기본형 : 작고 간단한 프로젝트. => 소수. 적은경험. 까다롭지 않은 요구사항
- 중간형 : 중간 정도의 크기와 복잡도의 프로젝트. => 중간. 다양경험. 약간 까다로운 요구사항
- 내장형 : 제한된 H/W, S/W, 운영조건을 가지고 개발해야하는 경우.
|
ex) 쇼핑몰 솔루션 COCOMO로 산정 <문제> - 쇼핑몰 프로젝트를 중간형으로 가정. 예상 규모 : 2,103 LOC <풀이> 1) 개발노력 : E = a * (KLOC)^b = 3.0 * (2.1)^2.5 = 약 6.9M/M 2) 개발기간 : D = c * (E)^d = 2.5 * (6.9)^0.35 = 약 4.9M(Month) - 팀원이 2명이면 3.5개월 정도의 개발노력이 필요하다. |
- LOC나 COCOMO와 같은 코드 라인 수 기반 방식은 개발 초기에는 소스 코드 라인수 예측이 어렵고, 개발 언어와 저,고평가에 따라 값이 다르게 된다.
[기능점수(FP)]
: 사용자의 관점에서 식별되는 기능을 기반으로 전체 시스템의 크기를 측정하는 산정 방식.
- 시스템을 구현한 기술에 독립적이고 사용자에 의해 식별되는 기능에 기반하여 전체 시스템의 크기를 측정하는 산정 방식.
- 일관성 있는 측정치를 구할 수 있다. (사용자 요구기능 기반 산정. 개발에 쓰인거 상관 X)
- 프로젝트 초기에 규모 산정 가능
# FP 측정 프로세스
- 기능점수를 산출하는 프로세스는 일반적으로 IFPUG에서 제공하는 7단계의 프로세스를 따른다.
1. 측정 유형의 결정
: 측정하고자 하는 프로젝트의 시점에 따라 유형 결정
<측정 유형>
1) DFP(개발 프로젝트 기능점수) : 최초 기능의 크기 산정 ( 신규시작 ~ 유지보수 시작 전 )
2) EFP(개선 프로젝트 기능점수) : 기존 시스템의 변경 부분 측정 ( 추가, 수정, 삭제한 기능 부분 크기 축정 )
3) AFP(어플리케이션 기능점수) : 시스템이 제공하는 현재 기능의 크기 측정 ( 개발완료, 개선완료 시점 제공기능 크기 측정 )
# 프로젝트 측정 유형
2. 측정 범위와 어플리케이션 경계 식별
- 측정 범위 : 기능점수를 측정하는 대상이 되는 범위(전체)
- 어플리케이션 경계 : 측정 대상 어플리케이션과 다른 어플리케이션 및 사용자 사이의 경계.
3. 데이터 기능 측정
: 사용자의 내, 외부 데이터 요구사항을 충족시키기 위해 제공되는 기능을 측정하는 것.
=> 사용자가 식별가능한 내부논리파일과 외부연계파일의 크기를 측정한다.
# ILF와 ELF 예시
- 사용자가 요구한 기능을 수행하기 위해 읽히거나 참조되는 데이터 그룹의 모음
1) 내부논리파일(ILF : Internal Logical Files)
: 측정대상 어플리케이션 내부에서 유지. #영화정보
2) 외부논리파일(EIF : External Interface Files)
: 측정대상 어플리케이션 외부에서 유지 #은행정보(외부 어플리케이션)
* 식별된 ILF와 EIF는 이들을 구성하고 있는 RET와 DET의 개수에 따라 기능점수 크기가 결정된다.
- 레코드요소유형(RET : Record Element Type)
: ILF나 EIF내에 존재하며, 하나의 정보를 구성하는 데이터베이스의 테이블과 같은 관련데이터의 그룹
- 데이터요소유형(DET : Data Element Type)
: RET에 존재하며, RET를 구성하는 개별 데이터 = 속성
# RET, DET 예시
: 각 파일의 RET, DET 개수를 파악한후, 아래에 도입
=>
# 데이터기능의 복잡도 Metric(결과)
# 기여도 Metric(결과)
# 영화예매시스템 복잡도와 기여도 결과 예시
4. 트랜잭션 기능 측정
: 어플리케이션이 데이터를 처리하여 사용자에게 제공하는 기능의 크기를 측정.
<측정 요소>
1) 외부입력(EI)
: 어플리케이션 경계 외부 사용자 또는 다른 어플리케이션으로부터 들어오는 데이터나 제어 정보를 이용하여 사용자의 요구를 처리하는 기능
2) 외부출력(EO)
: 데이터나 제어 정보를 어플리케이션 경계 외부의 사용자 또는 다른 어플리케이션으로 내보내어 사용자의 요구를 처리하는 기능.
3) 외부조회(EQ : External InQuiry)
: EO와 같이 내보내지만, 사용자가 요청한 기능을 수행하기위해, 계산, 처리과정 거치지 않는 기능.
# 영화 예매시스템의 EI, EO, EQ
- 정보 입력 : EI
- 정보 출력 : EO
- 정보 조회 : EQ
<EI, EO, EQ의 측정>
1) FTR, DET 측정
- 참조파일유형(FTR : File type Referenced) : 사용자가 요청한 기능을 처리하는데 필요한 ILF나 EIF들. = 테이블들이 속한곳.
- DET : 속성
# 영화 예매 시스템의 FTR과 DET
- FTR : 1개 (영화정보)
- DET : 6개 (영화제목, 극장명, 상영일자, 장영시간, 처리결과메세지, 예매버튼)
( FTR(요소개수) - RET(테이블개수) - DET(속성개수) : 연관지어기억하기! )
2) 미리 정의된 복잡도와 기여도 Metric에 적용하여 값을 산정
# 영화예매기능의 복잡도와 기여도
- 복잡도
: FTR 1개, DET 6개 => Low
=> EI 복잡도 3, EO 복잡도 4, EQ 복잡도 3.
5. 미조정 기능점수(UFP : Unadjusted Function Point) 결정
: 지금까지 측정한 데이터 기능과 트랜잭션 기능의 크기의 합.
- UFP = 데이터 기능 + 트랜잭션 기능 = (ILF + EIF) + (EI + EO + EQ)
- 이것들은 전부 기능적 관점.
6. 조정 인자(VAF : Value Adjustment Factor) 결정.
: 기능 외에 다른 요인들에 의해 영향 받음.
- VAF = (일반 시스템 특성의 총 영향도 합(TDI) * 0.01) + 0.65
7. 조정기능점수(AFP : Adjusted Function Point) 결정.
: 미조정 기능점수에 조정 인자를 반영한 기능 점수 값
- AFP = UFP * VAF
[일정 계획]
: 프로젝트 일정 계획은 WBS를 통해 파악된 단위 작업들을 산정된 기간이나 비용에 맞추어 계획하는 활동.
: 일정 한눈에 확인, 역할 할당 , 병행 작업 구성 편리하게 표현가능.
<종류> 퍼트차트, 간트차트
[퍼트차트(PERT Chart)]
: 프로젝트를 구성하는 작업들 사이의 관계 및 흐름을 그래픽으로 표현.
<표기법>
- 박스(, 원) : 작업, 업무
- 선, 화사표 : 각 작업간의 순서와 의존성 표현.
<특징>
- 작업의 병행 수행 가능
- 모든 작업들 간의 상호 의존성, 진행 경로 파악이 가능
# 퍼트차트 구성
- ES(Earliest Start Time) : 해당 단위 직업을 가장 빨리 시작할 수 있는 일자
- EF(Earliest Finish Time) : 해당 단위 작업을 가장 빨리 종료할 수 있는 일자
- DU(Duration) : ES~EF , LS~LF 작업기간
- LS(Latest Finish) : 해당 단위 작업을 가장 늦게 시작할 수 있는 일자
- LF(Latest Finish) : 해당 단위 작업이 가장 늦게 종료할 수 있는 일자
- FT(Float Time) : LS~ES 여유기간
# 결혼식 준비 퍼트 차트
: 병행수행 가능(서로 의존되는 작업 아닐시)
- 주요 경로(Critical path) : A경로. 경로안의 하나의 작업이라도 지연 되면 프로젝트 전체가 지연되는것.
[간트차트(Gantt Chart)]
: 프로젝트의 일정, 예산 및 자원 계획 등을 목적으로 사용될 수 있는 프로젝트 제어 기법
<특징>
- 프로젝트 시작 시간과 종료 시간을 막대 형태로 표현
- (장점) 작업 시작일과 종료일을 분명히 알 수 있다.
- (단점) 퍼트 차트와 달리 작업간의 의존성을 보여주지는 않는다.
# 결혼식 준비 간트 차트
[프로젝트 통제]
- 프로그램 목표 달성 위해 계획과 통제는 항상 함꼐 다뤄진다. (게획-실행-통제 반복)
- 프로젝트 통제를 위한 관리방법은 매우 중요 : 프로젝트 미완료 위험성 존재
[EVM(Earned Value management)]
: 프로젝트가 계획대로 진행되고 있는지 점검하는 방법
: 프로젝트의 일정 상태, 비용 상태 그리고 완료된 작업량을 비용화하여 계획 대비 실적을 비교 및 평가함으로써 프로젝트의 성과와 진행률을 정량적으로 관리.
<용어>
- BCWS (Budgeted Cost of Work Scheduled) = PV (Planned Value) : 계획된 작업량의 계획된 비용
- BCWP (Budgeted Cost of Work Performed) = EV (Earned Value) : 수행한 작업의 계획된 비용
- ACWP (Actual Cost of Work Performed) = AC (Actual Cost) : 수행한 작업의 실제 비용
- BAC (Budget at Completion) : BCWS의 합, 전체 작업에 대한 계획된 비용
- EAC (Estimate at Completion) : ACWP + 남은작업량의 예측 비용 = 전체 작업 완료되는데 예측되는 실제 비용.
[SV(Schedule Variance)]
= BCWP - BCWS : 계획된 작업량과 실제 수행된 작업량의 차이(단위 : 원)
-> 플러스 값 : 일정이 계획보다 빠름 / 마이너스 값 : 일정이 계획보다 느림
[CV(Cost Variance)]
= BCWP - ACWP : 계획된 비용과 실제 비용의 차이
-> 플러스 값 : 비용남음 / 마이너스 값 : 비용초과
# SV와 CV 그래프 표현
: 스케쥴 뒤쳐지는 중(SV)
: 비용초과(CV)
[VAC(Variance at Completion)]
= BAC - EAC : 전체 작업의 계획된 비용에서 남은 작업 계획된 비용과 현재까지 진행된 실제 비용을 뺀 값.
-> 플러스 값 : 비용이 남음 / 마이너스 값 : 비용이 초과
[성과 지표(Performance Indices)]
: SV,CV,VAC 말고 비율로 도출하는법
- SPI = BCWP / BCWS : 1보다 작으면 일정 지연
- CPI = BCWP / ACWP : 1보다 작으면 비용 초과
- CSI = SPI * CPI : 1에서 멀어줄수록 프로젝트 성공에서 멀어짐
[Summary]
|
1. 프로젝트 계획 수립을 시작할 때 제일 먼저 해야하는 작업을 기술하라. : 프로젝트 규모 파악
2. 프로젝트의 개발 비용 산정 시 결정에 영향을 주는 요소 3가지 : 규모, 공수(Effort), 비용
3. 소프트웨어 개발 비용은 시스템 크기, 개발 기간, 신뢰도, 투입 인력들과 일정한 상관관계가 있다. 개발비용을 Y축으로 하는 반비례 그래프를 그려 본다면, X축으로 어떤 요소가 가장 타당한지 기술하라. : 개발 기간.
4. 두명의 개발자가 5개월에 걸쳐 10,000 라인의 코드를 개발하였을때, 월별 생산성 측정을 위한 계산은 어떻게 하는지, 식을 기술하라. : 생산성은 LOC/M-Month 로 측정. 정답 : 10,00/(5*2)
5. LOC 기법에 의하여 예측된 총 라인수가 25,000 라인일 경우 개발에 투입될 프로그래머의 수가 5명이고, 프로그래머의 평균 생산성이 월당 500라인일때 개발에 소요되는 시간을 계산하라. : LOC = 시간*프로그래머수*생산성. 시간 : 10달
6. 대표적인 소프트웨어 산정 모형 3가지를 기술하라. : 델파이 기법, COCOMO, 기능점수(Function-Point)
7. 기능점수 산정 방식의 7단계 프로세스를 기술하라. : 측정 유형의 결정 -> 측정 범위와 어플리케이션 경계 식별 -> 데이터 기능 측정 -> 트랜잭션 기능 측정 -> 미조정 기능점수 결정 --> 조정인자 결정 -> 조정 기능점수 결정
8. 일정 계획에 사용되는 대표적인 차트는 무엇이고, 이들에 대해서 기술하라. : 퍼트차트 : 프로젝트 구성 여러 작업 관계, 흐름을 그래픽으로 표현 : 간트차트 : 일정, 예산, 자원 계획등을 목적으로 사용될 수 있는 프로젝트 일정 계획 기법
9. 프로젝트 통제기법에 대표적인 EVM에 대해 기술해라 : 프로젝트 일정 상태, 비용상태 그리고 완료된 작업량을 비용화하여 계획 대비 실적을 비교 및 평가함으로써 프로젝트의 성과와 진행률을 정량적으로 관리하는것. 현재 시점까지 완료된 작업량에 대해 계획 대비 이렁이 지연되고 있는지 또는 비용이 더 지출되고 있는지를 파악 가능하다.
10. EVM의 측정 지표와 성과 지표에는 무엇이 있는가? - 측정지표 : BCWS, BCWP, ACWP, SV, CV, VAC - 성과지표 : SPI, CPI |
'기타 > [소프트웨어 공학]' 카테고리의 다른 글
| 6.5장. 소프트웨어 공학 중간정리 (0) | 2019.04.22 |
|---|---|
| 6장. 리스크 관리 (0) | 2019.04.17 |
| 4장. 요구사항 개발 및 관리 (0) | 2019.04.03 |
| 3장. 프로젝트 관리 (1) | 2019.03.21 |
| 2장. 소프트웨어 프로세스와 생명주기 (0) | 2019.03.13 |