Unit:-3

Concept of software Design: - Basic concepts of software design is a software

engineering activity where software requirements are analyzed in order to
produce a description of the internal structure and organization of the system
that serves as a basis of its construction (coding), IEEE define software design as
both a process of defining the architecture, components, interface and other
characteristics of a system or components and the result of that process.
During software design phase, many critical and strategic decisions
are made to meet the required functional and quality requirement of a system.
Objective of software Design: - The main objective of software design phase is
to develop a blue print which serves as a base while developing the software
system. The other objectives of software design are listed below:
1. To produce various modules that can be analyzed and evaluate to
determine if they will allow the various requirements to be fulfilled.
2. To examine and evaluate various alternative solutions and trade-offs
involved.
3. To plan subsequent software development activities.
Principles of software design/ Architecture Design: - Software design is a
cumbersome process as most expensive errors are often introduced in this
phase. Since problems in the design phase can be very expensive to solve in later
stages of the software development, a number of principles are considered while
designing the software. These principles are considered while designing the
software. These principles act as a framework for the designers to follow a good
design practice.
Some of the commonly followed design principles are listed below
a. Software design should be traceable to the analysis model: As a single
design element often relates to multiples requirements, it becomes
 essential to have a means for tracking how requirements are satisfied by
the design model.
b. Choose the right programming paradigm: A programming paradigm is the
framework used for designing and describing the structure of the software
system.
c. Software design should demonstrate uniformity and integration: In most
cases, rules, format and styles are defined in advance to the design team
before the design work begins.
d. Software design should be structured to adapt changes: the fundamental
design concepts (abstraction, refinement, modularity) should be applied to
achieve this principles.
e. Software design should appraise to minimize conceptual (semantic)
errors: Design team must ensure that major conceptual elements of design,
such as ambiguousness and inconsistency are addressed in advance before
dealing with the syntactical errors present in the design model.
f. Software design should be structured to degrade gently: software should
be designed to handle unusual changes and circumstances, and if need
arise for termination it must do so in a proper manner so that functionality
of the software is not affected.
g. Software design should minimize the intellectual distance between the
software and problem existing in the real world: The design structure
should be such that it always relates with the real- world problem.
h. Code reuse: There is a common saying among software engineers do not
reinvent the wheel therefore existing design hierarchies should be
effectively reused to increase productivity.
i. Designing for testability: A common practice that has been followed is to
separate testing from design and implementation. That is the software is
designed, implemented, and then handed over to the testers.
j. Prototyping: prototyping should be used to explore those aspects of the
requirements, user interface, or software’s internal design, which are not
easily understandable.
Software Design Process
The design phase of software development deals with transforming the customer
requirements as described in the SRS documents into a form implementable
using a programming language.
The software design process can be divided into the following three levels of
phases of design:
1. Interface Design
2. Architectural Design
3. Detailed Design
Interface Design:
Interface design is the specification of the interaction between a system and its
environment. this phase proceeds at a high level of abstraction with respect to
the inner workings of the system i.e. during interface design, the internal of the
systems are completely ignored and the system is treated as a black box.
Attention is focused on the dialogue between the target system and the users,
devices, and other systems with which it interacts. The design problem
statement produced during the problem analysis step should identify the people,
other systems, and devices which are collectively called agents.
Interface design should include the following details
a. Precise description of events in the environment, or messages from agents
to which the system must respond.
b. Precise description of the events or messages that the system must
produce.
c. Specification on the data, and the formats of the data coming into and
going out of the system.
d. Specification of the ordering and timing relationships between incoming
events or messages, and outgoing events or outputs.
Architectural Design:
Architectural design is the specification of the major components of a system,
their responsibilities, properties, interfaces, and the relationships and
interactions between them. In architectural design, the overall structure of the
system is chosen, but the internal details of major components are ignored.
Issues in architectural design includes:
a. Gross decomposition of the systems into major components.
b. Allocation of functional responsibilities to components.
c. Component Interfaces
Component scaling and performance properties, resource consumption
properties, reliability properties, and so forth.
Communication and interaction between components.
The architectural design adds important details ignored during the interface
design. Design of the internals of the major components is ignored until the last
phase of the design.

Detailed Design:
Design is the specification of the internal elements of all major system
components, their properties, relationships, processing, and often their
algorithms and the data structures.
The detailed design may include:
a. Decomposition of major system components into program units.
b. Allocation of functional responsibilities to units.
 c. User interfaces
d. Unit states and state changes
e. Data and control interaction between units
f. Data packaging and implementation, including issues of scope and visibility
of program elements
g. Algorithms and data structures
Advantage of Object Oriented architecture
It enables the designer to separate a challenge into a collection of autonomous
objects. Other objects are aware of the implementation details of the object,
allowing changes to be made without having an impact on other objects

Introduction to design process

The main aim of design engineering is to generate a model which shows firmness,
delight and commodity.
Software design is an iterative process through which requirements are
translated into the blueprint for building the software.
Software quality guidelines
 A design is generated using the recognizable architectural styles and
compose a good design characteristic of components and it is implemented
in evolutionary manner for testing.
 A design of the software must be modular i.e. the software must be logically
partitioned into elements.
 In design, the representation of data, architecture, interface and
components should be distinct.
 A design must carry appropriate data structure and recognizable data
