LECTURE NOTES ON

SUBJECT: SOFTWARE ENGINEERING

SUBJECT CODE: BCS-601
Unit-3
[Link]
BRANCH: CSE
YEAR- 3RD SEMESTER- 6th

(AKTU)

Mr. Rahul Dubey

(Assistant Professor)

Department of Computer Science & Engineering

Maharana Pratap Engineering College, Kanpur

 Unit-3

Software Design
3.1 Basic Concept of Software Design

Software Design
Software design is a process to transform user requirements into some suitable form, which
helps the programmer in software coding and [Link] design phase designer plans
“How” a software system should be produced in order to make it functional, reliable reasonably
easy to understand, modify and maintain. A software Requirements Specification (SRS)
document becomes input to the design process which tells us “How” a software system works.
The result of design process is a Software Design Document (SDD). Thus, the purpose of design
phase is to produce a solution to the problem given in SRS document.
Design Framework
It starts with initial requirements and ends with the final design.

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 2
Objectives of Software Design:

1. Correctness: A good design should be correct i.e. it should correctly implement all the
functionalities of the system.
2. Efficiency: A good software design should address the resources, time and cost optimization
issues.
3. Understandability: A good design should be easily understandable, for which it should be
modular and all modules are arranged in layers.
4. Completeness: The design should have all the components like data structures, modules, and
external interfaces, etc.
5. Maintainability: A good software design should be easily amenable to change whenever a
change request is made from the customer side.

Conceptual and Technical Designs

To transform requirements into a working system, designers must satisfy both the customers
and the system builders. For this reason, design is really a two-part, iterative process. First, we produce
conceptual design the customer exactly what the system will do. Once the customer approves the
conceptual design it translated into technical design to understand for system builders.

Different levels of Software Design

There are three different levels of software design. They are:

1. Architectural Design: The architecture of a system can be viewed as the overall structure of
the system and the way in which structure provides conceptual integrity of the system. The
architectural design identifies the software as a system with many components interacting with
each other. At this level, the designers get the idea of the proposed solution domain.

2. Preliminary or high-level design: Here the problem is decomposed into a set of modules, the
control relationship among various modules identified, and also the interfaces among various
modules are identified. The outcome of this stage is called the program architecture. Design
representation techniques used in this stage are structure chart and UML.

3. Detailed design or Low-Level Design (LLD): Detailed design, is the stage in software
development where the high-level architectural design is translated into specific
implementation details. Once the high-level design is complete, a detailed design is undertaken.
In detailed design, each module is examined carefully to design the data structure and
algorithms. The stage outcome is documented in the form of a module specification document.

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 3
Architectural Design
• Architectural design is an early stage of the system design process. It represents the link
between specification and design processes and is often carried out in parallel with some
specification activities.
• The process of defining a collection of hardware and software components and their interfaces
to establish the framework for the development of a computer system.
• The output of this design process is a description of the software architecture. It represents the
link between specification and design processes and is often carried out in parallel with some
specification activities.

Architectural Design V/s Low-Level Design (LLD)

Feature Architectural Design Low-Level Design (LLD)

Scope Whole system structure Individual components/modules
Abstraction
High-level, conceptual Detailed, close to code
Level
Overall system layout & technology
Focus Internal logic, algorithms, data structures
choices
Audience Architects, tech leads, senior engineersDevelopers, software engineers
Class diagrams, pseudocode, sequence
Output Artifacts System architecture diagrams, tech stack
diagrams
Modules, services, communication Functions, classes, methods, internal
Includes
mechanisms workflows
3-tier architecture using REST APIs & UserService class with registerUser()
Example
Kafka method
Timing Early in the design phase After architectural design, before coding
Concerns Scalability, security, system integration Efficiency, maintainability, error handling

Modularization

Modularization is a technique to divide a software system into multiple discrete and

independent modules, which are expected to be capable of carrying out task(s) independently.
These modules may work as basic constructs for the entire software. Designers tend to design
modules such that they can be executed and/or compiled separately and independently.

Modularity is the single attribute of software that allows a program to be intellectually

manageable. It enhances design clarity, which in turn eases implementation, debugging,
testing, documenting, and maintenance of software product.
Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 4
 Modular design unintentionally follows the rules of ‘divide and conquer’ problem-solving
