cosc 4406 software engineering

45
1 COSC 4406 COSC 4406 Software Engineering Software Engineering Haibin Zhu, Ph.D. Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Dept. of Computer Science and mathematics, Nipissing University, 100 College Dr., North Bay, Nipissing University, 100 College Dr., North Bay, ON P1B 8L7, Canada, ON P1B 8L7, Canada, [email protected] , , http://www.nipissingu.ca/faculty/haibinz http://www.nipissingu.ca/faculty/haibinz

Upload: jael

Post on 22-Jan-2016

49 views

Category:

Documents


0 download

DESCRIPTION

COSC 4406 Software Engineering. Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100 College Dr., North Bay, ON P1B 8L7, Canada, [email protected] , http://www.nipissingu.ca/faculty/haibinz. Lecture 17 Project Estimation and Scheduling. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: COSC 4406 Software Engineering

1

COSC 4406COSC 4406

Software Software EngineeringEngineering

Haibin Zhu, Ph.D.Haibin Zhu, Ph.D.Dept. of Computer Science and mathematics, Nipissing University, Dept. of Computer Science and mathematics, Nipissing University,

100 College Dr., North Bay, ON P1B 8L7, Canada, 100 College Dr., North Bay, ON P1B 8L7, Canada, [email protected], http://www.nipissingu.ca/faculty/haibinz, http://www.nipissingu.ca/faculty/haibinz

Page 2: COSC 4406 Software Engineering

2

Lecture 17Lecture 17 Project Estimation and Project Estimation and

SchedulingScheduling

Page 3: COSC 4406 Software Engineering

3

Software Project Software Project PlanningPlanning

The overall goal of project planning is to The overall goal of project planning is to establish a pragmatic strategy for establish a pragmatic strategy for controlling, tracking, and monitoring a controlling, tracking, and monitoring a complex technical project.complex technical project.

Why?Why?

So the end result gets done on time, with So the end result gets done on time, with quality!quality!

Page 4: COSC 4406 Software Engineering

4

Project Planning Task Set-IProject Planning Task Set-I

Establish project scopeEstablish project scope Determine feasibilityDetermine feasibility Analyze risksAnalyze risks

Risk analysis is considered in detail in Chapter 25.Risk analysis is considered in detail in Chapter 25. Define required resourcesDefine required resources

Determine require human resourcesDetermine require human resources Define reusable software resourcesDefine reusable software resources Identify environmental resourcesIdentify environmental resources

Page 5: COSC 4406 Software Engineering

5

Project Planning Task Set-IIProject Planning Task Set-II

Estimate cost and effortEstimate cost and effort Decompose the problemDecompose the problem Develop two or more estimates using size, function Develop two or more estimates using size, function

points, process tasks or use-casespoints, process tasks or use-cases Reconcile the estimatesReconcile the estimates

Develop a project scheduleDevelop a project schedule Scheduling is considered in detail in Chapter 24.Scheduling is considered in detail in Chapter 24.

Establish a meaningful task setEstablish a meaningful task set Define a task networkDefine a task network Use scheduling tools to develop a timeline chartUse scheduling tools to develop a timeline chart Define schedule tracking mechanismsDefine schedule tracking mechanisms

Page 6: COSC 4406 Software Engineering

6

EstimationEstimation

