Chapter 024 Proj Scheduling N Tracking

(1)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

Software Engineering: A Practitioner’s Approach, Software Engineering: A Practitioner’s Approach,

6/e 6/e

Chapter 24 Project Scheduling and Tracking

R.S. Pressman & Associates, Inc.

For University Use Only

May be reproduced ONLY for student use at the university level

when used in conjunction with Software Engineering: A Practitioner's Approach.

(2)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

Why Are Projects Late?

 an unrealistic deadline established by someone outside the an unrealistic deadline established by someone outside the software development group

software development group

 changing customer requirements that are not reflected in schedule changing customer requirements that are not reflected in schedule changes;

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 considered predictable and/or unpredictable risks that were not considered when the project commenced;

when the project commenced;

 technical difficulties that could not have been foreseen in advance;technical difficulties that could not have been foreseen in advance;  human difficulties that could not have been foreseen in advance;human difficulties that could not have been foreseen in 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 is a failure by project management to recognize that the project is

falling behind schedule and a lack of action to correct the problem

(3)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

Scheduling Principles

 compartmentalizationcompartmentalization—define distinct tasks—define distinct tasks

 interdependencyinterdependency—indicate task interrelationship —indicate task interrelationship  effort validationeffort validation—be sure resources are available—be sure resources are available  defined responsibilitiesdefined responsibilities—people must be assigned—people must be assigned  defined outcomesdefined outcomes—each task must have an output—each task must have an output  defined milestonesdefined milestones—review for quality—review for quality

(4)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

Effort and Delivery Time

Effort Cost

Impossible region

td Ed

Tmin = 0.75Td

to Eo

Ea = m (td4/ ta4)

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

(5)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

Effort Allocation

40-50%

30-40%

 ““front end” activitiesfront end” activities

 customer communicationcustomer communication

 analysisanalysis

 designdesign

 review and modificationreview and modification

 construction activitiesconstruction activities

 coding or code generationcoding or code generation

 testing and installationtesting and installation

 unit, integrationunit, integration

 whitebox, black boxwhitebox, black box

 regression regression

15-20%

(6)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

Defining 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

(7)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

Task Set

Refinement

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

(8)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8

Define a Task

Network

I.1 Concept scoping I.3a Tech. Risk Assessment I.3b Tech. Risk Assessment I.3c Tech. Risk Assessment Three I.3 tasks are applied in parallel to 3 different concept functions Three I.3 tasks are applied in parallel to 3 different concept functions I.4 Proof of Concept I.5a Concept Implement. I.5b Concept Implement. I.5c Concept Implement. I.2 Concept planning I.6 Customer Reaction Integrate a, b, c

(9)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

Timeline Charts

Tasks _Week 1 _Week 2 _Week 3 _Week 4 _Week n

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

(10)

Use Automated Tools to

Derive a Timeline

Chart

I.1.1 Identify need and benefits Meet with customers

Identify needs and project constraints Establish product statement Milestone: product statement defined

I.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 defined

I.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 complete

I.1.4 Isolate software elements Milestone: Software elements defined

I.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 identified

I.1.6 Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessed I.1.7 Make quick estimate of size I.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 4

(11)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

Schedule Tracking

 conduct periodic project status meetings in which each team conduct periodic project status meetings in which each team member reports progress and problems.

member reports progress and problems.

 evaluate the results of all reviews conducted throughout the evaluate the results of all reviews conducted throughout the software engineering process.

