Software

Engineering
Unit 3
By
Shivani Agarwal
 Software Design
• Software Design is the process to transform the user requirements into some
suitable form, which helps the programmer in software coding and
implementation.
• During the software design phase, the design document is produced, based on
the customer requirements as documented in the SRS document. Hence the
aim of this phase is to transform the SRS document into the design document.
• The following items are designed and documented during the design phase:
• Different modules required.
• Control relationships among modules.
• Interface among different modules.
• Data structure among the different modules.
• Algorithms required to implement among the individual modules.
 Software Design Concepts
• The software design concept simply means the idea or principle
behind the design. It describes how you plan to solve the problem of
designing software, the logic, or thinking behind how you will design
software.
• It allows the software engineer to create the model of the system or
software or product that is to be developed or built.
• The software design concept provides a supporting and essential
structure or model for developing the right software. There are many
concepts of software design and some of them are given below:
Software Design Concepts: Abstraction-
hide details
• Abstraction simply means to hide the details to reduce
complexity and increases efficiency or quality.
• Different levels of Abstraction are necessary and must be
applied at each stage of the design process so that any error
that is present can be removed to increase the efficiency of
the software solution and to refine the software solution.
• The solution should be described in broadways that cover a
wide range of different things at a higher level of abstraction
and a more detailed description of a solution of software
should be given at the lower level of abstraction.
Software Design Concepts: Modularity- subdivide the system

Modularity simply means to divide the system or

project into smaller parts to reduce the complexity of
the system or project.

In the same way, modularity in design means to

subdivide a system into smaller parts so that these
parts can be created independently and then use these
parts in different systems to perform different
functions.
It is necessary to divide the software into components
known as modules because nowadays there are
different software available like Monolithic software
that is hard to grasp for software engineers.
Software Design Concepts: Modularity- Architecture- design a structure of
something

Architecture simply means a technique to

design a structure of something.
Architecture in designing software is a
concept that focuses on various elements
and the data of the structure.
These components interact with each other
and use the data of the structure in
architecture.
 Software Design Concepts: Refinement- removes impurities

Refinement simply means to refine something to remove

any impurities if present and increase the quality.

The refinement concept of software design is a process of

developing or presenting the software or system in a
detailed manner that means to elaborate a system or
software.

Refinement is very necessary to find out any error if

present and then to reduce it.
Software Design Concepts: Pattern- a repeated form

The pattern simply The pattern in the

means a repeated design process
form or design in means the repetition
which the same of a solution to a
shape is repeated common recurring
several times to form problem within a
a pattern. certain context.
Software Design Concepts: Information Hiding- hide the information

Information hiding simply means to

hide the information so that it cannot
be accessed by an unwanted party.
In software design, information hiding is
achieved by designing the modules in a
manner that the information gathered or
contained in one module is hidden and it
can't be accessed by any other modules.
Software Design Concepts: Refactoring- reconstruct something

Refactoring simply means to reconstruct something in

such a way that it does not affect the behavior or any
other features.

Refactoring in software design means to reconstruct

the design to reduce and complexity and simplify it
without affecting the behavior or its functions.

Fowler has defined refactoring as “the process of

changing a software system in a way that it won’t
affect the behavior of the design and improves the
internal structure”.
Levels of Software Design
Prelimina
Architect ry or
ural high-
Design level
design
Detailed
design
 Levels of Software Design: Architectural Design

The architecture of a system can be viewed as the overall

structure of the system & 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.
Levels of Software Design: High-level design 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.
 Levels of Software Design: Detailed Design

Once the high-level design is complete,

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.
 Coupling
 In software engineering, the coupling is the degree of interdependence between software
modules. Two modules that are tightly coupled are strongly dependent on each other.
 Two modules that are loosely coupled are not dependent on each other. Uncoupled modules have
no interdependence at all within them.
 A good design is the one that has low coupling. Coupling is measured by the number of relations
between the modules.
 As 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.
• Good design requirement – Modules should loosely coupled. i.e. should kept
as independent as possible.
Types of Coupling
 Data Coupling
• Occurs when module passes non-global variable to another
module.
• Two independent Modules can only communicate through passing
data elements example Customer billing System
 Stamp Coupling