strategy this is because there are many other benefits attached with the modular design of a
software.

Relationship Between cost/effort and number of modules

As the number of modules grows, the effort associated with integrating the module also grows.
This can graphically show as-

Advantage of modularization:

• Smaller components are easier to maintain

• Program can be divided based on functional aspects
• Desired level of abstraction can be brought in the program
• Components with high cohesion can be re-used again
• Concurrent execution can be made possible
• Desired from security aspect

Concurrency

Back in time, all software is meant to be executed sequentially. By sequential execution we

mean that the coded instruction will be executed one after another implying only one portion
of program being activated at any given time. Say, a software has multiple modules, then only
one of all the modules can be found active at any time of execution.

In software design, concurrency is implemented by splitting the software into multiple

independent units of execution, like modules and executing them in parallel. In other words,
concurrency provides capability to the software to execute more than one part of code in
parallel to each other. It is necessary for the programmers and designers to recognize those
modules, which can be made parallel execution.

Example
The spell check feature in word processor is a module of software, which runs alongside the
word processor itself. Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 5
Module Coupling and Cohesion

When a software program is modularized, its tasks are divided into several modules based on
some characteristics. As we know, modules are set of instructions put together in order to
achieve some tasks. They are though, considered as single entity but may refer to each other
to work together. There are measures by which the quality of a design of modules and their
interaction among them can be measured. These measures are called coupling and cohesion.

Coupling

Coupling is the measure of the degree of interdependence between software modules. Two
modules that are tightly coupled are strongly dependent on each other. However, two modules
that are loosely coupled are not dependent on each other. Uncoupled modules have no
interdependence at all within them.

The various types of coupling techniques are shown in fig:

A good design is the one that has low coupling. Coupling is measured by the number of
relations between the modules. That is, the coupling increases as the number of calls between
modules increase or the amount of shared data is large. Thus, it can be said that a design with
high coupling will have more errors.

Types of Module Coupling

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 6
 1. No Direct Coupling: There is no direct coupling between M1 and M2.

In this case, modules are subordinates to different modules. Therefore, no direct coupling.

2. Data Coupling: When data of one module is passed to another module, this is called data
coupling

3. Stamp Coupling: Two modules are stamp coupled if they communicate using composite
data items such as structure, objects, etc. When the module passes non-global data structure
or entire structure to another module, they are said to be stamp coupled. For example, passing
structure variable in C or object in C++ language to a module.

4. Control Coupling: Control Coupling exists between two modules if data from one module
is used to direct the structure of instruction execution in another.

5. External Coupling: External Coupling arises when two modules share an externally
imposed data format, communication protocols, or device interface. This is related to
communication to external tools and devices.

6. Common Coupling: Two modules are common coupled if they share information through
some global data items.

7. Content Coupling: Content Coupling exists among two modules if they share code or one
module changes data of another module. e.g., a branch from one module into another module.
Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 7
 Module Cohesion

In computer programming, cohesion defines to the degree to which the elements of a

module belong together. Thus, cohesion measures the strength of relationships between
pieces of functionality within a given module. For example, in highly cohesive systems,
functionality is strongly related.

Cohesion is an ordinal type of measurement and is generally described as "high

cohesion" or "low cohesion."

Types of Modules Cohesion

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 8
 1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of
a module, cooperate to achieve a single function.
2. Sequential Cohesion: A module is said to possess sequential cohesion if the element
of a module forms the components of the sequence, where the output from one
component of the sequence is input to the next.
3. Communicational Cohesion: A module is said to have communicational cohesion, if
all tasks of the module refer to or update the same data structure, e.g., the set of
functions defined on an array or a stack.
4. Procedural Cohesion: A module is said to be procedural cohesion if the set of purpose
of the module are all parts of a procedure in which particular sequence of steps has to
be carried out for achieving a goal, e.g., the algorithm for decoding a message.
5. Temporal Cohesion: When a module includes functions that are associated by the fact
that all the methods must be executed in the same time, the module is said to exhibit
temporal cohesion.
6. Logical Cohesion: A module is said to be logically cohesive if all the elements of the
module perform a similar operation. For example, Error handling, data input and data
output, etc.
7. Coincidental Cohesion: A module is said to have coincidental cohesion if it performs
a set of tasks that are associated with each other very loosely, if at all.

