Chapter 3

Software Project Planning

Chapter 3 -Software Project Planning

• Effective project management is crucial to the

success of any software development project.
• The main goal of software project management is to
enable a group of developers to work effectively
towards the successful completion of a project.
• project management involves use of a set of
techniques and skills to steer a project to success.
Software Project Management Complexities

• Management of software projects is much more

complex than management of many other types of
projects.
• Invisibility: Software remains invisible, until its
development is complete and it is operational.
• Anything that is invisible, is difficult to manage and control.
• Invisibility of software makes it difficult to assess the
progress of a project and is a major cause for the
complexity of managing a software project.
Software Project Management Complexities

• Changeability: Because the software part of any

system is easier to change as compared to the
hardware part, the software part is the one that gets
most frequently changed.
• Frequent changes to the requirements and the
invisibility of software are possibly the two major
factors making software project management a
complex task.
Software Project Management Complexities

• Complexity: Even a moderate sized software has

millions of parts (functions) that interact with each
other in many ways—data coupling, serial and
concurrent runs, state transitions, control
dependency, file sharing, etc.
• Uniqueness: Every software project is usually
associated with many unique features or situations.
• This makes every project much different from the
others.
Software Project Management Complexities

• Exactness of the solution: Mechanical components

such as nuts and bolts typically work satisfactorily
as long as they are within a tolerance of 1 percent or
so of their specified sizes.
• However, the parameters of a function call in a
program are required to be in complete conformity
with the function definition.
Software Project Management Complexities

• Team-oriented and intellect-intensive work:

Software development projects are akin to research
projects in the sense that they both involve team-
oriented, intellect-intensive work.
• In contrast, projects in many domains are labor-
intensive and each member works in a high degree
of autonomy.
Responsibilities of a Software Project Manager

• A software project manager takes the overall

responsibility of steering a project to success.
• The job responsibilities of a project manager ranges
from invisible activities like building up of team
morale to highly visible customer presentations.
• We can broadly classify a project manager’s varied
responsibilities into the following two major
categories:
• Project planning, and
• Project monitoring and control.
Responsibilities of a Software Project Manager

• Project planning: Project planning is undertaken

immediately after the feasibility study phase and
before the starting of the requirements analysis and
specification phase.
• Project planning involves estimating several
characteristics of a project and then planning the
project activities based on these estimates made.
• The initial project plans are revised from time to
time as the project progresses and more project data
become available.
Responsibilities of a Software Project Manager

• Project monitoring and control: Project

monitoring and control activities are undertaken
once the development activities start.
• The focus of project monitoring and control
activities is to ensure that the software development
proceeds as per plan.
• While carrying out project monitoring and control
activities, a project manager may sometimes find it
necessary to change the plan to cope up with specific
situations at hand.
Skills necessary for Managing Software Projects

• A theoretical knowledge of various project

management techniques is certainly important to
become a successful project manager.
• Three skills that are most critical to successful
project management are the following:
• Knowledge of project management techniques.
• Decision taking capabilities.
• Previous experience in managing similar projects.
Project Planning

• Once a project has been found to be feasible,

software project managers undertake project
planning.
• Project planning is undertaken and completed
before any development activity starts.
• However, for effective project planning, in addition
to a thorough knowledge of the various estimation
techniques, past experience is crucial.
Project Planning

• During project planning, the project manager

performs the following activities.
• Estimation: The following project attributes are
estimated.
a. Cost: How much is it going to cost to develop the
software product?
b. Duration: How long is it going to take to develop
the product?
c. Effort: How much effort would be necessary to
develop the product?
Project Planning

• The effectiveness of all later planning activities

such as scheduling and staffing are dependent on the
accuracy with which these three estimations have
been made.
• Scheduling: After all the necessary project
parameters have been estimated, the schedules for
manpower and other resources are developed.
• Staffing: Staff organization and staffing plans are
made.
Project Planning