• Occurs when module passes non-global data structure or

entire structure to another module.
• Here, modules are more dependent on each other.
• Exposes modules to more data than they need.
• A change in data structure will affect all modules that use
it.
 Control Coupling
• Occurs when module passes control flags or switches to
another modules.
• The sending module must know a great deal of about the
inner workings of the receiving module.
 External Coupling
• In external coupling, the modules depend on other modules, external to the software
being developed or to a particular type of hardware. Ex- protocol, external file, device
format, etc.
 Common Coupling
• Occurs when modules refer to the same global data area or data
structure
• Modules that use the same area have quite high level of
interdependence.
• This is undesirable as errors can spread throughout the system.
 Content Coupling
• Occurs when one module directly refer to the inner workings of
another module.
• Modules are highly interdependent to each other.
• One module can alter data in other module or change a statement
coded in other module.
 Cohesion
• Cohesion is the measure of strength of the association of elements within a module
• In other words, the extent to which all instructions in a module relate to a single function.
• In a truly cohesive module, all of the instructions in the module pertain to performing a
single task.
• Cohesion in modules should me maximized.
Types of Cohesion
 Functional cohesion
• The name of the module will indicate its function
• All statements within a module are based on one function.
• It is the best cohesion
• Functions like "compute square root" and "sort the array" are clear examples of
functionally cohesive modules.
• Ex- CALCULATE_SALES_TAX
IF PRODUCT IS SALES_TAX EXEMPT THEN
SALES_TAX = 0
ELSE
IF PRODUCT_PRICE <100 THEN
SALES_TAX = PRODUCT_PRICE * 0.25
ENDIF
ENDIF
Sequential Cohesion
• The instruction inside a module are related to each other thorough the input
data.
• The output from first instruction becomes input to the second and so on.
• Sequence of events is very important.
Ex – TOTAL_PURCHASES =0
READ NO_OF_PURCHASES
DO LOOP_INDEX = 1 TO NO_OF_PURCHASES
GET PURCHASES
ADD PURCHASES TO TOTAL_PURCHASES
ENDDO
SALES_TAX = TOTAL_PURCHASES * SALES_TAX_PERCENTAGES
AMT_DUE = TOTAL_PURCHASES + SALES_TAX
END
Communicational
Cohesion
• The activities are related to each other by the data that the modules uses.
• A module with communicational cohesion has elements that are related by a reference to the same input or output data.
• That is, in a communicational bound module, the elements are together because they operate on the same input or output
data.
• Sequence is not important

Ex- VALIDATE_PRODUCT_REC
IF TRANS_TYPE NOT = ‘0’ THEN
WRITE _ERR_REPORT
ENDIF
IF CUST_NO NOT NUMERIC THEN
WRITE_ERR_REPORT
ENDIF
IF PRODUCT_NO = BLANKS
WRITE_ERR_REPORT
ENDIF
END
 Procedural Cohesion
• A procedurally cohesive module contains elements that belong to a common procedural unit.
• For example, a loop or a sequence of decision statements in a module may be combined to
form a separate module.
• Procedurally cohesive modules often occur when modular structure is determined from
some form of flowchart.
• Procedural cohesion often cuts across functional hues.
• A module with only procedural cohesion may contain only part of a complete function or
parts of several functions.
Ex- READ_STUD_REC _AND_TOTAL_STUDENT _AGES
NO_OF_REC = 0
TOTAL_AGE = 0
READ STUD_REC
DO WHILE MORE_REC_EXIST
ADD AGE TO TOTAL_AGE
ADD 1 TO NO_OF_REC
READ STUD_REC
ENDDO
END
Temporal Cohesion
• Modules that perform activities like "initialization," "clean-up," and
"termination" are usually temporally bound.
• Even though the elements in a temporally bound module are logically related,
temporal cohesion is higher than logical cohesion, because the elements are
all executed together.
• This avoids the problem of passing the flag, and the code is usually simpler.
• – INITIALIZATION
OPEN TRANS_FILE
ISSUE PROMPT ‘ENTER DATE – DDMMYY’
READ TODAYS_DATE
SET TRANS_COUNT TO 0
SET REPORT_TOTAL TO 0
OPEN REPORT_FILE
END
 Logical Cohesion
