Software

Management

Chapter 3
1
 What is Project?
 A project is a group of tasks that need to complete to reach a clear
result. A project also defines as a set of inputs and outputs which are
required to achieve a goal.
 What is software project management?
 It is a procedure of managing, allocating and timing resources to
develop computer software that fulfills requirements.
 In software Project Management, the client and the developers need
to know the length, period and cost of the project.

 Prerequisite of software project management?

 There are three needs for software project management. These
are:
1. Time
2. Cost
3. Quality
 Activities in SPM
 Software Project Management consists of many
activities, that includes planning of the project, deciding
the scope of product, estimation of cost in different
terms, scheduling of tasks, etc.
 The list of activities are as follows:
1. Project planning and Tracking
2. Project Resource Management
3. Scope Management
4. Estimation Management
5. Project Risk Management
6. Scheduling Management
7. Project Communication Management
8. Configuration Management
 Project Management Tools
 To manage the Project management system adequately
and efficiently, we use Project management tools.
 Here are some standard tools:
 Gantt chart
 Gantt Chart first developed by Henry Gantt in 1917. Gantt
chart usually utilized in project management, and it is one
of the most popular and helpful ways of showing
activities displayed against time. Each activity
represented by a bar.
 Gantt chart is a useful tool when you want to see the
entire landscape of either one or multiple projects. It
helps you to view which tasks are dependent on one
another and which event is coming up.
5
 PERT chart
 PERT is an acronym of Programme Evaluation Review
Technique. In the 1950s, it is developed by the U.S.
Navy.
 In Project Management, PERT chart represented as a
network diagram concerning the number of nodes,
which represents events.
 The direction of the lines indicates the sequence of the
task. In the above example, tasks between "Task 1 to
Task 9" must complete, and these are known as a
dependent or serial task. Between Task 4 and 5, and
Task 4 and 6, nodes are not depended and can
undertake simultaneously. These are known as Parallel
or concurrent tasks. Without resource or completion
time, the task must complete in the sequence which is
considered as event dependency, and these are known
as Dummy activity and represented by dotted lines.
7
 Logic Network
 The Logic Network shows the order of activities over time. It
shows the sequence in which activities are to do. Distinguishing
events and pinning down the project are the two primary uses.
Moreover, it will help with understanding task dependencies, a
timescale, and overall project workflow.
 Product Breakdown Structure
 Product Breakdown Structure (BBS) is a management tool and
necessary a part of the project designing. It's a task-oriented
system for subdividing a project into product parts. The product
breakdown structure describes subtasks or work packages and
represents the connection between work packages. Within the
product breakdown Structure, the project work has
diagrammatically pictured with various types of lists. The
product breakdown structure is just like the work breakdown
structure (WBS).
9
 Logic Network
 Work Breakdown Structure
 It is an important project deliverable that classifies the team's
work into flexible segments. "Project Management Body of
Knowledge (PMBOK)" is a group of terminology that describes
the work breakdown structure as a "deliverable-oriented
hierarchical breakdown of the work which is performed by the
project team."
 There are two ways to generate a Work Breakdown Structure ?
The top-down and
 The bottom-up approach.
 In the top-down approach, the WBS derived by crumbling the
overall project into subprojects or lower-level tasks.
 The bottom-up approach is more alike to a brainstorming
exercise where team members are asked to make a list of low-
level tasks which is required to complete the project.
 Software Metrics
 A software metric is a measure of software
characteristics which are measurable or countable.
 Software metrics are valuable for many reasons,
including measuring software performance, planning
work items, measuring productivity, and many other
uses.
 Within the software development process, many
metrics are that are all connected.
 Classification of Software Metrics
 Software metrics can be classified into two types as
follows:
 1. Product Metrics: These are the measures of various
characteristics of the software product. The two important
software characteristics are:
1. Size and complexity of software.
2. Quality and reliability of software.
 These metrics can be computed for different stages of
SDLC.
 2. Process Metrics: These are the measures of various