patterns.
 Design components must show the independent functional characteristic.
  A design creates an interface that reduce the complexity of connections
between the components.
 A design must be derived using the repeatable method.
Quality attributes
The attributes of design name as 'FURPS' are as follows:
Functionality: -It evaluates the feature set and capabilities of the program.
Usability: - It is accessed by considering the factors such as human factor, overall
aesthetics, consistency and documentation.
Reliability: - It is evaluated by measuring parameters like frequency and security
of failure, output result accuracy, the mean-time-to-failure (MTTF), recovery
from failure and the program predictability.
Performance: - It is measured by considering processing speed, response time,
resource consumption, throughput and efficiency
Low level design: -
Low-level design is an important phase of the software development process,
because in this phase, the design is translated into concrete implementation
details. This phase of the design process focuses on defining the data structures,
algorithms, and interactions between the components that will be used to
implement the system. It is also concerned with defining the interfaces between
the various components and the protocols used for communication between
them.
Low-level design is often performed by software architects and engineers, who
use various techniques such as object-oriented design, design patterns, and UML
(Unified Modeling Language) diagrams to define the detailed design of the
system. Developers then use this design to implement the system, ensuring that
the system is built according to the specifications defined in the low-level design.
The steps involved in low-level design typically include the following:
Understanding requirements: The first step in low-level design is understanding
the system's requirements. This includes reviewing the requirements document,
talking to stakeholders, and gathering additional information to better
understand what the system should do.
Defining the architecture: Once the requirements are understood, the next step
is to define the system's architecture. This involves identifying the various
components that make up the system and defining how they will interact with
each other.
Designing the components: After defining the architecture, the next step is to
design each component in detail. This includes specifying the data structures and
algorithms to be used, and defining the interfaces between components.
Defining protocols: In this step, the protocols that will be used for
communication between components are defined. This includes specifying the
data formats, message structures, and communication protocols that will be
used.
Creating UML diagrams: To help communicate the design, UML (Unified
Modeling Language) diagrams may be created to illustrate the architecture and
the interactions between components.
Reviewing the design: Once the design is completed, it must be reviewed to
ensure that it meets the requirements and is technically sound. This may include
obtaining feedback from stakeholders and conducting peer reviews.
Refining the design: If necessary, the design can be refined based on feedback
received during the review process. This may involve changing the data
structures, algorithms, or protocols used in the design.
Documenting the design: Once the design has been finalized, it is important to
document it in a way that is clear, concise, and easy to understand. This may
involve creating detailed design specifications or creating diagrams and
flowcharts to illustrate the design.
These are the general steps involved in low-level design. The specific steps and
techniques may vary depending on the designed system and the tools and
processes used. However, these steps provide a good starting point for anyone
involved in low-level design.
High-Level Design
HLD (High-Level Design) is the initial stage of designing, commonly known as HLD.
It offers a comprehensive overview of the system architecture. It describes the
main components of the system and how they interact. A customer must involve
the HLD to confirm that the system's performance, functionality, and scalability
satisfy their needs. Hence, HLD is also known as macro-level design.
The Distinction between High-Level Design and Low-Level Design

S.No. LOW-LEVEL DESIGN HIGH-LEVEL DESIGN

1. LLD is an abbreviation for HLD stands for High-Level Design.

Low-Level Design.

2. Low-Level Design, like A high-level design is an overall

detailing, refers to the system design related to the entire
component-level design system design.
process.

3. It provides a full description It defines the application’s general

of each module. description/architecture.
4. It is often referred to as It is often referred to as macro-level
micro-level detailed design. System design.

5. Designers and developers A solution architect designs it.

make it.

6. Low-Level Design explains High-Level Design and describes the

the module’s functional module’s concise functioning.
logic in detail.

7. It is produced as a It is created initially, which implies it

secondary means following comes before Lower Level Design.
High-Level Design.

8. Participants in Low-Level The participants in High-Level Design

Design include the design are the design team, the review
team, operating teams, and team, and the client team.
implementers.

9. The Low-Level Design A high-Level Solution transforms a

process transforms the business/client demand into a High-
High-Level Solution into a Level Solution.
Detailed Solution.

10. The output criteria in LLD The output criteria in HLD include
are program definition and database design, functional design,
unit tests plan. and review records.
Modularization
Modularization is the process of separating the functionality of a program into
independent, interchangeable modules, such that each contains everything
necessary to execute only one aspect of the desired functionality.
Benefits of modularization
In modularization, the modules have minimal dependency on other modules. So,
we can easily make changes in a module without affecting other parts of the
program.
 Easier to add and maintain smaller components
 Easier to understand each module and their purpose
 Easier to reuse and refactor modules
 Better abstraction between modules
 Saves time needed to develop, debug, test and deploy a program
Structure Chart
Structure Chart represents the hierarchical structure of modules. It represents
the software architecture that means the various modules making up the system
and the dependency. Structure chart representation can be easily implemented
using some common programming language. The main focus in the structure
chart is on the module structure of the software.
Flow Chart
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.
Flow chart is a convenient technique to represent the flow of control in a
program.
Structure chart Flow chart

Structure chart represents the Flow chart represents the flow of

software architecture. control in program.

It is easy to identify the different It is difficult to identify the