• The instructions are hardly related to each other at all
• The instructions are grouped together due to certain classes or activities.
• A flag that is passed from outside will determine which set of instructions is
to be executed.
Ex – READ_ALL_FILES
CASE OF FILE_CODE
1: READ CUST_TRAN_REC
IF NOT EOF
INCREMENT CUST_TRAN_COUNT
ENDIF
2: READ CUST_MASTER_REC
IF NOT EOF
INCREMENT CUST_MASTER_COUNT
ENDIF
END CASE
END
Coincidental Cohesion
• The instructions have no relationship to each other at all, it is just a coincidence they
fall in the same module.
• It is the worst type of cohesion.
Ex- FILE PROCESSING
OPEN EMPLOYEE_UPDATE FILE
READ EMPLOYEE REC
PRINT_PAGE_HEADING
OPEN MASTER FILE(EMPLOYEE)
SET PAGE_COUNT TO 1
SET ERR_FLAG TO FLASE
END
 Difference between Coupling and
COHESION
Cohesion COUPLING
Cohesion is the concept of intra Coupling is the concept of inter
module. module.
Cohesion represents the Coupling represents the
relationship within module. relationships between modules.
Increasing in cohesion is good for Increasing in coupling is avoided
software. for software.
Cohesion represents the functional Coupling represents the
strength of modules. independence among modules.
Highly cohesive gives the best Whereas loosely coupling gives the
software. best software.
In cohesion, module focuses on the In coupling, modules are
single thing. connected to the other modules.
 Top-down Design
A top down design approach starts by identifying the major modules of the system,
decomposing them into their lower level modules and iterating until the desired level of
detail is achieved. This is stepwise refinement; starting from an abstract design, in each
step the design is refined to a more concrete level, until we reach a level where no more
refinement is needed and the design can be implemented directly

A top-down It is a stepwise Starting from an Suitable only if the It is a reasonable

approach starts by refinement method. abstract design, in requirements are approach if a
identifying the each step the clearly known and waterfall type of
major components design is refined to the system process model is
of the system, a more concrete development is being used.
decomposing them level, until we from the scratch.
into their lower- reach a level where
level components no more refinement
and iterating until is needed.
the desired level of
detail is achieved.
 Top-down Design
• Advantages:
1. 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:
1. Project and system boundaries tends to be application specification
oriented. Thus, it is more likely that advantages of component reuse will
be missed.
2. The system is likely to miss, the benefits of a well-structured, simple
architecture.
Bottom-up Design
• A bottom-up approach starts with the lowest level component of the
hierarchy and proceeds through progressively higher levels to the top
level component.
• Starts with the most basic or primitive components and proceeds to
higher level components that uses these lower level components.
• The amount of abstraction grows high as the design moves to more
high levels.
• If a system is to be built from an existing system , a bottom-up
approach is more suitable, as it starts with some existing components.
• If an iterative enhancement type of process is being followed, in later
iterations, the bottom-up approach could be more suitable.
 Bottom-up Design
• Advantages:
1. The economics can result when general solutions can be reused.
2. It can be used to hide the low-level details of implementation and be
merged with top-down technique.
• Disadvantages:
1. It is not so closely related to the structure of the problem.
2. High quality bottom-up solutions are very hard to construct.
3. It leads to proliferation of ‘potentially useful’ functions rather than
most appropriate ones.
Design Notifications and Specifications
• Design notations are used to represent design or design decisions.
• They are meant largely for designers so that he can quickly
represent his decision in a compact manner that he can evaluate and
modify.
• The notations are frequently graphical.
• To specify the design, specification languages are used.
• Generally design specification uses textual structure
• Helps developers to implement the design in a easy manner.
 Structure Chart
