SE

UNIT 4

Software Project Management

4.1 Overview of Project Management & planning

Software project management is an art and discipline of planning

and supervising software projects. It is a sub-discipline of software
project management in which software projects planned,
implemented, monitored and controlled.

A software project manager is a person who undertakes the

responsibility of executing the software project. Software project
manager is thoroughly aware of all the phases of SDLC that the
software would go through. Project manager may never directly
involve in producing the end product but he controls and
manages the activities involved in production.

Figure: 1 Project planning activities

Software Measurement and Metrics

Software measurement is a method to measure

software characteristics which are measurable or countable with
the help of metrics. Software metrics are used to
measure software performance, planning work items, measuring
productivity, and many other uses. Software metrics are similar to
the four functions of management: Planning, Organization,
Control, or Improvement.
 Product Metrics:

To measures of various characteristics of the software, product

metrics are used: on the basis of -
 Size and complexity of software.
 Quality and reliability of software.

These metrics can be computed for different stages of SDLC.

b. Process Metrics:

To measures various characteristics of the software development

process. For example, the efficiency of fault detection etc..

Responsibilities of project manager shoulders -

Managing People
 Act as project leader
 Liaison with stakeholders
 Managing human resources
 Setting up reporting hierarchy etc.

Managing Project
 Defining and setting up project scope
 Managing project management activities
 Monitoring progress and performance
 Risk analysis at every phase
 Take necessary step to avoid or come out of problems
 Act as project spokesperson
Software measurement life cycle
Many other metrics include the following:
 Various Size Oriented Measures

LOC Metrics- It is simplest size based metrics for calculating size

of program. It is computed by normalizing the quality and
productivity measures by considering the size of the product as a
metric.

In size-oriented metrics:

 Developed when FORTRAN and COBOL programming were very

popular.
 Productivity defined as KLOC / EFFORT, where effort is
measured in person-months.
 Depend on the programming language used.
 Productivity depends on KLOC, so assembly language code will
have more productivity.
 Not practically achievable as require details
 More expressive the programming language, the lower is the
productivity.
 Does not measure projects with GUI-based programming.
b. Halstead's software science

In Halstead's "A code is an implementation of an algorithm

considered to be a collection of tokens which can be classified as
either operators or operand."

Token Count- All program metrics can be defined in basic

symbols. These symbols are called as a token.
n1 = count of unique operators, n2 = count of unique operands.

N1 = count of total occurrences of operators. N2 = count of total

occurrence of operands, size of the program can be expressed as
N = N1 + N2.

Halstead metrics :

Program Volume (V)- The unit of measurement of volume is

the standard unit for size "bits."

V=N*log2n

Program Level (L)- The value of L ranges between zero and

one, with L=1 representing a program written at the highest
possible level (i.e., with minimum size).

L=V*/V

Program Difficulty-The difficulty level or error-proneness (D) of

the program is proportional to the number of the unique operator
in the program.

D= (n1/2) * (N2/n2)

Programming Effort (E)- The unit of measurement of E is

elementary mental discriminations.

E=V/L=D*V

Estimated Program Length-it is the length of a well-structured

program is a function only of the number of unique operators and
operands.

N=N1+N2

And estimated program length is denoted by N^

N^ = n1log2n1 + n2log2n2

The following alternate expressions have been published to

estimate program length:

NJ = log2 (n1!) + log2 (n2!)

NB = n1 * log2n2 + n2 * log2n1
NC = n1 * sqrt(n1) + n2 * sqrt(n2)

NS = (n * log2n) / 2

Potential Minimum Volume- V* is defined as the volume of the

most short program in which a problem can be coded.

V* = (2 + n2*) * log2 (2 + n2*), Here, n2* is the count of unique

input and output parameters

Size of Vocabulary (n)-The size of the vocabulary of a program,

which consists of the number of unique tokens used to build a
program, is defined as:

n=n1+n2 where n=vocabulary of a program

n1=number of unique operators

n2=number of unique operands