modules of the software from different modules of the software
structure chart. from the flow chart.

Symbols used in structure chart are Symbols used in flow chart are
complex. simple.

Data interchange among different

Data interchange between different
modules is not represented in
modules is represented here.
flow chart.

In structure chart different types of Only a single type of arrow is used

arrows are used to represent data to show the control flow in flow
flow and module invocation. chart.

It suppresses the sequential ordering It demonstrates the sequential

of tasks inherent in a flow chart. ordering of inherent tasks.

Structure chart is complex to Flow chart is easier to construct in

construct in comparison of flow chart. comparison of structure chart.
Structure chart Flow chart

Structure chart is hard to understand. Flow chart is easy to understand.

Function oriented design

The design activity begins when the requirements document for the software to
be developed is available and the architecture has been designed. During design
we determine what modules should the system have and which have to be
developed. The design exercise determines the module structure of the
components. We have to ensure that the module view created in design is
consistent with the architecture. The design of a system is a plan for a solution
for the system. A system is a set of modules with clearly defined behavior which
interact with each other in a defined manner to produce some behavior or
services for its environment. A module of a system can be considered a system,
with its own modules. The design process has two levels.
1. First level focus is on deciding which modules are needed for the system, the
specifications of these modules, and how the modules should be interconnected.
Known as system design or top-level design.
2. Second level the internal design of the modules, or how the specifications of
the module can be satisfied, is decided. Known as detailed design or logic design,
Expands the system design to contain a more detailed description of the
processing logic and data structures so that the design is sufficiently complete
for coding. In a function-oriented design approach, a system is viewed as a
transformation function, transforming the inputs to the desired outputs. Each
module in design supports a functional abstraction. The basic output of the
system design phase is the definition of all the major data structures in the
system, all the major modules of the system, and how the modules interact with
each other.
Object Oriented Design
Object oriented design is the result of focusing attention not on the function
performed by the program, but instead on the data that are to be manipulated
by the program. Thus, it is orthogonal to function -oriented design. Object-
oriented design begins with an examination of the real world “things”. These
things are characteristics individually in terms of their attributes and behavior.
Objects are independent entities that may readily be changed because all state
and representation information is held within the object itself. Object may be
distributed and may execute sequentially or in parallel.
Difference between Function Oriented Design and Object Oriented Design

COMPARISON FUNCTION ORIENTED

FACTORS DESIGN OBJECT ORIENTED DESIGN

The basic abstractions are not

The basic abstractions, the real world functions but
Abstraction which are given to the user, are the data abstraction where
are real world functions. the real world entities are
represented.

Function are grouped together

Functions are grouped
on the basis of the data they
Function together by which a higher
operate since the classes are
level function is obtained.
associated with their methods.
COMPARISON FUNCTION ORIENTED
FACTORS DESIGN OBJECT ORIENTED DESIGN

carried out using structured

execute analysis and structured Carried out using UML
design i.e. data flow diagram

In this approach the state

In this approach the state information is not represented
State information is often in a centralized memory but is
information represented in a centralized implemented or distributed
shared memory. among the objects of the
system.

Approach It is a top down approach. It is a bottom up approach.

Begins by considering the

Begins by identifying objects
Begins basis use case diagrams and the
and classes.
scenarios.

In function oriented design

Decompose we decompose in We decompose in class level.
function/procedure level.

This approach is mainly used

Use for computation sensitive This approach is mainly used
application. for evolving system which
COMPARISON FUNCTION ORIENTED
FACTORS DESIGN OBJECT ORIENTED DESIGN

mimics a business or business

case.

Coupling:
Coupling is the measure of the degree of interdependence between the modules.
A good software will have low coupling.
Types of Coupling:
 Data Coupling: If the dependency between the modules is based on the
fact that they communicate by passing only data, then the modules are said
to be data coupled. In data coupling, the components are independent of
each other and communicate through data. Module communications don’t
contain tramp data. Example-customer billing system.
 Stamp coupling: in stamp coupling, the complete data structure is passed
from one module to another module. Therefore, it involves tramp data. It
may be necessary due to efficiency factors- this choice was made by the
insightful designer, not a lazy programmer.
 Control Coupling: If the modules communicate by passing control
information, then they are said to be control coupled. It can be bad if
parameters indicate completely different behavior and good if parameters
allow factoring and reuse of functionality. Example- sort function that takes
comparison function as an argument.
 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: The modules have shared data such as global data
structures. The changes in global data mean tracing back to all modules
which access that data to evaluate the effect of the change. So it has got
disadvantages like difficulty in reusing modules, reduced ability to control
data accesses, and reduced maintainability.
 Content Coupling: In a content coupling, one module can modify the data
of another module, or control flow is passed from one module to the other
module. This is the worst form of coupling and should be avoided.
 Temporal Coupling: Temporal coupling occurs when two modules depend
on the timing or order of events, such as one module needing to execute
before another. This type of coupling can result in design issues and
difficulties in testing and maintenance.
 Sequential Coupling: Sequential coupling occurs when the output of one
module is used as the input of another module, creating a chain or
sequence of dependencies. This type of coupling can be difficult to maintain
and modify.
 Communicational Coupling: Communicational coupling occurs when two
or more modules share a common communication mechanism, such as a
shared message queue or database. This type of coupling can lead to
performance issues and difficulty in debugging.
 Functional Coupling: Functional coupling occurs when two modules
