unit - iii

75
UNIT - III UNIT - III Project Monitoring and Project Monitoring and Control Control

Upload: yadid

Post on 18-Mar-2016

78 views

Category:

Documents


1 download

DESCRIPTION

UNIT - III. Project Monitoring and Control. Dimensions of Project Monitoring & Control. Software Project: Project is a planned, non-routine activity, designed and implemented to achieve a predefined objective in a given time span. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: UNIT -  III

UNIT - IIIUNIT - III Project Monitoring and Project Monitoring and

ControlControl

Page 2: UNIT -  III

Dimensions of Project Monitoring Dimensions of Project Monitoring & Control& Control

Software Project: Project is a planned, non-routine activity, designed and implemented to achieve a predefined objective in a given time span.

Monitoring – collecting, recording, and reporting information concerning project performance that project manger and others wish to know.

Page 3: UNIT -  III

Project controlProject control

Controlling – -Uses data from monitor activity to bring actual performance to planned performance.

Software =Software = Program + Operating Program + Operating Procedures Procedures + + Documentation Manuals Documentation Manuals

Page 4: UNIT -  III

4

Project Control Cycle

PLANSpecificationsProject ScheduleProject budgetResource planVendor contracts

MONITORRecord statusReport progressReport cost

COMPAREActual status against plan-Schedule-Cost

ACTION

Correct deviations from plan

RE-PLAN as necessary

Page 5: UNIT -  III

Techniques for monitoring and control

Earned Value AnalysisCritical Ratio

Page 6: UNIT -  III

Earned Value Earned Value AnalysisAnalysis

Page 7: UNIT -  III

Earn Value AnalysisA way of measuring overall performance (not individual task) is using an aggregate performance measure - Earned ValueEarned value of work performed (value completed) for those tasks in progress found by multiplying the estimated percent physical completion of work for each task by the planned cost for those tasks. The result is amount that should be spent on the task so far. This can be compared with actual amount spent.

Page 8: UNIT -  III

Earn Value AnalysisMethods for estimating percent completion-

The 50-50 estimate. 50% is assumed when task is begun, and remaining 50% when work completed.0-100% rule. This rule allows no credit for work until task is complete, highly conservative rule, project always seem late until the very end of project when everything appears to suddenly catch upCritical input rule. This rule assigns progress according to amount of critical input that has been used. Labor or skilled dependent, machine critical input – buy machine complete task – may be misinformationProportional rule. This rule divides planned (or actual) time-to-date by total scheduled time(or budgeted (or actual ) cost-to-date by total budgeted cast] to calculate percent complete. This is commonly used rule.

Page 9: UNIT -  III

What is Earned Value Management (EVM)?

• A method of integrating scope, schedule, and resources, and for measuring project performance.

• It compares the amount of work that was planned with what was actually earned with what was actually spent to determine if cost and schedule performance are as planned.

Earned Value Analysis

Page 10: UNIT -  III

What is needed for EVM?• A baseline plan• A project budget

• (BAC – Budget at Completion)• A project end date• Tasks are identified & scheduled• Each task has a budget or effort

• (resource loaded / weighting)• Actuals tracked

Earned Value Analysis

Page 11: UNIT -  III

To Perform EVM, three values need to be determined

• Planned Value (PV or BCWS)

• Actual Costs (AC or ACWP)

• Earned Value (EV or BCWP)

Earned Value Analysis

Page 12: UNIT -  III

Planned Value (PV)“What are the budgeted costs of the work scheduled”?

•Time phased based on baseline budget.

•Only changes when baseline is changed.

•Also referred as “BCWS” & “BAC”.

Earned Value Management

Page 13: UNIT -  III

Earned Value Management

Actual Costs (AC)“What are the actual costs of the work performed”?

•Based on the actual completion of work packages.

•Actual costs for reported work.

•Also referred as “ACWP”.

Page 14: UNIT -  III

Earned Value Management

Earned Value (EV)“What are the budgeted costs of the work performed”?

•Based on the actual completion of work packages

•Baseline value of the reported work

•Also referred as “BCWP”

Page 15: UNIT -  III

Terms in EV AnalysisEAC: Independent Estimate at Completion AC : Actual Cost PF: Performance Factor BAC: Budget at Completion EV: Earned Value CPI: Cost Performance Index

[CPI = EV / AC] SPI: Schedule Performance Index

[SPI = EV / PV] CPIx = Value of CPI for last x periods

Page 16: UNIT -  III

Formulae in EV AnalysisCV=[EV-AC]