Language Level – calculates algorithm implementation program

language level. The same algorithm take extra effort if it is
written in a low-level program language. Hence, it is easier to
program in Pascal than in Assembler.

L' = V / D / D

lambda = L * V* = L2 * V

4.2 Project Estimation Techniques

For an effective management accurate estimation of various

measures is a must. With correct estimation managers can
manage and control the project more efficiently and effectively.
Project estimation may involve the following:
 Software size estimation
Software size may be estimated either in terms of KLOC
(Kilo Line of Code) or by calculating number of function
points in the software. Lines of code depend upon coding
 practices and Function points vary according to the user or
software requirement.
 Effort estimation
The managers estimate efforts in terms of personnel
requirement and man-hour required to produce the
software. For effort estimation software size should be
known. This can either be derived by managers’ experience,
organization’s historical data or software size can be
converted into efforts by using some standard formulae.
 Time estimation
Once size and efforts are estimated, the time required to
produce the software can be estimated. Efforts required is
segregated into sub categories as per the requirement
specifications and interdependency of various components
of software. Software tasks are divided into smaller tasks,
activities or events by Work Breakthrough Structure (WBS).
The tasks are scheduled on day-to-day basis or in calendar
months.
The sum of time required to complete all tasks in hours or
days is the total time invested to complete the project.

 Cost estimation
This might be considered as the most difficult of all because
it depends on more elements than any of the previous ones.
For estimating project cost, it is required to consider -
 Size of software
 Software quality
 Hardware
 Additional software or tools, licenses etc.
 Skilled personnel with task-specific skills
 Travel involved
 Communication
 Training and support

4.3 Project Size estimation Metrics

 Line of Code (LOC)

Estimation is done on behalf of number of line of codes in the
software product.

b. Function Point (FP) based measures

Estimation is done on behalf of number of function points in

the software product.

4.4 Development: Selecting a language, Coding guidelines,

Writing

Code documentation

The coding is the process of converting the design specifications

of a project into the source code of programming language. It is
necessary to write source code & internal documentation so that
conformance of the code to its specification can be easily
verified.

Coding is a process which can reduce cost testing and

maintenance done by programmers.

Coding standards and guidelines are summarized in

figures below:
Points to keep in mind while coding :
a) Clarity and simplicity of Expression.
b) Naming
c) Control Constructs
d) Information hiding
e) Nesting
f) User-defined types
g) Module size
h) Module Interface
i) Side-effects

Project Planning

Software project planning is task, which is performed before the

production of software actually starts. It is there for the software
production but involves no concrete activity that has any direction
connection with software production; rather it is a set of multiple
processes, which facilitates software production. Project planning
may include the following:

c. Various Size Oriented Measures

LOC Metrics- It is simplest size based metrics for calculating size

of program. It is computed by normalizing the quality and
productivity measures by considering the size of the product as a
metric.

In size-oriented metrics:

 Developed when FORTRAN and COBOL programming were very

popular.
 Productivity defined as KLOC / EFFORT, where effort is
measured in person-months.
 Depend on the programming language used.
 Productivity depends on KLOC, so assembly language code will
have more productivity.
 Not practically achievable as require details
 More expressive the programming language, the lower is the
productivity.
 Does not measure projects with GUI-based programming.
d. Halstead's software science

In Halstead's "A code is an implementation of an algorithm

considered to be a collection of tokens which can be classified as
either operators or operand."

Token Count- All program metrics can be defined in basic

symbols. These symbols are called as a token.

n1 = count of unique operators, n2 = count of unique operands.

N1 = count of total occurrences of operators. N2 = count of total
occurrence of operands, size of the program can be expressed as
N = N1 + N2.

Halstead metrics :

Program Volume (V)- The unit of measurement of volume is

the standard unit for size "bits."

V=N*log2n

Program Level (L)- The value of L ranges between zero and

one, with L=1 representing a program written at the highest
possible level (i.e., with minimum size).

L=V*/V

Program Difficulty-The difficulty level or error-proneness (D) of

