Dr. Thomas Hicks
Computer Science Department
Trinity University
1
Software Engineering
CSCI 3321
Software Engineering : A Practitioner’s
Approach
Software Project
Scheduling
Dr. Thomas E. Hicks
Computer Science Department
Trinity University
Thanks To Ian Sommerville & Roger Pressman For Much Of The Slide Content
Chapter 24
Scheduling
Suppose You Do This ?
1.
You selected an
Appropriate Process Model
Suppose You Do This ?
2.
You identified the
Software Engineering Tasks
to be performed.
Suppose You Do This ?
3.
You estimated the
Amount of Work.
4.
You selected and estimated the
Number of
People
Suppose You Do This ?
5.
You know the
Deadline.
6.
You considered the
Risks
.
Suppose You Do This ?
7.
You created a
Schedule
– you created a Network of Software
Engineering Tasks that would enable you to get
c
the job done
on time
.
You assigned
Responsibility
for Each SE Task
You tried to make sure Each SE Task was done on time
You adapt the Network as Risks become Reality
Rick
trotter
Story From Text
In the late 1960’s, a bright-eyed
young engineer
was
chosen to “
write
” a
computer program
for an automated
manufacturing application.
The reason for his selection was simple. He was the
only
person
in his technical group
who had attend classes
in
computer programming.
He
knew
the ins and outs of assembly language and
Fortran, but had
never had Software Engineering
. He
knew nothing about project scheduling or tracking.
His boss gave him appropriate manuals
and a verbal description
of what had to
be done.
He
read the manuals
, considered the
approach, and started writing code.
After two weeks, the boss called him into his office and
asked him how things were going.
“
Really Great
!” replied the young engineer with youthful
enthusiasm. “This was much easier than I thought. I am
probably
75% finished
.”
The boss smiled and encouraged the young engineer to
keep up the good work
. They planned to meet again in a
weeks time.
A
week later
, the boss called him into his office and
asked “Where are we
“
Everything’s going well
” said the youngster, “but I have
run into a few small snags. I’ll get them ironed out soon
and be back on track soon.”
“How does the deadline look?”, asked the boss .
“
No problem
!” said the engineer. “I am close to 90%
complete.”
If you have been working with software for more than a
few years, you can finish the story!
It’ll come as no surprise that the young engineer
stayed 90% complete for the entire duration of the
project.
The only reason the
project was finished more than
a month after the deadline
is because others were
hired to help complete the job.
This story has been repeated “tens of
thousands of times” during the past
four decades.
“Excessive or irrational
schedules are probably the most
single destructive influence in all
of software.”
Caspers Jones
“Patterns Of Large Software Systems: Failures & Successes”
“Any Commander and Chief who
undertakes to carry out a plan
which he considers defective is at
fault.
He must put forth his reasons,
insist on the plan being changed,
and finally tender his resignation
rather than be the instrument of his
army’s downfall.”
Napoleon
Projects Are Late
9 Of The More Common Reasons Why Are Projects
Late 1- 4
1.
Projects are sometimes Late because an
Unrealistic
Deadline
was established by someone outside the software
development group
2.
Projects are sometimes Late because
Changes To The
Requirements
have occurred and these changes are not
reflected in schedule changes.
3.
Projects are sometimes Late because the
effort and/or
resources
, necessary to complete the job, were honestly
underestimated by project management.
4.
Projects are sometimes Late because one or
more
Identified Risksbecame a Reality.
5.
Projects are sometimes Late because
Unidentified Risks
have surfaced as a Reality.
6.
Projects are sometimes Late because of
Technical
Difficulties
that could not have been foreseen in advance.
7.
Projects are sometimes Late because of Human Difficulties
that could not have been foreseen in advance.
8.
Projects are sometimes Late because of
Miscommunication
among project staff that results in delays.
9.
Projects are sometimes Late because
the project
management has failed to recognize that the project is falling
behind schedule and a lack of action to correct the problem
9 Of The More Common Reasons Why Are Projects
Iterative Development
Process
Chapter 23 dealt with Estimation
Techniques.
Chapter 24 deals with Scheduling!
If the best estimates indicate that the
deadline is unrealistic, a competent
project manager should “protect his
team from undue pressure” and “reflect
the pressure back to it’s originators”
Pressman
1.
Recognizes the reality of changing requirements
Caspers Jones’s research on 8000 projects
40% of final requirements arrived after the analysis phase, after
development had already begun
2.
Promotes early risk mitigation, by breaking down the
system into mini-projects and focusing on the riskier
elements first
3.
Allows you to “plan a little, design a little, and code a little”
4.
Encourages all participants, including testers, integrators,
and technical writers to be involved earlier on
5.
Allows the process itself to modulate with each iteration,
allowing you to correct errors sooner and put into practice
lessons learned in the prior iteration
6.
Focuses on component architectures, not final big bang
deployments
Revisit The Iterative Development Process
What’s A Project Manager To Do?
Scenario
Scenario
Your company has just been hired to build a “
real time
controller
” for a medical diagnostic instrument that is to be
introduced to the market in
nine months
. You have been
given the project.
You Are The Project Manager!
You do a careful estimation and a careful risk analysis and
come to the conclusion that the software, as requested, will
require 14 calendar months to create with your available staff.
What Do You Do?
Scenario (cont - 1)
Pressman says “You can’t just march into the
customer/marketing/sales group and demand that the deadline
be changed!”
There are external market pressures that have often dictated
the date, and the stakeholder is going to feel that the product
“must be released as advertised”.
What Do You Do?
Pressman says it is “equally foolish to
refuse to undertake the work (from a
career standpoint)”.
Scenario (Pressman Solution - 1 )
1.
Perform a detailed estimate using historical data from past
products.
Determine the effort and duration for the project.
2.
Using an “Incremental Process Model ” (ch 3), develop a
software engineering strategy that will deliver critically
functionality by the imposed deadline, but delay other
functionality until later
.
Document the plan.
3.
Meet with the customer and (using the detailed estimate),
explain why the imposed deadline is unrealistic.
Be certain to
note that all of the estimates are based on performance on
past projects.
Also be certain to indicate the percent
improvement that would be required to achieve the deadline
as it currently exists.
Scenario (Pressman Solution - 2 )
4.
Pressman says to say something like:
“I think we may have a problem with the delivery date for the
XYZ controller software.
I’ve given each of you an
abbreviated breakdown of production rates for past projects
and an estimate that we’ve done in a number of different
ways.
You’ll note that I have assumed a 20% improvement in past
production rates, but we still get a delivery date that is 14
calendar months rather than 9 months away.”
Scenario (Pressman Solution - 3 )
5.
Pressman says to offer the Incremental Development
strategy as an alternative:
“We have a few options, and I would like
you to make a decision based on them.
First, we can increase the budget and bring on additional
resources so that we’ll have a shot at getting the job done in
9 months.
But understand that this will increase the risk of
poor quality due to a tight timeline.
Second, we can remove a number of the software functions
and capabilities that you are requesting.
This will make the
preliminary version of the product less functional, but we can
announce all functionality and then deliver over a 14 month
period.
(cont)
Scenario (Pressman Solution - 3 )
5.
(cont)
Third, we can dispense with reality and wish the project
complete in nine months. We will wind up with nothing that
can be delivered to the customer.
The third option, I hope
you agree, is unacceptable. Past history, and our best
estimates, say that it is unrealistic and a recipe for disaster.”
Scheduling
Principles
6 Major Scheduling Principles
1.
Compartmentalization
- define Distinct Tasks
2.
Interdependency
- indicate Task Interrelationship
3.
Effort Validation
- be Sure Resources Are Available
4.
Defined Responsibilities
- people Must Be Assigned
5.
Defined Outcomes
- each Task Must Have An Output
Relationship Between
People & Effort
Effort Cost Impossible region td Ed Tmin = 0.75T d t o Eo Ea = m (td4/t a4) development time 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
About Program Scheduling
Really Small Project
– single person can do analysis,
design, coding, and testing.
As the Size of the Project Increases, more people must
become involved.
Really small projects, today, require more than a ten year
person effort.
[Rarely can we wait 10 years for one person to do it.]
Myth – “If we fall behind schedule, we can always add more
programmers and catch up later in the project”
The new people need to learn the project
Those who were doing the work often teach them
Fall Further
Behind!
One Day At A Time!
Fred Brooks
Mythical Man Month
How Do So Many Projects Fall Behind Schedule?
From The Mythical Man Month
Pressman says that Project Schedules are elastic to some degree; we can
add additional staff successfully to some degree.
Effort Cost Impossible region td Ed Tmin = 0.75T d t o Eo Ea = m (td4/t a4) development time 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
Putnam-Norden-Rayleigh (PNR) Curve
Effort Calculation (Use As Guide Only)
No Lines Delivered Source Code
L = P x E
1/3
t
4/3
L is related to effort and development!
E = development effort in person months
P = productivity parameter (2,000 – 20,000) that reflects a
variety of factors that lead to high quality software
engineering work
t = project duration in calendar months
Development Effort in Person Years E = L
3
/ (P
3
t
4
)
Can include a burdened labor rate factor ($/Person-Year) to the Development
Effort equation to get a Cost relationship.
Effort Allocation
Effort Allocation
40
40
-
-
50%
50%
30
30
-
-
40%
40%
“
Front End” Activities
Customer Communication
Analysis
Design
Review And Modification
Construction Activities
Coding Or Code Generation
Testing And Installation
Unit, Integration
White -box, Black Box
Regression
15
15
-
-
20%
20%
Task Set Refinement
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; endTaskdefinition: Task 1.1
is refined to
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
Use Tools
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
Use Automated Tools to
Derive a Timeline Chart
I.1.1 Identify need and benefitsMeet 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 Work tasks week 5
