Software project management

1. 1
Software Project Management
Indu Sharma
HOD(CSE)
CPTC,Rajsamand

2. 2
Introduction
 Project Management is an integrated part of software
development.
 It refers to manage the complete software project.
 The goal is to provide the necessary support for
development to proceed smoothly and reduce any
development problem. Its basic task is to ensure that,
once a development process is chosen, it is
implemented optimally.
 Effective s/w project management focuses on the 4
P’s: The People, The Product, The Process, and The
Project.

3. 3
Introduction
I. The People:
 People-intensive
 SEI has developed a “People Management-
Capability Maturity Model” (PM-CMM):
 This model defines the key practice areas for s/w
people: recruitment, selection, performance
management, training, compensation, career
development, organization and work design, and
team/culture development.
 Team leaders: Motivation, Innovative, Problem
solving, influence and team building.

4. 4
Introduction
II. The Product:

Product objectives: Overall goals (from the
customer’s point of view) without considering
how these goals will be achieved.

Scope: identifies its primary data, functions, and
behaviors.

Alternative Solutions: Once the project objectives
and scope are understood, alternative solutions
are considered. The alternative solutions enable
managers to select a “best” approach, given the
constraints imposed by the delivery deadlines,
budgetary restrictions, personnel availability,
technical interfaces etc.

5. 5
Introduction
III. The Process:
 The way in which we produce the software.
 Provides a framework from which a comprehensive
plan for s/w development can be established.
 Problem is to select the appropriate process model.
 The project manager must decide which process
model is appropriate for:

The customer who have requested the product

The characteristics of the product itself, and

The projcect environment in which the s/w team
works.

6. 6
Introduction
IV. The Project:
 In order to manage successful s/w projects, we must
understand what can go wrong and how to do it
right. Ten signs that indicate the project is in danger:
i. S/w people don’t understand their customer’s need.
ii. The product scope is poorly defined.
iii. Changes are managed poorly.
iv. The chosen technology changes.
v. Business needs change (or ill defined).

7. 7
Introduction
vi. Deadlines are unrealistic.
vii. Users are resistant.
viii. Sponsorship is lost ( or was never properly obtained)
ix. The project team lacks people with appropriate skills.
x. Managers avoid practices and lessones learned.

8. 8
Introduction
 Five commonsense approach to avoid problems to s/w
projects:

Start on the right foot:
 Working hard to understand the problem.
 Building the right team and giving the team
autonomy, authority, and technology needed to
the job.

Maintain Momentum:
 Good start and then slowly disintegrate
 To maintain momentum, the project manager
must provide incentives, should emphasize
quality in every task it performs etc.

Track progress:
 Progress is tracked as work products.

9. 9
Introduction

Make smart decisions:
 Keep it simple.
 Use of existing s/w components
 Decide to avoid custom interfaces when standard
approaches are available.
 Decide to identify and then avoid obvious risks.
 Decide to allocate more time than you think is
needed to complex or risky tasks.

10. 10
Introduction

Conduct a postmortem analysis:
 Establish consistent mechanism for extracting
lessons learned for each project.
 Evaluate the planned and actual schedules,
collect and analyze s/w project metrics, get
feedback from team members and customers,
and record finding is in written form.

11. 11
Activities
 The activities in the management
process for a project can be grouped
broadly into three phases:
 Project planning
 Project Monitoring & Control
 Project Termination

12. 12
Project Planning
 Project management begins with planning,
which is the perhaps most critical project
management activity.
 Lack of proper planning is sure ticket to
failure for a large s/w project.
 A s/w plan is usually produced before the
development activity begins and is updated
as development proceeds and data about
progress of the project becomes available.

13. 13
Project Planning
 The major issues project planning
addresses are:
I. Process Planning
II. Effort estimation
III. Project scheduling and staffing
IV. Configuration Management Plan
V. Quality Plans
VI. Risk Management
VII. Project Monitoring plans

14. 14
I Process Planning
 For a project during planning, a key activity is
to plan and specify the process that should
be used in the project.
 It means the various stages in the process,
the entry criteria for each stage, the exit
criteria, the verification activities that will be
done at the end of the stage.
 Some standard process model may be used
as a standard process and tailored to suit the
needs of the project.

15. 15
II Effort Estimation
 For a given set of requirements it is desirable
to know how much it will cost to develop the
s/w and how much time the development will
take. These estimates are needed before
development is initiated.
 The primary reason for cost and schedule
estimation are:
 Cost and benefit analysis
 Project monitoring and control
 More practical use: bidding for s/w projects

16. 16
Effort Estimation
 Because the s/w development is labour-
intensive(i.e. human resources), most cost
estimation procedures focuses on estimating
effort in terms of Person-Months(PM).
 Effort and schedule estimation is required to
answer the questions like:
 Is the project late?
 Are there cost overruns?
 When is the project likely to complete?
 What staffing level is required during different
phases?

17. 17
Effort Estimation
 To achieve reliable effort estimation in terms of