the program is proportional to the number of the unique operator
in the program.

D= (n1/2) * (N2/n2)

Programming Effort (E)- The unit of measurement of E is

elementary mental discriminations.

E=V/L=D*V

Estimated Program Length-it is the length of a well-structured

program is a function only of the number of unique operators and
operands.

N=N1+N2

And estimated program length is denoted by N^

N^ = n1log2n1 + n2log2n2

The following alternate expressions have been published to

estimate program length:

NJ = log2 (n1!) + log2 (n2!)

NB = n1 * log2n2 + n2 * log2n1

NC = n1 * sqrt(n1) + n2 * sqrt(n2)
NS = (n * log2n) / 2

Potential Minimum Volume- V* is defined as the volume of the

most short program in which a problem can be coded.

V* = (2 + n2*) * log2 (2 + n2*), Here, n2* is the count of unique

input and output parameters

Size of Vocabulary (n)-The size of the vocabulary of a program,

which consists of the number of unique tokens used to build a
program, is defined as:

n=n1+n2 where n=vocabulary of a program

n1=number of unique operators

n2=number of unique operands

Language Level – calculates algorithm implementation program

language level. The same algorithm take extra effort if it is
written in a low-level program language. Hence, it is easier to
program in Pascal than in Assembler.

L' = V / D / D

lambda = L * V* = L2 * V

4.5 Project Estimation Techniques

For an effective management accurate estimation of various measures is

a must. With correct estimation managers can manage and control the
project more efficiently and effectively.
Project estimation may involve the following:
 Software size estimation
Software size may be estimated either in terms of KLOC (Kilo Line
of Code) or by calculating number of function points in the
software. Lines of code depend upon coding practices and Function
points vary according to the user or software requirement.
 Effort estimation
The managers estimate efforts in terms of personnel requirement
and man-hour required to produce the software. For effort
estimation software size should be known. This can either be
derived by managers’ experience, organization’s historical data or
 software size can be converted into efforts by using some standard
formulae.
 Time estimation
Once size and efforts are estimated, the time required to produce
the software can be estimated. Efforts required is segregated into
sub categories as per the requirement specifications and
interdependency of various components of software. Software
tasks are divided into smaller tasks, activities or events by Work
Breakthrough Structure (WBS). The tasks are scheduled on day-to-
day basis or in calendar months.
The sum of time required to complete all tasks in hours or days is
the total time invested to complete the project.
 Cost estimation
This might be considered as the most difficult of all because it
depends on more elements than any of the previous ones. For
estimating project cost, it is required to consider -
 Size of software
 Software quality
 Hardware
 Additional software or tools, licenses etc.
 Skilled personnel with task-specific skills
 Travel involved
 Communication
 Training and support

Project Size estimation Metrics

c. Line of Code (LOC)

Estimation is done on behalf of number of line of codes in the software

product.

d. Function Point (FP) based measures

Estimation is done on behalf of number of function points in the

software product.

4.6 COCOMO

In the early 80’s, Barry Boehm developed a model called COCOMO

(COnstructive COstMOdel) to estimate total effort required to develop
the software project. COCOMO model is commonly used as it is based on
the study of already developed software projects. While estimating total
effort for a software project, cost of development, management, and
other support tasks are included. However, cost of secretarial and other
staff are excluded.

In this model, size is measured in terms of thousands of delivered lines of

code (KDLOC). In order to estimate effort accurately, COCOMO model
divides projects into three categories listed below:

Organic projects: These projects are small in size (not more than 50
KDLOC) and thus easy to develop. In organic projects, small teams with
prior experience work together to accomplish user requirements, which
are less demanding. Most people involved in these projects have
thorough understanding of how the software under development
contributes in achieving the organization objectives. Examples of
organic projects include simple business system, inventory management
system, payroll management system, and library management system.

Embedded projects: These projects are complex in nature (size is more

than 300KDLOC) and the organizations have less experience in
developing such type of projects. Developers also have to meet stringent
user requirements. These software projects are developed
under constraints (hardware, software, and people).