• Risk management : This includes risk

identification, analysis, and abatement planning.
• Miscellaneous plans: This includes making several
other plans such as quality assurance plan, and
configuration management plan, etc.
• Size is the most fundamental parameter based on
which all other estimations and project plans are
made.
Project Planning
The SPMP Document of Project Planning

• Once project planning is complete, project

managers document their plans in a software project
management plan (SPMP) document.
• Listed below are the different items that the SPMP
document should discuss.
• This list can be used as a possible organization of
the SPMP document.
The SPMP Document of Project Planning

1. Introduction 3. Schedule
a) Objectives a) Work Breakdown
b) Major Functions Structure
c) Performance Issues b) Task Network
d) Management and Representation
Technical Constraints c) Gantt Chart
Representation
2. Project estimates d) PERT Chart
a) Historical Data Used Representation
b) Estimation Techniques 4. Project resources
Used
c) Effort, Resource, Cost, a) People
and Project Duration b) Hardware and Software
Estimates c) Special Resources
The SPMP Document of Project Planning
7. Project tracking and
5. Staff organization control plan
a) Team Structure a) Metrics to be tracked
b) Management Reporting b) Tracking plan
c) Control plan
6. Risk management plan
a) Risk Analysis 8. Miscellaneous plans
b) Risk Identification a) Process Tailoring
c) Risk Estimation b) Quality Assurance Plan
d) Risk Abatement c) Configuration
Procedures Management Plan
d) Validation and
Verification
e) System Testing Plan
f) Delivery, Installation,
and Maintenance Plan
Project Size Estimation Metrics

• Accurate estimation of project size is central to

satisfactory estimation of all other project
parameters such as effort, completion time, and total
project cost.
• The size of a project is obviously not the number of
bytes that the source code occupies, neither is it the
size of the executable code.
• The project size is a measure of the problem
complexity in terms of the effort and time required
to develop the product.
Project Size Estimation Metrics

• Currently, two metrics are popularly being used to

measure size
• lines of code (LOC) and
• function point (FP).
• Each of these metrics has its own advantages and
disadvantages.
• Based on their relative advantages, one metric may
be more appropriate than the other in a particular
situation.
Line of Code (LOC)

• LOC is possibly the simplest among all metrics

available to measure project size.
• This metric measures the size of a project by
counting the number of source instructions in the
developed program.
• One can possibly estimate the LOC count at the
starting of a project, only by using some form of
systematic guess work.
Line of Code (LOC)
• Systematic guessing typically involves the
following.
• The project manager divides the problem into
modules, and each module into sub-modules and so
on, until the LOC of the leaf-level modules are
small enough to be predicted.
• To be able to predict the LOC count for the various
leaf-level modules sufficiently accurately, past
experience in developing similar modules is very
helpful.
Shortcomings of the LOC metric

• LOC is a measure of coding activity alone.

• A good problem size measure should consider the total
effort needed to carry out various life cycle activities (i.e.
specification, design, code, test, etc.) and not just the
coding effort.
• LOC count depends on the choice of specific
instructions:
• LOC gives a numerical value of problem size that can
vary widely with coding styles of individual
programmers.
Shortcomings of the LOC metric

• LOC measure correlates poorly with the quality

and efficiency of the code:
• Calculating productivity as LOC generated per man-
month may encourage programmers to write lots of poor
quality code rather than fewer lines of high quality code
achieve the same functionality.
• LOC metric penalizes use of higher-level
programming languages and code reuse:
• A paradox is that if a programmer consciously uses
several library routines, then the LOC count will be
lower.
Shortcomings of the LOC metric

• LOC metric measures the lexical complexity of a

program and does not address the more important issues
of logical and structural complexities:
• a program incorporating complex logic would require
much more effort to develop than a program with very
simple logic.
• It is very difficult to accurately estimate LOC of the final
program from problem specification:
• The LOC count can accurately be computed only after
the code has fully been developed.
Function Point Metric

