Software Project Management Project Planning 1 Project Planning

Software Project Management 소프트웨어 프로젝트 관리 Project Planning 프로젝트 계획 1

Project Planning n Overview n Defining the Work n Risk Engineering n Documenting the Plan 프로젝트 계획 개요 업무의 정의 리스크 엔지니어링 계획의 문서화 2

Overview 개요 Planning is like insurance. It’s too expensive until you need it, and then it’s too late. 계획이란 보험과 같은 것이다. 보험이 필요할 때 까지는 비용부담이 크지만 필요할 때에는 이미 늦다. 3

Triple Constraint 3대 제약 조건 Cost Constraints 비용 제약 Scope Constraints 범위 제약 Schedule Constraints 일정 제약 4

Why Plan? 왜 계획하는가 ? n n n To identify alternatives while they are still feasible. 대안들이 실행 가능 할 때 식별함 To identify critical risks when they can still be managed. 중요한 위험이 관리 가능할 때 식별함 To provide a baseline for performance measurement. 성 과측정을 위한 기준선을 제공함 5

The Wrong Way 잘못된 방법 1. Find out what the budget is. 2. Add 50% to provide negotiating room. 3. Let management cut it by 30% 4. Use 90% of the budget to do 50% of the work, 5. Justify the overrun as a scope change. 6. Repeat as necessary. 1. 2. 3. 4. 5. 6. 예산 규모를 알아냄 협상 여유를 위해 예산의 50%를 추가 관리진이 예산을 30% 줄이도록 내 버려 둠 작업의 50%를 실행하기위해 예산의 90%를 사용 함 사업 범위 변경을 예산초과 근거로 제시함 필요에 따라 반복함 6

Project Planning n Overview n Defining the Work n Risk Engineering n Documenting the Plan 7

Defining the Work 업무의 정의 n Scope Planning 계획 범위를 정함 n Work Breakdown Structure 업무 분장 n Estimate Cost/Manpower 비용/인력 추정 n Schedule the Work 업무 일정 8

Scope 프로젝트 범위 Product Scope 산출물 범위 w What you will do. 무엇을 할 것인가 w Measured against the requirements. 요구사항에 대 해 산출물 범위를 측정 Project Scope 프로젝트 범위 w How you will do it. 어떻게 할 것인가 w Measured against the plan. 프로젝트 계획에 대해 프로젝트범위를 측정 9

Scope Statement 프로젝트 범위 기술서 n n The Scope Statement is an internal document that describes the project in one page. 프로젝트 범위 기술서는 내부 서류로서 본 프로젝트를 한 페이지 내로 설명해 줌 It is used to bound the project. 프로젝트 경계를 규정하기 위해 사용 됨 It is for both the Software Team and Management. 소프트웨어 팀 및 관리 팀 모두 에게 필요함 Contents 내용 w Brief description of project. w Project justification (i. e. , the business reason for doing the project). w List of project deliverables. w List of project objectives (e. g. , cost, schedule). w w 프로젝트에 관한 간략한 설명 프로젝트의 정당성 (즉, 본 프로젝트를 착수하는 영업적 이유) 인도가능 프로젝트 항목 목록 프로젝트 대상 목록 (예: 비용, 일정) 10

Project Justification 프로젝트의 정당성 An explanation of why the project has been undertaken in enough detail to guide triple constraint tradeoffs. 3대 제약조건 트레이드오프에 대한 방향제시를 위해 본 프로젝트가 착수되어 된 이유에 대한 상세한 설명 11

Project Deliverables 인도 가능 프로젝트 항목 A full list of the summary level items whose full and satisfactory delivery marks the completion of the project (e. g. , things that are tangible). 완벽하고 만족스럽게 인도 되는 항목에 대한 요약 목록을 완전하게 작성 함으로서 본 프로젝트가 완성된다. (예: 대상은 형체가 있음 ). 12

Project Objectives 프로젝트 목표 Additional quantified success criteria. Things that are measured the day the project is complete (e. g. , profits, number produced). 수치화 된 추가 성공 기준. 프로젝트 대상물은 프로젝트 가 완성되는 날 측정된다. (예: 이익금, 산출 수치). 13

Additional Thoughts 추가 의견 n n n Balance brevity with clarity. 간결성과 명료성의 균형 Same scope statement for all audiences. 모든 경청자에 대해 동일한 프로젝트 범위 기술서 적용 Add explicit exclusions to avoid confusion (e. g. , We will do this. We will not do that. ). 명백한 배제내용을 부기 (예: 우리는 이것을 할 것이다. 우리는 그 것을 하지 않을 것이다. ) 하여 혼선을 피함 n Project scope may change over time. 프로젝트 범위는 시간이 지남에 따라 변경될 수 있음. n Turn risks into deliverables. n 위험을 인도가능항목으로 전환 n 14

Workshop 워크샵 1. Pick a project you are familiar with and draft a scope statement for it. 해당 지식이 있는 프로젝트를 택하여 그에 대한 범위 기술서를 기안함. 2. Circulate scope statement within your group for comments and constructive criticism. 귀하의 그룹에 범위 기술서를 회람하여 의견 및 건전한 비평을 구함. 3. The group should select one scope statement to share with the rest of the class. 회람한 그룹은 범위기술서 하나를 선택하여 나머지 참석자들과 공유함. 15

Defining the Work n Scope Planning n Work Breakdown Structure n Estimate Cost/Manpower n Schedule the Work 16

Work Breakdown Structure 업무 분장 How can you maximize the probability that you’ve identified all the work? ‘제반 업무를 식별했다’ 는 확률을 어떻게 극대화 시킬 수 있는가 ? 17

Work Breakdown Structure 업무 분장 The Work Breakdown Structure (WBS) is a deliverableoriented grouping of the project components (products and services) which organizes and defines the total project scope. WBS는 프로젝트 구성 요소 (제품 및 용역)를 인도가능항 목 중심으로 배치한 것이며 이는 전체 프로젝트 범위를 구성하고 정의한다. 18

Work Breakdown Structure 업무 분장 n n n n Management tool for subdividing the work into logical components. 업무를 논리적 구성요소로 세분하기 위한 관리도구 Hierarchical structure that shows relationships of elements to each other and to the overall contract. 구성요소 간의 관계 및 구성요소와 전체 계약간의 관계를 보여 주 는 계층구조 Organizes work into short manageable tasks. 업무를 간단한 처리가능 테스크로 조직 Basis for cost and progress planning and reporting. 비용/진척도 계획 및 보고에 대한 기준 19

Example 예 Project Management Deliverable Activity Deliverable Activity . . . Deliverable . . . 20

Creating a WBS 작성 1. Use “post-its” and a large work area. 포스팃트 와 넓은 작업장소를 이용 2. Write the project name on a post-it as Level 0 (i. e. , the top). 한 포스팃트에 프로젝트 명을 Level 10으로 기입 (즉, 상단) 3. Write each major deliverable on a post-it and arrange them below Level 0. This is Level 1. 각 주요 인도가능 항목을 다른 한 포스팃트에 기입하고 그 항목들을 Level 0 아래에 배열. 이것은 Level 1 임. 4. Write “Software Management” on a post-it and add it to Level 1. 한 포스팃트에 “소프트웨어 관리”라고 기입하고 그것을 Level 1에 더함. 5. Decompose the deliverables. 인도가능 항목을 분할함. 21

Decomposing Deliverables 인도가능 항목 분할 1. Ignore staffing and sequencing. 작업 조직과 작업순서는 무시 2. Identify logical elements of each deliverable: w interim products (i. e. , draft, final) w services (e. g. , meetings, reviews) 각 인도가능 항목에 대한 논리적 요소를 식별 w 중간 산출물 (즉, 초안, 최종 판) w 서비스 (예: 협의, 검토) 3. Write each element on a post-it and arrange them below the parent. 각 요소를 포스딧트에 기입하고 그것을 모 요소 아래에 배열 4. Continue until you have enough detail to estimate. 추정을 위한 충분한 내용이 입수될 때까지 계속 함 22

Detail to Estimate 추정 상세 Detail to estimate is defined as directly comparable experience. That is, something you have done before or understand well enough to estimate. 추정 상세는 직접 비교 가능한 경험으로 정의됨. 즉, 그것은 이전에 추정 한 적이 있거나 추정 할 수 있을 만큼 충분히 이해하고 있는 부분임. Isolate the uncertainty by decomposing the work. Then get the expertise t 6 help you estimate the work. The expertise may come in the form of subcontractors, consultants, others in the organization. 업무를 분할 함으로서 불확실성과 분리시킴. 그런 다음 전문지식을 얻으면 작업 추정에 도움이 될 것이다. 이러한 전문지식은 하도급 업체, 고문, 본 조직의 여타 형태로 나타날 수 있다. 23

Example - Top Level 예- 상위 급 System 1 Project Management 2 3 System Requirements Hardware 4 5 Software . . . 24

Software 4. 1 CSCI 1 Development 4. 2 CSCI 2 Development 4. n CSCI n Development 4. 4 Software Management 25

CSCI n Development 4. n. 1 Requirements Document 4. n. 2 Preliminary Design Doc 4. n. 3 Detailed Design Doc 4. n. 4 Code 4. n. 5 Unit Test Results 4. n. 6 Integration Test Results 26

Software Management 소프트웨어 관리 4. 4 Software Management 4. 4. 1 4. 4. 2 SCM SQA 4. 4. 3 Meetings 4. 4. 4 Planning 4. 4. 5 Tracking 4. 4. 6 Admin includes status reports, issue resolution, correspondence, and the day-to-day management of the software project. Admin 에는 소프트웨어 프로젝트 상황보고서, 쟁점해결, 통신 및 일일관리가 포함된다. 27

WBS Review Criteria WBS 검토 기준 n n n n Is there enough detail to estimate resource requirements with confidence? Are completion Criteria well-defined? Are deliverable and activity descriptions readily understandable by a non-team member? Do lower-level elements fully describe the upper-level? 자신 있게 자원 요구사항을 추정할 수 있도록 충분히 상세화 되어 있는가? 완료 기준이 잘 정의되어 있는가 ? 인도가능 항목 및 엑티비티 설명을 팀 이외의 단원들이 즉시 이해 할 수 있는가 ? 하위 요소가 상위요소를 완전히 설명해 주는가 ? 28