software engineering process.

 determine whether formal project milestones (the diamonds determine whether formal project milestones (the diamonds

shown in Figure 24.3) have been accomplished by the scheduled

date.

 compare actual startdate to planned startdate for each project compare actual startdate to planned startdate for each project task listed in the resource table (Figure 24.4).

task listed in the resource table (Figure 24.4).

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

assessment of progress to date and problems on the horizon.

 use earned value analysis (Section 24.6) to assess progress

(12)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

Progress on an OO ProjectI

 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 defined Class attributes and operations associated with a class have been 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.

(13)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

Progress on an OO ProjectII

 Technical milestone: OO programming completedTechnical milestone: OO programming completed

 Each new class has been implemented in code from the design model.Each new class has been implemented in code from the design 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 models has The correctness and completeness of OO analysis and design models has

been reviewed.

 A classresponsibilitycollaboration network (Chapter 8) has been developed A classresponsibilitycollaboration network (Chapter 8) has been developed

and reviewed.

 Test cases are designed and classlevel tests (Chapter 14) have been Test cases are designed and classlevel tests (Chapter 14) have been

conducted for each class.

 Test cases are designed and cluster testing (Chapter 14) is completed and the Test cases are designed and cluster testing (Chapter 14) is completed and the

classes are integrated.

(14)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

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

(15)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

Computing Earned ValueI

 The The budgeted cost of work scheduledbudgeted cost of work scheduled (BCWS) is determined (BCWS) is determined for each work task represented in the schedule.

for each work task represented in the schedule.

 BCWSBCWS_i_i 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 project To determine progress at a given point along the project

schedule, the value of BCWS is the sum of the BCWS

schedule, the value of BCWS is the sum of the BCWSii values for values for

all work tasks that should have been completed by that point in

time on the project schedule.

 The BCWS values for all work tasks are summed to The BCWS values for all work tasks are summed to derive the

derive the budget at completion,budget at completion, BAC. Hence, BAC. Hence,  BAC = BAC = ∑∑ (BCWS (BCWS_k_k) for all tasks ) for all tasks kk

(16)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

Computing Earned ValueII

 Next, the value for Next, the value for budgeted cost of work performedbudgeted cost of work performed (BCWP) is computed. (BCWP) is computed.

 The value for BCWP is the sum of the BCWS values for all work tasks that have 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 schedule.

 ““the distinction between the BCWS and the BCWP is that the former the distinction between the BCWS and the BCWP is that the former

represents the budget of the activities that were planned to be completed represents the budget of the activities that were planned to be completed

and the latter represents the budget of the activities that actually were and the latter represents the budget of the activities that actually were

completed.” [WIL99] completed.” [WIL99]

 Given values for BCWS, BAC, and BCWP, important progress indicators Given values for BCWS, BAC, and BCWP, important progress indicators

can be computed: 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 scheduled SPI is an indication of the efficiency with which the project is utilizing scheduled

resources.

(17)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman &

Computing Earned ValueIII

 Percent scheduled for completion = BCWS/BACPercent scheduled for completion = BCWS/BAC

 provides an indication of the percentage of work that should have been provides an indication of the percentage of work that should have been

completed by time

completed by time t.t.

 Percent complete = BCWP/BACPercent complete = BCWP/BAC

 provides a quantitative indication of the percent of completeness of the project at provides a quantitative indication of the percent of completeness of the project at

a given point in time,

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 actually , is the sum of the effort actually

expended on work tasks that have been completed by a point in time on the expended on work tasks that have been completed by a point in time on the

project schedule. It is then possible to compute project schedule. It is then possible to compute

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

(1)

These courseware materials are to be used in conjunction

with Software Engineering: A Practitioner’s Approach, 6/e

and are provided with permission by R.S. Pressman &

Associates, Inc., copyright © 1996, 2001, 2005

12

Progress on an OO ProjectI



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 defined Class attributes and operations associated with a class have been defined

and reviewed.



Technical milestone: OO design completed

 Task allocation has been established and reviewed.Task allocation has been established and reviewed.

(2)

These courseware materials are to be used in conjunction

with Software Engineering: A Practitioner’s Approach, 6/e

and are provided with permission by R.S. Pressman &

Associates, Inc., copyright © 1996, 2001, 2005

13

Progress on an OO ProjectII



Technical milestone: OO programming completed

 Prototype or increment has been built.Prototype or increment has been built.



Technical milestone: OO testing

 The correctness and completeness of OO analysis and design models has The correctness and completeness of OO analysis and design models has

been reviewed.

 A classresponsibilitycollaboration network (Chapter 8) has been developed A classresponsibilitycollaboration network (Chapter 8) has been developed

and reviewed.

 Test cases are designed and classlevel tests (Chapter 14) have been Test cases are designed and classlevel tests (Chapter 14) have been

conducted for each class.

 Test cases are designed and cluster testing (Chapter 14) is completed and the Test cases are designed and cluster testing (Chapter 14) is completed and the

classes are integrated.

(3)

These courseware materials are to be used in conjunction

with Software Engineering: A Practitioner’s Approach, 6/e

and are provided with permission by R.S. Pressman &

14

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

(4)

These courseware materials are to be used in conjunction

with Software Engineering: A Practitioner’s Approach, 6/e

and are provided with permission by R.S. Pressman &

15

Computing Earned ValueI



The

budgeted cost of work scheduled

(BCWS) is determined

for each work task represented in the schedule.



BCWS

_i_i

is the effort planned for work task

i.



To determine progress at a given point along the project

schedule, the value of BCWS is the sum of the BCWS

values for

all work tasks that should have been completed by that point in

time on the project schedule.



The BCWS values for all work tasks are summed to

derive the

budget at completion,

BAC. Hence,

(5)

These courseware materials are to be used in conjunction

with Software Engineering: A Practitioner’s Approach, 6/e

and are provided with permission by R.S. Pressman &

16

Computing Earned ValueII



Next, the value for

budgeted cost of work performed

(BCWP) is computed.

 The value for BCWP is the sum of the BCWS values for all work tasks that have 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 schedule. actually been completed by a point in time on the project schedule.



“

the distinction between the BCWS and the BCWP is that the former

represents the budget of the activities that were planned to be completed

and the latter represents the budget of the activities that actually were

completed.” [WIL99]



Given values for BCWS, BAC, and BCWP, important progress 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 scheduled SPI is an indication of the efficiency with which the project is utilizing scheduled resources.

(6)

These courseware materials are to be used in conjunction

with Software Engineering: A Practitioner’s Approach, 6/e

and are provided with permission by R.S. Pressman &

17

Computing Earned ValueIII



Percent scheduled for completion = BCWS/BAC

 provides an indication of the percentage of work that should have been provides an indication of the percentage of work that should have been

completed by time

completed by time t.t.



Percent complete = BCWP/BAC

 provides a quantitative indication of the percent of completeness of the project at provides a quantitative indication of the percent of completeness of the project at

a given point in time,

a given point in time, t.t.



Actual cost of work performed,

ACWP

, is the sum of the effort actually

expended on work tasks that have been completed by a point in time on the

project schedule. It is then possible to compute

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

Chapter 024 Proj Scheduling N Tracking

Chapter 24

Chapter 24

Project Scheduling and Tracking

Project Scheduling and Tracking

Why Are Projects Late?

Why Are Projects Late?

Scheduling Principles

Scheduling Principles

Effort and Delivery Time

Effort and Delivery Time

Effort Allocation

Effort Allocation

Defining Task Sets

Defining Task Sets

Task Set

Task Set

Refinement

Refinement

Define a Task

Define a Task

Network

Network

Timeline Charts

Timeline Charts

Use Automated Tools to

Use Automated Tools to

Derive a Timeline

Derive a Timeline

Chart

Chart

Schedule Tracking

Schedule Tracking

Progress on an OO Project­I

Progress on an OO Project­I

Progress on an OO Project­II

Progress on an OO Project­II

Earned Value Analysis (EVA)

Earned Value Analysis (EVA)

Computing Earned Value­I

Computing Earned Value­I

Computing Earned Value­II

Computing Earned Value­II

Computing Earned Value­III

Computing Earned Value­III

These courseware materials are to be used in conjunction

with Software Engineering: A Practitioner’s Approach, 6/e

and are provided with permission by R.S. Pressman &

Associates, Inc., copyright © 1996, 2001, 2005

12

Progress on an OO Project­I

Progress on an OO Project­I

Technical milestone: OO analysis completed

Technical milestone: OO analysis completed

Technical milestone: OO design completed

Technical milestone: OO design completed

These courseware materials are to be used in conjunction

with Software Engineering: A Practitioner’s Approach, 6/e

and are provided with permission by R.S. Pressman &

Associates, Inc., copyright © 1996, 2001, 2005

13

Progress on an OO Project­II

Progress on an OO Project­II

Technical milestone: OO programming completed

Technical milestone: OO programming completed

Technical milestone: OO testing

Technical milestone: OO testing

These courseware materials are to be used in conjunction

with Software Engineering: A Practitioner’s Approach, 6/e

and are provided with permission by R.S. Pressman &

Associates, Inc., copyright © 1996, 2001, 2005

14

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

These courseware materials are to be used in conjunction

Progress on an OO ProjectI

Progress on an OO ProjectI

Progress on an OO ProjectII

Progress on an OO ProjectII

Computing Earned ValueI

Computing Earned ValueI

Computing Earned ValueII

Computing Earned ValueII

Computing Earned ValueIII

Computing Earned ValueIII

Progress on an OO ProjectI

Progress on an OO ProjectI

Progress on an OO ProjectII

Progress on an OO ProjectII

Computing Earned ValueI

Computing Earned ValueI

Computing Earned ValueII

Computing Earned ValueII