• Structure Chart represent hierarchical structure of modules.
• It breaks down the entire system into lowest functional modules,
describe functions and sub-functions of each module of a system to a
greater detail.
• Structure Chart partitions the system into black boxes (functionality of
the system is known to the users but inner details are unknown).
Inputs are given to the black boxes and appropriate outputs are
generated.
• Modules at top level called modules at low level. Components are read
from top to bottom and left to right.
• When a module calls another, it views the called module as black box,
passing required parameters and receiving results.
•
Structure Chart
Symbols used in construction of structured chart
1.Module
It represents the process or task of the system. It is of three types.
i. Control Module
A control module branches to more than one sub module.
ii. Sub Module
Sub Module is a module which is the part (Child) of another module.
iii. Library Module
Library Module are reusable and invokable from any module.
2. Conditional Call
Structure Chart
It represents that control module can select any of the sub module on the basis of some condition.
 Structure
3. Loop (Repetitive call of module)
Chart
It represents the repetitive execution of module by the sub module. A curved
arrow represents loop in the module.
4. Data Flow
Structure Chart
It represents the flow of data between the modules. It is represented by
directed arrow with empty circle at the end.
5. Control Flow
Structure Chart
It represents the flow of control between the modules. It is represented by
directed arrow with filled circle at the end.
• Physical Storage
Structure Chart
Physical Storage is that where all the information are to be stored.
 Flowchart
• Flowchart is a graphical representation of an algorithm. Programmers
often use it as a program-planning tool to solve a problem. It makes
use of symbols which are connected among them to indicate the flow
of information and processing.
The process of drawing a flowchart for an algorithm is known as
“flowcharting”.
 Basic Symbols used in Flowchart
Designs
1.Terminal: The oval symbol indicates Start, Stop and Halt in a program’s logic
flow. A pause/halt is generally used in a program logic under some error
conditions. Terminal is the first and last symbols in the flowchart.

2. Input/Output: A parallelogram denotes any function of input/output type. Program

instructions that take input from input devices and display output on output devices are
indicated with parallelogram in a flowchart.
Basic Symbols used in Flowchart
Designs
3. Processing: A box represents arithmetic instructions. All arithmetic
processes such as adding, subtracting, multiplication and division are
indicated by action or process symbol.

4. Decision Diamond symbol represents a decision point. Decision based

operations such as yes/no question or true/false are indicated by
diamond in flowchart.
Basic Symbols used in Flowchart
Designs
5. Connectors: Whenever flowchart becomes complex or it spreads over more
than one page, it is useful to use connectors to avoid any confusions. It is
represented by a circle.

6. Flow lines: Flow lines indicate the exact sequence in which instructions are
executed. Arrows represent the direction of flow of control and relationship
among different symbols of flowchart.
 Flowchart: Benefits
• Logic understanding
• Effective analysis
• Useful in coding
• Proper testing and debugging
• Appropriate documentation
 Flowchart: Limitations
1. Complex
2. Costly
3. Difficult to modify
4. No update
 Pseudo Code
• Pseudo code is a term which is often used in programming and algorithm-based
fields.
• It is a methodology that allows the programmer to represent the implementation of
an algorithm.
• It is the cooked-up representation of an algorithm.
• Often at times, algorithms are represented with the help of pseudo codes as they
can be interpreted by programmers no matter what their programming background
or knowledge is.
• It’s simply an implementation of an algorithm in the form of annotations and
informative text written in plain English. It has no syntax like any of the
programming language and thus can’t be compiled or interpreted by the computer.
 Pseudo Code
• Advantages of Pseudocode
• Improves the readability of any approach. It’s one of the best approaches to
start implementation of an algorithm.
• Acts as a bridge between the program and the algorithm or flowchart. Also
works as a rough documentation, so the program of one developer can be
understood easily when a pseudo code is written out. In industries, the
approach of documentation is essential. And that’s where a pseudo-code
proves vital.
• The main goal of a pseudo code is to explain what exactly each line of a
program should do, hence making the code construction phase easier for the
programmer.
Pseudo Code
 Function Oriented Design
• The design process for software systems often has two levels. At the first
level the focus is on deciding which modules are needed for the system
based on SRS (Software Requirement Specification) and how the modules
should be interconnected.
• Function Oriented Design is an approach to software design where the
design is decomposed into a set of interacting units where each unit has a
clearly defined function.
• Generic Procedure: Start with a high-level description of what the
software / program does. Refine each part of the description one by one by
specifying in greater details the functionality of each part. These points lead
to Top-Down Structure.
 Function Oriented Design