SV=[EV-PV]

CPI=[EV/AC]

SPI=[EV/PV]

EAC=[BAC/CPI]

ETC=[EAC-AC]

VAC=[BAC-EAC]

When memorizing theformulas I have found it best to look for patterns. When I see the correct pattern I know the formula is correct.AC = ACWPPV = BCWSEV = BCWP

Page 17: UNIT -  III

Earned Value Management Example

Task – Drill & install 10 piezometers• Budget - $100,000 ($10K per piezometer)• Time – 10 weeks (1 piezometer per week)Progress Report At week 5:

• 4 piezometers drilled and installed• $47,500 spent to date

PV = $50,000

AC = $47,500

EV = $40,000

Page 18: UNIT -  III

Calculating Earned Value and interpreting results

• to measure the progress of the project

• help identify trends

• forecast costs

• and identify ways to correct/mitigate project pitfalls.

Earned Value Management

Page 19: UNIT -  III

Cost Variance (CV)

CV = EV - AC

•Good News: If CV value is positive, the project is currently under budget (spending less than planned for the work)

•Bad News: If CV value is negative, the project is currently over budget (spending more than planned for the work)

Earned Value Management

Page 20: UNIT -  III

Earned Value Management

Cost Performance Index (CPI)

CPI = EV / AC•Good News: If CPI value is >1 or =1, the project cost trend is currently under or at planned budget

•Bad News: If CPI value <1, the project cost trend is currently over budget

Page 21: UNIT -  III

Earned Value Management

Cost Variance % (CV%)

CV% = CV / EV

•Good News: If CV% value is positive, the project is currently under budget by the CV%

•Bad News: If CV% value is negative, the project is currently over budget by the CV%

Page 22: UNIT -  III

Earned Value Management

Schedule Variance (SV)

SV = EV - PV

•Good News*: If SV value is positive, the project is currently ahead of schedule

•Bad News: If SV value is negative, the project is currently behind schedule

* - not all positive SVs are good

Page 23: UNIT -  III

Earned Value Management

Schedule Performance Index (SPI)

SPI = EV / PV•Good News: If SPI value is >1 or =1, the project schedule trend is currently ahead or on planned schedule

•Bad News: If SPI value <1, the project schedule trend is currently behind schedule

Page 24: UNIT -  III

Earned Value Management

Schedule Variance % (SV%)

SV% = SV / PV

•Good News: If SV value is positive, the project is currently ahead of schedule

•Bad News: If SV value is negative, the project is currently behind schedule

Page 25: UNIT -  III

Earned Value Management

Estimate at Completion (EAC)

#1Actual costs to date plus a new estimate for all remaining work (original plan no longer valid)

EAC = AC + ETC(ETC Estimate to Complete)

Page 26: UNIT -  III

Earned Value Management

Actual costs to date plus remaining budget (current variances are viewed as atypical of future variances)

EAC = AC + BAC - EV

Estimate at Completion (EAC)

#2

Page 27: UNIT -  III

Earned Value Management

Estimate at Completion (EAC)

#3 & #4Actual costs to date plus remaining budget modified by a performance factor (CPI) (current variances are viewed as typical of future variances).

EAC = AC + [(BAC - EV) / CPI]

EAC = BAC / CPI

Page 28: UNIT -  III

Earned Value Scenario

Page 29: UNIT -  III

Earned Value Scenario

Page 30: UNIT -  III

Earned Value Scenario

Page 31: UNIT -  III

Earned Value Scenario

Page 32: UNIT -  III

Earned Value Scenario

BAC = $100,000 (current project budget)

EV = $42,000 (42% of project completed, $100,000 planned)

PV = $56,000 (56% of project planned $100,000 completed – initial aging report)

AC = $48,000 (from actual expenditures reporting)

Is this project on schedule / budget? Or is it in trouble?

Page 33: UNIT -  III

Earned Value Scenario

Cost Variance (CV):CV = EV – AC = $42,000 - $48,000 = - $6,000

Cost Performance Index (CPI):CPI = EV / AC = $42,000 / $48,000 = 0.875

Cost Variance % (CV%):CV% = CV / EV = - $6,000 / $42,000 = 14% OVER BUDGET

Page 34: UNIT -  III

Earned Value Scenario

Schedule Variance (SV):SV = EV – PV = $42,000 - $56,000 = - $14,000

Schedule Performance Index (SPI):SPI = EV / PV = $42,000 / $56,000 = 0.750