Examples of embedded systems include software system used in avionics

and military hardware.

• Semi-detached projects: These projects are less complex as the user

requirements are less stringent compared to embedded projects. The size
of semi-detached project is not more than 300 KDLOC. Examples of semi-
detached projects include operating system, compiler design, and
database design

Types of Models:

 Basic COCOMO Model

 Intermediate COCOMO Model
 Detailed COCOMO Model

Basic COCOMO can be used for quick and slightly rough calculations of
Software Costs. Its accuracy is not very reliable.

Effort=a *(KLOC) a PM
1 2

Tdev=b *(efforts)b Months

1 2
Where KLOC is the estimated size of the software product indicate in Kilo
Lines of Code,

a ,a ,b , b are constants for each group of software products,

1 2 1 2

Tdev is the estimated time to develop the software, expressed in months,

Effort is the total effort required to develop the software product,

expressed in person months (PMs).

Intermediate COCOMO takes Cost Drivers into account

Intermediate COCOMO equation:

E=ai (KLOC) bi*EAF

D=ci (E)di

EAF = Effort adjustment factor

A table for Coefficients for intermediate COCOMO is given below:

Detailed COCOMO additionally accounts for the influence of individual

project phases, i.e in case of Detailed it accounts for both these cost
drivers and also calculations are performed phase wise henceforth
producing a more accurate result. The Six phases of detailed COCOMO
are:

Planning and requirements

System structure

Complete structure

Module code and test

Integration and test

Cost Constructive model

4.7 Staffing Level Estimation

Project manager has to determine the actual Staff Estimation number

after the effort required to develop a software is known.

Norden Estimation: Norden studied the Staffing patterns of R & D

projects and proposed. Staffing level patterns can be approximated by
"Rayleigh Distribution Curve" which specifies that the relationship
between applied effort and delivery time for software project. It is also
called Putnam- NORDEN-Rayleigh Curve or PNR curve.

In 1976, Putnam studied the problem of staffing of software projects

observed that the level of effort required in software development efforts
has a similar envelope.Putnam analysed a large number of projects, and
gave the expression:

L=CkK1/3td4/3

K is the effort expended and L is the size in KLOC.

td is the time to develop the software.

Ck is the state of technology constant reflects factors that affect

programmer productivity.
4.8 Scheduling, Organization & Team Structures
Staffing

Project Scheduling in a project refers to roadmap of all activities to be

done with specified order and within time slot allotted to each activity.
Project managers tend to define various tasks, and project milestones
and arrange them keeping various factors in mind. They look for tasks lie
in critical path in the schedule, which are necessary to complete in
specific manner (because of task interdependency) and strictly within the
time allocated. Arrangement of tasks which lies out of critical path are
less likely to impact over all schedule of the project.
For scheduling a project, it is necessary to -
 Break down the project tasks into smaller, manageable form
 Find out various tasks and correlate them
 Estimate time frame required for each task
 Divide time into work-units
 Assign adequate number of work-units for each task
 Calculate total time required for the project from start to finish

4.9 Risk Management-Project Risk Management

Risk management involves all activities pertaining to

identification, analysing and making provision for predictable and non-
predictable risks in the project. Risk may include the following:

 Experienced staff leaving the project and new staff coming in.
 Change in organizational management.
 Requirement change or misinterpreting requirement.
 Under-estimation of required time and resources.
 Technological changes, environmental changes, business competition.
Figure: 2 Risk Management Activities

Risk Management Process

There are following activities involved in risk management process:

 Identification - Make note of all possible risks, which may occur in the
project.
 Categorize - Categorize known risks into high, medium and low risk
intensity as per their possible impact on the project.
 Manage - Analyse the probability of occurrence of risks at various
phases. Make plan to avoid or face risks. Attempt to minimize their side-
effects.
 Monitor - Closely monitor the potential risks and their early symptoms.
Also monitor the effects of steps taken to mitigate or avoid them.