Other Things to Include 여타 포함할 항목 n n n n Change Management Demonstrations, equipment set-up Internal documentation and training Meetings Time to learn, time to train Turnover and closure 변경 관리 Demo, 장비 설치 n 내부 문서화 작업 및 교육 협의 습득시간, 교육시간 n 인계 및 종결 n n 29

Exercise 연습 Working in your teams, develop a draft WBS for the project whose scope statement was presented by your group (10 minutes). 귀하의 팀 내에서 작업하여 귀하의 그룹이 제시한 범위기술서에 해 당되는 프로젝트에 대해 WBS 초안을 개발함 (10분). Be ready to present your lessons learned. 습득한 내용을 표현할 수 있도록 준비되어 있을 것. 30

Cost Account 비용 계정 n n n n Lowest level unit of a WBS, a small indivisible unit of work which can be assigned to an individual or team. A unit of planning, budgeting and scheduling. A unit of responsibility. Can measure performance. Actual cost accumulation. Cost element for timecard charges. Contains work and planning packages. 최 하위 WBS 단위, 개별 또는 팀에 할당 가능한 소형 단일 작업단위 계획, 예산편성 및 일정 단위 책임 단위 성과측정 가능 실제비용 누적 타임카드 비용에 대한 비용요소 작업 및 계획 페키지를 포함 31

Work Package A specification of the work to be accomplished in completing a Cost Account. 비용계정을 완성함에 있어 완성되어야 할 작업 사양 Contents: 내용 w Objectives of the Task 테스크 목표 w Staffing and Resource Requirements 인력 및 자원 요구사항 w Budget 예산 w Schedule 스케쥴 w Products 제품 w Completion Criteria 완료 기준 w Earned Value Method 이익 가치 기준 방법 (EVM) 32

Planning Package 계획 패키지 n n n n n Used for Cost Accounts that cannot be fully defined. Define the work to the extent possible. Schedule the work in an approximate time period. Converted into work packages prior to the performance of the work. Has no completion Criteria or earned value method. 완전하게 정의될 수 없는 비용계정에 사용됨 가능한 한도내의 업무를 정의 함 추정 기간 내로 업무 일정을 정함 업무 실행 전에 업무 패키지로 전환 완성 기준 또는 EVM 이 없음 33

Work Authorization Document 업무 인증 서류 n n A WAD describes the work, schedule and budget assigned to a Cost Account. Reflects the contract between the Project Manager (PM) and the Cost Account Manager (CAM). Defines the product deliverables. Form the framework for detailed budgets and schedules. n n WAD에는 비용계정에 할당된 업무, 일정 예산을 설명되어 있음. PM 과 CAM 간의 계약을 반영함. 인도가능 산출물을 정의함. n 상세 예산 및 일정에 대한 틀을 형성 n n 34

WAD Example 35

Earned Value Methods The earned value method chosen for a specific work package is used to determine the amount of work performed when reporting cost/schedule performance for a reporting period. EVM은 특정 업무 페키지 용으로 선택되었으며, 보고기간동안 실행된 비용/일정에 대 해 보고할 때 실행된 업무량을 정하기 위해 이용되는 방법이다. Methods 방법 : Incremental Milestone Cumulative Equivalent Value Milestone Cumulative Unequal Value Milestone Cumulative Percent Complete 점진적인 이정표 누적 동등가치 이정표 0/100 50/50 누적 차등가치 이정표 완성된 누적% 노력 분배 노력 수준 0/100 50/50 Apportioned Effort Level of Effort 36

Incremental Milestone 점진적 이정표 n n n This method is for long-term efforts (i. e. , > 2 months). Earned Value is based on accomplishment of pre-determined milestones. The milestones are defined in the work package by dividing the work task into subordinate sequential tasks. There must be at least one milestone per month. The total WP budget is distributed over the each of the tasks. As a task is completed, the milestone value is reported as earned. 이 방법은 장기간 노력이 필요함 (즉, 두 달 이상) EV는 미리 정한 이정표 달성에 기초를 두고 있다. 본 이정표들은 업무패키지에서 업무 테스크를 하위 순서 테스크로 분할 함으로서 정의됨. 최소한 매월 이정표 하나가 있어야 함. WP 총 예산은 각 테스크에 걸쳐 분배됨. 한 테스크가 완성 됨으로서 이정표 가치는 획득된 것으로 보고됨. 37

0/100 n n n n n This method is for tasks with a duration of one reporting period. There are two milestones, start and stop. 100% of the budget is assigned to the stop milestone. No earned value is reported when the task is started. The entire earned value is reported when the task is completed. 한 보고기간에 해당되는 테스크에 이용되는 방법. 시작과 정지의 두 가지 이정표가 있음. 예산의 100%가 ‘정지 이정표’에 할당됨. 과업이 착수될 때 이익가치가 보고 되지 않음. 과업이 완성될 때 전체 이익 가치가 보고됨. 38

50/50 n n n This method is for tasks with a duration of not more than two reporting periods. There are two milestones, start and stop. 50% of the budget is assigned to the start milestone. 50% of the budget is assigned to the stop milestone. When the task is started, 50% of the earned value is reported. When the task is completed, the remaining 50% of the earned value is reported. 두 보고기간 이하 기간에 해당하는 테스크에 이용됨. 시작 및 정지의 두 이정표가 있음. 예산의 50%가 ‘시작 이정표’에 할당됨. 예산의 50%가 ‘정지 이정표’에 할당됨. 테스크가 착수되면 이익가치의 50%가 보고됨. 테스크가 완성되면 EV의 나머지 50%가 보고됨. 39

Cumulative Equivalent Value Milestone 누적 동등가치 이정표 n n n This method is used if the series of measurable units of work are essentially equivalent is value. The budget for each unit of work is derived by dividing the budget for the WP by the number of units. As each unit is completed, the earned value for that unit is reported. 이 방법은 일련의 측정가능 업무단위 가치가 본질적으로 대등할 경우 사용됨. 각 업무단위 예산은 WP 에산을 단위 숫자로 나누어 획득됨. 각 업무단위가 완성됨에 따라 그 단위의 이익가치가 보고됨. 40

Cumulative Unequal Value Milestone 누적 차등가치 이정표 n n Identical to the Cumulative Equivalent Value Milestone method except the value of each unit depends is relative to the other units based on a defining characteristic such as size or complexity. 각 단위가치가 경우에 따라 다르다는 것이 단위규모나 복잡성과 같은 내용을 한정 해주는 특징에 의거한 나 머지 단위들과 관계 있는것을 제외하고는 ‘누적 동등 가치 이정표’ 방법과 동일하다. 41

Apportioned Effort 노력 분배 n n Earned value is reported as a percentage of the earned value for a directly related WP. 이익가치는 직접 관련된 한 WP에 대한 이익가치 %로 보고됨. Example: If the Quality Assurance activity is planned to be 10% of the widget assembly activity and the assembly activity reports an earned value of $100, the QA activity can report an earned value of $10. 예 : QA 엑티비티가 제품 어샘블리 엑티비티의 10%로 계획되어 있고 어샘블리 엑티비티의 이익가치가 $100로 보고하면 QA 엑티 비티는 $10의 이익가치로 보고할 수 있음. 42

Cumulative Percent Complete 완성된 누적 % n n Earned value is based on an evaluation of progress to date (very subjective). 이익가치는 현재까지의 진척에 대한 평가에 의거한다. (매우 주관적임). Most systems allow earned value to be reported up to 90% with the last 10% earned at the completion of the task. 대개의 체계하에서 이익가치가 최대 90% 보고되며 테 스크 완성 때 나머지 이익 10%가 보고됨. 43

Level of Effort 노력 수준 n n n The amount of earned value is equal to the amount of the budget actually spent during the reporting period. 이익가치 총액은 보고기간동안 실제로 사용된 예산총액과 동등함. This technique should not be used unless all other techniques have been evaluated and found to be inappropriate. 본 기법을 제반 여타 기술이 평가 후 부적절 하다고 판단되지 않는 한 이용 하지 말것. Example: Program Management. 예 : 프로그램 관리 44

Defining the Work n Scope Planning n Work Breakdown Structure n Estimate Cost/Manpower n Schedule the Work 45

Estimating Cost/Manpower 비용/인력 추정 n n n n Most critical activity of software planning. Determines schedule and resource planning. Based on estimates of software size. Must rely on past experience. w Experience of Manager w Quantitative data from past projects 가장 중요한 소프트웨어 계획 엑티비티 일정 및 자원 계획을 정함 소프트웨어 규모 추정결과에 기초함 과거 경험에 의존해야 함 w 관리직 경험 w 과거 프로젝트에서 얻은 수치적 자료 46

Inputs 입력 정보 n n n n n Work Breakdown Structure Resource Requirements - for each WBS element, the type and quantity of resources needed. Resource Rates Activity Duration Estimates Historical Information - project files, metrics, estimating databases, team knowledge. 업무 분장 자원 요구사항 - 각 WBS 요소에 대해 필요한 자원 형태 및 수량 자원 비율 엑티비티 기간 추정 과거정보 - 프로젝트 파일, 메트릭스, 추정 데이터베이스, 팀의 지식 47

Definitions 정의 Estimate An assessment of the likely quantitative result; every estimate is but one of many possible outcomes. 추정 가능하다고 생각되는 수치적 결과에 대한 평가; 각 추정은 단지 가 능한 다수의 결과 중 하나임. Estimating The process of determining the likely range of probable outcomes (not precise). 추정함 예상 결과 (정확하지 않은) 에 대한 가능하다고 생각되는 범위 를 정하는 과정 48

Developing a Cost Estimate 비용 추정 개발 1. Develop the WBS. 2. Select an appropriate technique. 3. Document any and all assumptions. 4. Develop and document the range of possible outcomes. 5. Review and revise as necessary. 1. 2. 3. 4. 5. WBS 를 개발함 적절한 기법을 선택함 가능한 모든 가정을 문서로 증명함 가능 결과 범위를 개발하여 문서로 증명함 필요에 따라 검토 수정함 49