Strategies
1.Data Flow Diagram (DFD):A data flow diagram (DFD) maps out the flow of
information for any process or system. It uses defined symbols like
rectangles, circles and arrows, plus short text labels, to show data inputs,
outputs, storage points and the routes between each destination.
2.Data Dictionaries: Data dictionaries are simply repositories to store
information about all data items defined in DFDs. At the requirement stage,
data dictionaries contains data items. Data dictionaries include Name of the
item, Aliases (Other names for items), Description / purpose, Related data
items, Range of values, Data structure definition / form.
3.Structure Charts: It is the hierarchical representation of system which
partitions the system into black boxes (functionality is known to users but
inner details are unknown). Components are read from top to bottom and left
to right. When a module calls another, it views the called module as black
box, passing required parameters and receiving results.
4.Pseudo Code : Pseudo Code is system description in short English like
phrases describing the function. It use keyword and indentation. Pseudo
codes are used as replacement for flow charts. It decreases the amount of
 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.
 Object Oriented Design
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
 Object Oriented Design
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.
 FUNCTIONAL PROGRAMMING OBJECT ORIENTED PROGRAMMING
This programming paradigm emphasizes on This programming paradigm is based on object
the use of functions where each function oriented concept. Classes are used where
performs a specific task. instance of objects are created
Fundamental elements used are variables and Fundamental elements used are objects and
functions. The data in the functions are methods and the data used here are mutable
immutable(cannot be changed after creation). data.
Importance is not given to data but to Importance is given to data rather than
functions. procedures.
It follows declarative programming model. It follows imperative programming model.

It uses recursion for iteration. It uses loops for iteration.

The statements in this programming paradigm The statements in this programming paradigm
does not need to follow a particular order need to follow a order i.e., bottom up approach
while execution. while execution.
Has three access specifiers namely, Public,
Does not have any access specifier.
Private and Protected.
Provides and easy way to add new data and
To add new data and functions is not so easy.
functions.
No data hiding is possible. Hence, Security is Provides data hiding. Hence, secured
 Measurement and Metrics
• A measurement is a manifestation of the size, quantity, amount or
dimension of a particular attributes of a product or process. Software
measurement process is defined and governed by ISO Standard.
• Need of Software Measurement:
Software is measured to:
1. Create the quality of the current product or process.
2. Anticipate future qualities of the product or process.
3. Enhance the quality of a product or process.
4. Regulate the state of the project in relation to budget and schedule.
 Classification of Software
Measurement:
• There are 2 types of software measurement:
1.Direct Measurement:
In direct measurement the product, process or thing is measured directly
using standard scale.
2. Indirect Measurement: In indirect measurement the quantity or
quality to be measured is measured using related parameter i.e. by use
of reference.
 Metrics
• A metrics is a measurement of the level that any impute
belongs to a system product or process. There are 4
functions related to software metrics:
1.Planning
2.Organizing
3.Controlling
4.Improving
 Characteristics of Software
Metrics
1.Quantitative:
Metrics must possess quantitative nature. It means metrics can be expressed in
values.
2.Understandable:
Metric computation should be easily understood ,the method of computing metric
should be clearly defined.
3.Applicability:
Metrics should be applicable in the initial phases of development of the software.
4.Repeatable:
The metric values should be same when measured repeatedly and consistent in
nature.
5.Economical:
Computation of metric should be economical.
6.Language Independent:
Metrics should not depend on any programming language.
 Classification of Software
Metrics
• There are 2 types of software metrics:
1.Product Metrics:
Product metrics are used to evaluate the state of the product, tracing
risks and undercovering prospective problem areas. The ability of
team to control quality is evaluated. Size, Reliability, Complexity etc
2.Process Metrics:
Process metrics pay particular attention on enhancing the long-term
process of the team or organization. Productivity, Quality, Efficiency
etc.
 Lines of Code (LOC)
