Software Project 개발 계획.

Presentation on theme: "Software Project 개발 계획."— Presentation transcript:

1 Software Project 개발 계획

2 Software Project 관리(1) 정의 Project 관리의 필요성
사용자의 요구에 부합하는 소프트웨어를 계획된 일정에 맞게 개발하기 위하여 필요한 제반 활동 Project를 준비하고, 계획을 수립하여 일정을 관리하는 활동 Project 관리의 필요성 Software Project는 주어진 예산의 범위 안에서 수행 사용자와 약속한 개발일정을 준수해야 함

3 Software Project 관리(2) Software Project 관리의 특성
S/W product is intangible S/W product is uniquely flexible, not fixed 소프트웨어공학은 다른 공학과 달리 아직 정착된 학문 분야로 인식되지 못하고 있는 것이 현실 S/W 개발 절차가 표준화되어 있지 않음 대부분의 Software Project는 ‘일회성’이므로, 동일한 Project가 반복되는 경우가 거의 없음

4 Software Project 관리(3) Project 관리에 필요한 활동 제안서 작성 Project 계획 및 일정 수립
구성원 채용 및 평가 숙련된 IT 인력이 현저히 부족 우수 인력을 확보하기에는 턱없이 부족한 개발비 책정 특정 Project 수행에 필요한 기술인력만을 양성하고자 함 보고서 작성 및 Presentation

5 Project Planning(1) Project Planning? Project 관리에서 가장 많은 시간을 필요로 하는 활동
개발 예산 및 일정을 포함하는 소프트웨어 개발계획을 보조하기 위해서 다양한 종류의 부수적인 계획을 수립할 필요가 있음

6 Project Planning(2) Project Plan의 종류
Quality Plan: Project에서 사용할 품질 절차 및 표준을 기술 Validation Plan: 시스템의 검증을 위한 접근 방법, 소요 자원, 일정에 대하여 기술 Configuration Plan: 형상관리 절차와 사용할 구조에 대하여 기술 Maintenance Plan: 유지보수에 대한 요구, 소요 비용, 및 노력을 예측 Staff Development Plan: 팀 구성원의 능력 향상을 위한 계획을 기술

7 소프트웨어 개발계획(1) 개발계획의 필요성 계획 단계에서 수행하는 작업 소프트웨어 개발상의 많은 문제가 계획의 부재에서 기인
좋은 소프트웨어의 생산을 위해서는 세심한 계획이 필요 프로젝트 초기에 계획을 수립하는 것은 매우 어려운 작업 개발계획의 수립을 통하여 목표, 요구사항, 제약조건 등을 명확히 할 수 있음 계획 단계에서 수행하는 작업 문제의 이해 및 정의 필요한 소작업(Activity)을 정의하고 순서를 결정 일정계획 수립 비용 산정 및 팀 조직 개발계획서 작성

8 소프트웨어 개발계획(2) 소작업(Activity)?
Activities in a project should be organized to produce tangible outputs for management to judge progress Milestones are the end-point of a process activity Deliverables are project results delivered to customers The waterfall process allows for the straightforward definition of progress milestones

9 소프트웨어 개발계획(3)  Milestones in the RE process

10 소프트웨어 개발계획(4) 개발계획의 수립 및 조정 절차 4.1 일정계획을 수립 1. 프로젝트에 대한 제약사항을 파악
2. 프로젝트 영향 요인에 대한 최초 평가 3. 단계별 Milestones 및 산출물을 정의 4. 프로젝트를 완료(또는 중도 취소)될 때까지 다음 작업을 반복 4.1 일정계획을 수립 4.2 일정에 따라 프로젝트 수행 4.3 프로젝트의 진척도를 검토 4.4 프로젝트 영향 요인의 지표를 수정 4.5 일정계획을 조정 4.6 프로젝트의 제약조건 및 산출물에 대하여 Re-negotiate 4.7 문제가 발생하면 기술적인 재검토 실시