Types of Estimates 추정 형태 Activity Estimates Low level predictions used to manage the project. 엑티비티 추정 프로젝트를 관리하는데 사용되는 하위 예측 Project Estimates High level approximations used to guide funding decisions. 프로젝트 추정 자금조달 결정 방향을 정하는데 사용되는 상위 근사 값 50

Activity Estimates are not Negotiable 엑티비티 추정은 협상불가 If the manager thinks your high. . . First find out why. . . open lines of discussion. Then accept higher risk. . . Or develop a new strategy (e. g. , COTS). . . But NEVER lower your estimate. Manager가 귀하의 높은 …. . . 이라고 생각하면 그 이유를 알아내고 … 협의방향을 열고 그런 후 더 높은 위험부담을 수용하거나 … 새로운 전략 (예: COTS)을 개발하라 … 그러나 결코 귀하의 추정 가를 낮추지 말 것 51

Single Point Estimate 단일 항목 추정 Probability of Occurrence 발생 확률 Possible Outcomes 가능 결과 Fallacy 1 - Single point estimate is the mean of the distribution. Fallacy 2 - Overs and unders will net out over time. 오류 1 - 단일점 추정은 평균 분포임 오류 2 - Overs 와 unders는 시간이 경과함에 따라 이익발생 52

Range Estimates 범위 추정 Most Likely Expected Value Probability of Occurrence 30 Optimistic (1 in 1000) 60 70 Possible Outcomes 120 Pessimistic (1 in 1000) 53

Range Estimates 범위 추정 n n n Using a 1 - 2 - 4 distribution where the : w Pessimistic = Most Likely / 2 w Optimistic = Most Likely * 2 1 -2 -4 분포를 사용 : w 비관적 = 최대 가능성 /2 w 낙관적 = 최대 가능성 * 2 We usually estimate at the most likely (single point) w This is statistically underestimating. w Overs and unders won’t balance out here. w Underestimating by 15% (this is why we work 6 hours of uncompensated overtime a week). 우리는 대개 최대 가능 (단일 점) 위치 에서 추정함 w 이것은 통계적으로 과소 추정임. w 여기에서 넘거나 떨어지는 것은 균형이 잡히지 않음 w 15% 과소 추정 (이것이 우리가 한 주 6시간의 무 보상 시간외 일을 하는 이유임) Expected Value w Mean of the distribution. w Pessimistic + Most Likely + Optimistic / 3. 예상 가치 w 평균 분포 w 비관적 + 최대 가능성 + 낙관적 / 3. 54

Range Estimates 범위 추정 n n n Defines boundaries for acceptable performance. Reminds team of the uncertainty inherent in estimates. Improves: w Team Morale w Quality of planning decisions w accuracy of reporting 수용가능 실행에 대한 경계를 정의함. 팀에게 추정에 따르는 불확실성을 상기시킴. 다음 사항을 개선함 : 팀 사기 w 계획 결정 수준 w 보고의 정확성 w 55

Project Estimates 프로젝트 추정 n Bottom-up Construction Summing of Ranges Sum is Normal of the Bell Curve n 보텀 업 (하위상달 식) 구조 n n 범위 합계 합계는 정규 분포임 56

Bottom-up Construction 하위 상달식 구조 ? , ? . . . 4, 6, 8 3, 6, 8 4, 6, 8 5, 6, 10 6, 7, 11 1, 2, 3 5, 8, 20 57

Summing Ranges 범위를 합함 For each activity, calculate: w Mean = (low + most likely + high) / 3 w Standard Deviation = (high - low) / 5 w Variance = standard deviation ^ 2 각 엑티비티는 다음과 같이 계산 : w 평균 = (저 + 최대가능 + 고) / 3 w 표준편차 = (고 - 저) / 5 w 분산 = 표준편차 2 For the project, calculate: w Mean = sum of the individual activity means w Variance = sum of the individual activity variances w Standard Deviation = Square Root of Variance 프로젝트는 다음과 같이 계산 : w 평균 = 각 엑티비티 평균의 합 w 분산 = 각 엑티비티 분산의 합계 w 표준편차 = 분산의 제곱근 58

Worksheet 작업표 Estimate Mean Sigma Variance 4, 6, 8 5, 6, 10 1, 2, 3 3, 4, 8 4, 6, 8 6, 7, 11 5, 8, 20 59

Sum of the Means is the Normal 평균값의 합은 정규 분포임 Probability of Occurrence Possible Outcomes 60

Project Estimating is not Pricing 프로젝트 추정은 가격산정이 아님. Have to separate the estimating decision from the pricing. n n n If the customer won’t pay. . . First, find out why. . . Then accept a lower profit. . . Or develop a new strategy. . . But NEVER lower the estimate! 추정결정을 가격산정과 분리 해야 함. n n n 고객이 지불거절을 하면 …. 우선 그 이유를 찾아내고. . . 그런 후 보다 적은 이익을 수용하거나 … 새로운 전략을 개발할 것 그러나 결코 추정 가를 낮추지 말 것. 61

Where should you be? 어느 위치에 있어야 하나 ? B - Technology Companies Probability of Occurrence High Risk Low Risk A C - Construction Companies Possible Outcomes 5 out of 6 Projects will Overrun Out of Business 62

Where to Bid 가격 제출 지점 Optimistic Most Likely Pessimistic ? ? ? X If bid here. . . ? - too much up front risk 과다한 관리부문 위험부담 ? ? - sloppy management 불성실한 관리 63

Outputs 산출물 n n Cost Estimates Supporting Detail - Basis for Estimates (BOE) 비용 추정 상세 지원 : 추정 기초 (BOE) 64

REVIC Model n n n n REVIC - Revised Intermediate COCOMO Parametric model for software cost estimating. Based on SLOC count. Provides estimates for: w Labor cost (dollars and man-months) w Required personnel w Distribution of cost and schedule by project activity REVIC - 중간 개정 COCOMO 소프트웨어 비용 추정을 위한 파라메트릭 모델 SLOC 집계에 의거 다음 항목에 대한 추정 제공 : w 인건비 (금액 및 인원 -개월 수) 요구인원 w 프로젝트 엑티비티 별 비용/일정 분배 w 65

SLOC n n n n n What is a SLOC? Difficulty in estimating. Becomes obsolete with reuse? Need a tools to count SLOCs. Methods for counting w Total SLOCs w Non-comment, Non-blank lines w Semi-colons (C, Ada) w Statements SLOC 란 ? 추정하는 데 있어 어려움 재 사용함 으로서 진부해 지는가 ? SLOCs 셈을 위한 툴이 필요 w 집계 방법 w 총 SLOCs w 설명이 없고 공백이 없는 행 w 세미콜론 (C, Ada) w 명세서 66

Estimating SLOCs 추정 n n n n Collect metrics. Decompose system as much as possible. Select 2 or more people to estimate each component of the system. Compare new components to existing components, where possible. Consider reuse. Make three estimates - optimist, pessimist, best guess. First, each person independently estimates the component. Meet in group to discuss estimate, achieve consensus. Save all individual and group estimates in a database. 메트릭스를 수집 체계를 가능한 많이 분할 체계의 각 구성요소를 추정하기 위해 2인 이상을 선정 새로운 구성요소를 기존 구성요소와 비교 (가능한 부분). 재 사용 고려. 3가지 추정을 함 - 낙관, 비관, 안전한 추측 우선, 각자가 독립적으로 구성요소를 추정 그룹단위로 추정 협의를 통해 합의를 도출해 냄 제반 개인/그룹별 추정을 데이터베이스에 저장함 67

REVIC Model REVIC assumes sequential development life cycle with phases including: REVIC는 다음 항목을 포함한 단계를 이용하여 순차적 개발 수명주기를 가정 함: « « « Requirements Analysis, Preliminary Design, Detailed Design, Code & Unit Test, Integration & Test, System Test & Integration. 요구사항 분석 예비 디자인 상세 디자인 코드 및 유니트 시험 통합 및 시험 체계 시험 및 통합 68

REVIC Modes n n Organic Standalone program with few interfaces, a stable development environment, no new algorithms, and few constraints. Usually very small programs, i. e. less than KSLOC 독립형 프로그램으로 인터페이스가 적고, 안정된 개발 환경이며, 새로운 알고리듬과 제한 조건이 적음. 대개 매우 소형 프로그램으로KSLOC보다 작음. Embedded A program with considerable interfaces, new algorithms, and/or extremely tight constraints. Usually very large or complicated programs 인터페이스가 많고 새 알고리듬이 있고 또는 매우 엄격한 제한조건이 있는 프로그램. 대개 대형이거나 복잡한 프로그램임. Semi-detached A combination of organic and embedded features Organic과 Embedded 특징의 결합 형태 프로그램 Ada A program which is developed using the Ada development methodology or object -oriented design. Ada 개발 방법 또는 목표지향 디자인을 사용하여 개발되는 프로그램. 69

Documentation 문서화 The REVIC effort and development time includes all the key 2167 A documents including the: REVIC 노력과 개발시간에는 다음을 포함한 제반 주요 2167 A 서류가 포함되 어 있다: REVIC SSDD IRS STP SPS SPM CRISD SDP SDD STD VDD SUM SRS IDD STR CSOM FSM REVIC estimates page counts for each of the 2167 A documents listed above. REVIC 은 상기에 기입된 각 2167 A 서류 페이지 숫자를 추정한다. 70

New and Adapted Code 새 코드 및 개작 코드 Estimated code size drives the REVIC model. REVIC distinguishes between new and adapted code. It does not address the use of computer generated code (e. g. , GUI) or Commercial Off The Shelf (COTS) software. REVIC presents the user with a menu allowing him to enter code size for modules consisting of: exclusively new code. « exclusively adapted code. « a combination of new and adapted code. 추정 코드 크기는 REVIC 모델을 움직인다. REVIC는 새 코드와 개작코드 를 구별함. 자동 생성 코드 (예: GUI) 또는 COTS 소프트웨어 사용에 대 한 언급이 없음. REVIC는 사용자에게 특별히 새 코드로 구성된 모듈에 대한 코드 크기를 입력할 수 있도록 메뉴를 제시함: « 완전 적용 (개작)코드 « 새 코드와 개작 코드의 혼합형 71