• LOC is possibly the simplest among all metrics available to measure
project size. Consequently, this metric is extremely popular.
• This metric measures the size of a project by counting the number of
source instructions in the developed program.
• Obviously, while counting the number of source instructions,
comment lines, and header lines are ignored.
• Determining the LOC count at the end of a project is very simple.
• However, accurate estimation of LOC count at the beginning of a
project is a very difficult task. One can possibly estimate the LOC
count at the starting of a project, only by using some form of
systematic guess work.
• 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
 LOC: Disadvantages
• LOC is a measure of coding activity alone: A problem size measure should consider the total
effort of various life cycle activities (i.e. specification, design, code and test etc.) However LOC
completely focus on the coding activity alone. Sometimes, for small code, design and testing issues
are complex.
• LOC count depends on the choice of specific instructions: Due to different coding styles of
programmers (e.g. one instruction may be written in multiple lines or multiple instructions written in
one line), It is difficult get accurate LOC. If we count the language token even in this case,
programmers can choose the different tokens for instructions e.g. one can choose the if..else.. And
another can do with switch etc.
• LOC measure correlates poorly with the quality and efficiency of the code: The quality of
code does not depend upon number of lines in code
• LOC metric penalises use of higher-level programming languages and code reuse: Effort
cannot be measured by mangers on Line of code because if programmer choose object oriented
approach which encourage reuse of components
 LOC: Disadvantages
• LOC metric measures the lexical complexity of a program and does
not address the more important issues of logical and structural
complexities: The efforts of two programs cannot be same based on Lines of
Code. Because one program may use multiple loops while other is using
sequence of instructions.
• It is very difficult to accurately estimate LOC of the final program from
problem specification: This is not useful for project planning because it is
difficult to predict number of lines before development
 Function Point Metric
• Function point metric was proposed by Albrecht in 1983. This metric overcomes many of the
shortcomings of the LOC metric. Since its inception in late 1970s, function point metric has
steadily gained popularity.
• One of the important advantages of the function point metric over the LOC metric is that it
can easily be computed from the problem specification itself.
• The conceptual idea behind the function point metric is the following. The size of a software
product is directly dependent on the number of different high-level functions or features it
supports.
• Efforts to developed is considered by the function point metric by counting the number of
input and output data items and the number of files accessed by the function. The implicit
assumption made is that the more the number of data items that a function reads from the
user and outputs and the more the number of files accessed, the higher is the complexity of
the function.
 Function Point Metric
• The computation of the number of input and output data items would give a
more accurate indication of the code size compared to simply counting the
number of high-level functions supported by the system.
• Albrecht postulated that in addition to the number of basic functions that a
software performs, size also depends on the number of files and the number of
interfaces that are associated with the software.
 Function Point Metric
Computation
• The principle of Albrecht’s function point analysis (FPA) is that a
system is decomposed into functional units.
•
Function Point: Functional Unit
System
 Function Point: Functional Unit
System
• The five functional units are divided in two categories:
• (i) Data function types
• Internal Logical Files (ILF): A user identifiable group of logical
related data or control information maintained within the system.
• External Interface files (EIF): A user identifiable group of logically
related data or control information referenced by the system but
maintained within another system. This means that EIF counted for
one system, may be an ILF in another system
 Function Point: Functional Unit
System
• (ii) Transactional function types
• External Input (EI): An EI processes data or control information that
comes from outside the system. The EI is an elementary process,
which is the smallest unit of activity that is meaningful to the end
user in the business.
• External Output (EO): An EO is an elementary process that generate
data or control information to be sent outside the system.
• External Inquiry (EQ): An EQ is an elementary process that is made
up to an input-output combination that results in data retrieval.
 Function Point: Features
• Function point approach is independent of the language, tools, or methodologies used
for implementation; i.e. they do not take into consideration programming languages,
data base management systems, processing hardware or any other data base
technology.
• Function points can be estimated from requirement specification or design
specification, thus making it possible to estimate development efforts in early phases
of development.
• Function points are directly linked to the statement of requirements; any change of
requirements can easily be followed by a re-estimate.
• Function points are based on the system user’s external view of the system, non-
technical users of the software system have a better understanding of what function
points are measuring.
 Function Point Metric Computation:
Unadjusted Function Point (UFP)