11 문제의 정의 문제의 정의에 포함해야 할 사항 문제를 정의할 때 주의할 사항 현재 업무의 정확한 상황 현 상황에서의 문제점
문제 해결을 위한 대책 ==> 구현 시스템의 기능 문제해결에 전제되는 제약 조건 ==> 적절한 개발모형, 프로젝트 수행에 필요한 자원 문제를 정의할 때 주의할 사항 문제는 사용자의 입장에서 기술 문제의 배경 및 응용 분야에 대한 깊은 이해가 중요 사용자와 면담 현장을 관찰 실제 업무를 수행해 봄

12 일정계획(1) 일정계획의 개념 일정계획 수립시 어려움
프로젝트를 구성하는 작업(task)을 파악하고, 작업을 수행하는데 필요한 시간 및 자원 예측하여 계획 (참고자료 #1 참조) 작업들의 병행처리가 가능하도록 계획하여 구성원의 능력을 최대한 활용 작업들의 상호 독립성을 높여 개발지연을 극소화 Project Manager의 직관과 경험에 의존적 일정계획 수립시 어려움 소요자원 및 기간의 산정이 매우 어려움 생산성은 투입 인력의 수에 비례하지 아니함 프로젝트 후반에 신규 인력을 투입하면 진도가 더욱 늦어짐 <== 의사소통 문제 예상하지 못한 상황은 항상 발생하게 마련 ==> 계획의 조정이 항상 가능

13 참고자료 #1 The project scheduling process

14 일정계획(2) Bar charts & Activity networks 프로젝트의 일정계획을 표현하는 그래픽 도구
CPM 소작업 목록표 프로젝트를 작업(task)으로 분해한 결과를 표현 너무 작은 단위로 분해하는 것은 바람직하지 못함 1~2주 정도에 수행 가능한 크기가 적당 참고자료 #2 참조 Activity chart 작업간의 종속 관계와 임계경로를 표현 참고자료 #3 참조 Bar chart 프로젝트의 수행일정을 표현 참고자료 #4 참조

15 참고자료 #2 CPM Task List

16 참고자료 #3 Activity network

17 참고자료 #4 Activity timeline

18 참고자료 #5 Staff allocation

19 Cost Estimation(1) 비용 산정의 기본 개념 소프트웨어 개발비용의 산정은 매우 어려운 작업 비용 예측
주요 변수: 투입되는 기술인력의 수, 투입 기간 과거의 프로젝트 수행 경험이 매우 중요 측정단위(ManMonth) = 소요인력 x 투입기간(월) 소요비용 = 인건비 + 간접비 인건비 예측방법 소요기간을 기준으로 산정 (작업별 소요기간 x 작업별 투입인원 x 참여도 x 단가)의 합 프로그램의 규모를 기준으로 산정 COCOMO 방법 Function Points 방법

20 Cost Estimation(2) COCOMO 방법 B. Boehm이 1981년에 제안 COCOMO
프로그램 개발에 소요되는 Programmer MM를 추출 PMinitial = c * (KDSI)k Organic:2.4/1.05, SemiDetached:3.0/1.12, Embedded:3.6/1.20 노력승수값(Effort Adjustment Factor)에 따라 보정 PM = PMinitial * EAF (교재 66쪽의 표2.4 참조) 총 인건비 = PM * 평균 인건비 총 개발기간(Total DEvelopment Time)의 계산 TDEV= 2.5 * (PM)k Organic:0.38, Semi-detached:0.35, Embedded:0.32 투입할 평균인원의 적정값 = PM / TDEV 문제점 많은 가정과 제약조건 존재 산정비용은 KLOC의 정확한 예측에 지나치게 종속적

21 Cost Estimation(3) COCOMO Ⅱ 방법 B. Boehm이 1995년에 제안
프로젝트가 진행되는 단계별로 3가지 모델 제시 1단계: 프로토타입을 만드는 단계, 응용점수에 기반 2단계: 초기설계 단계, 기능점수에 기반 3단계: 구조설계 이후 단계, KLOC에 기반 기본 모델: E = b * Sc * m(X) S: Scale factor c: 기본값=1, 선행작업/적응도/…에 따라 조정 m(X): EAF에 대응하는 비용 승수 교재 69쪽의 표2.5 참조

22 Cost Estimation(4) Function Points 방법 기본 개념 비용산출 절차 IBM의 Albrecht가 제안
기능점수는 소프트웨어 시스템이 가지는 기능을 정량화 Business 응용분야의 소프트웨어 개발비용 산정에 적합 5가지 항목에 대하여 기능점수 부여: 교재 71쪽 표2.6 기능점수는 구현 언어와 무관한 metric 모든 항목에 일률적인 점수를 적용하는 문제점은 보완 필요 비용산출 절차 기능항목별로 복잡도를 고려하여 Unadjusted FP 계산 시스템의 특성을 고려하여 Total Degree of Influence 계산 FP = UFP * ( * TDI) MM = FP / 프로젝트 수행 실적에 의한 평균 FP/MM

23 조직계획 개발팀 구성방법 선택에 영향을 주는 요소 개발팀 구성 방법 프로젝트 수행기간
작업의 특성 및 팀 구성원 사이의 의사 교류의 횟수 개발 대상 소프트웨어의 특성 개발팀 구성 방법 중앙집중식 팀 chief programmer, librarian, programmer, … 교재 79쪽의 그림2.5 분산형 팀 계층구조가 없이 팀 구성원 모두가 동등한 위상 유지 교재 80쪽의 그림2.6 혼합형 팀 중앙집중식과 분산형을 혼합한 형태 교재 81쪽의 그림2.7

24 위험 관리(1) 기본 개념 위험관리: 위험을 인식하여 프로젝트 수행에 미치는 영향을 최소화시키기 위한 제반 활동
위험(risk): 프로젝트의 수행에 적대적인 상황이 발생할 가능성 (참고자료 #6 참조) Project risks affect schedule or resources Product risks affect the quality or performance of the software being developed Business risks affect the organisation developing or procuring the software

25 참고자료 #6: 위험의 종류

26 위험 관리(2) 위험관리 절차 위험 식별(Risk identification): 발생 가능한 위험을 식별
위험 분석(Risk analysis): 위험 발생 가능성과 위험으로 인한 결과를 평가 위험 계획(Risk planning): 위험으로 인한 영향을 피하거나 최소화시킬 수 있는 대책을 수립 위험 감시(Risk monitoring): 프로젝트를 진행하는 과정에서 실제로 위험이 발생하는지를 감시 * 참고자료 #7 참조

27 참고자료 #7: Risk Management Process

28 위험 식별 위험의 유형 위험 유형별 발생 가능한 위험 Technology risks People risks
Organizational risks Requirements risks Estimation risks 위험 유형별 발생 가능한 위험 참고자료 #8 참조

29 참고자료 #8: Risks and risk types

30 위험 분석 기본 개념 위험별 발생가능성 및 그 영향
Assess probability and seriousness of each risk Probability may be very low, low, moderate, high or very high Risk effects might be catastrophic, serious, tolerable or insignificant 위험별 발생가능성 및 그 영향 참고자료 #9 참조

31 참고자료 #9: Risk analysis

32 위험 계획 기본개념 Consider each risk and develop a strategy to manage that risk Avoidance strategies: 위험이 발생할 가능성을 감소 Minimization strategies: 프로젝트 또는 제품에 대한 위험의 영향을 감소 Contingency plans: 위험이 발생할 경우에 사용할 대책을 수립 위험별 관리 방법 참고자료 #10 참조

33 참고자료 #10: 위험관리 정책

34 위험 감시 기본 개념 Assess each identified risks regularly to decide whether or not it is becoming less or more probable Also assess whether the effects of the risk have changed Each key risk should be discussed at management progress meetings 위험 유형별 발생 징후 참고자료 #11 참조

35 참고자료 #11: 위험 유형별 발생징후

36 개발계획서 작성(1) 개발계획서 작성시 유의 사항 프로젝트의 성격이나 사용자의 요구에 따라 다양한 형식으로 작성 가능
포함해야 할 사항 개요 소요 자원 개발 일정 개발팀 구성 방법 WBS (Work Breakdown Structure) 기술관리 방법 교재 85쪽의 표2.15 참조

37 개발계획서 작성(2) 개발계획서의 다른 양식 Introduction Project organization
Risk analysis Hardware and software resource requirements Work breakdown Project schedule Monitoring and reporting mechanisms