New Code 새 코드 For modules whose implementation is all or part new code, REVIC allows the estimator to enter three estimates: 실행의 전부 또는 일부가 새 코드인 모듈에 대해 REVIC는 추정자 가 다음 세 가지 형태의 추정을 입력할 수 있게 해 준다: « Optimistic Estimate 낙관적 추정 « Best Guess Estimate 확실한 추측에 의한 추정 « Pessimistic Estimate 비관적 추정 These three estimates are combined into a single estimate during the REVIC estimating process. 위 세 가지 추정은 REVIC 추정 과정에서 단일 추정이 된다. 72

Adapted Code 개작 코드 Examples of adapted code include: « new language/same host « new host/same language « modified capability/same host/same language « modified code with higher reliability requirements « code obtained from a reuse library « government furnished software 개작 코드 예 로 다음항목이 포함된다: « 새 프로그램 언어 / 동일 호스트 « 새 호스트 / 동일 프로그램 언어 « 수정된 성능 / 동일 호스트 / 동일 프로그램 언어 « « « 보다 높은 신뢰성 요구사항으로 수정된 코드 재 사용 라이브러리로 부터 입수된 코드 정부에 제공된 소프트웨어 73

Adapted Code 개작 코드 For a system consisting of all or part adapted code the user is asked to specify: 전부 또는 부분적으로 개작 코드로 구성된 체계에 대해서는 사용자 가 다음사항을 명시한다: «% new design. 새 디자인 % « % new code. 새 코드 % « % required testing. 요구 시험 % 74

Environmental Factors 환경 요인 n n n n n A list of factors that are directly controlled by the user. Used to calculate the multiplier used in the estimating equations. The multiplier is the product of all of the environmental factors. Larger values result in more effort and schedule. Small values result in less effort and schedule. Always set the factors to the actual environment. Do not “play” the factors to come out with the “right” answer. 사용자가 직접 통제하는 요인 목록 방정식 추정에 사용되는 배수를 계산하기 위해 사용됨 본 배수는 제반 환경적 요인에 대한 산출물임. 가치가 클수록 더 많은 노력과 일정이 요구되고, 적은 가치는 보다 보다 적은 노력과 일정이 필요함. 본 요소들을 항상 실제 환경에 맞춤. “옳음”이라는 답을 도출 시키기 위 해 본 요인들을 “조작”하지 말 것. 75

Analysts Capability 분석자 능력 This is a measure of the average capabilities of the software systems engineering team. These members are required to perform the initial software requirements analysis, top level decomposition, and generate the preliminary design of the CSCIs and upper level CSCs. Experience with the languages to be used and the required, or chosen methodology should be considered. 이것은 소프트웨어 체계 엔지니어링 팀의 평균능력 측정 크기이다. 본 단원들은 초기 소프트웨어 요구사항 분석 및 상위 분할 실행시키며 CSCIs 및 상위 CSCs의 예비 디자인을 생성시키도록 요구 된다. 사용 될 콤퓨터 언어 경험과 요구되거나 선택된 일 련의 방법에 대한 경험이 고려되어야 한다. w w w w w VL LO NM HI VH New personnel, no experience (15%) Functional team with low efficiency (35%) [1. 19] Average team with nominal efficiency (55%) Strong team with good efficiency (75%) Strong team with many top people (90%) [0. 71] 신입 직원으로 경험 없음 (15%) 기능성 팀으로 효율성이 낮음 (35%) 중간수준 팀으로 보통수준 효율성 (55%) 능력 있는 팀으로 효율성 좋음 (75%) 여러 상위급 직원으로 능력 있는 팀 (90%) [1. 46] [1. 00] [0. 86] 76

Programming Team Capability 프로그래밍 팀 능력 This is a measure of the average capabilities of the programming team. These are the people who will perform the detailed CSCI/CSC design during the critical design phase, as well as write and test the code during the coding phase of the contract. Experience with the languages to be used, and the required or chosen methodology should be considered. 프로그램 팀의 평균능력 측정이다. 이들은 코딩 계약 단계에서 코드를 작성하거 나 시험할 뿐 아니라 주요 디자인 단계에서 상세 CSCI/CSC 디자인을 실행할 인원들이다. w w w w w VL New personnel, no experience (15%) LO Functional team with low efficiency (35%) NM Average team with nominal efficiency (55%) HI Strong team with good efficiency (75%) VH Strong team with many top people (90%) 신입직원으로 경험 없음 (15%) 효율성이 낮은 기능성 팀 (35%) 효율성이 보통인 보통수준 팀 (55%) 효율성 높은 우수 팀 (75%) 상위급 인원이 많은 능력있는 팀 (90%) [1. 42] [1. 17] [1. 00] [0. 86] [0. 71] 77

Application Experience 응용프로그램 경험 Attempts to measure the familiarity of the design and development team with the specific program, that is, experience designing products similar to this one. Business unit experience, and program continuations should weigh heavily on the determination. 디자인 및 개발팀의 특정 프로그램에 대한 지식, 즉 이와 유사한 산출 물의 디자인 경험 정도를 측정함 w w w w w VL LO NM HI VH No experience (less than 4 months) Limited experience (1 year) [1. 13] Nominal experience (3 years) [1. 00] Better than average (6 years) [0. 91] Experts (more than 12 years experience) 경험 없음 (4개월 이하) 경험 적음 (1년) 보통수준의 경험 (3년) 평균 이상 (6년) 전문가 수준 (12년 이상) [1. 29] [0. 82] 78

Virtual Machine Experience 가상 기계 경험 Measures the experience of the design and programming team with the host development system, as well as the target computer. NOTE: software tools should be considered here for experience and learning curve (i. e. CASE, compiler, debugger, etc. ). 디자인 및 프로그래밍 팀의 타깃 콤퓨터 및 호스트 개발 체계에 대한 경험 정도를 측정. 메모: 소프트웨어 툴은 여기에서 경험과 학습곡선에 대해 고려되어야 한 다 (즉, CASE, compiler, debugger 등) VL w LO w NM w HI w w w Never used before [1. 21] Less than 6 months Less than 1 year [1. 00] More than 1 year [0. 90] 이전에 사용경험 없음 사용 한 후 6개월 이하 경과 사용 한 후 1년 이상 경과 [1. 10] 79

Language Experience 프로그램 언어 경험 Measures the design and programming team's experience with the language used to implement the design. 디자인 및 프로그래밍 팀의 디자인 실행에 사용되는 콤퓨터 언어 경 험 정도를 측정 VL w LO w NM w HI w w w Never used before Less than 1 year At least 1 year 2 or more years experience 이전에 사용경험 없음 1년 이하 사용 경험 최소한 1년 사용 경험 2년 이상 사용 경험 [1. 14] [1. 07] [1. 00] [0. 95] 80

Execution Time Constraints 실행 시간 제한조건 Measures the approximate percentage of the available CPU execution time that will be used by the software. 소프트웨어에 사용될 가용 CPU 실행시간 근사%를 측정 w NM For 60% utilization [1. 00] w HI For 70% utilization [1. 11] w VH For 85% utilization [1. 30] w XH For 95% or more [1. 66] w 60% 활용 w 70% 활용 w 85% 활용 w 95% 이상 활용 81

Main Storage Constraints 주요 저장장치 제한조건 Measures the amount of constraint imposed on the software due to main memory limitations in the target computer. If a contractual requirement exists for 50% growth, common in DOD contracts, the percentages should be of the usable 50%, hence, 47. 5% of total memory usage yields an XH rating. 타깃 콤퓨터의 주 메모리 한계로 인해 소프트웨어에 주어진 제한조건 양을 측 정. 계약 요구사항이 DOD 계약에서 흔히 볼 수 있는 50% 생성을 위해 실 재한다면 이 %는 사용 가능한 50%이다. 따라서 총 사용 메모리 의 47. 5% 는 XH 등급을 산출한다. w NM No memory constraints [1. 00] w HI For 70% utilization [1. 06] w VH For 85% utilization [1. 21] w XH For 95% or higher [1. 56] w 메모리 제한조건이 없음 w 70% 활용에 대해 w 85% 활용에 대해 w 95% 또는 그 이상 활용에 대해 82

Virtual Machine Volatility 가상 기계 소멸성 Measures the amount of volatility of the host and target computers during the design and development phases. 디자인 및 개발 단계에서 호스트 및 타깃 콤퓨터 소멸성 합계 측정 w w w w w LO NM HI VH XH One change every 6 months [0. 87] One change every 3 months [1. 00] One change every month [1. 15] Several changes every month [1. 30] Concurrent development, constant change [1. 49] 6개월마다 1회 교체 3개월 마다 1회 교체 매월 수 회 교체 동시 개발, 지속적인 교체 83

Computer Turnaround Time 콤퓨터 처리 소요시간 Measures the time spent waiting for the host or development systems to produce listings, compiles, etc. This is a measure of the designer's and programmer's non-productive time. 호스트 또는 개발 체계가 목록, 컴파일 등 을 산출하는데 대기하는 시간을 측 정. 이것은 디자이너 및 프로그래머의 비 생산적인 시간임. w VL Less than 6 minutes [0. 79] w LO Less than 30 minutes [0. 87] w NM Less than 4 hours [1. 00] w HI More than 4 hours [1. 07] w VH More than 12 hours [1. 15] w 6분 이하 w 30분 이하 w 4시간 이상 w 12시간 이상 84

Requirements Volatility 요구사항 소멸성 Measures the amount of project design and development rework that is a result of changes in customer specified requirements. This factor is designed to measure the time spent evaluating the change requirements, estimating the engineering impact, and preparing the ECPs required to modify the contractual requirements of the job. w 고객 명시 요구사항의 변경 결과인 프로젝트 디자인/ 개발 재 작업 량 을 측 정. 이 요소는 본 작업에 대한 변경요구사항을 평가하고 엔지니어링 영향 을 추정하고 계약 요구사항을 수정하는데 필요한 ECPs를 준비하는데 소요 되는 시간을 측정하기 위한 것임. w w w w w LO NM HI VH XH Essentially none Small, non-critical re-directions Occasional moderate re-directions Frequent moderate or occasional major redirects Frequent major re-directions 근본적으로 없음 경미한 정도 이며 중요하지 않은 방향전환 가끔 적당히 방향전환 자주 적당하게 또는 가끔 전면적인 방향전환 자주 전면적인 방향전환 [0. 91] [1. 00] [1. 19] [1. 38] [1. 62] 85