The weighting factors are identified for all functional units and multiplied with the
functional units accordingly.
 Function Point Metric Computation:
Unadjusted Function Point
• The procedure for the calculation of UFP in mathematical form is given
below:

Where i indicate the row and j indicates the column of Table 1

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.
 Function Point
• 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
 Function Point
• Functions points may compute the following important metrics:
• Productivity = FP / persons-months
• Quality = Defects / FP
• Cost = Rupees / FP
• Documentation = Pages of documentation per FP
• These metrics are controversial and are not universally acceptable. There are
standards issued by the International Functions Point User Group (IFPUG,
covering the Albrecht method) and the United Kingdom Function Point User
Group (UFPGU, covering the MK11 method). An ISO standard for function
point method is also being developed.
 Example
• Consider a project with the following functional units:
• Number of user inputs = 50
• Number of user outputs = 40
• Number of user enquiries = 35
• Number of user files = 06
• Number of external interfaces = 04
• Assume all complexity adjustment factors and weighting factors are
average. Compute the function points for the project.
• UFP = 50 x 4 + 40 x 5 + 35 x 4 + 6 x 10 + 4 x 7
• = 200 + 200 + 140 + 60 + 28 = 628
• CAF = (0.65 + 0.01 Fi)
• = (0.65 + 0.01 (14 x 3)) = 0.65 + 0.42 = 1.07
• FP = UFP x CAF
• = 628 x 1.07 = 672
 Question
• An application has the following:
• 10 low external inputs, 12 high external outputs, 20 low internal logical
files, 15 high external interface files, 12 average external inquiries, and
a value of complexity adjustment factor of 1.10.
• What are the unadjusted and adjusted function point counts ?
Solution
 Halstead’s Software Metrics
• A computer program is an implementation of an algorithm considered to be a
collection of tokens which can be classified as either operators or
operands. Halstead’s metrics are included in a number of current
commercial tools that count software lines of code. By counting the tokens
and determining which are operators and which are operands, the following
base measures can be collected :
 n1 : Number of distinct operators.
 n2: Number of distinct operands.
 N1: Total number of occurrences of operators.
 N2: Total number of occurrences of operands.
 In addition to the above, Halstead defines the following:
 n1*: Number of potential operators.
 n2*: Number of potential operands.
• Halstead refers to n1* and n2* as the minimum possible number of operators
 Halstead’s Software Metrics
• This minimum number would be embodied in the programming
language itself, in which the required operation would already exist
(for example, in C language, any program must contain at least the
definition of the function main()), possibly as a function or as a
procedure: n1* = 2, since at least 2 operators must appear for any
function or procedure : 1 for the name of the function and 1 to serve
as an assignment or grouping symbol, and n2* represents the number
of parameters, without repetition, which would need to be passed on
to the function or the procedure.
 Halstead’s Metrics
• Halstead's metrics are all defined based on its set of base quantities (n1, n2, N1,
N2, n1* and n2*).
• The length (N) of a program P is :
• N = N1 + N2
• The vocabulary (n) of a program P is :
• n = n1 + n2
• The volume (V) of a program P is defined as :
• V = N * log2n
 Halstead’s Metrics
• Difficulty level (D) = ( n1 / 2 ) * ( N2 / n2 )
• Program level (L) = 1/D
• Effort to implement (E) = V * D
 Halstead’s Software Metrics

• Comments are not considered.

• The identifier and function declarations are not considered
• All the variables and constants are considered operands.
• Global variables used in different modules of the same program are counted
as multiple occurrences of the same variable.
• Local variables with the same name in different functions are counted as
unique operands.
• Functions calls are considered as operators.
• All looping statements e.g., do {…} while ( ), while ( ) {…}, for ( ) {…}, all
control statements e.g., if ( ) {…}, if ( ) {…} else {…}, etc. are considered as
operators.
• In control construct switch ( ) {case:…}, switch as well as all the case
statements are considered as operators.
 Halstead’s Software Metrics
