• No results found

How To Write A Project Plan

N/A
N/A
Protected

Academic year: 2021

Share "How To Write A Project Plan"

Copied!
9
0
0

Loading.... (view fulltext now)

Full text

(1)

WVU LDCSEE

WVU LDCSEE

CS 430

CS 430

CS 430

CS 430

Project Scheduling and Tracking

Project Scheduling and Tracking

copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.

For University Use Only

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 1

May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach.

Any other reproduction or use is expressly prohibited.

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 group

software development group

changing customer requirements that are not reflected in

changing customer requirements that are not reflected in

schedule changes;

schedule changes;

gg

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

technical difficulties that could not have been foreseen in

advance;

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;

g p j

g p j

y

y

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

falling behind schedule and a lack of action to correct the

problem

(2)

Scheduling Principles

Scheduling Principles

compartmentalization

compartmentalization

—define distinct tasks

define distinct tasks

interdependency

interdependency

—indicate task interrelationship

indicate task interrelationship

interdependency

interdependency

indicate task interrelationship

indicate task interrelationship

effort validation

effort validation

—be sure resources are available

be sure resources are available

defined responsibilities

defined responsibilities

—people must be assigned

people must be assigned

defined outcomes

defined outcomes

—each task must have an output

each task must have an output

defined milestones

defined milestones

—review for quality

review for quality

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 3

Effort and Delivery Time

Effort and Delivery Time

Effort Cost Impossible region Ed Eo Ea = m ( td4 / ta4) Ea = effort in person-months t d = nominal delivery time for schedule t o = optimal development time (in terms of cost) t a = actual delivery time desired

t d Tmin = 0.75T d

(3)

Effort Allocation

Effort Allocation

40

40--50%

50%



“front end” activities

“front end” activities

customer communication

customer communication

customer communication

customer communication

analysis

analysis

design

design

review and modification

review and modification

construction activities

construction activities

coding or code generation

coding or code generation

testing and installation

testing and installation

15

15--20%

20%

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 5

30

30--40%

40%

testing and installation

testing and installation

unit, integration

unit, integration

white

white--box, black box

box, black box

regression

regression

Defining Task Sets

Defining Task Sets

determine type of project

determine type of project

assess the degree of rigor required

assess the degree of rigor required

assess the degree of rigor required

assess the degree of rigor required

identify adaptation criteria

identify adaptation criteria

(4)

Task Set Refinement

Task Set Refinement

1.1

Concept scoping

determines the

overall scope of the project.

T k d fi iti T k 1 1 C t S i 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;

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 7

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

Define a Task Network

Define a Task Network

I.3a Tech. Risk Assessment I.5a Concept Implement. I.1 Concept scoping I.3b Tech. Risk Assessment I.3c Tech. Risk Assessment

Three I.3 tasks are Three I.3 tasks are li d i ll l t I.4 Proof of Concept I.5b Concept Implement. I.5c Concept Implement. I.2 Concept planning I.6 Customer Reaction Integrate a, b, c applied in parallel to 3 different concept functions applied in parallel to 3 different concept functions

(5)

Timeline Charts

Timeline Charts

Tasks Week 1 Week 2 Week 3 Week 4 Week n

Task 1 Task 1 Task 2 Task 3 Task 4Task 5 Task 6 Task 7 Task 8 Task 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 & Associates, Inc., copyright © 1996, 2001, 2005 9

Task 10 Task 11 Task 12

Use Automated Tools to

Use Automated Tools to

Derive a Timeline Chart

Derive a Timeline Chart

I.1.1 Identify need and benefits Meet with customers Identify needs and project constraints E t bli h d t t t t

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

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 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

(6)

Schedule Tracking

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

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

shown in Figure 24.3) have been accomplished by the

scheduled date.

scheduled date.

compare actual start

compare actual start--date to planned start

date to planned start--date for each project

date for each project

task listed in the resource table (Figure 24.4).

task listed in the resource table (Figure 24.4).

t i f

ll

ith

titi

t

bt i th i

bj ti

t i f

ll

ith

titi

t

bt i th i

bj ti

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 11

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

quantitatively.

Progress on an OO Project

Progress on an OO Project--II

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. 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 completed

Technical 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 reviewedClasses are allocated to subsystems 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. 

(7)

Progress on an OO Project

Progress on an OO Project--II

II

Technical milestone: OO programming completed

Technical 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 testing

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. been reviewed.

 A classA class--responsibilityresponsibility--collaboration network (Chapter 8) has been developed collaboration network (Chapter 8) has been developed

and reviewed. and reviewed.

 Test cases are designed and classTest cases are designed and class--level tests (Chapter 14) have been level tests (Chapter 14) have been

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

gg (( pp ))

conducted for each class. conducted for each class.

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

the classes are integrated. the classes are integrated.

 System level tests have been completed.System level tests have been completed.

Earned Value Analysis (EVA)

Earned Value Analysis (EVA)

Earned value

is a measure of progress

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

(8)

Computing Earned Value

Computing Earned Value--II

The

The

budgeted cost of work scheduled

budgeted cost of work scheduled

(BCWS) is

(BCWS) is

determined for each work task represented in the

determined for each work task represented in the

determined for each work task represented in the

determined for each work task represented in the

schedule.

schedule.

BCWS

BCWS

ii

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 BCWS

ii

values for

values for

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

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

time on the project schedule.

time on the project schedule.

Th BCWS

l

f

ll

k

k

d

Th BCWS

l

f

ll

k

k

d

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 15

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

kk

) for all tasks

) for all tasks k

k

Computing Earned Value

Computing Earned Value--II

II

Next, the value for

Next, the value for

budgeted cost of work performed

budgeted 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.

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 = BCWPSchedule variance SV = BCWP –– BCWSBCWS 

 Schedule variance, SV BCWP Schedule variance, SV BCWP BCWSBCWS 

 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. resources.

(9)

Computing Earned Value

Computing Earned Value--III

III

Percent scheduled for completion = BCWS/BAC

Percent scheduled for completion = BCWS/BAC

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

 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

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,

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

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 17

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 

References

Related documents

Minors who do not have a valid driver’s license which allows them to operate a motorized vehicle in the state in which they reside will not be permitted to operate a motorized

Drawing on published document collections from the Central Powers (Germany, Austria-Hungary) and the Allies (Great Britain, France, and Russia), as well as unpublished materials from

However, this would likely give rise to much litigation to determine whether this was consistent with the MSFCMA and not an overly broad reading of section 1856(a)(3)(A) of that

The range of both headcount measures (RCDH and CDH) is very large and, in one case, an extreme reversal in country ranking occurs. As explained earlier in this section,

a posteriori error estimation procedure for velocity and pressure fields based on the Babuˇ ska’s inf-sup constant (including residuals calculations), iii) the compu- tation of a

2) Positional information is sent into embeddings since the encoder of the transformer doesn‟t have it. Sine and Cosine functions are used for positional encoding, at

In the case of non-economic well- being indicators, the decline in aggregate inequality in life expectancy, education, and human development did not preclude that, by the dawn of

If a logical archive of a known server is replicated to the original server, this archive can be checked in Replicated Archives in the Archives object of the console tree..