Required Software Reliability 소프트웨어 요구 신뢰도 Quantifies the required reliability of the finished software. Higher quality requirements lengthen the design and testing phases of the program. 완성된 소프트웨어의 요구 신뢰도를 수치화 함. 질 높은 요구사항 수준이 높으면 프로그램 디자인 및 시험단계가 길어짐. w w w w w VL LO NM HI VH Slight inconvenience Easily recoverable loss Moderate recoverable loss For MIL-STD or high financial loss for possible loss of life 약간 불편함 손실 회복가능이 쉬움 손실 회복가능이 보통 MIL-STD 또는 상당한 재정손실에 대한 수명 소실이 가능한 것에 대한 [0. 75] [0. 88] [1. 00] [1. 15] [1. 40] 86

Database Size 데이터베이스 크기 Attempts to determine the effects on the software development due to the size of the database that must be designed, maintained, and manipulated. 설계, 보수유지 및 조종되어야 할 데이터베이스 크기로 인해 소프트 웨어 개발에 미치는 영향이 무엇인지를 정함. LO w NM w HI w VH w w w Very small (DB bytes/program DSI <10) Nominal size effort (107 D/P <100) Large and complex effort (1007 D/P <1000) This one is the pits (1000 7 D/P) 매우 적음 (DB bytes / program DSI <10) 보통 크기 (107 D/P <100) 대형이면서 복잡함 (1007 D/P <1000) Pits 임 (DB bytes / program DSI <10) [0. 94] [1. 00] [1. 08] [1. 16] 87

Software Product Complexity 소프트웨어 제품 콤플렉시티 Attempts to quantify the complexity of the software product to be developed. 개발 될 소프트웨어 제품 콤플렉시티를 수치화 함. w w w VL LO NM HI VH XH Off-Line simple print routines Off-Line data processing Data processing and math routines Some h/w I/O & advanced data structures Real-Time applications and advanced math Extremely complex scientific processing 간단한 오프라인 프린트 루틴 오프라인 데이터 처리 및 계산 루틴 일부 H/W I/O 및 고급 데이터 구조 실시간 응용 프로그램 및 고급 계산 매우 복잡한 과학적 처리 [0. 70] [0. 85] [1. 00] [1. 15] [1. 30] [1. 65] 88

Required Reusability 재 사용성 요구 Measures the extra effort required to generalize the software modules when it must be developed specifically for reuse in other software packages. 소프트웨어 모듈이 여타 소프트웨어 페키지에 재 사용 용으로 특별 히 개발 되어야 할 때 그것을 보편화 시키는데 필요한 추가노력을 측정함 NM w HI w VH w XH w w w not for reuse within single-mission products reuse across a single product line reuse in any application 재 사용 용 아님 단일 미션 제품 내에서 재 사용 단일 제품 라인에 걸쳐 재 사용 모든 응용프로그램에 재 사용 [1. 00] [1. 10] [1. 30] [1. 50] 89

Modern Programming Practices Quantifies the use of modern programming practices such as structured programming, data flow diagrams, etc. Overall experience of the team is considered. 구조적 프로그래밍, 데이터 흐름표 등 과 같은 MPP 이용을 수치화한다. 팀의 전반적인 경험이 고려된다. VL w LO w NM w HI w VH w w w No use of MPPs [1. 24] Beginning use of MPPs [1. 10] Some use of MPPs [1. 00] General use of MPPs by all members [0. 91] Routine use of MPPs with strong training [0. 82] MPPs를 사용 안함 MPPs 사용 초기 MPPs 일부 사용 일반적으로 모든 멤버가 MPPs를 사용 상당한 훈련이 되어 있으며 MPPs를 정규적으로 사용 90

Use of Software Tools 소프트웨어 툴 사용 Measures the use of automated software tools such as CASE tools and APSE. Overall experience of the team is considered. CASE 툴 및 APSE와 같은 자동 소프트웨어 툴의 사용을 측정한다. 팀의 전반적인 경험이 고려된다. w w w w VL LO NM HI VH XH XX Very few, primitive tools Basic micro tools Basic mini tools Basic maxi tools Extensive tools, little integration Moderately integrated environment (UNIX) [0. 73] Fully integrated environment (APSE) 거의 없으며 원시적인 툴임 기본 마이크로 툴 최소량의 기본 툴 최대량의 기본 툴 광범위한 툴, 거의 통합 안됨 적절한 통합 환경 (UNIX) 완전 통합 환경 (APSE) [1. 24] [1. 10] [1. 00] [0. 91] [0. 83] [0. 62] 91

Classified Security Application 분류 보안 응용프로그램 Measures the extra work required to develop software either in a classified security area, or for a classified security application. Note that this factor does not relate to the certification of security processing levels, as specified by the NSA. Use the complexity factor to account for that type of application. This factor increases the time factor based on more nonproductive time due to the environment 분류 보안 영역내의 소프트웨어 또는 분류 보안 응용 프로그램을 위한 소프 트웨어 개발에 요구되는 추가작업을 측정함. 이 요소는 NSA가 명시한 대로 보안 처리 수준 인증과 관계 없음을 메모할 것. 그러한 프로그램 형 식을 설명하기 위해 콤플렉시티 요소를 사용 함. 이 요소는 본 환경으로 인해 더욱 비 생산적인 시간에 근거한 시간적 요소를 증가 시킨다. UN w CL w w w Unclassified Classified (Secret or Top Secret) [1. 10] 분류되지 않음 분류되어 있음 (기밀 또는 일급 기밀) [1. 00] 92

Risk 위험 부담 Allows for the addition of a percentage factor to account for the varying levels of program risk. 다양한 프로그램 위험 수준을 설명하기위해 % 요소를 추가할 수 있음. w w w w VL LO NM HI VH XH XX Ground systems Mobile systems Communications/avionics Military avionics Missile systems Unmanned space programs Manned space 지상 체계 이동 체계 통신/항공 군 항공 미사일 체계 무인 우주 프로그램 유인 우주 [1. 00] [1. 20] [1. 40] [1. 60] [1. 80] [2. 00] [2. 50] 93

Lab on REVIC 94

Defining the Work n Scope Planning n Work Breakdown Structure n Estimate Cost/Manpower n Schedule the Work 95

Scheduling The process of converting planned project activities into an operational time-table given available resources and within known constraints. 계획 프로젝트 엑티비티를 주어진 가용 리소스로 알려진 제한 조건 내에서 운영 예정표로 전환 시키는 과정 96

Process 1. Define the Scope (Scope Statement). 2. Develop the complete WBS. 3. Estimate durations of activities (lowest branches of the WBS). 4. Identify activity dependencies and sequencing (network logic). 5. Add external and resource constraints. 6. Analyze results. 7. Adjust as needed and repeat. 1. 2. 3. 4. 5. 6. 7. 범위를 정의 함 (범위 기술서) 완전한 WBS 개발 엑티비티 기간 추정 (최하위 WBS 지선) 엑티비티 의존상태 및 순서를 식별 (네트워크 논리) 외부 리소스 제한사항을 추가 결과분석 필요에 따라 조정 및 반복 97

Scheduling Tools w Used to plan and track future events. w May depict start and stop times of events relative to calendar and/or milestones. w May show precedence relationships and dependencies between tasks. 스케쥴링 툴 w 미래 이벤트 를 계획하고 추적하는데 사용됨. w 일정표 및/또는 이정표와 관련된 이벤트 시작 및 정지 회수를 묘사할 수 있음. w 테스크 간의 선행 관계 및 의존상태를 보여 줄 수 있음. 98

Duration Estimates 기간 추정 n n n Reflect one of many possible outcomes. Can be: w Duration-driven - allocate resources to complete an activity within a defined duration. w Staffing-driven - calculate duration based on when resources are available. Do range estimates and take the mean. 다수의 가능성 있는 산출물 중 하나를 반영 다음과 같이 가능함: w 기간 위주 - 하나의 엑티비티를 정해진 기간 내에 완결하기 위 해 할당 w 인력 위주 - 리소스 가용 시점에 의거한 기간을 계산 추정범위를 정하고 평균을 구할 것 99

Techniques 기간 추정 기법 n n n Expert Judgment - specialized knowledge or training supplemented with historical information (e. g. , consultants, industry groups, other divisions). Analogous Estimating - Use actual estimates from previous, similar activities. Simulation - Calculating multiple durations with different sets of assumptions. Export Judgment - 과거 정보로 보충된 전문지식 또는 훈련 (예: 고문, 산업체, 여타 부문) Analogous Estimating - 과거 및 유사한 엑티비티에 산출된 실제 추정결과를 사용 Simulation - 여러 가정 단위로 다수 기간을 계산 100

Activity Dependencies 엑티비티 의존상태 n n Define a relationship between two activities. For example, the writing of a document must complete before the review of the document can begin. This is a finish-to-start relationship. 2 엑티비티 간의 관계를 정의. 예로 서류작성은 서류 검토가 시작 되기 전에 완성되어야 힘. 이것은 완료-시작 관계임. FS 101

Relationships 관계도 n n n n Finish-to-Start (most common) The first activity must complete before the second activity can begin. Finish-to-Finish The first activity must complete before the second activity can finish. Start-to-Start The first activity must start before the second activity can start. Start-to-Finish (rarely used) The first activity must start before the second activity can finish. Finish-to-Start (가장 많이 이용됨) 제 1 엑티비티는 제 2 엑티비티가 시작하기 전에 완성되어야 한다. Finish-to-Finish 제 1 엑티비티는 제 2 엑티비티가 끝나기 전에 완성되어야 한다. Start-to-Start 제 1 엑티비티는 제 2 엑티비티가 시작하기 전에 시작해야 한다. Start-to-Finish (거의 사용되지 않음) 제 1 엑티비티는 제 2 엑티비티가 끝나기 전에 시작되어야 한다. 102