depend on each other’s functionality, such as one module calling a function
from another module. This type of coupling can result in tightly-coupled
code that is difficult to modify and maintain.
 Data-Structured Coupling: Data-structured coupling occurs when two or
more modules share a common data structure, such as a database table or
data file. This type of coupling can lead to difficulty in maintaining the
integrity of the data structure and can result in performance issues.
 Interaction Coupling: Interaction coupling occurs due to the methods of a
class invoking methods of other classes. Like with functions, the worst form
 of coupling here is if methods directly access internal parts of other
methods. Coupling is lowest if methods communicate directly through
parameters.
 Component Coupling: Component coupling refers to the interaction
between two classes where a class has variables of the other class.
Cohesion:
Cohesion is a measure of the degree to which the elements of the module are
functionally related. It is the degree to which all elements directed towards
performing a single task are contained in the component. Basically, cohesion
is the internal glue that keeps the module together. A good software design
will have high cohesion.
Types of Cohesion:
 Functional Cohesion: Every essential element for a single computation is
contained in the component. A functional cohesion performs the task and
functions. It is an ideal situation.
 Sequential Cohesion: An element outputs some data that becomes the
input for other element, i.e., data flow between the parts. It occurs
naturally in functional programming languages.
 Communicational Cohesion: Two elements operate on the same input data
or contribute towards the same output data. Example- update record in the
database and send it to the printer.
 Procedural Cohesion: Elements of procedural cohesion ensure the order of
execution. Actions are still weakly connected and unlikely to be reusable.
Ex- calculate student GPA, print student record, calculate cumulative GPA,
and print cumulative GPA.
 Temporal Cohesion: The elements are related by their timing involved. A
module connected with temporal cohesion all the tasks must be executed
in the same time span. This cohesion contains the code for initializing all
the parts of the system. Lots of different activities occur, all at unit time.
 Logical Cohesion: The elements are logically related and not functionally.
Ex- A component reads inputs from tape, disk, and network. All the code
for these functions is in the same component. Operations are related, but
the functions are significantly different.
 Coincidental Cohesion: The elements are not related (unrelated). The
elements have no conceptual relationship other than location in source
code. It is accidental and the worst form of cohesion. Ex- print next line and
reverse the characters of a string in a single component.
 Procedural Cohesion: This type of cohesion occurs when elements or tasks
are grouped together in a module based on their sequence of execution,
such as a module that performs a set of related procedures in a specific
order. Procedural cohesion can be found in structured programming
languages.
 Communicational Cohesion: Communicational cohesion occurs when
elements or tasks are grouped together in a module based on their
interactions with each other, such as a module that handles all interactions
with a specific external system or module. This type of cohesion can be
found in object-oriented programming languages.
 Temporal Cohesion: Temporal cohesion occurs when elements or tasks are
grouped together in a module based on their timing or frequency of
execution, such as a module that handles all periodic or scheduled tasks in
a system. Temporal cohesion is commonly used in real-time and embedded
systems.
 Informational Cohesion: Informational cohesion occurs when elements or
tasks are grouped together in a module based on their relationship to a
specific data structure or object, such as a module that operates on a
specific data type or object. Informational cohesion is commonly used in
object-oriented programming.
 Functional Cohesion: This type of cohesion occurs when all elements or
tasks in a module contribute to a single well-defined function or purpose,
 and there is little or no coupling between the elements. Functional
cohesion is considered the most desirable type of cohesion as it leads to
more maintainable and reusable code.
 Layer Cohesion: Layer cohesion occurs when elements or tasks in a module
are grouped together based on their level of abstraction or responsibility,
such as a module that handles only low-level hardware interactions or a
module that handles only high-level business logic. Layer cohesion is
commonly used in large-scale software systems to organize code into
manageable layers.
Advantages of low coupling:
 Improved maintainability: Low coupling reduces the impact of changes in
one module on other modules, making it easier to modify or replace
individual components without affecting the entire system.
 Enhanced modularity: Low coupling allows modules to be developed and
tested in isolation, improving the modularity and reusability of code.
 Better scalability: Low coupling facilitates the addition of new modules and
the removal of existing ones, making it easier to scale the system as
needed.
Advantages of high cohesion:
 Improved readability and understandability: High cohesion results in clear,
focused modules with a single, well-defined purpose, making it easier for
developers to understand the code and make changes.
 Better error isolation: High cohesion reduces the likelihood that a change
in one part of a module will affect other parts, making it easier to Isolate
and fix errors.
 Improved reliability: High cohesion leads to modules that are less prone to
errors and that function more consistently, Leading to an overall
improvement in the reliability of the system.
Disadvantages of high coupling:
 Increased complexity: High coupling increases the interdependence
between modules, making the system more complex and difficult to
understand.
 Reduced flexibility: High coupling makes it more difficult to modify or
replace individual components without affecting the entire system.
 Decreased modularity: High coupling makes it more difficult to develop
and test modules in isolation, reducing the modularity and reusability of
code.
Disadvantages of low cohesion:
 Increased code duplication: Low cohesion can lead to the duplication of
code, as elements that belong together are split into separate modules.
 Reduced functionality: Low cohesion can result in modules that lack a clear