characteristics of the software development process. For
example, the efficiency of fault detection. They are used
to measure the characteristics of methods, techniques,
and tools that are used for developing software.
13
 Types of Metrics
 Internal metrics: Internal metrics are the metrics used for
measuring properties that are viewed to be of greater
importance to a software developer. For example, Lines of Code
(LOC) measure.
 External metrics: External metrics are the metrics used for
measuring properties that are viewed to be of greater
importance to the user, e.g., portability, reliability, functionality,
usability, etc.
 Hybrid metrics: Hybrid metrics are the metrics that combine
product, process, and resource metrics. For example, cost per FP
where FP stands for Function Point Metric.
 Project metrics: Project metrics are the metrics used by the
project manager to check the project's progress. Data from the
past projects are used to collect various metrics, like time and
cost.
 Size Oriented Metrics
 It is one of the earliest and simpler metrics for calculating the
size of the computer program. It is generally used in calculating
and comparing the productivity of programmers.
 Size Oriented Metrics
 Halstead's Software Metrics
 According to Halstead's "A computer program is an implementation
of an algorithm considered to be a collection of tokens which can be
classified as either operators or operand."
 Token Count
 In these metrics, a computer program is considered to be a
collection of tokens, which may be classified as either operators or
operands. All software science metrics can be defined in terms of
these basic symbols. These symbols are called as a token.
 The basic measures are
 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 Oriented Metrics
 Halstead's Software Metrics
 According to Halstead's "A computer program is an implementation
of an algorithm considered to be a collection of tokens which can be
classified as either operators or operand."
 Token Count
 In these metrics, a computer program is considered to be a
collection of tokens, which may be classified as either operators or
operands. All software science metrics can be defined in terms of
these basic symbols. These symbols are called as a token.
 The basic measures are
 n1 = count of unique operators.
 n2 = count of unique operands.
 N1 = count of total occurrences of operators.
 N2 = count of total occurrence of operands.
❖ In terms of the total tokens used, the size of the program can be
expressed as N = N1 + N2.
 Size Oriented Metrics
 Example: Consider the sorting program as shown in
fig: List out the operators and operands and also
calculate the value of software science measure like n,
N, V, E, λ ,etc.
 Size Oriented Metrics
int sort (int x[ ], int n)
{
int i, j, save, im1;
/*This function sorts array x in ascending order */
If (n< 2) return 1;
for (i=2; i< =n; i++)
{
im1=i-1;
for (j=1; j< =im1; j++)
if (x[i] < x[j])
{
Save = x[i];
x[i] = x[j];
x[j] = save;
}
}
return 0;
}
 Size Oriented Metrics
 Step 1 – List out the operators and operands and also calculate the
values of software science measures like
Operators
 Occurrences Operands Occurrences
int 4 SORT 1
() 5 x 7
, 4 n 3
[] 7 i 8
if 2 j 7
< 2 save 3
; 11 im1 3
for 2 2 2
= 6 1 3
- 1 0 1
<= 2 - -
++ 2 - -
return 2 - -
{} 3 - -
n1=14 N1=53 n2=10 N2=38
 Size Oriented Metrics
 Here N1=53 and N2=38. The program length
N=N1+N2=53+38=91
 Vocabulary of the program n=n1+n2=14+10=24
 Volume V= N * log2n=91 x log2 24=417 bits.
 Functional Point (FP) Analysis
 FPA is used to make estimate of the software project,
including its testing in terms of functionality or
function size of the software product.

 Objectives of FPA
 The basic and primary purpose of the functional point
analysis is to measure and provide the software
application functional size to the client, customer, and
the stakeholder on their request.

21
 Measurements Examples
Parameters
Functional Point
1.Number of Input screen and
(FP) Analysis External Inputs(EI) tables
 Following are the points
regarding FPs 2. Number of Output screens and
 1. FPs of an application is External Output (EO) reports
found out by counting
the number and types of
functions used in the 3. Number of Prompts and
applications. Various external inquiries interrupts.
functions used in an (EQ)
application can be put
under five types, as 4. Number of Databases and
shown in Table: internal files (ILF) directories
 All these parameters are 5. Number of Shared databases