Schedule Variance % (SV%):SV% = SV / PV = - $14,000 / $56,000 = 25% BEHIND SCHEDULE

Page 35: UNIT -  III

Earned Value Scenario

Estimate at Completion (EAC):Method #1:EAC = AC + ETC (say $68,000) = $48,000 + $68,000 = $116,000(Change Management for $16,000 funds request)

Method #2:EAC = AC + BAC – EV = $48,000 + $100,000 - $42,000 = $106,000(Change Management for $6,000 funds request)

Page 36: UNIT -  III

Earned Value Scenario

Estimate to Complete (ETC):Method #3EAC = AC + [(BAC – EV) / CPI] = $48,000 + [($100,000 - $42,000) / 0.875] = $48,000 + $66,285 = $114,285(Change Management for $14,285 funds request)

Method #4EAC = BAC / CPI = $100,000 / 0.875 = $114,285(Change Management for $14,285 funds request)

Page 37: UNIT -  III

Earned Value Scenario

Page 38: UNIT -  III
Page 39: UNIT -  III
Page 40: UNIT -  III
Page 41: UNIT -  III
Page 42: UNIT -  III

Budget Management

Module 6 Exercise• Work as a team to perform EVM on

assigned project on page 69.

• Prepare a report similar to the module scenario reporting project progress.

• Brief class on methods of recovery, if needed, for project.

Page 43: UNIT -  III

Budget Management

Graphing Earned Value exercise• Gantt chart baseline (report)

• EVM graph

• Task information

• Cost distribution

• EVM worksheets

Page 44: UNIT -  III

Budget Management

Graphing Earned Value exercise• Planned Value (PV) is always shown

in blue with circle nodes

• Actual Cost (AC) is always shown in red with square nodes

• Earned Value (EV) is always shown in green with triangle nodes

Page 45: UNIT -  III

Budget Management

Graphing Earned Value exercise• Work together as a team to calculate the

task cost (task budget) for each task

• Record these values on the worksheet with the total (BAC) calculated

• Warning: Wait to plot on the EVM graph as a class – we will use the Cost Distribution Report

Page 46: UNIT -  III

1w 2w 3w 4w 5w 6w 7w 8w 9w 10w

$10K

$20K

$30K

$40K

$50K

$60K

Page 47: UNIT -  III

Budget Management

Graphing Earned Value – week 1• Task A started on time – 30% complete

• Task B started 2 days late – 30% complete

• Task C started 1 day late – 25% complete

• Tasks D, E, F, G, H, and J have not started

• Project Management is on-going

• Actual Costs reported for week 1 = $5000

Page 48: UNIT -  III

1w 2w 3w 4w 5w 6w 7w 8w 9w 10w

$10K

$20K

$30K

$40K

$50K

$60K

Page 49: UNIT -  III

1w 2w 3w 4w 5w 6w 7w 8w 9w 10w

$10K

$20K

$30K

$40K

$50K

$60K

Schedule Variance

Cost Variance

Page 50: UNIT -  III

Error TrackingAllows comparison of current work to past projects and provides a quantitative indication of the quality of the work being conducted.The more quantitative the approach to project tracking and control, the more likely problems can be anticipated and dealt with in a proactive manner.

Page 51: UNIT -  III

51

ReviewsConducting reviews of requirements, design, and code is one of the best ways to improve your work’s quality and your productivityHere we’ll look at various types of reviews and how to document them

Page 52: UNIT -  III

INFO636 Week #8 52

ReviewsReview types, in descending order of formality, include

Inspections Walk-throughsPersonal reviews

Page 53: UNIT -  III

53

InspectionsInspections follow a structured procedure for evaluating a work product

Fagan inspections are among the best known brand of inspection

Inspections start with preparation, where each participant reviews the work separately, and makes note of defects found

Page 54: UNIT -  III

54

InspectionsThen there’s an inspection meeting to discuss the findings of each participant, and put together a cumulative list of defectsThen the work product owner fixes the defects, and puts together a report to say so, in the repair and report phase

Page 55: UNIT -  III

55

Walk-throughsWalk-throughs require little preparation, except by the work product ownerA presentation is given, and participants provide feedback during itFollow-up is informal, with the work product owner responding to the comments received

Page 56: UNIT -  III

56

Personal reviewsPersonal review is the work product owner reviewing their own stuffAs compiling code has gotten trivially easy, many programmers have dropped reviewing their own work in the hopes that the computer will find their mistakes

Not a good strategy!

Page 57: UNIT -  III

57