purpose and contain elements that don’t belong together, reducing their
functionality and making them harder to maintain.
 Difficulty in understanding the module: Low cohesion can make it harder
for developers to understand the purpose and behavior of a module,
leading to errors and a lack of clarity.

Cohesion Coupling

Coupling is the concept of

Cohesion is the concept of intra-module. inter-module.

Coupling represents the

Cohesion represents the relationship within a relationships between
module. modules.
 Increasing coupling is
Increasing cohesion is good for software. avoided for software.

Coupling represents the

Cohesion represents the functional strength independence among
of modules. modules.

Whereas loosely coupling

Highly cohesive gives the best software. gives the best software.

In coupling, modules are

In cohesion, the module focuses on a single connected to the other
thing. modules.

Coupling is created
Cohesion is created between the same between two different
modules. modules.

There are Six types of Cohesion

1. Functional
Cohesion.
2. Procedural
There are Six types of
Cohesion.
Coupling
3. Temporal
Cohesion. 1. Common Coupling.
4. Sequential 2. External Coupling.
Cohesion. 3. Control Coupling.
5. Layer Cohesion. 4. Stamp Coupling.
6. Communication 5. Data Coupling
Cohesion. 6. Content Coupling.
Top- Down and Bottom Up- Design
In the top-down model, an overview of the system is formulated without going
into detail for any part of it. Each part of it then refined into more details, defining
it in yet more details until the entire specification is detailed enough to validate
the model. If we glance at a haul as a full, it’s going to appear not possible as a
result of it’s so complicated. We break the problem into parts, then break the
parts into parts soon and now each of parts will be easy to do.
Advantages
 Breaking problems into parts help us to identify what needs to be done.
 At each step of refinement, new parts will become less complex and
therefore easier to solve.
 Parts of the solution may turn out to be reusable.
 Breaking problems into parts allows more than one person to solve the
problem.
Bottom-up design model
In this design, individual parts of the system are specified in detail. The parts are
linked to form larger components, which are in turn linked until a complete
system is formed.
Advantage:
 Make decisions about reusable low-level utilities then decide how there will
be put together to create high-level construct.
S. No. TOP DOWN APPROACH BOTTOM UP APPROACH

In bottom up approach, we solve

In this approach We focus on
smaller problems and integrate it
1. breaking up the problem into
as whole and complete the
smaller parts.
solution.

Each part is programmed Redundancy is minimized by

3. separately therefore contain using data encapsulation and
redundancy. data hiding.

In this the communications is In this module must have

4.
less among modules. communication

It is used in debugging,
5. It is basically used in testing.
module documentation, etc.

In top down approach, In bottom up approach

6.
decomposition takes place. composition takes place.

In this sometimes we cannot

In this top function of system
7. build a program from the piece
might be hard to identify.
we have started.

In this implementation details This is not natural for people to

8.
may differ. assemble.
S. No. TOP DOWN APPROACH BOTTOM UP APPROACH

Pros-
Easier isolation of interface
errors
Pros-
It benefits in the case error
occurs towards the top of the Easy to create test conditions
9. program. Test results are easy to observe
Defects in design get It is suited if defects occur at the
detected early and can be bottom of the program.
corrected as an early working
module of the program is
available.

Cons-
Cons-
There is no representation of the
Difficulty in observing the working model once several
output of test case. modules have been constructed.
Stub writing is quite crucial as There is no existence of the
it leads to setting of output program as an entity without the
10. parameters. addition of the last module.
When stubs are located far From a partially integrated
from the top level module, system, test engineers cannot
choosing test cases and observe system-level
designing stubs become more functions. It can be possible only
challenging. with the installation of the top-
level test driver.
Matrices
A metric is a measurement of the level at which any impute belongs to a system
product or process. Software metrics is a quantifiable or countable assessment
of the attributes of a software product.
There are 4 functions related to software metrics:
 Planning
 Organizing
 Controlling
 Improving
Characteristics of software Metrics:
 Quantitative: Metrics must possess quantitative nature. It means metrics
can be expressed in numerical values.
 Understandable: Metric computation should be easily understood, and the
method of computing metrics should be clearly defined.
 Applicability: Metrics should be applicable in the initial phases of the
development of the software.
 Repeatable: When measured repeatedly, the metric values should be the
same and consistent in nature.
 Economical: The computation of metrics should be economical.
 Language Independent: Metrics should not depend on any programming
language.
Classification of Software Metrics:
There are 3 types of software metrics:
 Product Metrics: Product metrics are used to evaluate the state of the
product, tracing risks and undercover prospective problem areas. The
ability of the team to control quality is evaluated. Examples include lines of
 code, cyclamatric complexity, code coverage, defect density, and code
maintainability index.
 Process Metrics: Process metrics pay particular attention to enhancing the
long-term process of the team or organization. These metrics are used to
optimize the development process and maintenance activities of software.
Examples include effort variance, schedule variance, defect injection rate,
and lead time.
 Project Metrics: The project metrics describes the characteristic and
execution of a project. Examples include effort estimation accuracy,
schedule deviation, cost variance, and productivity.
Usually measures-
 Number of software developer
 Staffing patterns over the life cycle of software
 Cost and schedule
 Productivity