then individually assessed external interfaces and shared 22
for complexity. (EIF)
23
 Functional Point (FP) Analysis
 2. FP characterizes the complexity of the software
system and hence can be used to depict the project
time and the manpower requirement.
 3. The effort required to develop the project depends
on what the software does.
 4. FP is programming language independent.
 5. FP method is used for data processing systems,
business systems like information systems.
 6. The five parameters mentioned above are also
known as information domain characteristics.
 7. All the parameters mentioned above are assigned
some weights that have been experimentally
determined and are shown in Table 24
 Functional Point (FP) Analysis
Weights of 5-FP Attributes

Measurement Parameter Low Average High

1. Number of external inputs (EI) 7 10 15

2. Number of external outputs (EO) 5 7 10

3. Number of external inquiries (EQ) 3 4 6

4. Number of internal files (ILF) 4 5 7

5. Number of external interfaces (EIF) 3 4 6

The functional complexities are multiplied with the corresponding weights against
each function, and the values are added up to determine the UFP (Unadjusted
25

Function Point) of the subsystem.

 Functional Point (FP) Analysis

Here that weighing factor will be simple, average, or complex for a measurement
parameter type. 26
 Functional Point (FP) Analysis
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
1. When ∑(fi) = 0 then CAF = 0.65
2. When ∑(fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 =271.35
 Data Structure Metrics
Essentially the need for software development and other
activities are to process data. Some data is input to a system,
program or module; some data may be used internally, and
some data is the output from a system, program, or module.
Program Data Input Internal Data Data Output
Payroll Name/Social Security Withholding rates Gross Pay
No./Payrate/ Overtime Factors withholding Net Pay
Number of hours Insurance Premium Pay Ledgers
worked Rates
Spreadsheet Item Names/Item Cell computations Spreadsheet of items
Amounts/Relationshi Subtotal and totals
ps among Items

Software Planner Program Size/No of Model Parameter Est. project effort Est.
28
Software developer Constants project duration
on team Coefficients
 Data Structure Metrics
 There are some Data Structure metrics to compute the
effort and time required to complete the project. There
metrics are:
1. The Amount of Data.
2. The Usage of data within a Module.
3. Program weakness.
4. The sharing of Data among Modules.

29
 Data Sructure Metrics
 1. The Amount of Data: To measure the amount of
Data, there are further many different metrics, and
these are:
• Number of variable (VARS): In this metric, the Number
of variables used in the program is counted.
• Number of Operands (η2): In this metric, the Number of
operands used in the program is counted.
η2 = VARS + Constants + Labels
• Total number of occurrence of the variable (N2): In this
metric, the total number of occurrence of the variables
are computed
 2. The Usage of data within a Module: The measure
this metric, the average numbers of live variables are
computed. A variable is live from its first to its last
30
references within the procedure.
 Data Structure Metrics

For Example: If we want to characterize the average number of live

variables for a program having modules, we can use this equation.

Where (LV) is the average live variable metric computed from the ith module.
This equation could compute the average span size (SP) for a program of n
spans.

31
 Data Structure Metrics
 3. Program weakness: Program weakness depends on its
Modules weakness. If Modules are weak(less Cohesive),
then it increases the effort and time metrics required to
complete the project.

Module Weakness (WM) = LV* γ
 A program is normally a combination of various modules;
hence, program weakness can be a useful measure and
is defined as:
WP: Weakness of the program

m: No of modules in the program

Where,

WMi: Weakness of the ith module 32

 Information Flow Metrics
 The other set of metrics we would live to consider are
known as Information Flow Metrics. The basis of
information flow metrics is found upon the following
concept the simplest system consists of the component,
and it is the work that these components do and how they
are fitted together that identify the complexity of the
system. The following are the working definitions that are
used in Information flow:
 Component: Any element identified by decomposing a
(software) system into it's constituent's parts.
 Cohesion: The degree to which a component performs
a single function.
 Coupling: The term used to describe the degree of
linkage between one component to others in the same
33
system
 Information Flow Metrics
 Information Flow metrics deal with
this type of complexity by observing
the flow of information among
system components or modules.
 FAN-IN: FAN-IN of a procedure is the
number of local flows into that
procedure plus the number of data
structures from which this
procedure retrieve information.
 FAN -OUT: FAN-OUT is the number
of local flows from that procedure
plus the number of data structures
which that procedure updates.
 Procedure Complexity = Length * 34

(FAN-IN * FANOUT)**2
Cyclomatic Complexity
➢ Cyclomatic Complexity is a metric that helps us
measure how complex a particular software
program is. One of the uses of knowing the
Cyclomatic Complexity is that it helps us
understand the extent of unit testing to be done
in order to achieve complete coverage (more
information and links below).
Flow chart is a go-to method to arrive at this
measure.

35
Universal Formula:
❑ Branch Coverage <= Cyclometric Complexity
<= Path Coverage
 Replacing our values:
 2 <= 3 <= 4 (holds good :))