Network Logic Diagram n Graph that uses nodes to represent activities and connecting them with arrows that show the dependency. 그래프는 노드로 엑티비 티를 나타내며 엑티비티를 의존상태를 나타내는 화살과 연결시 킨다. Activity A Start Activity F Activity B Activity C Activity D Activity E Activity G Finish Activity H 103

Exercise NLD 작성 연습 Create a network logic diagram for a breakfast project with the following activities: 다음 엑티비티로 간이 프로젝트용 NLD를 작성 n Juice - get glass, get juice container from the refrigerator, pour the juice, put glass with juice on the table. n Juice - 유리잔 갖고 옴. 냉장의 쥬스 병을 내어 쥬스를 유리잔에 붓 고 그것을 테이블 위에 놓음. n Coffee - get the coffee pot (percolator kind), fill coffee pot with water, get coffee from the refrigerator, put coffee into the pot, brew the coffee, get cup from the cabinet, pour the coffee into the cup, put cup with coffee on the table. n Coffee - 커피폿 (여과기 달린 타입) 에 물을 채움. 냉장고에서 커 피를 내어 폿에 붓고 커피를 끓임. 찬장의 컵을 내어 커피를 붓고 그것을 테이블 위에 놓음. 104

Other Information n n n Sequence the activities as given and note places for future modifications. Assume unlimited resources and use finish-to-start dependencies. Draw by hand or use post-its. 엑티비티를 주어진 대로 배열하고 앞으로 수정할 부분을 메모함. 비 제한적 리소스를 추정하고 finish-to-start 의존상태를 이용함 손으로 그리거나 포스트잇을 사용. 105

Develop the Schedule Critical Path Method w Mathematical analysis technique to predict project duration. w Calculates theoretical early and late start and finish dates for all project activities. w The resulting dates are not the schedule, but are the time periods within which the activity should be scheduled after all constraints are applied. w The focus is on calculating the float in order to determine which activities have the least scheduling flexibility. w The critical path is the path that has no float. Critical Path Method w 수학적 분석기법으로 프로젝트기간을 예측 w 제반 프로젝트 엑티비티에 대한 이론상의 조기/지체 시작 및 종료 일자를 계 산 w 그 결과로 나오는 일자가 그 일정이 아니지만 모든 제한 사항이 적용된 후 그 기간 내에 엑티비티 일정이 개발 되어야 함. w 어느 엑티비티가 스케쥴링 신축성이 가장 적은지를 정하기 위해 플로트 계산 에 초점이 주어짐. w 크리티칼 패스 는 를로트가 없는 경로임. 106

Critical Path n n The critical path is the longest time sequences of tasks in a scheduling network. It represents minimum time required to complete a project. It is the path on which everything depends. 크리티칼 패스는 스케쥴링 네트워크에 있는 최 장 테스크 시간 순서이다. 그것은 한 프로젝스를 완성하기 위해 요구 되는 최저 시간을 나타낸다. 이 패스에 모든 것이 좌우된다. w If something on the critical path slips, the whole project slips. w Accelerating tasks not on the critical path will not change the project completion date. w Need to have the optimal allocation of resources to the tasks on the critical path. . w 크리티칼 래스에서 무엇인가가 헐거워지면 모든 프로젝트가 헐거워 짐. w 크리티칼 패스에 있지 않은 테스크를 가속시킨다고 본 프로젝트 완 성일자가 변경되지 않음. w 크리티칼 패스 상의 테스크에 리소스를 최적으로 할당 해 줄 필요가 있음. 107

Critical Path Calculations CP 계산 CPM Forward Pass w determines the project’s “natural end date” based on early start and early finish dates. w 조기 시작 과 조기 완료일자에 의거한 프로젝트의 “본래 종료 일자”를 정함 CPM Backward Pass w determines late start and late finish dates. w 지체 시작 및 종료일자를 정함 Total Float w Late Start - Early Start w 지체 시작 - 조기 출발 108

Float - slack time. 슬랙 시간 Total Float - the amount of time an activity may be delayed without affecting the project completion date. Total Float - 한 엑티비티가 프로젝트 완성일자에 영향을 주지 않고 지체될 수 있는 시간 Free Float - the amount of time an activity may be delayed without affecting the early start of any successor activities. Free Float - 한 엑티비티가 모든 후속 엑티비티의 조기 시작에 영향 을 주지 않고 지체될 수 있는 시간 109

Example Activity A (14) Start Activity F (11) Activity B (5) Activity C (2) Activity D (13) Activity E (12) Finish Activity G (21) 110

Incorporate Constraints 제한 사항 상호조정 Incorporate constraints using each activity’s slack time to adjust the start and stop dates in the activity’s time period. 엑티비티 기간내의 시작/종료 일자를 조절하기 위해 각 액티비티의 슬랙 시간을 이용하여 제한 조건을 상호조정 Use resource leveling techiniques. 리소스 균일 기법을 사용 Incorporate fixed milestones and imposed dates. 정해진 이정표 및 의무일자를 상호조정 Perform activities in parallel, where possible. 가능한 부분에 엑티비티를 동시에 이행 111

Gantt Charts n n n In use since the early 1900’s. Shows activities as bar charts with start and stop times. Depicts start and stop times relative to calendar and milestones. Typically used for high-level planning but may also show detailed tasks. Represents overlap between activities. May show progress (status). 1900년도 초기 이래 사용되어 옴 바 챠트로 엑티비티 시작/종료 회수를 보여 줌 일정표 및 이정표 에 관한 시작/종료 회수를 묘사 일반적으로 상위급 계획에 사용되지만 상세한 테스크도 나타낼 수 있음. 엑티비티 간의 중복 부분을 나타냄. 진척도 (상태)를 나타낼 수 있음. 112

Gantt Chart Example 113

Rescheduling n n n Low Productivity - Actual Hours > Projected Hours w Try to increase the team’s productivity. If not, increase time estimates of all activities to which the team is assigned. 저 생산성 - 실제 시간 > 계획시간 w 팀 생산성 증대에 힘쓸 것. 그렇지 않으면 팀에게 할당된 제반 엑티 비티에 대한 추정 시간을 늘릴 것. Estimation Error - Actual SLOCs > Project SLOCs w Adjust estimates for similar activities. 추정오류 - 실제 SLOCs > 계획 SLOCs w 유사 엑티비티에 대한 추정을 조정 External Event Delay - Dependent item is late. External Event Delay - 의존 항목이 지체 114

Project Planning n Overview n Defining the Work n Risk Engineering n Documenting the Plan 115

Risk Engineering n Definitions n Risk Analysis n Risk Management 116

What is the value of flipping the coin? 동전 뒤집기의 가치는 ? Heads + 20 = + 10 probability. 5 Flip the Coin +6. 5 Tails -8= -4 Stand Pat +5 Decision Tree 118

Definitions n n n Dictionary Definition 사전적 정의 w The possibility of loss or injury. 유실 또는 상해 가능성 Another Definition 새로운 정의 w The potential for the realization of unwanted, negative consequences of an event. 원치 않는 부정적 결과 산출 이벤트 의 실현 가능성 Three Elements of Risk 3대 위험 요소 w Potential Loss 잠재적 손실 w Uncertainty 불 확실성 w Choice 선택 119

Software Risk Engineering The goal of software risk engineering is to minimize the probability of unwanted consequences. 스프트웨어 리스크 엔지니어링의 목표는 원하지 않는 결과 산출 확 률을 최소화 하는 것임. Examples 예 : w Overrunning the Budget or Schedule w Operational Problems due to Errors or Performance Shortfalls w Product is Difficult to Maintain or Modify 예산 또는 일정을 오버런 w 오류 또는 실행 단점으로 인한 운용문제 w 산출물이 유지 또는 수정되기 어려움 w 120

Risk Impact Areas 리스크가 영향을 미치는 영역 n Schedule n Performance (Technical) 실행 (기술적) n Cost 비용 일정 A single risk may impact more than one of these areas. 한가지 리스크가 상기 한 영역 이상에 영향을 줄 수 있음. 121

Risk Analysis 리스크 분석 The purpose of Risk Analysis is prioritize the risk elements and quantify the likelihood and consequence of failure. 리스크 분석 목적은 리스크 요소를 우선시 하여 실패 가능성과 결과 를 수치화하는 것임 Risk Analysis Activities 리스크 분석 엑티비티 Risk Identification w Risk Estimation w Risk Evaluation w 리스크 식별 리스크 추정 리스크 평가 122

Risk Identification 리스크 식별 Identify and Categorize Potential Problem Areas 잠재적 문제부분을 식별하고 분류함 w Use Risk Identification Checklists 리스크 식별 점검표 사용 « Generic software problems 일반적 소프트웨어 문제 « Cost drivers from estimation model 추정 모델의 코스트 드라이 브 w Analyze Underlying Assumptions 기본 가정을 분석 « Compare assumptions with past experience 가정을 과거 경험과 비교 « Look for Murphy 머피 법칙을 찾음 w Analyze Poorly Defined Items 정의가 잘못된 항목을 분석 123

Team Exercise 팀 별 연습 1. Brainstorm the top risks to a software project. 소프트웨어 프로젝트에 대한 일급 리스크를 브레인스토밍함. 2. Use Nominal Group Techniques to determine the top 3. 상위 3 리스크를 정하기 위해 NGT를 사용 3. Pick a spokesperson to present to the class. 참석자들에게 설명해 줄 수 있는 사람을 선정 124

Top Ten Generic Software Risks 10 가지 일반적 소프트웨어 리스크 1. Personnel Shortfalls w can’t get the staff need to perform the job w can be either quantity or quality, or both 1. 인사 취약점 w 작업을 수행하는 데 필요한 인원을 구할 수 없음 w 인력을 수치 및/또는 질이 될 수 없음 2. Unrealistic Schedule or Budget, or both 비 현실적인 스케쥴 및/또는 예산 3. Don’t Understand or a Misinterpretation of the Requirements 요구사항을 이해 못하거나 오류 해석하지 말 것. 4. Wrong Interface Definition 잘못된 인터페이스 정의 5. Gold Plating (excessive requirements) Gold Plating (과다 요구사항) 125