Advantages of Software Metrics:
1. Reduction in cost or budget.
2. It helps to identify the particular area for improvising.
3. It helps to increase the product quality.
4. Managing the workloads and teams.
5. Reduction in overall time to produce the product,
6. It helps to determine the complexity of the code and to test the code with
resources.
7. It helps in providing effective planning, controlling and managing of the
entire product.
Disadvantages of Software Metrics:
 It is expensive and difficult to implement the metrics in some cases.
 Performance of the entire team or an individual from the team can’t be
determined. Only the performance of the product is determined.
  Sometimes the quality of the product is not met with the expectation.
 It leads to measure the unwanted data which is wastage of time.
 Measuring the incorrect data leads to make wrong decision making.
Objectives of software testing
Software Testing is the process of evaluating the software product for identifying
bugs/issues in the product. Improving software quality is the core purpose of
running software tests. A mix of manual and automated tests are normally
conducted at every juncture of software development. This is to make sure that
a fully-functional application is released to the end-users of the product. It is
important to reiterate that testing must be performed from different angles like
functional, non-functional, security, accessibility, and more.
1. Identification of Bugs
2. Improvement of software quality
3. Enhancement of software quality
4. Enhancement of scalability and reliability
Main objective of software testing
 To find any defects or bugs that may have been created when the software
was being developed
 To increase confidence in the quality of the software
 To prevent defects in the final product
 To ensure the end product meets customer requirements as well as the
company specifications
 To provide customers with a quality product and increase their confidence
in the company
Grey box testing
The Gray Box Testing is a combination of Black Box and White Box Testing.
In the Black Box Testing technique, the tester is unaware of the internal structure
of the item being tested and in White Box Testing the internal structure is known
to the tester. The internal structure is partially known in Gray Box Testing. This
includes access to internal data structures and algorithms to design the test
cases. Gray Box Testing is named so because the software program is like a
semitransparent or gray box inside which the tester can partially see. It
commonly focuses on context-specific errors related to web systems. It is based
on requirement test case generation because it has all the conditions presented
before the program is tested.
Objectives of Gray Box Testing
1. To provide combined advantages of both black box testing and white box
testing.
2. To combine the input of developers as well as testers.
3. To improve overall product quality.
4. To reduce the overhead of long process of functional and non-functional
tastings.
5. To provide enough free time to developers to fix defects.
6. To test from the user point of view rather than a designer point of view.
Advantages of Gray Box Testing
 Clarity of goals: Users and developers have clear goals while doing testing.
 Done from user perspective: Gray box testing is mostly done by the user
perspective.
 High programming skills not required: Testers are not required to have
high programming skills for this testing.
 Non-intrusive: Gray box testing is non-intrusive.
 Improved product quality: Overall quality of the product is improved.
 Defect fixing: In gray box testing, developers have more time for defect
fixing.
  Benefits of black box and white box testing: By doing gray box testing,
benefits of both black box and white box testing is obtained.
 Unbiased: Gray box testing is unbiased. It avoids conflicts between a tester
and a developer.
 Effective testing: Gray box testing is much more effective in integration
testing.
Importance of software testing
Software testing is the culmination of application development through which
software testers evaluate code by questioning it. This evaluation can be brief or
proceed until all stakeholders are satisfied. Software testing identifies bugs and
issues in the development process so they're fixed prior to product launch. This
approach ensures that only quality products are distributed to consumers.
1. Identifies defects early.
2. Improves product quality.
3. Increases customer trust and satisfaction.
4. Detects security vulnerabilities.
5. Helps with scalability.
6. Saves money.
Types of software testing
1. Integration testing. This groups together two or more modules of an
application to ensure they function collectively. This type of testing also
reveals interface, communication and data flow defects between modules.
2. Unit testing. Typically conducted during the application development
phase, the purpose of unit testing is to ensure that each individual unit or
component performs as expected. This is a type of white box testing and
test automation tools -- such as NUnit, JUnit and xUnit -- are typically used
to execute these tests.
 3. Functional testing. This entails checking functions against functional
requirements. A common way to conduct functional testing is by using the
black box testing
4. Security testing. This ensures the software is free of potential
vulnerabilities, known flaws and security loopholes that might affect the
user system and data. Security testing is generally conducted through
penetration testing
5. Performance testing. This tests the performance and speed of an
application under a given workload.
6. Regression testing. This verifies whether adding new features causes a
decline in the functionality of an application.
7. Stress testing. This assesses the strength of software by testing how much
load it can take before reaching a breaking point. This is a type of
nonfunctional test.
8. Acceptance testing. This evaluates the entire system against the desired
requirements and ensures the project is complete.
Unit testing
Unit testing is a type of software testing that focuses on individual units or
components of a software system. The purpose of unit testing is to validate that
each unit of the software works as intended and meets the requirements. Unit
testing is typically performed by developers, and it is performed early in the
development process before the code is integrated and tested as a whole system.
unit testing is a software testing technique using which individual units of
software i.e. group of computer program modules, usage procedures, and
operating procedures are tested to determine whether they are suitable for use
or not. It is a testing method using which every independent module is tested to
determine if there is an issue by the developer himself.
The objective of Unit Testing is:
1. To isolate a section of code.
 2. To verify the correctness of the code.
