Chapter_07_Project Scheduling and Tracking.ppt

Software Engineering

1. 1
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,
5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
Chapter 7Chapter 7
Project Scheduling and Project Scheduling and
TrackingTracking

2. 2
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,
5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
Why Are Projects Why Are Projects
Late?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 schedule changing customer requirements that are not reflected in schedule
changes;changes;
an honest underestimate of the amount of effort and/or the number an honest underestimate of the amount of effort and/or the number
of resources that will be required to do the job;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 problemfalling behind schedule and a lack of action to correct the problem

3. 3
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,
5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
Scheduling Scheduling
PrinciplesPrinciples
compartmentalization—define distinct taskscompartmentalization—define distinct tasks
interdependency—indicate task interdependency—indicate task
interrelationshipsffort validation—be sure interrelationshipsffort validation—be sure
resources are availableresources are available
defined responsibilities—people must be defined responsibilities—people must be
assignedassigned
defined outcomes—each task must have an defined outcomes—each task must have an
outputoutput
defined milestones—review for qualitydefined milestones—review for quality

4. 4
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,
5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
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
compute task set selector (TSS) valuecompute task set selector (TSS) value
interpret TSS to determine degree of rigorinterpret TSS to determine degree of rigor
select appropriate software engineering select appropriate software engineering
taskstasks

5. 5
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,
5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
ExampleExample
Figure 7.2 Concept development tasks using an
evolutionary model
Project Definition
I.1 Concept scoping
Concept Development
New Application
DevelopmentApplication
Enhancement
Application
Maintenance
I.4 Proof of concept
I.5 Concept implementation
Planning
Release
Customer
Evaluation
Engineering/
Construction
I.6 Customer reaction
I.2 Preliminary concept planning
I.3 Technology risk assessment
Reengineering

6. 6
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,
5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
Define a Task NetworkDefine 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

7. 7
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,
5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
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 generationcoding or code generation
testing and installationtesting and installation

unit, integrationunit, integration
 white-box, black boxwhite-box, black box
 regression regression
15-20%15-20%

8. 8
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,
5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
Use Automated Tools Use Automated Tools
toto
Derive a Timeline ChartDerive 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 4Work tasks week 5