• All the brackets, commas, and terminators are considered as operators.
• GOTO is counted as an operator and the label is counted as an operand.
• The unary and binary occurrence of “+” and “-” are dealt separately. Similarly “*”
(multiplication operator) are dealt separately.
• In the array variables such as “array-name [index]” “array-name” and “index” are
considered as operands and [ ] is considered as operator.
• In the structure variables such as “struct-name, member-name” or “struct-name ->
member-name”, struct-name, member-name are taken as operands and ‘.’, ‘->’ are
taken as operators. Some names of member elements in different structure variables
are counted as unique operands.
• All the hash directive are ignored.
S.No. Operator Frequency Operand Frequency
1 main 1 a 3
2 () 4 b 3
3 int 1 c 3
4 {} 1 avg 3
5 , 7 “%d%d%d” 1
6 ; 4 3 1
7 scanf 1 “avg=%d” 1
8 printf 1
9 = 1
10 + 2
11 / 1
12 & 3
total 27 15
 Halstead’s Software Metrics
 n1 : Number of distinct operators =12
 n2: Number of distinct operands =7
 N1: Total number of occurrences of operators =27
 N2: Total number of occurrences of operands=15
• The length (N) of a program P is :
• N = N1 + N2=27+15=42
• The vocabulary (n) of a program P is :
• n = n1 + n2=12+7=19
• The volume (V) of a program P is defined as :
• V = N * log2n=42*4.25 =178.5
 Halstead’s Software Metrics
• Difficulty level (D) = ( n1 / 2 ) * ( N2 / n2 ) =
(12/2)*(15/7)=12.85
• Program level (L) = 1/D=1/12.85=.077
• Effort to implement (E) = V * D
=178.5*12.85=2293.75
int BinSearch (char *item, char *table[], int n)
{
int bot = 0;
int top = n - 1;
int mid, cmp;
while (bot <= top) {
mid = (bot + top) / 2;
if (table[mid] == item)
return mid;
else if (compare(table[mid], item) < 0)
top = mid - 1;
else
bot = mid + 1;}return -1; // not found}
operator occurrence operands occurrence
s s
int 5 item 3
char* 2 table 2
BinSearch() 1 n 2
, 2 bot 4
[] 3 0 2
= 5 top 4
; 8 1 3
- 2 mid 6
while() 1 cmp 1
<= 1 -1 1
{} 1
+ 2
() 4
/ 1
if() elseif else 1
return 2
compare() 1
< 1
n1:18 N1:43 n2:10 N2:28
Measure N (Length of a program) : N = N1 + N2.
= 43 + 28
= 71

Measure n (Vocabulary): n = n1 + n2.

= 18 + 10
= 28

Measure V (Volume): V = (N1 + N2) log2 (n1 + n2)

V = N log2 (n).
= 71 log (28)
= 341.322205
Measure D (Difficulty): D = (n1*N2)/(2*n2)
= 18*28/2*10
= 25.2

Measure E (Effort): E=D*V

= 25.2*341.322205
= 8601.319566

Measure B (Bugs expected): B = E0.667/3000

= .14

Measure T (Time): T = E/18 seconds

= 478 seconds
 Cyclomatic Complexity
• Cyclomatic complexity is a source code complexity measurement that is
being correlated to a number of coding errors. It is the structural complexity
because it gives the internal view of the code.
• It is calculated by developing a Control Flow Graph of the code that
measures the number of linearly-independent paths through a program
module.
• Lower the Program's cyclomatic complexity, lower the risk to modify and
easier to understand. It can be represented using the below formula:
cyclomatic complexity is 8 - 7 + 2 = 3
Method-01:

Cyclomatic Complexity
= Total number of closed regions in the control flow
graph + 1
=2+1
=3

Method-02:

Cyclomatic Complexity
=E–N+2
=8–7+2
=3
 Consider a software project with the following functional units:
User input = 35, User output = 15, User Enquiries = 10, User Files = 6, External Interfaces
= 7.
Assume complexity adjustment factors are essential and weighting factors are average.
Calculate the functional point for the project.
 Consider a software project with the following functional units:
User input = 55, User output = 35, User Enquiries = 40, User Files = 8, External Interfaces = 5.
Assume complexity adjustment factors are significantly complex and weighting factors are high.
Calculate the functional point for the project.