cost , a no. of options arise:
a) Delay estimates until late in the project.
Not practical, as cost estimation must be provided “up-
front”
b) Base estimates on similar projects that have already
been completed
Can work reasonably well, if the current project is quite
similar to past efforts.
c) Use relatively simple decomposition techniques to
generate project cost and effort estimation.
d) Use one or more empirical models for s/w cost and effort
estimation.
(c) And (d) are viable approaches to s/w project estimation.

18. 18
Measure, Measurement, Metrics
and Indicators
 Although, the terms measure, measurement, and
metrics are often used interchangeably, but it is
important to note the subtle differences between
them.
 Measure: A measure provides a quantitative
indication of the extent, amount, dimension, capacity,
or size of some attributes of a product or process.
 Measurement: Measurement is the act of determining
a measure.
 Metric: A quantitative measure of the degree to which
a system, component, or process possesses a given
attribute.

19. 19
Measure, Measurement, Metrics
and Indicators
 Example:
 When a single data point has been collected (e.g.,
the number of errors uncovered in the review of a
single module), a measure has been established.
Measurement occurs as the result of the collection
of one or more data points (e.g., a number of
module reviews are investigated to collect
measures of the number of errors in each
module). A software metric relates the individual
measures in some way (e.g., the average number
of errors found per review).

20. 20
Measure, Measurement, Metrics
and Indicators
 A software engineer collects measures and
develops metrics so that indicators will be
obtained. An indicator is a metric or
combination of metrics that provide insight
into the software process, a software project,
or the product itself.
 An indicator provides insight that enables the
project manager or software engineers to
adjust the process, the project, or the process
to make things better.

21. 21
Measure, Measurement, Metrics
and Indicators
 For example, four software teams are working on a
large software project. Each team must conduct
design reviews but is allowed to select the type of
review that it will use. Upon examination of the
metric, errors found per person-hour expended, the
project manager notices that the two teams using
more formal review methods exhibits an errors found
per person-hour expended that is 40% higher than
the other teams. Assuming all parameters are equal,
this provides the project manager with an indicator
that formal review methods may provide a higher
return on time investment than another, less formal
review approach. She may decide to suggest that all
teams use the more formal approach.

22. 22
Metrics
 Because the s/w has not physical attributes,
conventional metrics are not much help in
designing metrics of s/w. A number of metrics
have been proposed to quantify things like
the size, complexity, and reliability of a s/w
product.
 A s/w metrics relates the individual
measures in some way.
Eg. Avg lines of code: KLOC per module
Avg number of errors found per module

23. 23
Metrics
 There are three types of metrics:
 Product Metrics: Product metrics are used to
quantify characteristics of the product being
developed i.e. Software. Eg. Size, complexity,
performance, efficiency, portability, reliability etc.
 Process Metrics: Process metrics are used to
quantify characteristics of the process being used
to develop the s/w. Eg. Effort required in the
process, time to produce the product, effect of
development techniques and tools, no. of defects
found during testing etc.

24. 24
Metrics
 Project Metrics: are used for strategic
purposes. That is, project metrics and indicators
derived from them are used by a project manager
and a software team to adapt project work flow
and technical activities.
 Two purpose:

First, to minimize the development schedule by making
necessary adjustments in order to avoid delays and
alleviate potential risks and problems.

Secondly, these metrics are used to assess the product
quality on a regular basis and modify the technical issues
if required. As the quality improves, the number of errors
and defects are reduced, which in turn leads to a
decrease in the overall cost of a software project.

25. 25
Metrics
 Values of metrics can be measured directly
or indirectly.
 Directly:
 eg. Distance can be directly measured.
 eg. Size of the s/w (LOC), cost, execution
speed etc.
 Indirectly:
 eg. Distance = speed * time
 eg. Reliability has to be estimated from
other possible measurements, quality,
complexity, maintainability etc.

26. 26
Decomposition Techniques
 Decomposition techniques take a “divide and
conquer” approach to s/w project estimation.
 Decomposition techniques are used to estimate cost
and effort by decomposing the complete project
problem into subsequent parts. Now, first these parts
or subdivisions are solved one-by-one and after their
solutions can be combined to form a whole.
 The s/w size is the most important factor that effects
the cost. LOC and FP-Based are distinct estimate
techniques for s/w size.
 If a direct approach is chosen, size can be measured
in LOC. If an indirect approach is chosen, size is
represented in FP.

27. 27
LOC-Based Estimation
 It simply refers to the no. of lines of the
delivered source code.
 Eg. 5000 KLOC
 LOC
 From this a set of simple size-oriented
metrics can be developed:
 Errors / KLOC, Defects / KLOC, $ / KLOC
 Other Metrics:
 Errors / person-month
 LOC / Person-month
 $ / page of documentation

28. 28
LOC-Based Estimation
 Advantages:
 Simple to measure
 It can be determined uniquely by automated tools
once the project is completed.
 Drawbacks:
 It is defined on code. For example it can’t measure
the size of specification.
 It characterize only one specific view of size, name
length, it takes no account of functionality or
complexity.
 Bad s/w design may cause excessive line of code
 It is language dependent.