Estimation of resources, cost, and schedule for a Estimation of resources, cost, and schedule for a software engineering effort requires software engineering effort requires experienceexperience access to good historical information (metricsaccess to good historical information (metrics the courage to commit to quantitative predictions when the courage to commit to quantitative predictions when

qualitative information is all that existsqualitative information is all that exists Estimation carries inherent risk and this risk Estimation carries inherent risk and this risk

leads to uncertaintyleads to uncertainty

Page 7: COSC 4406 Software Engineering

7

Write it Down!Write it Down!

SoftwareSoftwareProjectProject

PlanPlan

Project ScopeProject ScopeEstimatesEstimatesRisksRisksScheduleScheduleControl strategyControl strategy

Page 8: COSC 4406 Software Engineering

8

To Understand Scope ...To Understand Scope ...

Understand the customers needsUnderstand the customers needs understand the business contextunderstand the business context understand the project boundariesunderstand the project boundaries understand the customer’s understand the customer’s

motivationmotivation understand the likely paths for understand the likely paths for

changechange understand that ...understand that ...Even when you understand,Even when you understand,

nothing is guaranteed!nothing is guaranteed!

Page 9: COSC 4406 Software Engineering

9

What is Scope?What is Scope?

Software scopeSoftware scope describes describes the functions and features that are to be delivered to the functions and features that are to be delivered to

end-usersend-users the data that are input and outputthe data that are input and output the “content” that is presented to users as a the “content” that is presented to users as a

consequence of using the softwareconsequence of using the software the performance, constraints, interfaces, and reliability the performance, constraints, interfaces, and reliability

that that boundbound the system. the system. Scope is defined using one of two techniques:Scope is defined using one of two techniques:

A narrative description of software scope is developed A narrative description of software scope is developed after communication with all stakeholders.after communication with all stakeholders.

A set of use-cases is developed by end-users.A set of use-cases is developed by end-users.

Page 10: COSC 4406 Software Engineering

10

ResourcesResources

project

people

skills

number

location

reusable software

OTS components

full-experience components

new components

part.-experience components

environment

hardware

software tools

network resources

Page 11: COSC 4406 Software Engineering

11

Project EstimationProject Estimation

Project scope must be understoodProject scope must be understood Elaboration (decomposition) is Elaboration (decomposition) is

necessarynecessary Historical metrics are very helpfulHistorical metrics are very helpful At least two different techniques At least two different techniques

should be usedshould be used Uncertainty is inherent in the processUncertainty is inherent in the process

Page 12: COSC 4406 Software Engineering

12

Estimation TechniquesEstimation Techniques Past (similar) project experiencePast (similar) project experience Conventional estimation techniquesConventional estimation techniques

task breakdown and effort estimatestask breakdown and effort estimates size (e.g., FP) estimatessize (e.g., FP) estimates

Empirical modelsEmpirical models Automated toolsAutomated tools

Page 13: COSC 4406 Software Engineering

13

Estimation AccuracyEstimation Accuracy

Predicated on …Predicated on … the degree to which the planner has properly estimated

the size of the product to be built the ability to translate the size estimate into human

effort, calendar time, and dollars (a function of the availability of reliable software metrics from past projects)

the degree to which the project plan reflects the abilities of the software team

the stability of product requirements and the environment that supports the software engineering effort.

Page 14: COSC 4406 Software Engineering

14

Functional DecompositionFunctional Decomposition

functional functional decompositiondecomposition

StatementStatementofof

ScopeScope Perform a Perform a Grammatical “parse”Grammatical “parse”

Page 15: COSC 4406 Software Engineering

15

Conventional Methods:Conventional Methods:LOC/FP ApproachLOC/FP Approach

compute LOC/FP using estimates of compute LOC/FP using estimates of information domain valuesinformation domain values

use historical data to build estimates for use historical data to build estimates for the projectthe project

Page 16: COSC 4406 Software Engineering

16

Example: LOC Example: LOC ApproachApproach

Average productivity for systems of this type = 620 Average productivity for systems of this type = 620 LOC/pm. LOC/pm.

Burdened labor rate =$8000 per month, the cost per Burdened labor rate =$8000 per month, the cost per line of code is approximately $13. line of code is approximately $13.

Based on the LOC estimate and the historical Based on the LOC estimate and the historical productivity data, the total estimated project cost is productivity data, the total estimated project cost is $431,000 and the estimated effort is 54 person-$431,000 and the estimated effort is 54 person-months.months.

Page 17: COSC 4406 Software Engineering

17

Example: FP ApproachExample: FP Approach

The estimated number of FP is derived:The estimated number of FP is derived:FPFPestimatedestimated = count-total = count-total 33 [0.65 + 0.01 [0.65 + 0.01 33 SS (F (Fii)])]

FPFPestimatedestimated = 375 = 375

organizational average productivity = 6.5 FP/pm. organizational average productivity = 6.5 FP/pm. burdened labor rate = $8000 per month, the cost per FP is burdened labor rate = $8000 per month, the cost per FP is approximately $1230. approximately $1230. Based on the FP estimate and the historical productivity data, Based on the FP estimate and the historical productivity data, the total the total estimated project cost is $461,000 and the estimated effort is 58 person-estimated project cost is $461,000 and the estimated effort is 58 person-monthsmonths..

Page 18: COSC 4406 Software Engineering

18

Process-Based EstimationProcess-Based EstimationObtained from “process framework”Obtained from “process framework”

applicationapplicationfunctionsfunctions

framework activitiesframework activities

Effort required to Effort required to accomplishaccomplisheach framework each framework activity for each activity for each application functionapplication function

Page 19: COSC 4406 Software Engineering

19

Process-Based Estimation Process-Based Estimation ExampleExample

Activity

Task

Function

UICF2DGA3DGA

DSMPCF

CGDF

DAM

Totals

% effort

CC PlanningRisk

Analysis EngineeringConstruction

Release TotalsCE

analysis design code test

0.25 0.25 0.25 3.50 20.50 4.50 16.50 46.00

1% 1% 1% 8% 45% 10% 36%

CC = customer communication CE = customer evaluation

0.50

0.750.500.50

0.500.25

2.50

4.004.003.00

3.002.00

0.40

0.601.001.00

0.750.50

5.002.003.001.501.501.50

8.40

7.358.506.00

5.754.25

0.50 2.00 0.50 2.00 5.00

n/an/an/an/an/an/an/a

Based on an average burdened labor rate of $8,000 per Based on an average burdened labor rate of $8,000 per month, the total estimated project cost is $368,000 and the month, the total estimated project cost is $368,000 and the estimated effort is 46 person-months.estimated effort is 46 person-months.

Page 20: COSC 4406 Software Engineering

20

Tool-Based EstimationTool-Based Estimation

project characteristicsproject characteristics

calibration factorscalibration factors

LOC/FP dataLOC/FP data

Page 21: COSC 4406 Software Engineering

21

Estimation with Use-CasesEstimation with Use-Cases

use cases scenarios pages Êscenarios pages LOC LOC estimatee subsystem 6 10 6 Ê 12 5 560 3,366subsystem group 10 20 8 Ê 16 8 3100 31,233e subsystem group 5 6 5 Ê 10 6 1650 7,970

Ê Ê Ê Êstimate Ê Ê Ê Ê 42,568

User interface subsystem Engineering subsystem group Infrastructure subsystem group

Total LOC estimate

Using 620 LOC/pm as the average productivity for systems Using 620 LOC/pm as the average productivity for systems of this type and a burdened labor rate of $8000 per month, of this type and a burdened labor rate of $8000 per month, the cost per line of code is approximately $13. Based on the the cost per line of code is approximately $13. Based on the use-case estimate and the historical productivity data, the use-case estimate and the historical productivity data, the total estimated project cost is $552,000 and the estimated total estimated project cost is $552,000 and the estimated effort is 68 person-months.effort is 68 person-months.

Page 22: COSC 4406 Software Engineering

22

Empirical Estimation Empirical Estimation ModelsModels

General form:General form:

effort = tuning coefficient * sizeeffort = tuning coefficient * sizeexponentexponent

usually derivedusually derivedas person-monthsas person-monthsof effort requiredof effort required

either a constant oreither a constant ora number derived based a number derived based on complexity of projecton complexity of project

usually LOC butusually LOC butmay also bemay also befunction pointfunction point

empiricallyempiricallyderivedderived

Page 23: COSC 4406 Software Engineering

23

COCOMO-IICOCOMO-II

COCOMO II is actually a hierarchy of estimation COCOMO II is actually a hierarchy of estimation models that address the following areas:models that address the following areas:

Application composition model.Application composition model. Used during the early Used during the early stages of software engineering, when prototyping of user stages of software engineering, when prototyping of user interfaces, consideration of software and system interfaces, consideration of software and system interaction, assessment of performance, and evaluation of interaction, assessment of performance, and evaluation of technology maturity are paramount.technology maturity are paramount.

Early design stage model.Early design stage model. Used once requirements have Used once requirements have been stabilized and basic software architecture has been been stabilized and basic software architecture has been established.established.

Post-architecture-stage model.Post-architecture-stage model. Used during the Used during the construction of the software.construction of the software.

Page 24: COSC 4406 Software Engineering

24

The Software EquationThe Software EquationA dynamic multivariable modelA dynamic multivariable model

E = [LOC x BE = [LOC x B0.3330.333/P]/P]33 x (1/t x (1/t44))

where where E = effort in person-months or person-yearsE = effort in person-months or person-yearst = project duration in months or yearst = project duration in months or yearsB = “special skills factor”B = “special skills factor”P = “productivity parameter”P = “productivity parameter”

Page 25: COSC 4406 Software Engineering

25

Estimation for OO Projects-IEstimation for OO Projects-I Develop estimates using effort decomposition, FP analysis, and Develop estimates using effort decomposition, FP analysis, and

any other method that is applicable for conventional applications.any other method that is applicable for conventional applications. Using object-oriented analysis modeling (Chapter 8), develop use-Using object-oriented analysis modeling (Chapter 8), develop use-

cases and determine a count. cases and determine a count. From the analysis model, determine the number of key classes From the analysis model, determine the number of key classes

(called analysis classes in Chapter 8).(called analysis classes in Chapter 8). Categorize the type of interface for the application and develop a Categorize the type of interface for the application and develop a

multiplier for support classes:multiplier for support classes: Interface typeInterface type MultiplierMultiplier No GUINo GUI 2.0 2.0 Text-based user interfaceText-based user interface 2.25 2.25 GUIGUI 2.5 2.5 Complex GUIComplex GUI 3.0 3.0

Page 26: COSC 4406 Software Engineering

26

Estimation for OO Projects-IIEstimation for OO Projects-II

Multiply the number of key classes (step 3) by the Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support multiplier to obtain an estimate for the number of support classes.classes.

Multiply the total number of classes (key + support) by the Multiply the total number of classes (key + support) by the average number of work-units per class. Lorenz and Kidd average number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days per class.suggest 15 to 20 person-days per class.

Cross check the class-based estimate by multiplying the Cross check the class-based estimate by multiplying the average number of work-units per use-caseaverage number of work-units per use-case

Page 27: COSC 4406 Software Engineering

27

Estimation for Agile ProjectsEstimation for Agile Projects Each user scenario (a mini-use-case) is considered separately for Each user scenario (a mini-use-case) is considered separately for

estimation purposes.estimation purposes. The scenario is decomposed into the set of software engineering The scenario is decomposed into the set of software engineering

tasks that will be required to develop it.tasks that will be required to develop it. Each task is estimated separately. Note: estimation can be based Each task is estimated separately. Note: estimation can be based

on historical data, an empirical model, or “experience.”on historical data, an empirical model, or “experience.” Alternatively, the ‘volume’ of the scenario can be estimated in LOC, Alternatively, the ‘volume’ of the scenario can be estimated in LOC,

FP or some other volume-oriented measure (e.g., use-case count).FP or some other volume-oriented measure (e.g., use-case count). Estimates for each task are summed to create an estimate for the Estimates for each task are summed to create an estimate for the

scenario.scenario. Alternatively, the volume estimate for the scenario is translated into Alternatively, the volume estimate for the scenario is translated into

effort using historical data.effort using historical data. The effort estimates for all scenarios that are to be implemented The effort estimates for all scenarios that are to be implemented

for a given software increment are summed to develop the effort for a given software increment are summed to develop the effort estimate for the increment.estimate for the increment.

Page 28: COSC 4406 Software Engineering

28

The Make-Buy DecisionThe Make-Buy Decision

system Xsystem Xreusereuse

simple (0.30)simple (0.30)

difficult (0.70)difficult (0.70)

minorminor changeschanges

(0.40)(0.40)

majormajorchangeschanges

(0.60)(0.60)

simple (0.20)simple (0.20)

complex (0.80)complex (0.80)

majormajor changeschanges (0.30)(0.30)

minorminor changeschanges

(0.70)(0.70)

$380,000$380,000

$450,000$450,000

$275,000$275,000

$310,000$310,000

$490,000$490,000

$210,000$210,000

$400,000$400,000

buybuy

contractcontract

without changes (0.60)without changes (0.60)

with changes (0.40)with changes (0.40)

$350,000$350,000

$500,000$500,000

buildbuild

Page 29: COSC 4406 Software Engineering

29

Computing Expected CostComputing Expected Cost

(path probability) x (estimated path cost) (path probability) x (estimated path cost) ii ii

For example, the expected cost to build is:For example, the expected cost to build is:

expected cost = 0.30 ($380K) + 0.70 ($450K) expected cost = 0.30 ($380K) + 0.70 ($450K)

similarly,similarly,

expected cost = expected cost = $382K$382Kexpected cost = expected cost = $267K$267Kexpected cost = expected cost = $410K$410K

buildbuild

reureusesebubuyyconcontrtr

expected cost =expected cost =

= $429 K= $429 K

Page 30: COSC 4406 Software Engineering

30

Why Are Projects Late?Why Are Projects Late? an unrealistic deadline established by someone outside the an unrealistic deadline established by someone outside the

software development groupsoftware development group changing customer requirements that are not reflected in changing customer requirements that are not reflected in

schedule changes;schedule changes; an honest underestimate of the amount of effort and/or the an honest underestimate of the amount of effort and/or the

number of resources that will be required to do the job;number of resources that will be required to do the job; predictable and/or unpredictable risks that were not predictable and/or unpredictable risks that were not

considered when the project commenced;considered when the project commenced; technical difficulties that could not have been foreseen in technical difficulties that could not have been foreseen in

advance;advance; human difficulties that could not have been foreseen in human difficulties that could not have been foreseen in

advance;advance; miscommunication among project staff that results in delays;miscommunication among project staff that results in delays; a failure by project management to recognize that the project a failure by project management to recognize that the project

is falling behind schedule and a lack of action to correct the is falling behind schedule and a lack of action to correct the problemproblem

Page 31: COSC 4406 Software Engineering

31

Scheduling PrinciplesScheduling Principles

compartmentalizationcompartmentalization—define distinct tasks—define distinct tasks interdependencyinterdependency—indicate task —indicate task

interrelationship interrelationship effort validationeffort validation—be sure resources are —be sure resources are

availableavailable defined responsibilitiesdefined responsibilities—people must be —people must be

assignedassigned defined outcomesdefined outcomes—each task must have an —each task must have an

outputoutput defined milestonesdefined milestones—review for quality—review for quality

Page 32: COSC 4406 Software Engineering

32

Effort and Delivery TimeEffort and Delivery Time

Effort Cost

Impossible region

td

Ed

Tmin = 0.75T d

to

Eo

Ea = m (td4/ ta

4)

development time

Ea = effort in person-months

td = nominal delivery time for schedule

to = optimal development time (in terms of cost)

ta = actual delivery time desired

Page 33: COSC 4406 Software Engineering

33

Effort AllocationEffort Allocation

40-50%40-50%

30-40%30-40%

““front end” activitiesfront end” activities customer communicationcustomer communication analysisanalysis designdesign review and modificationreview and modification

construction activitiesconstruction activities coding or code coding or code

generationgeneration testing and installationtesting and installation

unit, integrationunit, integration white-box, black boxwhite-box, black box regression regression

15-20%15-20%

Page 34: COSC 4406 Software Engineering

34

Defining Task SetsDefining Task Sets

determine type of projectdetermine type of project assess the degree of rigor requiredassess the degree of rigor required identify adaptation criteriaidentify adaptation criteria select appropriate software engineering select appropriate software engineering

taskstasks

Page 35: COSC 4406 Software Engineering

35

Task Set Task Set RefinementRefinement

1.1 Concept scoping determines the overall scope of the project.Task definition: Task 1.1 Concept Scoping

1.1.1 Identify need, benefits and potential customers;

1.1.2 Define desired output/control and input events that drive the application;

Begin Task 1.1.2

1.1.2.1 FTR: Review written description of need FTR indicates that a formal technical review (Chapter 26) is to be conducted.

1.1.2.2 Derive a list of customer visible outputs/inputs

1.1.2.3 FTR: Review outputs/inputs with customer and revise as required;

endtask Task 1.1.2

1.1.3 Define the functionality/behavior for each major function;

Begin Task 1.1.3

1.1.3.1 FTR: Review output and input data objects derived in task 1.1.2;

1.1.3.2 Derive a model of functions/behaviors;

1.1.3.3 FTR: Review functions/behaviors with customer and revise as required;

endtask Task 1.1.3

1.1.4 Isolate those elements of the technology to be implemented in software;

1.1.5 Research availability of existing software;

1.1.6 Define technical feasibility;

1.1.7 Make quick estimate of size;

1.1.8 Create a Scope Definition;endTask definition: Task 1.1

is refined to

Page 36: COSC 4406 Software Engineering

36

Define a Task Define a Task NetworkNetwork

I.1Conceptscoping

I.3aTech. Risk

Assessment

I.3bTech. Risk

Assessment

I.3cTech. Risk

Assessment

Three I.3 tasks areapplied in parallel to3 different conceptfunctions

Three I.3 tasks areapplied in parallel to3 different conceptfunctions

I.4Proof ofConcept

I.5aConcept

Implement.

I.5bConcept

Implement.

I.5cConcept

Implement.

I.2Conceptplanning

I.6CustomerReaction

Integratea, b, c

Page 37: COSC 4406 Software Engineering

37

Timeline ChartsTimeline Charts

Tasks Week 1 Week 2 Week 3 Week 4 Week n

Task 1Task 2Task 3Task 4Task 5Task 6Task 7Task 8Task 9Task 10Task 11Task 12

Page 38: COSC 4406 Software Engineering

38

Use Automated Use Automated Tools toTools to

Derive a Timeline Derive a Timeline ChartChart

I.1.1 Identify need and benefits Meet with customers Identify needs and project constraints Establish product statement Milestone: product statement definedI.1.2 Define desired output/control/input (OCI) Scope keyboard functions Scope voice input functions Scope modes of interaction Scope document diagnostics Scope other WP functions Document OCI FTR: Review OCI with customer Revise OCI as required; Milestone; OCI definedI.1.3 Define the functionality/behavior Define keyboard functions Define voice input functions Decribe modes of interaction Decribe spell/grammar check Decribe other WP functions FTR: Review OCI definition with customer Revise as required Milestone: OCI defintition completeI.1.4 Isolate software elements Milestone: Software elements definedI.1.5 Research availability of existing software Reseach text editiong components Research voice input components Research file management components Research Spell/Grammar check components Milestone: Reusable components identifiedI.1.6 Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessedI.1.7 Make quick estimate of sizeI.1.8 Create a Scope Definition Review scope document with customer Revise document as required Milestone: Scope document complete

week 1 week 2 week 3 week 4Work tasks week 5

Page 39: COSC 4406 Software Engineering

39

Schedule TrackingSchedule Tracking conduct periodic project status meetings in which each conduct periodic project status meetings in which each

team member reports progress and problems.team member reports progress and problems. evaluate the results of all reviews conducted throughout evaluate the results of all reviews conducted throughout

the software engineering process.the software engineering process. determine whether formal project milestones (the determine whether formal project milestones (the

diamonds shown in Figure 24.3) have been accomplished diamonds shown in Figure 24.3) have been accomplished by the scheduled date.by the scheduled date.

compare actual start-date to planned start-date for each compare actual start-date to planned start-date for each project task listed in the resource table (Figure 24.4).project task listed in the resource table (Figure 24.4).

meet informally with practitioners to obtain their meet informally with practitioners to obtain their subjective assessment of progress to date and problems subjective assessment of progress to date and problems on the horizon.on the horizon.

use earned value analysis (Section 24.6) to assess progress quantitatively.

Page 40: COSC 4406 Software Engineering

40

Progress on an OO Project-IProgress on an OO Project-I

Technical milestone: OO analysis completed Technical milestone: OO analysis completed All classes and the class hierarchy have been defined and reviewed.All classes and the class hierarchy have been defined and reviewed. Class attributes and operations associated with a class have been Class attributes and operations associated with a class have been

defined and reviewed.defined and reviewed. Class relationships (Chapter 8) have been established and reviewed.Class relationships (Chapter 8) have been established and reviewed. A behavioral model (Chapter 8) has been created and reviewed.A behavioral model (Chapter 8) has been created and reviewed. Reusable classes have been noted.Reusable classes have been noted.

Technical milestone: OO design completedTechnical milestone: OO design completed The set of subsystems (Chapter 9) has been defined and reviewed.The set of subsystems (Chapter 9) has been defined and reviewed. Classes are allocated to subsystems and reviewed.Classes are allocated to subsystems and reviewed. Task allocation has been established and reviewed.Task allocation has been established and reviewed. Responsibilities and collaborations (Chapter 9) have been identified.Responsibilities and collaborations (Chapter 9) have been identified. Attributes and operations have been designed and reviewed.Attributes and operations have been designed and reviewed. The communication model has been created and reviewed.The communication model has been created and reviewed.

Page 41: COSC 4406 Software Engineering

41

Progress on an OO Project-IIProgress on an OO Project-II

Technical milestone: OO programming completedTechnical milestone: OO programming completed Each new class has been implemented in code from the design Each new class has been implemented in code from the design

model.model. Extracted classes (from a reuse library) have been implemented.Extracted classes (from a reuse library) have been implemented. Prototype or increment has been built.Prototype or increment has been built.

Technical milestone: OO testingTechnical milestone: OO testing The correctness and completeness of OO analysis and design The correctness and completeness of OO analysis and design

models has been reviewed.models has been reviewed. A class-responsibility-collaboration network (Chapter 8) has been A class-responsibility-collaboration network (Chapter 8) has been

developed and reviewed.developed and reviewed. Test cases are designed and class-level tests (Chapter 14) have Test cases are designed and class-level tests (Chapter 14) have

been conducted for each class.been conducted for each class. Test cases are designed and cluster testing (Chapter 14) is Test cases are designed and cluster testing (Chapter 14) is

completed and the classes are integrated.completed and the classes are integrated. System level tests have been completed.System level tests have been completed.

Page 42: COSC 4406 Software Engineering

42

Earned Value Analysis (EVA)Earned Value Analysis (EVA)

Earned value is a measure of progress enables us to assess the “percent of completeness” of a

project using quantitative analysis rather than rely on a gut feeling

“provides accurate and reliable readings of performance from as early as 15 percent into the project.” [FLE98]

Page 43: COSC 4406 Software Engineering

43

Computing Earned Value-IComputing Earned Value-I

The The budgeted cost of work scheduledbudgeted cost of work scheduled (BCWS) is (BCWS) is determined for each work task represented in determined for each work task represented in the schedule. the schedule. BCWSBCWSii is the effort planned for work task is the effort planned for work task i.i. To determine progress at a given point along the To determine progress at a given point along the

project schedule, the value of BCWS is the sum of the project schedule, the value of BCWS is the sum of the BCWSBCWSii values for all work tasks that should have been values for all work tasks that should have been completed by that point in time on the project schedule. completed by that point in time on the project schedule.

The BCWS values for all work tasks are summed The BCWS values for all work tasks are summed to derive the to derive the budget at completion,budget at completion, BAC. Hence, BAC. Hence,

BAC = BAC = ∑∑ (BCWS (BCWSkk) for all tasks ) for all tasks kk

Page 44: COSC 4406 Software Engineering

44

Computing Earned Value-IIComputing Earned Value-II Next, the value for Next, the value for budgeted cost of work performedbudgeted cost of work performed (BCWP) is (BCWP) is

computed. computed. The value for BCWP is the sum of the BCWS values for all work tasks The value for BCWP is the sum of the BCWS values for all work tasks

that have actually been completed by a point in time on the project that have actually been completed by a point in time on the project schedule.schedule.

““the distinction between the BCWS and the BCWP is that the the distinction between the BCWS and the BCWP is that the former represents the budget of the activities that were planned former represents the budget of the activities that were planned to be completed and the latter represents the budget of the to be completed and the latter represents the budget of the activities that actually were completed.” [WIL99] activities that actually were completed.” [WIL99]

Given values for BCWS, BAC, and BCWP, important progress Given values for BCWS, BAC, and BCWP, important progress indicators can be computed:indicators can be computed:

Schedule performance index, SPI = BCWP/BCWSSchedule performance index, SPI = BCWP/BCWS Schedule variance, SV = BCWP – BCWSSchedule variance, SV = BCWP – BCWS SPI is an indication of the efficiency with which the project is utilizing SPI is an indication of the efficiency with which the project is utilizing

scheduled resources.scheduled resources.

Page 45: COSC 4406 Software Engineering

45

Computing Earned Value-IIIComputing Earned Value-III

Percent scheduled for completion = BCWS/BACPercent scheduled for completion = BCWS/BAC provides an indication of the percentage of work that should have provides an indication of the percentage of work that should have

been completed by time been completed by time t.t. Percent complete = BCWP/BACPercent complete = BCWP/BAC

provides a quantitative indication of the percent of completeness of provides a quantitative indication of the percent of completeness of the project at a given point in time, the project at a given point in time, t.t.

Actual cost of work performed,Actual cost of work performed, ACWP ACWP, is the sum of the effort , is the sum of the effort actually expended on work tasks that have been completed by a actually expended on work tasks that have been completed by a point in time on the project schedule. It is then possible to point in time on the project schedule. It is then possible to computecompute

Cost performance index, CPI = BCWP/ACWPCost performance index, CPI = BCWP/ACWP Cost variance, CV = BCWP – ACWPCost variance, CV = BCWP – ACWP