Differentiate between Coupling and Cohesion

Coupling Cohesion

Coupling is also called Inter-Module Binding. Cohesion is also called Intra-Module Binding.

Coupling shows the relationships Cohesion shows the relationship within

between modules. the module.
Coupling shows the relative independence Cohesion shows relative the module's
between the modules. functional strength.

While creating, you should aim for low coupling, While creating you should aim for high
i.e., dependency among modules should be less. cohesion, i.e., a cohesive component/ module
focuses on a single function (i.e., single-
mindedness) with little interaction with
other modules of the
system.
In coupling, modules are linked to the other In cohesion, the module focuses on a single
modules. thing.

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 9
 Design Verification
The output of software design process is design documentation, pseudo codes, detailed logic
diagrams, process diagrams, and detailed description of all functional or non-functional requirements.
The next phase, which is the implementation of software, depends on all outputs mentioned above.
It then becomes necessary to verify the output before proceeding to the next phase. The early any
mistake product. If the outputs of design phase are in formal notation form, then their associated tools
for verification should be used otherwise a thorough design review can be used for verification and
validation.
By structured verification approach, reviewers can detect defects that might be caused by overlooking
some conditions. A good design review is important for good software design, accuracy and quality.
Design Structure Charts

It partitions a system into block boxes. A Black box system that functionality is known to the user
without the knowledge of internal design.

Structured Chart is a graphical representation which shows:

• Partitions of system into modules

• Hierarchy of component modules
• The relation between processing modules
• Interaction between modules
• Information passed between modules

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 10
 The following notations are used in structured chart:

Pseudo Codes
Pseudocode notation can be used in both the preliminary and detailed design phases. Using
pseudocode, the designer describes system characteristics using short, concise, English language
phrases that are structured by key words such as It-Then-Else, While-Do, and End.
Thus, A Pseudocode is defined as a step-by-step description of an algorithm. Pseudocode does
not use any programming language in its representation instead it uses the simple English
language text as it is intended for human understanding rather than machine reading.
Pseudocode is the intermediate state between an idea and its implementation(code) in a high-
level language.
Flow Charts
A flowchart is a graphical representation of an algorithm. It should follow some rules while
creating a flowchart
• Rule 1: Flowchart opening statement must be ‘start’ keyword.
• Rule 2: Flowchart ending statement must be ‘end’ keyword.
• Rule 3: All symbols in the flowchart must be connected with an arrow line.
• Rule 4: Each decision point should have two or more distinct outcomes.
• Rule 5: Flow should generally move from top to bottom or left to right.
Flowchart Symbols

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 11
 Design Strategies

System Design Strategy refers to the approach that is taken to design a software system. There are
several strategies that can be used to design software systems, including the following:
1. Top-Down Design: This strategy starts with a high-level view of the system and gradually
breaks it down into smaller, more manageable components.
2. Bottom-Up Design: This strategy starts with individual components and builds the system
up, piece by piece.
3. Function Oriented Design: This strategy builds the system from a functional viewpoint.

Function Oriented Design

Function Oriented design is a method to software design where the model is decomposed into
a set of interacting units or modules where each unit or module has a clearly defined function.
Thus, the system is designed from a functional viewpoint.
Design Notations

Design Notations are primarily meant to be used during the process of design and are used to
represent design or design decisions. For a function-oriented design, the design can be
represented graphically or mathematically by the following:

Data Flow Diagram

Data-flow design is concerned with designing a series of functional transformations that convert system
inputs into the required outputs. The design is described as data-flow diagrams. These diagrams show
how data flows through a system and how the output is derived from the input through a series of
functional transformations.

Data-flow diagrams are a useful and intuitive way of describing a system. They are generally
understandable without specialized training, notably if control information is excluded. They show
end-to-end processing. That is the flow of processing from when data enters the system to where it
leaves the system can be traced.
Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 12
Data-flow design is an integral part of several design methods, and most CASE tools support
data-flow diagram creation. Different ways may use different icons to represent data-flow
diagram entities, but their meanings are similar.