Top Ten Generic Software Risks 6. Requirements Changes 요구사항 변경 7. Problems with Externally Furnished Components 외부적으로 제공되는 구성 품 (EFC) 문제 8. Problems with Externally Performed Tasks (subcontractor) 외부적으로 실행되는 테스크 (EPT) 문제 (하청업자) 9. Shortfalls in Real-time Performance 실시간 실행을 하는데 있어 취약점 10. Straining Computer Science Capabilities CSC를 약화시킴 126

Identification of Risk Types 리스크 형태 식별 Known Risks 인지된 리스크 Predictable Risks 예측가능 리스크 Unpredictable Risks 예측 불능 리스크 127

Known Risks 알려진 리스크 n n Those risk elements that are apparent following an analysis of the RFP or contract. RFP 또는 계약 분석후 잇따라 명백해 지는 리스크 요소. Examples 예: w Lack of requirements definition 요구사항 정의 부족 w Lack of experience with elements of the system 체계 구성요소 에 대한 경험부족 w Dependencies on subcontractors 하청업자 의존상태 w Performance/reliability requirements 성과 / 신뢰도 요구사항 w Cost/productivity estimates 비용/생산성 추정 w Schedule 일정 w Acquisition of Resources 리소스 취득 128

Predictable Risks 예측 가능 리스크 Those Risks that experience tells us we have a high probability of encountering. 경험으로 부딪칠 확률이 높다라는 것을 알 수 있는 리스크. n n Examples 예 w Changes in requirements 요구사항 변경 w Lack of timely customer inputs/approvals 적시적 고객 입력/ 인증이 안됨 w Late deliveries 인도 지체 w Personnel turnover 인원 교체 129

Unpredictable Risks 예측 불능 리스크 n n n Those risks that could happen, but the likelihood or timing of the events occurring cannot be predicted very far in advance. 발생할 수 있으나 이벤트 발생 가능성 또는 시기는 상당 시간 전 에는 예측할 수 없는 리스크 Examples 예 : w Changes in priority 중요순서 변경 w Funding Availability 가용 자금 조달 w Poor management by customer 고객의 부실관리 w Erroneous inputs 오류 입력 130

Risk Estimation 위험 추정 n Assign Quantitative Value or Priority to Risks n 수치적 가치 또는 중요도를 리스크에 할당 n n Use a Simple Rating Scheme - Low, Medium, High SRS를 이용 -낮음, 중간, 높음 Quantify as Probability of Occurrence (0. 0 - 1. 0) and Consequence of Occurrence ($) 발생 확률 (0. 0 ~ 1. 0) 및 발생 결과 ($)로 수치화 함. 131

Risk Rating Mechanism 리스크 평가 메카니즘 Probability of Occurrence 1. 00 0. 75 High 0. 50 Medium 0. 25 Low 0. 00 0 Severity of Impact ($) (Consequences) 1000 132

Risk Classifiers 리스크 분류자 Low Little potential to cause disruption to schedule, increase cost, or degrade performance. w Normal processes and normal monitoring will probably be able to overcome difficulties. w 일정을 망치고 비용을 늘리거나 퍼포먼스를 격하 시킬 가능성이 적음. w 아마도 일반적 처리과정 및 일반 모니터링을 통해 어려움을 극복할 수 있을 것임. Medium w Can potentially cause some disruption of schedule, increase cost, or degrade performance. w Innovative processes and close monitoring will probably be able to overcome difficulties. w 일정을 망치고 비용을 늘리거나 퍼포먼스를 격하 시킬 가능성 이 다소 있음. w 아마 혁신적 처리과정 및 면밀한 모니터링을 통해 어려움을 극복할 수 있을 것임. High w Likely to cause serious disruption of schedule, increase cost, or degrade performance in spite of innovative processes and close monitoring. w 혁신적인 처리과정 및 면밀한 모니터링에도 불구하고 일정을 심각하게 망치 고, 비용을 증가 시키거나 또는 퍼포먼스를 격하시킬 가능성 이 큼. w 133

Risk Classifiers - Criteria 리스크 분류자 - 기준 Probability of Occurrence 발생 확률 w Estimate of Probability 확률 추정 w Extent of Demonstration 데모 범위 w Existence of Capabilities 성능 실재 w Extent of Changes Required to Achieve Desired Results 기대 결과 성취 (ARR) 를 위해 요구되는 변경 범위 Risk Consequences w Impact on Cost, Schedule, Performance 리스크 결과 w 비용, 스케쥴, 퍼포먼스에 미치는 영향 134

Low Risk Level Classifiers 하위급 리스크 분류자 Probability of Occurrence 발생 확률 w Estimate of Probability 확률 추정 « Sufficiently low as to cause no concern. 염려 야기를 시키지 않을 정도로 리스크가 충분히 낮음. w Extent of Demonstration 데모 범위 « Full scale integrated technology has previously been demonstrated. 완전 통합규모 기술이 이미 시범설명 되었음. w Existence of Capability 성능 실재 « Already exists in existing items but needs to be integrated into system during development. 기존 항목에 이미 존재하지만 개발 되는 동안 체계에 통합될 필요가 있음. w Extent of Changes Required 요구변경 범위 « Effects straight forward and easily achievable within program cost, schedule and performance allocation. 프로그램 비용, 스케 쥴 및 퍼포먼스 할당 내에서 올바르고 쉽게 성취할 수 있는 효과 Risk Consequences 리스크 결과 w Insignificant cost, schedule or technical impact on program. 프로그 램에 미치는 중요하지 않은 비용, 스케쥴 또는 기술적인 영향 135

Moderate Risk Level Classifiers 보통 수준의 리스크 분류자 Probability of Occurrence 발생 확률 w Estimate of Probability 확률 추정 « High enough to be of concern. 염려할 만큼 리스크 높음 w Extent of Demonstration 시범설명 범위 « Breadboard or simulations have been accomplished. Breadboard 또는 모의가 실행되었음. w Existence of Capability 성능 실재 « Could exist in existing items in use today but not at performance standards for the system. 오늘날 사용중인 기존 항목에 실재할 수 있으나 본 체계에 대해선 실행 기준에 있지 않음. w Extent of Changes Required 요구 변경 범위 « Design iterations are probable to achieve required/desired results. 디자인 반복은 요구/기대 결과를 성취하기 위해 예상됨. Risk Consequences 리스크 결과 w Would affect program but achievable within allocated baselines. 프 로그램에 영향을 미치겠지만 할당된 기준 내에서 성취가능. 136

High Risk Level Classifiers 상위급 리스크 분류자 Probability of Occurrence 발생 확률 w Estimate of Probability 확률 추정 « High. 높음 w Extent of Demonstration 데모 범위 « Technology has not been demonstrated. 기술이 시범설명 되지 않 았음. w Existence of Capability 성능 실재 « Does not currently exist. 현재 실재 하지 않음 w Extent of Changes Required 요구 변경 범위 « Significant design iterations expected to achieve desired results. 기대 결과 성취를 위해 중요한 디자인 반복 예상 Risk Consequences 리스크 결과 w Significant program impact, significant reserve requirements required, alternative actions or parallel development appropriate. 중 요한 프로그램 영향, 요구된 중요한 유보 요구사항, 적절한 대안 실행 또는 병행적 개발 137

Simple Table Probability of Occurrence Low Medium High Consequence of Occurrence 138

Risk Evaluation 리스크 평가 n Determine Acceptability of Outcomes n 산출물 수용도를 정함 n n Determine Overall Acceptable Level of Risk w Aggregate overall risk exposure for all risk items 전반적인 리스크 수용 가능 수준을 정함 w 제반 리스크 항목에 대한 전반적인 리스크 노출 집계 Compare Estimated Overall Risk to Acceptable Risk Level 전반 추정 리스크를 수용가능 리스크 수준과 비교함. 139

Case Study - Fire Control System 사례 - 화제 제어 시스템 Product Description Displays Using new flat screen technology not yet demonstrated in similar applications. Radar Using proven design currently in use. Integration only. Computer Technology in hand, in use in other systems. Integration only. Software Risk Currently in development. Modifying existing code. Expect some delays. May require re-design of some modules. 140

Comparison to Risk Levels 리스크 수준과 비교 Acceptable 수용가능 w Estimated risk less than acceptable risk. 수용가능 리스크 보다 적은 추정 리스크 w Proceed as planned. 계획대로 진행 Infeasible 실행 불가능 w Estimated risk greater than, but almost equal to acceptable risk. 수 용가능 리스크 보다는 더 크지만 거의 같은 정도의 추정 리스크 w Change plans to avert the risks. 리스크를 피하 기 위한 계획 변경 Impossible 불가능 w Estimated risk much greater than acceptable risk. 수용가능 리스크 보다 훨씬 더 큰 수준의 추정 리스크 w Start planning over again or abandon the project. 계획을 다시 시작 하여 본 프로젝트를 단념. 141

Risk Management 리스크 관리 Definition 정의 w The application of appropriate risk control tools/procedures for the express purpose of containing risk within acceptable limits. w 수용가능 한도내의 리스크를 포함시킬 명백한 목적을 위해 적절한 리스크 제 어 툴/절차를 적용함 Why do Risk Management? 리스크 관리는 왜 하는가 ? w Every project involves risk to some extent. w The competitive process makes it necessary that we take risks. w The probability is high that we have less than a complete understanding of all elements of a project. w 모든 프로젝트에는 어느 정도 리스크가 수반됨. w 본 경쟁적 과정으로 우리가 위험부담이 필요하게 됨. w 우리가 프로젝트의 모든 요소에 대해 완전한 이해를 하지 못할 확률이 높음. It is a very good get that a project will take longer than you think and cost more than you think. 한 프로젝트의 완성은 예상보다 더 오래 걸리고 더 많은 비용이 소요 될 것이라는 것은 매우 올바른 추측이다. 142

Risk Management 리스크 관리 Risk Management is comprised of three activities: 리스크 관리는 3가지 엑티비티로 구성되어 있다: Planning 계획 Monitoring 모니터링 Controlling 콘트롤링 143