3. To test every function and procedure.
4. To fix bugs early in the development cycle and to save costs.
5. To help the developers understand the code base and enable them to make
changes quickly.
6. To help with code reuse
Integration testing
Integration testing is a type of software testing where components of the
software are gradually integrated and then tested as a unified group. Usually
these components are already working well individually, but they may break
when integrated with other components. With integration testing, testers want
to find defects that surface due to code conflicts between software modules
when they are integrated with each other.
Importance of integration testing
1. Inconsistent code logic: They are coded by different programmers whose
logic and approach to development differ from each other, so when
integrated, the modules cause functional or usability issues.
2. Shifting requirements: Clients change their requirements frequently.
Modifying the code of 1 module to adapt to new requirements sometimes
means changing in its code logic entirely, which affects the entire
application.
3. Erroneous Data: Data can change when transferred across modules. If not
properly formatted when transferring, the data can’t be read and
processed, resulting in bugs.
4. Third-party services and API integrations: Since data can change when
transferred, API and third-party services may receive false input and
generate false responses.
 5. Inadequate exception handling: Developers usually account for exceptions
in their code, but sometimes they can’t fully see all of the exception
scenarios until the modules are pieced together.
6. External Hardware Interfaces: Bugs can also arise when there is software-
hardware incompatibility, which can easily be found with proper
integration testing.
Advantages:
Suitable for simple and small-sized system with low level of dependency among
software components.
 Little to no planning beforehand required
 Easy to set up since all modules are integrated simultaneously
 Management and coordination efforts are minimized since there is only
one major testing phase
Disadvantages:
 Costly and time-consuming for large systems with a huge number of units
as testers have to wait until all modules have been developed to start
testing.
 Waiting for all modules to be developed before testing also means late
defect detection.
 Hard to isolate and pinpoint bugs in specific modules
 Hard to debug due to the complexity of multiple integrated modules
Acceptance testing
It is a formal testing according to user needs, requirements and business
processes conducted to determine whether a system satisfies the acceptance
criteria or not and to enable the users, customers or other authorized entities to
determine whether to accept the system or not.
Types of Acceptance Testing
 1. User acceptance testing
2. Business acceptance testing
3. Contract acceptance testing
4. Regulation acceptance testing
5. Operational acceptance testing
6. Alpha testing
7. Beta testing
Advantages of Acceptance Testing:
 This testing helps the project team to know the further requirements from
the users directly as it involves the users for testing.
 Automated test execution.
 It brings confidence and satisfaction to the clients as they are directly
involved in the testing process.
 It is easier for the user to describe their requirement.
 It covers only the Black-Box testing process and hence the entire
functionality of the product will be tested.
Disadvantages of Acceptance Testing:
 Users should have basic knowledge about the product or application.
 Sometimes, users don’t want to participate in the testing process.
 The feedback for the testing takes long time as it involves many users and
the opinions may differ from one user to another user.
 Development team is not participated in this testing process.
Regression Testing
Regression Testing is the process of testing the modified parts of the code and
the parts that might get affected due to the modifications to ensure that no new
errors have been introduced in the software after the modifications have been
made. Regression means the return of something and in the software field, it
refers to the return of a bug.
Performance of regression testing
 When a new functionality is added to the system and the code has been
modified to absorb and integrate that functionality with the existing code.
 When some defect has been identified in the software and the code is
debugged to fix it.
 When the code is modified to optimize its working.
Techniques for the selection of Test cases for Regression Testing:
 Select all test cases: In this technique, all the test cases are selected from
the already existing test suite. It is the simplest and safest technique but
not much efficient.
 Select test cases randomly: In this technique, test cases are selected
randomly from the existing test-suite, but it is only useful if all the test cases
are equally good in their fault detection capability which is very rare. Hence,
it is not used in most of the cases.
 Select modification traversing test cases: In this technique, only those test
cases are selected which covers and tests the modified portions of the
source code the parts which are affected by these modifications.
 Select higher priority test cases: In this technique, priority codes are
assigned to each test case of the test suite based upon their bug detection
capability, customer requirements, etc.
Advantages of Regression Testing:
 It ensures that no new bugs has been introduced after adding new
functionalities to the system.
 As most of the test cases used in Regression Testing are selected from the
existing test suite, and we already know their expected outputs. Hence, it
can be easily automated by the automated tools.
 It helps to maintain the quality of the source code.
Disadvantages of Regression Testing:
 It can be time and resource consuming if automated tools are not used.
 It is required even after very small changes in the code.
Functional testing
Functional Testing is a type of Software Testing in which the system is tested
against the functional requirements and specifications. Functional testing
ensures that the requirements or specifications are properly satisfied by the
application. This type of testing is particularly concerned with the result of
processing.
Purpose of functional testing
1. Functional testing mainly involves black box testing and can be done
manually or using automation. The purpose of functional testing is to:
2. Test each function of the application: Functional testing tests each function
of the application by providing the appropriate input and verifying the
output against the functional requirements of the application.
3. Test primary entry function: In functional testing, the tester tests each
entry function of the application to check all the entry and exit points.
4. Test flow of the GUI screen: In functional testing, the flow of the GUI screen
is checked so that the user can navigate throughout the application.
Functional testing involves the following steps:
 Identify test input: This step involves identifying the functionality that
needs to be tested. This can vary from testing the usability functions, and
main functions to error conditions.
 Compute expected outcomes: Create input data based on the