36
Flow Graph Notation for Program
In the graph, Nodes represent
processing tasks while edges
represent control flow
between the nodes.

37
How to Calculate Cyclomatic Complexity?
The calculation of CC revolves around 2 concepts
❑ Nodes
❑ Edges
Statements in a program are represented as nodes, and
control paths from one statement to another are
represented by Edges.
Cyclomatic Complexity formula
The formula for calculating CC is as:
CC = E~N+2
Where:
E= Number of edges
N= Number of nodes. 38

(There is a shortcut for calculating it, but not now……later…)

Calculate Cyclomatic complexity

39
Calculate Cyclomatic complexity

40
Calculate Cyclomatic complexity
Path 1: 1,2,3,5,6, 7
Path 2: 1,2,4,5,6, 7
Path 3: 1, 6, 7

Steps for Basis Path testing

The basic steps involved in basis path testing include

Draw a control graph (to determine different program paths)

Calculate Cyclomatic complexity (metrics to determine the
number of independent paths)
Find a basis set of paths
Generate test cases to exercise each path

41
Calculate Cyclomatic complexity

i = 0;
n=4; //N-Number of nodes present in the graph

while (i<n-1) do
j = i + 1;

while (j<n) do

if A[i]<A[j] then
swap(A[i], A[j]);

end do;
j=j+1;

end do;

42
Calculate Cyclomatic complexity
Computing mathematically,

V(G) = 9 – 7 + 2 = 4
V(G) = 3 + 1 = 4 (Condition nodes are 1,2 and 3 nodes)
Basis Set – A set of possible execution path of a program
1, 7
1, 2, 6, 1, 7
1, 2, 3, 4, 5, 2, 6, 1, 7
1, 2, 3, 5, 2, 6, 1, 7

43
Calculate Cyclomatic complexity

IF A = 10 THEN

IF B > C THEN

A=B

ELSE

A=C

ENDIF

ENDIF

Print A

Print B
44
Print C
Complexity Number Meaning

Structured and well written code

1-10 High Testability
Cost and Effort is less

Complex Code
10-20 Medium Testability
Cost and effort is Medium

Very complex Code

20-40 Low Testability
Cost and Effort are high

Not at all testable

>40 45
Very high Cost and Effort
Conclusion
❑ Now what do we conclude by doing all
this:
 Does 100 % statement coverage ensures
no bugs?
 Answer is NO. 100% statement coverage
just ensure every statement is executed
at least once BUT it doesn’t guarantee
that all the conditions are tested for
different combination of data and hence
it is not the most efficient method

46
Conclusion
❑ Does 100 % branch coverage ensures no
bugs?
 Answer is again NO. 100 % branch
coverage is certainly better than
statement coverage and more efficient
but it only ensures that each branch is
executed at least once but again it
doesn’t cover all the possible
combinations (like two Ifs can be tested
with 2 branch test case for TT, FF where
as total possible combination will be 4
(TT,TF,FT,FF) which are not getting
covered here)
47