• Function point metric was proposed by Albrecht in

1983.
• This metric overcomes many of the shortcomings of
the LOC metric.
• It can easily be computed from the problem
specification itself.
• The size of a software product is directly dependent
on the number of different high-level functions or
features it supports.
 Function point (FP) metric computation

• The size of a software product is computed using

different characteristics of the product identified in its
requirements specification.
• It is computed using the following three steps:
• Step 1: Compute the unadjusted function point (UFP) using
a heuristic expression.
• Step 2: Refine UFP to reflect the actual complexities of the
different parameters used in UFP computation.
• Step 3: Compute FP by further refining UFP to account for
the specific characteristics of the project that can influence
the entire development effort.
Step 1: UFP Computation

• The unadjusted function points (UFP) is computed as

the weighted sum of five characteristics of a product as
shown in the following expression.

UFP = (Number of inputs)*4 + (Number of outputs)*5

+ (Number of inquiries)*4 + (Number of files)*10
+ (Number of interfaces)*10
 Step 1: UFP Computation

The principle of Albrecht’s function point analysis (FPA)

is that a system is decomposed into functional units.

• Inputs : information entering the system

• Outputs : information leaving the system
• Enquiries : requests for instant access to
information
• Internal logical files : information held within the
system
• External interface files : information held by other system
that is used by the system being
analyzed.
 Step 1: UFP Computation
The FPA functional units are shown in figure given below:
User

Inquiries

Other
ILF applications
Inputs
EIF
User
Outputs ILF: Internal logical files
System EIF: External interfaces

Fig: FPAs functional units System

Step 2: Refine parameters

• UFP computed at the end of step 1 is a gross indicator

of the problem size.
• This UFP needs to be refined.
• This is possible, since each parameter (input, output,
etc.) has been implicitly assumed to be of average
complexity.
• The complexity of each parameter is graded into three
broad categories—simple, average, or complex.
• Based on these weights of the parameters, the
parameter values in the UFP are refined.
Step 2: Refine parameters

• Counting Function Point

• Table 1: Functional units with weighting factors
Step 3: Refine UFP based on complexity of
the overall project
The procedure for the calculation of UFP in mathematical
form is given below:
5 3

UFP  ∑∑ Z ij wij
i1 J 1
Where i indicate the row and j indicates the column of Table 1
Wij : It is the entry of the ith row and jth column of the table 1
Zij : It is the count of the number of functional units of Type i that
have been classified as having the complexity corresponding to
column j.
Step 3: Refine UFP based on complexity of
the overall project

Organizations that use function point methods develop a criterion for

determining whether a particular entry is Low, Average or High.
Nonetheless, the determination of complexity is somewhat
subjective.

FP = UFP * CAF

Where CAF is complexity adjustment factor and is equal to [0.65 +

0.01 x ΣFi]. The Fi (i=1 to 14) are the degree of influence and are
based on responses to questions noted in table 3.
 Step 3: Refine UFP based on complexity of the
overall project
Table 3 : Computing function points.
Rate each factor on a scale of 0 to 5.
0 1 2 3 4 5
No
Influence Incidental Moderate Average Significant Essential
Number of factors considered ( Fi )
1. Does the system require reliable backup and recovery ?
2. Is data communication required ?
3. Are there distributed processing functions ?
4. Is performance critical ?
5. Will the system run in an existing heavily utilized operational environment ?
6. Does the system require on line data entry ?
7. Does the on line data entry require the input transaction to be built over multiple screens or operations ?
8. Are the master files updated on line ?
9. Is the inputs, outputs, files, or inquiries complex ?
10. Is the internal processing complex ?
11. Is the code designed to be reusable ?
12. Are conversion and installation included in the design ?
13. Is the system designed for multiple installations in different organizations ?
14. Is the application designed to facilitate change and ease of use by the user ?
 Project Estimation Techniques

