Chapter 4 Software

Project Planning
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.
• Cost: How much is it going to cost to develop the
software product?
• Duration: How long is it going to take to develop
the product?
• 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
d) PERT Chart
2. Project estimates Representation
e) Historical Data Used
f) Estimation Techniques 4. Project resources
Used e) People
g) Effort, Resource, Cost, and f) Hardware and Software
Project Duration Estimates g) Special Resources
The SPMP Document of Project
Planning
7. Project tracking and
5. Staff organization control plan
a) Metrics to be tracked
a) Team Structure b) Tracking plan
b) Management c) Control plan
Reporting
8. Miscellaneous plans
6. Risk management d) Process Tailoring
plan e) Quality Assurance Plan
c) Risk Analysis f) Configuration Management
Plan
d) Risk Identification g) Validation and Verification
e) Risk Estimation h) System Testing Plan
f) Risk Abatement i) Delivery, Installation, and
Procedures 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
System files 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
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  ∑ ∑ ij
i1 J 1 Z
Where i indicate the row and j indicates the column of Table
1 wij
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 Average
Incidental Moderate 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 sw 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 in unpleasant surprises and
results 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 people do not wish to air their
most
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 Risk Resolution
Activities
 Risk Management
Risk Assessment
Identification of risks

Risk analysis involves how project

might change with modification of riskoutcomes
examining 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.