The notation used on DFD:

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 13
The report generator produces a report which describes all of the named entities in a data-flow
diagram. The user inputs the name of the design represented by the diagram. The report
generator then finds all the names used in the data-flow diagram. It looks up a data dictionary
and retrieves information about each name. This is then collated into a report which is output
by the system.

Data Dictionaries

A data dictionary lists all data elements appearing in the DFD model of a system. The data
items listed contain all data flows and the contents of all data stores looking on the DFDs in
the DFD model of a system.

A data dictionary lists the objective of all data items and the definition of all composite data
elements in terms of their component data items. For example, a data dictionary entry may
contain that the data grossPay consists of the parts regularPay and overtimePay.

grossPay = regularPay + overtimePay

For the smallest units of data elements, the data dictionary lists their name and their type.

A data dictionary plays a significant role in any software development process because of the
following reasons:

• A Data dictionary provides a standard language for all relevant information for use by
engineers working in a project. A consistent vocabulary for data items is essential since,
in large projects, different engineers of the project tend to use different terms to refer to
the same data, which unnecessarily causes confusion.
• The data dictionary provides the analyst with a means to determine the definition of
various data structures in terms of their component elements.

Object-Oriented Design
In the object-oriented design method, the system is viewed as a collection of objects (i.e.,
entities). The state is distributed among the objects, and each object handles its state data. For
example, in a Library Automation Software, each library representative may be a separate
object with its data and functions to operate on these data. The tasks defined for one purpose
cannot refer or change data of other objects. Objects have their internal data which represent
their state. Similar objects create a class. In other words, each object is a member of some class.
Classes may inherit features from the superclass.

The different terms related to object design are:

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 14
 1. Objects: All entities involved in the solution design are known as objects. For example,
person, banks, company, and users are considered as objects. Every entity has some
attributes associated with it and has some methods to perform on the attributes.
2. Classes: A class is a generalized description of an object. An object is an instance of a
class. A class defines all the attributes, which an object can have and methods, which
represents the functionality of the object.
3. Messages: Objects communicate by message passing. Messages consist of the integrity
of the target object, the name of the requested operation, and any other action needed
to perform the function. Messages are often implemented as procedure or function calls.
4. Abstraction In object-oriented design, complexity is handled using abstraction.
Abstraction is the removal of the irrelevant and the amplification of the essentials.
5. Encapsulation: Encapsulation is also called an information hiding concept. The data
and operations are linked to a single unit. Encapsulation not only bundles essential
information of an object together but also restricts access to the data and methods from
the outside world.
6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner where
the lower or sub-classes can import, implement, and re-use allowed variables and
functions from their immediate super classes. This property of OOD is called an
inheritance. This makes it easier to define a specific class and to create generalized
classes from specific ones.
7. Polymorphism: OOD languages provide a mechanism where methods performing
similar tasks but vary in arguments, can be assigned the same name. This is known as
polymorphism, which allows a single interface is performing functions for different
types. Depending upon how the service is invoked, the respective portion of the code
gets executed.
Top-Down and Bottom-Up Design

A good system design is to organize the program modules in such a way that are easy to develop
and change. Structured design techniques help developers to deal with the size and complexity
of programs. Analysts create instructions for the developers about how code should be written
and how pieces of code should fit together to form a program.
Importance:

1. If any pre-existing code needs to be understood, organized and pieced together.

2. It is common for the project team to have to write some code and produce original
programs that support the application logic of the system.

There are many strategies or techniques for performing system design. They are:

Bottom-up approach:

The design starts with the lowest level components and subsystems. By using these components, the
next immediate higher-level components and subsystems are created or composed. The process is
continued till all the components and subsystems are composed into a single component, which is
considered as the complete system. The amount of abstraction grows high as the design moves to
more high levels.

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 15
By using the basic information existing system, when a new system needs to be created, the bottom-
up strategy suits the purpose.

Advantages:
• The economics can result when general solutions can be reused.
• It can be used to hide the low-level details of implementation and be merged with top-down
technique.
Disadvantages:
• It is not so closely related to the structure of the problem.
• High quality bottom-up solutions are very hard to construct.
• It leads to proliferation of ‘potentially useful’ functions rather than most appropriate ones.

Top-down approach:

In top-down approach system is divided into several subsystems and components. Each of the
subsystem is further divided into set of subsystems and components. This process of division facilitates
in forming a system hierarchy structure. The complete software system is considered as a single entity
and in relation to the characteristics, the system is split into sub-system and component. The same is
done with each of the sub-system.

This process is continued until the lowest level of the system is reached. The design is started initially
by defining the system as a whole and then keeps on adding definitions of the subsystems and
components. When all the definitions are combined together, it turns out to be a complete system.

For the solutions of the software need to be developed from the ground level, top- down design best
suits the purpose.

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 16
Advantages:
• The main advantage of top-down approach is that its strong focus on requirements helps to
make a design responsive according to its requirements.
Disadvantages:
• Project and system boundaries tend to be application specification oriented. Thus, is more
likely that advantages of component reuse will be missed.
• The system is likely to miss, the benefits of a well-structured, simple architecture.

Hybrid Design:

It is a combination of both the top – down and bottom – up design strategies. In this we can reuse the
modules.

Software Measurement and Metrics:

Measurement is fundamental to any engineering discipline. We measure the software because of the
following
• To establish the quality of the current product or process
• To predict future qualities of the product or process.
• To improve the quality of a product or process.
• To determine the state of the project in relation to budget and schedule.

A metric is not just a number. It is a quantitative function that calculates some characteristic and
produces a numeric measurement which will be used to make a decision. A software metric is a
measure of software characteristics which are measurable or countable. Within the software
development process, many metrics are that are all connected.

For software product development, metrics fall into three broad categories:

1. Product Metrics: These are the measures of various characteristics of the software product.
These describe the characteristics of the software product, such as size, complexity, design
features, performance, efficiency, reliability, portability etc. These metrics can be computed
for different stages of SDLC.
2. Process Metrics: Activities related to production of software like effort required in the process,
time to produce the product, number of defects found during testing, effectiveness of defect
removal during development, maturity of the process
3. Project Metrics: Describe the project characteristics and execution like number of software
developers, cost and schedule, productivity.

Generally, they are categorized into two broad categories: -

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 17
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.

Advantage of Software Metrics

• Comparative study of various design methodology of software systems.
• For analysis, comparison, and critical study of different programming language concerning
their characteristics.
• In comparing and evaluating the capabilities and productivity of people involved in software
development.
• In the preparation of software quality specifications.
• In making inference about the effort to be put in the design and development of the software
systems.
• In getting an idea about the complexity of the code.
• In taking decisions regarding further division of a complex module is to be done or not.
Including resource manager for their proper utilization.

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 18
Disadvantage of Software Metrics

• The application of software metrics is not always easy, and in some cases, it is difficult and
costly. The verification and justification of software metrics are based on historical/empirical
data whose validity is difficult to verify.
• These are useful for managing software products but not for evaluating the performance of the
technical staff. The definition and derivation of Software metrics are usually based on
assuming which are not standardized and may depend upon tools available and working
environment.
• Most of the predictive models rely on estimates of certain variables which are often not
known precisely.

Various Size Oriented Measures:

LOC Metrics

It is one of the earliest and simpler metrics for calculating the size of the computer program. A line of
code (LOC) is any line of text in a code that is not a comment or blank line, regardless of the number
of statements or fragments of statements on the line. LOC consists of all lines containing the
declaration of any variable, and executable and non-executable statements.
Example- Consider the following code-

Void main()
{
int fN, sN, tN;
cout << "Enter the 2 integers: ";
cin >> fN >> sN;
// sum of two numbers in stored in variable sum
sum = fN + sN;
// Prints sum
cout << fN << " + " << sN << " = " << sum;
return 0;
}

Here also, If LOC is simply a count of the numbers of lines, then the above function shown contains
11 lines of code (LOC). But when comments and blank lines are ignored, the function shown above
contains 9 lines of code (LOC).

Advantages LOC are as follows:

1. It is widely used and universally accepted.
2. It permits comparison of size and productivity metrics between diverse development groups.
3. It directly relates to the end product.
4. LOC are easily measured upon project completion.
5. It measures software from the developer’s point of view- what he actually does (write line of
codes).
Disadvantages of using line of code as a unit of sizing of software.
1. Difficult to measure LOC in the early stages of a new product.
2. Source instructions vary with coding languages, design methods and with programmer’s ability.
3. No industry standard for measuring LOC.
4. LOC cannot be used for normalizing if platforms and languages are different.
Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 19
 Based on the LOC/KLOC count of software, many other metrics can be computed as:

a. Errors/KLOC.
b. $/ KLOC.
c. Defects/KLOC.
d. Pages of documentation/KLOC.
e. Errors/PM.
f. Productivity = KLOC/PM (effort is measured in person-months).
g. $/ Page of documentation.

Halstead's Software Metrics

Halstead’s software science is an analytical technique to measure size, development effort, and
development cost of software products. Halstead used a few primitive parameters to develop the
expressions for over all program length, potential minimum volume, actual volume, language level,
effort and development time.

For a given program, let η₁ be the number of unique operators used in the program, η₂ be the number
of unique operands used in the program, N₁ be the total number of operators used in the program, and
N₂ be the total number of operands used in the program.

For Example-

int func(int a, int b)

{
...
}

For the above example code, the operators are: {}, (). We do not consider func, a, and b as operands,
since these are a part of the function definition.

In terms of the total tokens used, the size of the program can be expressed as N = N1 + N2.
Halstead metrics are:
a. Length and Vocabulary
The length of a program as defined by N = N₁ + N₂
The program vocabulary is the number of unique operators and operands used in the program.
Thus, program vocabulary η = η₁ + η₂.
b. Program Volume
The program volume V is the minimum number of bits needed to encode the program.
V= Nlog2 η
c. Potential Minimum Volume
The potential minimum volume V* is defined as the volume of the most succinct program in
which a problem can be coded.

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 20
 If an algorithm operates on input and output data d₁, d₂,..., dₙ, the most succinct program would
be f(d₁, d₂,..., dₙ); for which η₁ = 2, η₂ = n. Therefore,

V*=(2+η2) log2 (2+η2)

The program level L is given by:

L= V*/ V
d. Effort and Time

The effort required to develop a program can be obtained by dividing the program volume with
the level of the programming language used to develop the code. Thus, effort E = V / L=V2/V*,
where E is the number of mental discriminations required to implement the program and also the
effort required to read and understand the program.

The programmer’s time T = E / S, where S is the speed of mental discriminations.

The value of S has been empirically developed from psychological reasoning, and its
recommended value for programming applications is 18.

e. Length Estimation
Halstead suggests a way to determine the length of a program using the number of unique
operators and operands used in the program.

f. 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= (η1/2) * (N2/ η2)

Functional Point (FP) Analysis

Allan J. Albrecht initially developed function Point Analysis in 1979 at IBM and it has been
further modified by the International Function Point Users Group (IFPUG). FPA is used to
make estimate of the software project, including its testing in terms of functionality or function
size of the software product. However, functional point analysis may be used for the test
estimation of the product. The functional size of the product is measured in terms of the
function point, which is a standard of measurement to measure the software application.

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.
Further, it is used to measure the software project development along with its maintenance,
consistently throughout the project irrespective of the tools and the technologies.

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 21
 Following are the points regarding FPs

1. FPs of an application is found out by counting the number and types of functions used in the
applications. Various functions used in an application can be put under five types, as shown in
Table:

Types of FP Attributes

Measurements Parameters Examples

[Link] of External Inputs (EI) Input screen and tables

2. Number of External Output (EO) Output screens and reports

3. Number of external inquiries (EQ) Prompts and interrupts.

4. Number of internal files (ILF) Databases and directories
5. Number of external interfaces (EIF) Shared databases and shared routines.

All these parameters are then individually assessed for complexity.

The FPA functional units are shown in Fig:

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.

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 22
7. All the parameters mentioned above are assigned some weights that have been
experimentally determined and are shown in Table

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

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 23
 The functional complexities are multiplied with the corresponding weights against each function, and
the values are added up to determine the UFP (Unadjusted Function Point) of the subsystem.

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:

a. Errors/FP
b. $/FP.
c. Defects/FP
d. Pages of documentation/FP
Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 24
 e. Errors/PM.
f. Productivity = FP/PM (effort is measured in person-months).
g. $/Page of Documentation.

8. LOCs of an application can be estimated from FPs. That is, they are interconvertible. This
process is known as backfiring. For example, 1 FP is equal to about 100 lines of COBOL code.