• The different parameters of a project that need to be

estimated include—project size, effort required to
complete the project, project duration, and cost.
• A large number of estimation techniques have been
proposed by researchers.
• These can broadly be classified into three main
categories:
• Empirical estimation techniques
• Heuristic techniques
• Analytical estimation techniques
 1. Empirical Estimation Techniques

• Empirical estimation techniques are essentially based

on making an educated guess of the project parameters.
• Prior experience with development of similar products
is helpful.
• Although empirical estimation techniques are based on
common sense and subjective decisions, over the
years, the different activities involved in estimation
have been formalized to a large extent.
 2. Heuristic Techniques
• Heuristic techniques assume that the relationships that
exist among the different project parameters can be
satisfactorily modelled using suitable mathematical
expressions.
• Once the basic (independent) parameters are known,
the other (dependent) parameters can be easily
determined by substituting the values of the
independent parameters in the corresponding
mathematical expression.
• Different heuristic estimation models can be divided
into the following two broad categories:
• single variable and
• multivariable models.
 2. Heuristic Techniques

• Single variable estimation models assume that various

project characteristic can be predicted based on a
single previously estimated basic (independent)
characteristic of the software such as its size.

• Estimated Parameter = c1 * ed1

• e represents a characteristic of the software that has
already been estimated (independent variable).
• The dependent parameter to be estimated could be
effort, project duration, staff size, etc., c1 and d1 are
constants.
 2. Heuristic Techniques

• A multivariable cost estimation model assumes that a

parameter can be predicted based on the values of
more than one independent parameter.
• It takes the following form:
Estimated Resource = c1 * p1d1 + c2 * p2d2 + c3 * p3d3 +…
• where, p1, p2, ... are the basic (independent)
characteristics of the software already estimated, and
c1, c2, d1, d2, .... are constants.
• Multivariable estimation models are expected to give
more accurate estimates compared to the single
variable models
 3. Analytical Estimation Techniques

• Analytical estimation techniques derive the required

results starting with certain basic assumptions
regarding a project.
• Unlike empirical and heuristic techniques, analytical
techniques do have certain scientific basis.
• In fact, it outperforms both empirical and heuristic
techniques as far as estimating software maintenance
efforts is concerned.
 Scheduling

• The scheduling problem, in essence, consists of

deciding which tasks would be taken up when and by
whom.
Scheduling …….General Practices:

• On large projects, hundreds of small tasks must occur

to accomplish a larger goal
• Project manager’s objectives
• Define all project tasks
• Build an activity network that depict their interdependencies
• Identify the tasks that are critical within the activity network
• Build a timeline depicting the planned & actual progress of
each task
• Track task progress to ensure that delay is recognized “one
day at a time”
• To do this, the schedule should allow progress to be
monitored and the project to be controlled.
General Practices…..Cont’d

• SW project scheduling distributes estimated effort

across the planned project duration by allocating the
effort to specific tasks
• Scheduling for project can be viewed from two
different perspectives
• First, an end-date for release for a computer-based system
has already been established & fixed
• The sw organization is constrained to distribute effort within the
prescribed time frame
• Second, assume that rough chronological bounds have been
discussed but that the end-date is set by the SE organization
• Effort is distributed to make best use of resources and an end-date is
defined after careful analysis of the software.
Basic Principles for Project Scheduling

• Compartmentalization
• The project must be compartmentalized into a number of
manageable activities, actions, & tasks; both the product &
process are decomposed
• Interdependency
• The interdependency of each compartmentalized activity,
action, or task must be determined
• Some task must occur in sequence while others can occur in
parallel
• Some actions or activities cannot commence until the work
product produced by another is available
Basic Principles for Project Scheduling