Target of ReviewsAny work product can be the subject of reviews

Any documentRequirements specificationDesign modelsTest plansInternal project processes & procedures

Source codeScripts too!

Page 58: UNIT -  III

58

CommentaryFor those taking INFO 637, the Team Software Process uses formal reviews extensively, so pay extra attention!N track people - while the text obviously focuses on reviews related to code, keep in mind that these methods and tools for reviews can be used to plan and conduct reviews for anything

Page 59: UNIT -  III

59

Why Review Software?The history of the PSP has shown that most people

Initially spend much of their time (30-50%) in compiling and testingBy the end of this course, only about 10% of their time is spent testing

Good reviews are a key to reducing testing time

Page 60: UNIT -  III

60

Review EfficiencyFinding and fixing defects is much faster to do in review than in testing

Humphrey found 8x faster fix time in review than testing

Code reviews are 3-5 times as efficient at finding defects than testing

Part of the reason is that testing finds symptoms of the defect, which has to be investigated by debugging

Page 61: UNIT -  III

61

Severity of Review We don’t mean to imply that every piece of code needs exhaustive reviewDifferent approaches can be used, depending on the complexity, risk, and importance of the code

Hence you might use inspections for critical code, walk-throughs for typical code, and just personal review for low risk code

Page 62: UNIT -  III

62

Review PrinciplesAny kind of review process typically follows three principles

Establish defined review goalsFollow a defined process for conducting a review (here, we’ll use scripts)Measure and improve your review process

Page 63: UNIT -  III

63

Separate Design and Code Reviews

Design and code should be reviewed separately

Forces making a design before codingIt’s hard to decipher design from the codeHelps spot logic errors in design, and identify design improvementsHelps focus review scope

Page 64: UNIT -  III

64

Design ReviewsMake your design reviewable

Follow a standard notation for design, such as UML, DFD, ERD, etc.Make sure design addresses both functional and non-functional requirementsFollow personal design standards, hopefully in concert with organizational standards

Page 65: UNIT -  III

65

Design ReviewsFollow a design review strategy

Look at various elements of design systematically – don’t try to assess it all at once

Design review strategy stages might include

Check for required program elements

Page 66: UNIT -  III

66

Design ReviewsExamine overall program structure and flow Check for logical completenessCheck for robustness - handling errors, etc.Check parameters and types for methods and procedure callsCheck special variables, data types, and files, including aliases

Page 67: UNIT -  III

67

Design ReviewsCheck design against the requirementsMore elaborate inspections might use

A traceability matrix to prove completeness, or Use formal methods (Z, Larch) to show correctness mathematically

Page 68: UNIT -  III

68

Measuring ReviewsKey basic measures for reviews are

Size of product being reviewed (in pages or LOC)The review time, in minutesThe number of defects foundAnd based on later work, the defects that weren’t found by the review

Page 69: UNIT -  III

69

Measuring ReviewsDerived metrics for reviews are

Review yield, the percent of defects found by review

Yield = 100*(defects found) / (defects found + defects not found)

Number of defects found per kLOC or pageNumber of defects found per hour of review time

Page 70: UNIT -  III

70

Measuring ReviewsThe number of LOC or pages reviewed per hourDefect Removal Leverage (DRL)

The ratio of defects removed per hour for any two phases or activities

DRL(coding) = Defects/hour(coding)/ Defects/hour(design)

Page 71: UNIT -  III

71

ChecklistsChecklists are used to help make sure a process or procedure is followed consistently each timeA sample code review checklist for C++ is on variations can be developed for other languages.

It has several blank columns so each module can be checked off separately

Page 72: UNIT -  III

72

Designing ChecklistsChecklists should be designed so that you have to focus on only one topic at a time

Similar to reviewing a book for grammar versus plot development – it’s hard to look for both at once

To use a checklist most effectively, completely review one module

Page 73: UNIT -  III

73

Using ChecklistsDifferent strategies should be considered for different types of reviews

Design review for a large application might prefer to be from the top downCode review often works better from the bottom up for your code, but top down for someone else’s

Page 74: UNIT -  III

74

Building ChecklistsDon’t take the example as the ultimate final perfect most-wonderful-of-all checklist that ever was *breathe*

Study the kinds of problems you encounter (in your defect log) to see what you need to emphasize in your checklist

Page 75: UNIT -  III

75

Building ChecklistsThe types of defects are given again, consider adapting this to your needs and other languagesOne way to look for your most common types of defects is to lump all your defect logs together, and generate a Pareto chart by defect type