9. FP metrics is used mostly for measuring the size of Management Information System (MIS)
software.

10. But the function points obtained above are unadjusted function points (UFPs). These (UFPs)
of a subsystem are further adjusted by considering some more General System Characteristics
(GSCs). It is a set of 14 GSCs that need to be considered. The procedure for adjusting UFPs is
as follows:

a. Degree of Influence (DI) for each of these 14 GSCs is assessed on a scale of 0 to 5. (b) If a
particular GSC has no influence, then its weight is taken as 0 and if it has a strong influence
then its weight is 5.
b. The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI).
c. Then Value Adjustment Factor (VAF) is computed from TDI by using the formula:
VAF = (TDI * 0.01) + 0.65

Remember that the value of VAF lies within 0.65 to 1.35 because

a. When TDI = 0, VAF = 0.65

b. When TDI = 70, VAF = 1.35
c. VAF is then multiplied with the UFP to get the final FP count: FP = VAF * UFP

Example: Compute the function point, productivity, documentation, cost per function for the
following data:
1. Number of user inputs = 24
2. Number of user outputs = 46
3. Number of inquiries = 8
4. Number of files = 4
5. Number of external interfaces = 2
6. Effort = 36.9 p-m
7. Technical documents = 265 pages
8. User documents = 122 pages
9. Cost = $7744/ month

Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 25
 Solution:

Measurement Parameter Count Weighing factor

1. Number of external inputs (EI) 24 * 4 = 96

2. Number of external outputs (EO) 46 * 4 = 184

3. Number of external inquiries (EQ) 8 * 6 = 48

4. Number of internal files (ILF) 4 * 10 = 40

5. Number of external interfaces (EIF) 2 * 5 = 10

Count-total → 378

So, sum of all fi (i ← 1 to 14) = 4 + 1 + 0 + 3 + 5 + 4 + 4 + 3 + 3 + 2 + 2 + 4 + 5 = 43

FP = Count-total * [0.65 + 0.01 *∑(fi)]

= 378* [0.65 + 0.01 * 43]
= 378*[0.65+0.43]
= 378 * 1.08 = 408

Total pages of documentation = technical document + user document

= 265 + 122 = 387pages

Documentation = Pages of documentation / FP

= 387/408 = 0.94

Differentiate between FP and LOC

FP LOC

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 26
 1. FP is specification based. 1. LOC is an analogy based.

2. FP is language independent. 2. LOC is language dependent.

3. FP is user-oriented. 3. LOC is design-oriented.

4. It is extendible to LOC. 4. It is convertible to FP (backfiring)

Cyclomatic Complexity
Cyclomatic complexity is a software metric used to measure the complexity of a program. Thomas J.
McCabe developed this metric in [Link] interprets a computer program as a set of a strongly
connected directed graph. Nodes represent parts of the source code having no branches and arcs represent
possible control flow transfers during program execution. The notion of program graph has been used for
this measure, and it is used to measure and control the number of paths through a program. The complexity
of a computer program can be correlated with the topological complexity of a graph.
How to Calculate Cyclomatic Complexity?

McCabe proposed the cyclomatic number, V (G) of graph theory as an indicator of software complexity.
The cyclomatic number is equal to the number of linearly independent paths through a program in its
graph’s representation. For a program control graph G, cyclomatic number, V (G), is given as:

V (G) = E - N + 2 * P

E= The number of edges in graphs G

N = The number of nodes in graphs G

P = The number of connected components in graph G.

Example:

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 27
Properties of Cyclomatic complexity:

Following are the properties of Cyclomatic complexity:

1. V (G) is the maximum number of independent paths in the graph

2. V (G) >=1
3. G will have one path if V (G) = 1
4. Minimize complexity to 10
5. to calculate Cyclomatic complexity of a program module, we use the formula –
V(G) = e – n + 2, where e is total number of edges, n is total number of nodes

The Cyclomatic complexity of the above module is- Here e=10, n=8
Cyclomatic Complexity = 10 - 8 + 2 =4
According to P. Jorgensen, Cyclomatic Complexity of a module should not exceed 10.

Prepared By:
Mr. Rahul Dubey
Assistant Professor (MPEC) 28