• Time allocation
• Each task to be scheduled must be allocated some number of
work units
• In addition, each task must be assigned a start date and a
completion date that are a function of the interdependencies
• Start and stop dates are also established based on whether
work will be conducted on a full-time or part-time basis
• Effort validation
• Every project has a defined number of people on the team
• As time allocation occurs, the project manager must be
ensure that no more than the allocated number of people
have been scheduled at any given time
Basic Principles for Project Scheduling

• Defined responsibilities
• Every task that is scheduled should be assigned to a specific
team member
• Defined outcomes
• Every task that is scheduled should have a defined outcome
for sw projects such as a work product or part of a work
product
• Work products are often combined in deliverables
• Defined milestones
• Every task or group of tasks should be associated with a
project milestone
• A milestone is accomplished when one or more work
products has been reviewed for quality and has been
approved
Task Network

• A task set is the work breakdown structure for the

project.
• No single task set is appropriate for all projects and
process models.
• It varies depending on the project type and the degree of
rigor (based on influential factors) with which the team
plans to work
• The task set should provide enough discipline to
achieve high software quality
• But it must not burden the project team with unneccesary
work
Types of software project

• Concept development projects

• Explore some new business concept or application of some new
technology
• New application development
• Undertake as a consequence of a specific customer request
• Application enhancement
• Occur when existing software undergoes major modification to
function, performance, or interfaces that are observable by the end
user
• Application maintenance
• Correct, adapt or extend existing software in ways that may not be
immediately obvious to the end user
• Reengineering projects
• Undertaken with the intent of rebuilding an existing (legacy)
system in whole or in part
Factors that influence a project’s schedule

• Size of the project

• Number of potential users
• Application longevity
• Stability of requirements
• Ease of customer or developer communications
• Maturity of applicable technology
• Performance constraints
• Embedded and non-embedded characteristics
• Project staff
• Reengineering factors
Purpose of a Task Network

• Also called an activity network

• It is a graphical representation of the task flow for a
project
• It depicts task length, sequence, concurrency and
dependency
• Points out inter-task dependencies to help the manager
ensure continuous progress toward project completion
• The critical path
• A single path leading from start to finish in a task network
• It contain the sequence of tasks that must be completed on
schedule if the project as a whole is to be completed on
schedule
• It also determines the minimum duration of the project
Purpose of a Task Network
Purpose of a Task Network
Timeline Chart Mechanics of a Timeline chart

• Also called a Gantt chart;

• All project tasks are listed in the far left column
• The next few columns may list the following for each task:
the project start-date, project stop-date, project duration,
actual start-date, actual stop-date, actual duration, task-
interdependencies (i.e. predecessors)
• To the far right are columns representing dates on the
calendar
• The length of a horizontal bar on the calendar indicates the
duration of the task
• When multiple bars occur at the same time interval on the
calendar, this implies task concurrency
• A diamond in the calendar area of a specific task indicates
that the task is a milestone; a milestone has a time duration
of zero
Timeline Chart
Methods for Tracking the Schedule

• Qualitative approach
• Conduct periodic project status meetings in which each team
member reports progress and problem
• Evaluate the result of all reviews conducted throughout the
software engineering process
• Determine whether formal project milestones (i.e. diamond)
have been accomplished by the scheduled date
• Compare actual start date to planned start date for each
project task listed in the timeline chart
• Meet informally with the software engineering team to obtain
their subjective assessment of progress to date and problem
on the horizon
• Quantitative approach
• Use earned value analysis to assess progress quantitatively
 Risk Management

Software Risk Management

Y We Software developers are extremely optimists.

Y We assume, everything will go exactly as planned.
Y Other view
not possible to predict what is going to happen ?
Software surprises
Never good news
 Risk Management

Risk management is required to reduce this surprise

factor

Dealing with concern before it becomes a crisis.

Quantify probability of failure & consequences of failure.

 Risk Management

What is risk ?
Tomorrow’s problems are today’s risks.

“Risk is a problem that may cause some loss or