specifications of the function and determine the output based on these
specifications.
 Execute test cases: This step involves executing the designed test cases and
recording the output.
  Compare the actual and expected output: In this step, the actual output
obtained after executing the test cases is compared with the expected
output to determine the amount of deviation in the results. This step
reveals if the system is working as expected or not.
Type of Functional Testing
 Unit testing
 Integration testing
 Smoke testing
 User acceptance testing
 Interface testing
 Usability testing
 System testing
 Regression testing
 Sanity testing
 White box testing
 Black box testing
 Database testing
 Adhoc testing
 Recovery testing
 Static testing
 Grey box testing
 Component testing
Parameters Functional Testing Non-functional Testing

Functional testing
Non-functional verifies
verifies the operations
Definition the behavior of an
and actions of an
application.
application.

It is based on the It is based on the

Testing based on requirements of the expectations of the
customer. customer.

The objective is to The objective is to

Objective validate software performance of the
actions. software system

Non-functional testing is
Functional testing is
carried out using the
Requirements carried out using the
performance
functional specification.
specifications.

It describes what the It describes how the

Functionality
product does. product works.

Unit testing. Performance testing.

Example Integration testing. Load testing.
Sanity testing Stress testing.
Parameters Functional Testing Non-functional Testing

Smoke testing. Volume testing.

Regression testing. Usability testing.

Performance Testing Functional Testing

Objective Validates performance Validates behavior
Focus Area User expectations User requirements
Test data input Performance Functional Requirements
requirements
Test Execution Done after functional Done before performance
Sequence testing testing
Testing Approach Automation preferred Manual or Automated or
Crowdsource
Production test Preferred Not mandatory
environment emulation
Infrastructural High Minimal
requirements
Time taken for testing Less More
Impact of functional No Yes
Requirement changes
Testing Tools examples LoadRunner, Jmeter Selenium, QTP, WinRunner
Top down and bottom up
In top down testing technique, high-level modules are tested first, and then
lower-level modules are tested. High-level modules are also known as main
modules, whereas low-level modules are referred to as submodules. The prime
objective of top-down integration testing is to uncover key design defects early
on since the main modules are tested first.
Advantages:
 Critical Modules are tested on priority
 Early detection & fixing of major design defects
 Fault localization becomes easier
 Allows creation of early prototype
 Early prototype makes test case creation easier
Disadvantages:
 Many stubs need to be produced
 Creating stubs for intricate features may become complicated
 Representing test cases in stubs can be difficult
 Observation of test output is more difficult
 Lower-level modules are insufficiently tested
In the bottom up testing technique, testing is done from the submodule to the
main module. The modules will be added from the bottom to the top, and the
data flow will be tested in a similar manner.
Advantages:
 Detects major flaws that occur at the lower level modules
 Testing can start without waiting for all units to be completed
 Easy to create test conditions
 Test result observation is easier
Disadvantages:
  Driver modules have to be produced
 Early prototype can not be generated
 Critical modules at top get tested inadequately
 Main modules may remain prone to defects

Top Down Integration Testing Bottom Up Integration Testing

In top down Integration,

In bottom up integration, testing
testing takes place from top to
takes place from bottom to top
bottom means system
means system integration begins
integration begins with main
with lower level or submodules.
modules.

If the invoked submodule If the main module hasn’t been

hasn’t been developed yet, developed yet, drivers are used
stubs are used for temporarily for temporarily simulating that
simulating that submodule. main module.

Higher level modules are Lower level modules are tested &
tested & integrated first and integrated first and then higher
then lower level modules are level modules are tested &
tested & integrated. integrated.

Main modules are created first Different smaller modules are

and then submodules are developed and then integrated
called from it. with the main module.

Control flows from top to Control flows from bottom to

bottom. top.
 Top Down Integration Testing Bottom Up Integration Testing

This approach is advantageous This approach is advantageous if

if the significant bugs occur in the crucial defects occur in the
the top modules. lower modules.

Mainly implemented in
Mainly implemented in object
structure or procedure
oriented programming
oriented programming
languages.
languages.

Testing complexity is high and

Testing complexity is low.
data intensive.

Stubs and Drivers

Independent testing of a Unit becomes impossible. But that is what we want to
do; we want to test a Unit in isolation! So here we use ‘Stub’ and ‘Driver.
A ‘Driver’ is a piece of software that drives (invokes) the Unit being tested. A
driver creates necessary ‘Inputs’ required for the Unit and then invokes the Unit.
Driver passes test cases to another piece of code. Test Harness or a test driver is
supporting code and data used to provide an environment for testing part of a
system in isolation. It can be called as as a software module which is used to
invoke a module under test and provide test inputs, control and, monitor
execution, and report test results or most simplistically a line of code that calls a
method and passes that method a value.
A ‘Stub’ is a piece of software that works similar to a unit which is referenced by
the Unit being tested, but it is much simpler that the actual unit. A Stub works as
a ‘Stand-in’ for the subordinate unit and provides the minimum required
behavior for that unit. A Stub is a dummy procedure, module or unit that stands
in for an unfinished portion of a system.
There are 4 basic types of stubs used for top down testing. They are:
1. Display trace messages,
2. Display parameter values,
3. Return table values,
4. Return specific table values based on parameter.