Risk Planning 리스크 계획 n n First, determine the appropriate risk management strategy for each risk. 첫째로, 각 위험에 대한 적절한 위험관리 전략을 정한 다. Second, develop the Risk Management Plan. 둘째로, 리스크 관리 계획을 개발한다. 144

Risk Management Strategies 리스크 관리 전략 1. Avoid the Risk 리스크를 피함 w Scope down requirements 철저하게 요구사항 범위를 정함 (? ) w Change level of available resources 가용 리소스 수준을 변경 w Extend the schedule 일정을 늘림 w Bail out 비상사태 구제 2. Transfer the Risk 리스크 이전 w Shift function to hardware 기능을 하드웨어에 전환 w Subcontract 하청 3. Control the Risk 리스크 조절 w Develop risk management plan 리스크 관리 계획 개발 w develop contingency plan 비상계획 개발 145

Risk Management Strategies 리스크 관리 전략 4. Buy Information 정보 매입 w Prototype, model, simulate 프로토 타입, 모델, 모의 w Market survey 시장 조사 5. Assume the Risk 리스크 가정 w Appropriate if risk is low 리스크가 낮으면 적절함 w May require larger management risk reserve 보다 큰 리스크 관리는 유보를 요구할 수 있음. 146

Risk Mitigation 리스크 완화 Risk Mitigation Plan w What do I do to decrease the likelihood of the risk happening? 리스크 완화 계획 w 리스크 발생 가능성을 줄이기 위해 나는 무엇을 할 것인가 ? Risk Contingency Plan w What do I do if the risk occurs? 리스크 비상계획 w 리스크가 발생하면 나는 무엇을 할 것인가 ? 147

Mitigation Approaches Known Risks 리스크 완화 접근방법 - 랄려진 리스크 n n n n Define and classify the known risks, document assumptions. 알려진 리스크를 정의/분류하고 가정을 문서화 함. Include the risk and mitigation plans in the Project Management Plan. 리스크 및 리스크 완화 계획을 PMP에 포함함. Mitigate the high risks as early as possible. 리스크가 높은 것은 가능한 조기에 완화 시킴. Report risk status regularly and obtain customer feedback. 리스크 상태를 정기적으로 보고하고 고객 피드백을 입수함. 148

Mitigation Approaches Predictable Risks 리스크 완화 접근방법 - 예측가능 리스크 n n n Develop a personnel succession/backup plan. 직원 인계/충원 계 획을 개발. Don’t put activities that have risk associated with them on the critical path. 리스크와 관련된 리스크가 있는 엑티비티를 크리티 칼 패스에 두지 않는다. Document change, track cost and schedule impacts. 문서 변경, 비 용추적 및 일정 영향 Define a management reserve. 관리 유보를 정의함. Obtain and retain good customer relationships. 양호한 고객 관계 를 갖고 유지한다. 149

Mitigation Approaches Unpredictable Risks 리스크 완화 접근방법 - 예측불능 리스크 n n n Use information from all sources to move unpredictable risks into predictable category. 모든 소스에서 나오는 정보를 이용하여 예 측 불능 리스크를 예측가능 범주로 옮김. Don’t commit outside the contract, don’t commit to the contract if you can’t do it. 계약 외에는 관여하지 말고 감당할 수 없는 계약 이라면 관여하지 않음. Watch out for shifting risks, i. e. , reducing one risk while elevating others. 리스크 이전 - 즉 다른 리스크가 커지는 동안 한 리스크를 줄임 - 을 살핌. 150

Risk Management Techniques 리스크 관리 기법 1. Personnel Shortfalls 인사 취약점 w Staff with top talent; Teambuilding; Training 고급 재능을 겸비한 직원 ; 팀 구축; 훈련 2. Unrealistic Schedule or Budget, or both 비 현실적 일정 및/또는 예산 w Detailed cost and schedule estimation; Incremental development; reuse 상세 비용 및 일정 추정; 점증적인 개발; 재 사용 3. Don’t Understand or a Misinterpretation of the Requirements 요구사항을 이해 못하거나 잘 못 해석함 w Prototyping; Early user manuals 프로토 타이핑; 초기 사용자 설명서 4. Wrong Interface Definition 잘못된 인터페이스 정의 w Prototyping; Peer reviews 프로토 타이핑; 상호 검토 5. Gold Plating (excessive requirements) Gold Plating (과다 요구사항) w Cost/Benefit analysis; Prototyping 비용-편익 분석; 프로토 타이핑 151

Risk Management Techniques 리스크 관리 기법 6. Requirements Changes 요구사항 변경 w Encapsulation; Information hiding; Incremental development (defer changes to later builds) w 요약; 정보 은폐; 점증적인 개발 (변경을 추후 구조로 ) 7. Problems with Externally Furnished Components EFC 문제 w Inspections; Benchmarking 검사 ; 일반 기준 8. Problems with Externally Performed Tasks (subcontractor) EPT (하청업자) 문제 w Cost Plus contracts; Team building; Prototyping w 비용에 계약 추가; 팀 구축; 프로토 타이핑 9. Shortfalls in Real-time Performance 실시간 실행 단점 w Simulation; Benchmarking; Modeling; Prototyping w 모의; 일반기준; 모델링; 프로토타이핑 10. Straining Computer Science Capabilities CSC에 부담 가중 w Technical analysis; Cost/Benefit analysis; Prototyping w 기술 분석; 비용-편익 분석; 프로토타이핑 152

Risk Management Plan 리스크 관리 계획 Contents of a Risk Management Plan - Answer the Following Questions: 리스크 관리 계획 내용 - 다음 질문에 대답함 n n n n n Why? Risk item importance, relation to project objectives What, When? Deliverables, milestones Who, Where? Ownership, organization How? Risk Approach How much? Resources (budget, schedule, personnel) 왜 ? 프로젝트 목표와 관련하여 리스크 항목의 중요성 무엇을, 언제 ? 인도가능 항목, 이정표 누가, 어디서 ? 소유권, 기관 어떻게 ? 리스크 접근 방법 얼마나 ? 리소스 (예산, 일정, 인원) 153

Risk Management 리스크 관리 Risk Management is comprised of three activities: 리스크 관리는 3 엑티비티로 구성된다 : Planning 계획 Monitoring 모니터링 Controlling 통제 154

Risk Monitoring 리스크 모니터링 n n n Risk monitoring occurs after a Risk Management Plan has been implemented. You want to see if the plan is working. 라스크 모니터링은 RMP 실행 후 실시되며, 이 계획이 제대로 실 행되는지 알고자 할 것임. Goals 목표 : w Verify outcomes were as envisioned. 결과가 구상한 대로인지 검증함. w Identify opportunities for refinement of risk plans. 리스크 계 획 보충 기회를 식별함. w Provide feedback to those making future decisions. 미래 결정 을 할 사람들에게 피드백을 제공 155

Risk Monitoring Techniques 리스크 모니터링 기법 Metrics Collection and Analysis 메트릭 수집 및 분석 w Compare actual data to plans and estimates 실제 자료를 계획 및 추정된 것과 비교 w Detect problems and trends 문제 및 경향 검색 Top 10 Risk Tracking 10가지 리스크 추적 w Weekly status reporting 주별 상황 보고 Formal Reviews (PDR, CDR, TIMS, etc. ) 공식 검토 (PDR, CDR, TIMS 등) w Highlight status of major risks 주요 리스크 상황을 강조 156

Risk Management 리스크 관리 Risk Management is comprised of three activities: Planning Monitoring Controlling 157

Risk Control 리스크 통제 n n n Provide resources required to implement risk planning. 리스크 계획 실행에 요구되는 리소스를 제공 w resolve any resource conflicts 모든 리소스 마찰을 해결 Respond to Risk Monitoring outcomes. 리스크 모니트링 결과에 반응 Document Risk Management Plan changes. 리스크 관리 계획 변 경사항을 문서화 158

Responses to Risk Monitoring Outcomes 리스크 모니터링 결과에 대한 반응 n n Risk item has been resolved. 리스크 항목이 해소되었음 w Risk resolution is complete. 리스크 해소완결 Risk control activities track to Risk Management Plan 리스크 조절 엑 티비티의 RMP (까지)추적 w Continue risk control activities as planned. 리스크 통제 엑티비티를 계획대로 계속함. Some risk control activities do not track to Risk Management Plan. 일부 리스크 통제 엑티비티는 RMP까지 추적하지 않음 w Determine corrective actions. 개선 액션을 정함 Significant changes to one or more risk items. 한 개 이상의 리스크 항목 으로 상당히 전환됨 w Analyze risk item, adjust plans accordingly. 리스크 항목을 분석하고 이에 따라 계획을 조정할 것. 159

Project Planning n Overview n Defining the Work n Risk Engineering n Documenting the Plan 160

Software Development Plan A formal, approved document used to guide the project execution and project control. n 프로젝트 실행 및 프로젝트 통제 방향 제시를 위해 사용되는 공식 인증 서류 n The plan is used to 본 계획은 w ensure we have identified all activities. w ensure that resources are alllocated to the activities. w identify and manage risks. w provide a road map for the software team to follow. w to measure performance. w 모든 엑티비티가 식별되었음을 확실하게 해 주고 w 리소스가 엑티비티에 배분되었음을 확실하게 해주고 w 리스크를 식별하며 관리하고 w 후속 소프트웨어 팀에게 도로 지도를 제공하고 w 실적 측정을 위해 사용된다. n 161

Contents 내용 Overview Section 개요 란 w Identification of the system and software 체계 및 소프트웨어 식별 Purpose of the software 소프트웨어 목적 w Scope of the SDP 범위 Management Section 관리 란 w Schedule 일정 w Facilities 설비 w Risks and mitigation strategies 리스크 및 리스크 완화 전략 w Reviews 검토 w Metrics 메트릭스 162

Contents - cont. 내용 - 계속 Technical Section 기술 란 w Software Engineering Environment 소프트웨어 엔지니어링 환경 w Life cycle 수명 주기 w Methodologies and techniques 일련의 방법 및 기법 w Software Development Folders 소프트웨어 개발 폴더 Software Configuration Management Plan (optional) 소프트웨어 구성 관리 계획 (선택) Software Quality Program Plan (optional) 소프트웨어 품질 프로그램 계획 (선택) 163