CS724 4
CS724 4
Lecture # 4
1
Software Project Planning
• Software development can be exceedingly
complex and it needs to be planned in such
a way that all required resources are made
available at the right time for the necessary
duration
2
Logic of Software Project
Planning - 1
• While requirements are initially vague and
incomplete, a quality program can only be
built from an accurate and precise
understanding of the users’ needs. The
project plan thus starts by mapping the
route from vague and incorrect
requirements to accurate and precise ones
3
Logic of Software Project
Planning - 2
• A conceptual design is then developed as a basis
for planning. This initial structure must be
produced with care since it generally defines the
breakdown of the product into units, the allocation
of functions to these units, and the relationships
among them. Since this provides the
organizational framework for planning and
implementing the work, it is almost impossible to
recover from a poor conceptual design
4
Logic of Software Project
Planning - 3
• At each subsequent requirements
refinement, resource projections, size
estimates, and schedules are also refined
• When requirements are sufficiently clear, a
detailed design and implementation strategy
is developed and incorporated in the plan
5
Logic of Software Project
Planning - 4
• As various parts of the project become
sufficiently well understood,
implementation details are established and
documented in further plan refinements
• Throughout this cycle, the plan provides the
framework for negotiating the time and
resources to do the job
6
Goal Of Project Planning
• The overall goal of project planning is to
establish a pragmatic strategy for
controlling, tracking, and monitoring a
complex technical project
• Why?
• So the end result gets done on time, with
quality
7
Objectives of Project Planning -
1
• The objective of software project planning
is to provide a framework that enables the
manager to make reasonable estimates of
resources, cost, and schedule
• These estimates are made within a limited
time frame at the beginning of a software
project and should be updated regularly as
the project progresses
8
Objectives of Project Planning -
2
• Estimates should attempt to define best case
and worst case scenarios so that the project
outcomes can be bounded
9
Steps of Project Planning
10
Steps of Project Planning
• Software scope
• Estimation
• Risk
• Schedule
• Control strategy
11
Software Scope - 1
• Understand the problem and the work that
must be done – in a nutshell
12
Software Scope - 2
• Project scope must be unambiguous and
understandable at the management and
technical levels
• A statement of software scope must be
bounded – in other words
• At the beginning of a project, things are
very hazy and nothing is clear
13
Software Scope - 3
• Good and open communication is required
between developers and customer to define
the scope of the project
14
Software Scope - 4
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a
successful solution?
• Is there another source for the solution?
15
To Understand Scope
• Understand the customer needs
• Understand the business context
• Understand the project boundaries
• Understand the customer’s motivation
• Understand the likely paths for change
• Understand that even when you understand,
nothing is guaranteed
16
Feasibility
• Once scope has been identified (with the
concurrence of the customer), it is
reasonable to ask: “Can we build software
to meet this scope? Is the project feasible?”
• Often times this question is overlooked and
developers face serious problems because
of that
17
Estimation
• How much effort?
• How much time?
18
Cost Estimation
• Project scope must be explicitly defined
• Task and/or functional decomposition is
necessary
• Historical measures (metrics) are very helpful
• At least two different techniques should be
used
• Remember that uncertainty is inherent
19
Project Resources
20
Project Resources
People
Reusable software
components
Hardware/software tools
21
Project Resources
• Discussion on people, reusable software
components, and hardware/software tools
22
Project Resources
• Software cost and effort estimation will
never be an exact science, as too many
variables – human, technical,
environmental, political – can affect the
ultimate cost of software and effort applied
to develop it
23
Options for Reliable Cost and
Effort Estimates
• Delay estimation until late in the project
• Base estimates on similar projects that have
already been completed
• Use relatively simple decomposition
techniques to generate project cost and effort
estimates
• Use one or more empirical models for
software cost and effort estimation
24
Functional decomposition
– divide and conquer
25
Functional Decomposition
Statement functional
perform
of Scope a decomposition
"grammatical
parse"
26
Estimation Techniques
• Past similar projects experience
• Conventional estimation techniques
– Task breakdown and effort estimates
– Size (e.g., FP) estimates
– Tools (e.g., Checkpoint)
27
Creating a Task Matrix
28
Creating a Task Matrix
Obtained from “process framework”
framework activities
30
COCOMO model
31
Risk
• What can go wrong?
• How can we avoid it?
• What can we do about it?
32
Schedule
• How do we allocate resources along the
time line?
• What are the milestones?
33
Control Strategy
• How do we control quality?
• How do we control change?
34
Summary
35
References
• Software Engineering 5th Edition by Roger
Pressman, Chapter 5
36