threaten the success of the project, but which has
not happened yet”.
 Risk Management

Risk management is the process of identifying, addressing

and eliminating these problems before they can damage
the project.

Current problems &

Potential Problems
 Risk Management
Typical Software Risk
• Capers Jones has identified the top five risk factors
that threaten projects in different applications.
1. Dependencies on outside agencies or factors.
• Availability of trained, experienced persons
• Inter group dependencies
• Customer-Furnished items or information
• Internal & external subcontractor relationships
 Risk Management
2. Requirement issues
Uncertain requirements

Wrong product
or
Right product badly

Either situation results in unpleasant surprises and

unhappy customers.
 Risk Management
• Lack of clear product vision
• Lack of agreement on product requirements
• Unprioritized requirements
• New market with uncertain needs
• Rapidly changing requirements
• Inadequate Impact analysis of requirements changes
 Software Project Planning
3. Management Issues
Project managers usually write the risk management
plans, and most people do not wish to air their
weaknesses in public.
• Inadequate planning
• Inadequate visibility into actual project status
• Unclear project ownership and decision making
• Staff personality conflicts
• Unrealistic expectation
• Poor communication
 Risk Management
4. Lack of knowledge

• Inadequate training
• Poor understanding of methods, tools, and
techniques
• Inadequate application domain experience
• New Technologies
• Ineffective, poorly documented or neglected
processes
 Risk Management
5. Other risk categories
• Unavailability of adequate testing facilities
• Turnover of essential personnel
• Unachievable performance requirements
• Technical approaches that may not work
 Risk Management
Risk Management Activities
Risk Identification
Risk Analysis
Risk
Assessment Risk Prioritization

Risk
Management Risk Management
Planning
Risk Control
Risk Monitoring
Fig. 9: Risk Management
Activities Risk Resolution
 Risk Management
Risk Assessment
Identification of risks

Risk analysis involves examining how project outcomes

might change with modification of risk input variables.

Risk prioritization focus for severe risks.

Risk exposure: It is the product of the probability of incurring

a loss due to the risk and the potential magnitude of that loss.
 Risk Management
• Another way of handling risk is the risk
avoidance.
• Do not do the risky things!
• We may avoid risks by not undertaking
certain projects, or by relying on proven
rather than cutting edge technologies.
 Risk Management
Risk Control
Risk Management Planning produces a plan for dealing with
each significant risks.

Y R ecord decision in the plan.

Risk resolution is the execution of the plans of dealing with

each risk.
• Here that weighing factor will be simple, average, or complex for a
measurement parameter type.
• The Function Point (FP) is thus calculated with the following formula.
• FP = Count-total * [0.65 + 0.01 * ∑(fi)]
= Count-total * CAF
• where Count-total is obtained from the above Table.
• CAF = [0.65 + 0.01 *∑(fi)]
• and ∑(fi) is the sum of all 14 questionnaires and show the complexity
adjustment value/ factor-CAF (where i ranges from 1 to 14). Usually, a student is
provided with the value of ∑(fi)
• Also note that ∑(fi) ranges from 0 to 70, i.e.,
• 0 <= ∑(fi) <=70
• and CAF ranges from 0.65 to 1.35 because
• When ∑(fi) = 0 then CAF = 0.65
• When ∑(fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35
• Based on the FP measure of software many other
metrics can be computed:
• Errors/FP
• $/FP.
• Defects/FP
• Pages of documentation/FP
• Errors/PM.
• Productivity = FP/PM (effort is measured in person-
months).
• $/Page of Documentation.
• Example: Compute the function point, productivity, documentation,
cost per function for the following data:
• Number of user inputs = 24
• Number of user outputs = 46
• Number of inquiries = 8
• Number of files = 4
• Number of external interfaces = 2
• Effort = 36.9 p-m
• Technical documents = 265 pages
• User documents = 122 pages
• Cost = $7744/ month
• Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2,
4, 5.