Noida Institute of Engineering and Technology, Greater Noida

Software Design

Unit: III

Subject Name: Software

Dr. Amba Mishra
Engineering (AIT401)
Assistant Professor
IT and M.Tech(Int.)
Course Details
B.Tech.(IT)
4th Sem

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 1

 Brief Introduction of Faculty

Dr. Amba Mishra

Designation: Assistant Professor IT Department
NIET Greater Noida
Qualification:
 Ph. D(CSE) from Noida International University 2018
 M.Tech (CSE) from CDAC Noida(GGSIPU) 2010
 B.Tech (CSE) GGSIPU in 2007

Teaching Experience: 11Yrs

Research Publication

Particulars Journals Conferences

International 2 5

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 2

 Content

 Evaluation Scheme
 Syllabus
 Course Objective
 Course Outcomes
 Program Outcome
 CO-PO Mapping
 Program Specific Outcome
 CO-PSO Mapping
 Program Educational Objective
 Result Analysis
 End Semester Question Paper Template
 Prerequisite/Recap
 Brief Introduction about subject with video
 Unit Content

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 3

 Content

 Unit Objective
 Topic Objective/Topic Outcome
 Design principles
 The design process
 Design concepts: Abstraction, Refinement, Modularity (Cohesion and coupling)
 Software Architecture (Function Oriented Design, Object Oriented Design)
 Control Hierarchy (Top-Down and Bottom-Up Design)
 Structural partitioning
 Data structure
 Software procedure
 Information hiding
 Daily Quiz
 Weekly Assignment
 Old Question Papers
 Expected Questions
 Recap of Unit
19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 4
 Evaluation Scheme

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 5

 Syllabus

Course Contents / Syllabus

Introduction 8 Hours
Introduction: Evolving role of Software, Software Characteristics, Software Crisis, Silver Bullet, Software Myths,
Software Process, Software Engineering Phases, Team Software Process (TSP), Emergence of Software Engineering,
Software process, Project and Product.

Software Process Models: SDLC, Waterfall Model, Prototype Model, Spiral, Model, Iterative Model, Incremental
Model, V Process Model, Agile Methodology.

Software Requirement 8 Hours

Software Requirement Specifications (SRS): Requirement Engineering Process: Elicitation, Analysis, Documentation,
Review and Management of User Needs, Feasibility Study, Information Modelling, Decision Tables, SRS Document,
IEEE Standards for SRS.

Software Design 8 Hours

Software Design: Design principles, The design process; Design concepts: Abstraction, Refinement, Modularity
(Cohesion and coupling), Software Architecture (Function Oriented Design, Object Oriented Design), Control
Hierarchy (Top-Down and Bottom-Up Design), Structural partitioning, Data structure, Software procedure,
Information hiding.

Software Measurement and Metrics: Various Size Oriented Measures, Function Point, Design Heuristics for effective
modularity, Cyclomatic Complexity Measures: Control Flow Graphs.

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 6

 Syllabus

UNIT-IV Software Testing 8 Hours

Software Testing: Testing Objectives, Unit Testing, Integration Testing, User Acceptance Testing,
Regression Testing, Testing for Functionality and Testing for Performance, Top Down and Bottom-Up
Testing Strategies: Test Drivers and Test Stubs, Test Beds and Test Oracle, Structural Testing (White Box
Testing), Functional Testing (Black Box Testing), Test Data Suit Preparation, Alpha and Beta Testing of
Products.
Static Testing Strategies: Formal Technical Reviews (Peer Reviews), Walk Through, Code Inspection,
Compliance with Design and Coding Standards.
Software Quality Assurance (SQA): Quality concepts, Software quality assurance, SQA activities,
Formal approaches to SQA; Statistical software quality assurance; CMM, The ISO standard.

UNIT-V Project Maintenance and Management Concepts 8 Hours

Software Maintenance: Preventive, Corrective and Perfective Maintenance, Project Management
concepts, Planning the Software Project, Cost of Maintenance, Estimation—Empirical Estimation
COCOMO- A Heuristic Estimation Techniques, Staffing Level Estimation, Team structures, Risk analysis
and management, Configuration Management, Software reengineering, Reverse Engineering,
restructuring, Forward engineering, Clean Room software engineering, CASE Tools.

Dr. Amba Mishra ACSE0301 Software Engineering Unit III

19/05/2024 7
 Branch wise Application

• Business software.
• Accounting software.
• Analytics.
• Decision support systems.
• Airline reservations.
• Banking, Automated teller machines, Cheque processing.
• Commerce, Trade, Auctions (e.g. eBay)
• Compilers
• Animation

Dr. Amba Mishra ACSE0301 Software Engineering Unit III

19/05/2024 8
 Course Objective(unit-3)

• To enable students to develop methods and procedures for software

development that can scale up for large systems and that can be used
consistently to produce high-quality software at low cost and with a small
cycle of time.
• Students will be able to understand the concepts of requirement
engineering, designing and its principles, testing techniques and
maintenance methods for effective software development.

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 9

 Objective of Topics

TOPIC Objective
Software Design To Understand the basic concept of
design
Low Level Design Study of Low Level Design
Coupling and Cohesion Measures To Understand and compare the Coupling
and Cohesion

Design Strategies To examine the different design Strategies

Test Data Suit Preparation, Alpha Study of Software Measurement and

and Beta Metrics
Cyclomatic Complexity Measures To find the Cyclomatic Complexity

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 10

 Course Outcome

Course outcome: After completion of this course students will be able to

CO 1 Explain various software characteristics and analyze different K1, K2

software Development Models

CO 2 Demonstrate the contents of a SRS and apply basic software quality K1, K2
assurance practices to ensure that design, development meet or
exceed applicable standards

CO 3 Compare and contrast various methods for software design. K2, K3

CO 4 Formulate testing strategy for software systems, employ techniques K3

such as unit testing, Test driven development and functional testing

CO 5 Manage software development process independently as well as in K5

teams and make use of Various software management tools for
development, maintenance and analysis.

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 11

 Program Outcomes (POs)
1. Engineering knowledge
2. Problem analysis
3. Design/development of solutions
4. Conduct investigations of complex problems
5. Modern tool usage
6. The engineer and society
7. Environment and sustainability
8. Ethics
9. Individual and team work
10. Communication
11. Project management and finance
12. Life-long learning

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 12

 CO-PO Mapping

CO-PO Correlation Matrices

Correlation levels are taken 1, 2 and 3 as defined below:
1: Slight (Low) 2: Moderate (Medium) 3: Substantial (High)
Software Engineering (Code: ACSE0301) Year of Study: 2021-22

CO PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO10 PO11 PO12

2 3 3 3 2 - - - - - 3 3
CO1
3 3 3 3 3 - - - - - 2 3
CO2
CO3 3 2 3 2 2 - - - - - 3 3

CO4 2 2 2 2 3 3 - 3 3 - 3 3

CO5 2 2 3 2 3 3 - 3 - 3 3 3

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 13

 Program Specific Outcomes (PEOs)
The Program Educational Objectives (PEOs) of B.Tech (Information Technology) program
are established and are listed as follow:
PEO 1: To have an excellent scientific and engineering breadth so as to comprehend,
analyze, design and provide sustainable solutions for real-life problems using state-of-
the-art technologies.
PEO 2: To have a successful career in industries, to pursue higher studies or to support
entrepreneurial endeavors and to face the global challenges.
PEO 3: To have an effective communication skills, professional attitude, ethical values
and a desire to learn specific knowledge in emerging trends, technologies for research,
innovation and product development and contribution to society.
PEO 4: To have life-long learning for up-skilling and re-skilling for successful professional
career as engineer, scientist, entrepreneur and bureaucrat for betterment of society.

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 14

 CO-PO and PSO Mapping

Program Specific Outcomes and Course Outcomes Mapping

CO PSO1 PSO2 PSO3 PSO4

CO1 3 3 - 3
CO2 3 3 2 3
CO3 3 3 - 3
CO4 3 3 - 3
CO5 3 3 - 3

*3= High *2= Medium *1=Low

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 15

 Program Educational Objective(PEOs)

PEO 1: Apply sound knowledge in the field of Information

Technology to full the needs of IT industry.
PEO 2: Design innovative and interdisciplinary systems through
latest digital technologies.
PEO 3: Inculcate professional – social ethics, team work and
leadership for serving the society.
PEO 4: Inculcate lifelong learning in the field of computing for
successful career in organizations and R&D sectors.

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 16

 End Semester Question Paper Templates

B TECH
(SEM-V) THEORY EXAMINATION 20__-20__
SOFTWARE ENGINEERING
Time: 3 Hours Total Marks:
100
Note: 1. Attempt all Sections. If require any missing data; then choose
suitably.
SECTION A
1. Attempt all questions in brief.
Q.No. Question
1 x 10CO
Marks
= 10
1 2
2 2
. .
10 2

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 17

 End Semester Question Paper Templates

SECTION A
2. Attempt all questions in brief. 2 x 5 = 10
Q.No. Question Marks CO
1 2
2 2
. .
5 2

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 18

 End Semester Question Paper Templates
SECTION B
3. Attempt any five of the following: 5 x 6 = 30

Q.No. Question Marks CO

1 6
2 6
. .
7 6

SECTION C
4. Attempt any one part of the following: 1 x 10 = 10
Q.No. Question Marks CO

1 10
2 10

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 19

 Prerequisite and Recap

• Basic knowledge about software and its types.

• Basic knowledge of any programming language

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 20

 Brief Introduction with Video

•A software design process involves the

transformation of ideas into details
implementation description, with good
satisfying the s/w requirement.
• https://youtu.be/sGxgZxwuHzc

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 21

 Unit Content

• Software Design: Design principles, The design process;

Design concepts: Abstraction, Refinement, Modularity
(Cohesion and coupling), Software Architecture (Function
Oriented Design, Object Oriented Design), Control Hierarchy
(Top-Down and Bottom-Up Design), Structural partitioning,
Data structure, Software procedure, Information hiding.

• Software Measurement and Metrics: Various Size Oriented

Measures, Function Point, Design Heuristics for effective
modularity, Cyclomatic Complexity Measures: Control Flow
Graphs.

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 22

tware Engineering Unit III
 Unit Objective

• To make the student know the various

techniques used to design a software
• To make the student to find out the cyclomatic
complexity of a software

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 23

tware Engineering Unit III
 Topic Outcome
• Student will know the various techniques used
to design a software
• Student will be able to know the difference
between loosely coupled and strongly coupled
software.
• Student will be able to find out cyclomatic
complexity of a software.

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 24

tware Engineering Unit III
 Software Design (CO3)

• In this process(phase) designer plans “ How’ a s/w system should be produced as

per customer requirements.
• SRS tell us “What” a system does. Design Process tell us “How” a s/w system work.
• Designing of a s/w system means determining how requirements are realized and
result in a s/w design document(SDD).
• Framework of design is given below:

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 25

 Software Design

• Software Design is also a process to plan or

convert the software requirements into a step
that are needed to be carried out to develop a
software system.
• There are several principles that are used to
organize and arrange the structural components
of Software design.
• Software Designs in which these principles are
applied affect the content and the working
process of the software from the beginning.
19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 26
 Software Design Principles

Dr. Amba Mishra ACSE0301 Software Engineering Unit III

19/05/2024 27
 Principles of Software Design

• Should not suffer from “Tunnel Vision” –

While designing the process, it should not suffer from “tunnel vision” which means that is should not
only focus on completing or achieving the aim but on other effects also.

• Traceable to analysis model –

The design process should be traceable to the analysis model which means it should satisfy all the
requirements that software requires to develop a high-quality product.

• Should not “Reinvent The Wheel” –

The design process should not reinvent the wheel that means it should not waste time or effort in
creating things that already exist. Due to this, the overall development will get increased.

• Minimize Intellectual distance –

The design process should reduce the gap between real-world problems and software solutions for
that problem meaning it should simply minimize intellectual distance.

• Exhibit uniformity and integration –

The design should display uniformity which means it should be uniform throughout the process
without any change. Integration means it should mix or combine all parts of software i.e. subsystems
into one system.

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 28

 Principles of Software Design
• Accommodate change –
The software should be designed in such a way that it accommodates the change implying
that the software should adjust to the change that is required to be done as per the user’s
need.

• Degrade gently –
The software should be designed in such a way that it degrades gracefully which means it
should work properly even if an error occurs during the execution.
• Assessed or quality –
The design should be assessed or evaluated for the quality meaning that during the
evaluation, the quality of the design needs to be checked and focused on.

• Review to discover errors –

The design should be reviewed which means that the overall evaluation should be done to
check if there is any error present or if it can be minimized.

• Design is not coding and coding is not design –

Design means describing the logic of the program to solve any problem and coding is a
type of language that is used for the implementation of a design.
19/05/2024 Dr. Amba Mishra ACSE0301 Sof 29
tware Engineering Unit III
 Software Design

• It start with initial requirement and ends with final design.

• Data is gathered on user requirement and analyze accordingly.
• A High level design is prepared after answering question requirements.
• Design is validated against requirements on regular basis.
• Design is refined in every cycle and finally it is documented to produce SDD(S/w design
document)

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 30

 Conceptual design and Technical design (CO3)

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 31
Unit III
 Conceptual design and Technical design

• To transform req. into working system, designer must satisfy both

customer and system(S/W) builder.
• A design is a two part iterative process
1. Conceptual design or preliminary design or high level design:
it is the identification of different modules and control
relationship among them and definition of the interface among
these module. It is also called program structure or S/W
architecture.

2. Technical design or detailed design or low level design: it

describe h/w configuration, s/w needs, communication
interface, I/O of the system, data structure and algorithms of
different modules are designed

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 32

tware Engineering Unit III
 Conceptual design and Technical design

Conceptual design Technical design

 Where will the data come  Hardware configuration
from ?  Software needs
 What will happen to data in
 Communication interfaces
the system?
 I/O of the system
 How will the system look to
users?  Software architecture
 What choices will be offered  Network architecture
to users?  Any other thing that translates
 What is the timings of events? the requirements in to a
solution to the customer’s
 How will the reports &
problem.
screens look like?

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 33
Unit III
 Outcome of a design process

• Out come of a design process:

i. Different modules required.
ii. Control relationship among modules.
iii. Interfaces among different modules.
iv. Data structure of individual modules.
v. Algorithm required to implement module.
• Characteristic of a good design:
i. Correctness: implement all functionality identified in SRS doc.
ii. Understandability: interpret by coder and tester.
iii. Efficiency: should be efficient.
iv. Maintainability: easy amenable to change

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 34
Unit III
 Design Transformation

Informal More
design Informal formal Finished
outline design design design

Fig: The transformation of an informal design to a detailed

design.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 35
Unit III
 Architectural Design (CO3)

• Outcome of AD/high level design is called program structure or

s/w architecture.
• Problem is decomposed into a set of modules and manage them
with cohesive and low coupling.
• Control relationship and interfaces among various modules are
identified.
• Many notations such as structure chart, UML etc. are used in high
level design.

Dr. Amba Mishra ACSE0301 Software Engineering Unit III

19/05/2024 36
 Architectural Design

• AD methods have various alternative arch. Style of designing a

system. these are:
1. Data flow architecture : flow of data in the system or sub
systems.
2. Object oriented architecture : it involves class and objects
3. Layered architecture: define no. of layered. Outer layered
handle functionality of user interface and inner most
layer handle interaction with the H/W.
4. Data centric architecture: it involves the use of a central
database operation such as inserting, updating, etc. in
the form of a table.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 37
Unit III
 Low level Design (CO3)

• Technical design or detailed design or low level design

– Modularization
– Coupling
– Cohesion
– Flow chart
– Pseudo codes

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 38
Unit III
 Modularization (CO3)

• Modularization:
– Complex system may be divided into simpler pieces called modules.
– A system is composed of modules is called modular.
– Module is treated separately If different modules have either no or
little interactions with each other.
– Cohesion and coupling are decide the degree of modularity.
– A design solution is considered to be highly modular if different
modules in the solution have high cohesion and their inter module
coupling are low.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 39
Unit III
 Modularity

Properties of a module
• Well defined subsystem
• Well defined purpose
• Can be separately compiled and stored in a library.
• Module can use other modules
• Module should be easier to use than to build
• Simpler from outside than from the inside.

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

be intellectually manageable. It enhances design clarity, which in turn
eases implementation, debugging, testing, documenting, and
maintenance of software product.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 40
Unit III
 Modularity

• A system considered modular if it consists of discrete component so

that each component can be implemented separately and a change
to one component has minimal impact on other component.
• No. of module grow, the effort associated with integration the
module also grows.
• So Under modularity and over modularity in a software should be
avoided.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 41
Unit III
 Modularity

Fig. : Modularity and software cost

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 42
Unit III
 Module Coupling (CO3)

• Coupling is the measure of the degree of interdependence(or no of

interconnection) between modules.
• Two modules with high coupling are strongly interconnected i.e.
dependent on each other.
• Two modules with low coupling are not dependent on one another.
• A good design will have low coupling.
• Design with High coupling will have more error.
• Loose coupling minimize the interdependence amongst modules.
• Low coupling can be achieve by:
• eliminating unnecessary relationships
• reducing the number of necessary relationships
• easing the ‘tightness’ of necessary relationships

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 43
Unit III
 Module Coupling

Uncoupled : no Loosely coupled: Highly coupled:

dependencies some dependencies many dependencies

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 44

tware Engineering Unit III
 Module Coupling

Loose coupling can be achieved as:

– Controlling the no of parameter passed amongst
modules.
– Avoid passing undesired data to calling module.
– Maintain parent/child relationship between calling and
called modules.
– Pass data, not the control information.

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 45

tware Engineering Unit III
 Example of coupling

Consider the example of editing a student record in a ‘student

Information system’.

Poor design: Tight Good design: Loose

Coupling Coupling

Dr. Amba Mishra ACSE0301 Software Engineering Unit

19/05/2024 46
III
 Types of Module Coupling

Data coupling Best

Stamp coupling
Control coupling
External coupling
Common coupling
Content coupling Worst

Strength of coupling from lowest coupling(best) to highest

coupling(worst).

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 47
Unit III
 Types of Module Coupling

Data coupling
 Modules communicate by parameters Each parameter is an
elementary piece of data Each parameter is necessary for the
communication. Nothing extra is needed
 Data coupling problems
Too many parameters - makes the interface difficult to
understand and possible error to occur
Tramp data - data ‘traveling’ across modules before being used
Stamp coupling
Occurs when A composite data(data structure) is passed
between modules
problem in stamp coupling
Internal structure contains data not used Bundling -
grouping of unrelated data into an artificial structure

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 48
Unit III
 Types of Module Coupling

Control coupling
• A module controls the logic of another module through the
control information(flag)
• Controlling module needs to know how the other module
works – not

External Coupling
• Occurs when another module is external to the s/w being
developed or to a particular type of hardware.
• It is based on communication to external tools and devices.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 49
Unit III
 Types of Module Coupling

Common coupling
Use of global data as communication between modules
Making a change to the common data means tracing back to
all the modules which access that data to evaluate the effect of
changes.
problem in Common coupling
ripple effect
inflexibility
difficult to understand the use of data
It can difficult to determine which value is responsible for having
set a variable to a particular values

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 50
Unit III
 Example of common coupling

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 51
Unit III
 Types of Module Coupling

Content coupling
Content coupling occurs when module A changes data of module B or when
control is passed from one module to the middle of another. In Fig. , module B
branches into D, even though D is supposed to be under the control of C. A
module refers to the inside of another module. Branch into another module
Refers to data within another module Changes the internal workings of
another module Mostly by low-level languages

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 52
Unit III
 Module Cohesion (CO3)

• Cohesion is a measure of the degree(strength) to which the

elements of a module are functionally related.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 53
Unit III
 Cohesion
Cohesion

• Definition
– The degree to which all elements of a module are directed
towards a single task.
– The degree to which all elements directed towards a task are
contained in a single component.
– The degree to which all responsibilities of a single class are
related.
• Internal glue with which Module is constructed
• All elements of module are directed toward and essential for
performing the same task.
• Elements: instructions, groups of instructions, data definition, call of
another module.

• Strong cohesion will reduce relations between modules - minimize

coupling
19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit 54
III
 Type of Cohesion

 Functional cohesion
 Sequential cohesion
 Procedural cohesion
 Temporal cohesion
 Logical cohesion
 Coincident cohesion

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 55

tware Engineering Unit III
 Type of Module Cohesion

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 56
Unit III
 Type of Cohesion

High Cohesion
Functional

Sequential

Communicational

Procedural

Temporal

Logical

Coincidental Low

Dr. Amba Mishra ACSE0301 Software Engineering Unit III 37

19/05/2024
 Coincidental Cohesion

• Parts of the module are unrelated (unrelated functions, processes,

or data)
• Parts of the module are only related by their location in source
code.
• Elements needed to achieve some functionality are scattered
throughout the system.
• EX.
1. Print next line
2. Reverse string of characters in second
argument
3. Add 7 to 5th argument
4. Convert 4th argument to float

Dr. Amba Mishra ACSE0301 Software Engineering

Unit III 58
19/05/2024
 Logical Cohesion

• Elements of module are related logically and not functionally.

• Several logically related elements are in the same module and one
of the elements is selected by the client module. Ex.
• A module reads inputs from tape, disk, and network.
• All the code for these functions are in the same module.
• Operations are related, but the functions are significantly
different.

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering

Unit III
 Temporal Cohesion

• Elements are related by timing involved

• Elements are grouped by when they are processed.
• Example: An exception handler that
– Closes all open files
– Creates an error log
– Notifies user
– Lots of different activities occur, all at same time

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 60

tware Engineering Unit III
 Procedural Cohesion

• Elements of a module are related only to ensure a particular order

of execution.
• Actions are still weakly connected and unlikely to be reusable.
• Example:
– ...
– Write output record
– Read new input record
– Pad input with spaces
– Return new record
– ...

Dr. Amba Mishra ACSE0301 Software Engineering Unit III

19/05/2024 61
 Communicational Cohesion

• Functions performed on the same data or to produce the same data.

• Examples:
– Update record in data base and send it to the printer
• Update a record on a database
• Print the record

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 Unit III 62
 Sequential Cohesion

• Def: The output of one part is the input to

another.
• Data flows between parts (different from
procedural cohesion)
• Occurs naturally in functional programming
languages

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 63

 Functional Cohesion

• Every essential element to a single computation is contained in the

module.
• Every element in the module is essential to the computation.
• What is a functionally cohesive module?
– One that not only performs the task for which it was designed
but
– it performs only that function and nothing else.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 64
Unit III
 Relationship between cohesion & coupling (CO3)

If the software is not properly modularized, a host of seemingly trivial

enhancement or changes will result into death of the project. Therefore, a
software engineer must design the modules with goal of high cohesion and low
coupling.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 65
Unit III
 Flow Chart (CO3)

• It is convenient technique to represent the flow of control in a

program.
• It is a graphical representation of an algorithms.
• It also help during testing and modifications in the programs.
• Advantage of Flow chart:
• It help in following ways:
– Synthesis(Systematic combination of different
elements.)
– Coding
– Debugging
– Communication
– Testing

Dr. Amba Mishra ACSE0301 Software Engineering Unit

19/05/2024 66
III
 Flow Chart

Limitation:
• No standard way that should be included in flow chart.
• Difficult to draw, if algorithms has complex branches and
loops.
• Time consuming process for large complex problems
• Difficult to include any new step in existing flow chart.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 67
Unit III
 Basic Component of Flow Chart

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 68
Unit III
 Example 1

Dr. Amba Mishra ACSE0301 Software Engineering Unit III

19/05/2024 69
 Example 2

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 70

tware Engineering Unit III
 Structure Chart (CO3)

• It represent the s/w architecture that can be easily implemented

using some prog. language.
• It partitions a system into black box(input/output)
• Connection between modules are represented by lines between
rectangular boxes.
• Component are generally read from top to bottom and left to right.
• Top level modules called lower level modules.
• It has only one module on the top called root.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 71
Unit III
 Structure Chart

It partition a system into block boxes. A black box means that

functionality is known to the user without the knowledge of
internal design.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 72
Unit III
 Notation of Structure Chart

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 73
Unit III
 Notation of Structure Chart

• Rectangular boxes: Represents a module.

• Module invocation arrows: Control is passed from one module to
another module in the direction of the connecting arrow.
• Data flow arrows: Arrows are annotated with data name; named
data passes from one module to another module in the direction of
the arrow.
• Library modules: Represented by a rectangle with double edges.
• Selection: Represented by a diamond symbol.
• Repetition: Represented by a loop around the control flow arrow.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 74
Unit III
 Structure Chart Ex.1: rms calculator

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 75
Unit III
 Pseudo Code (CO3)

• Pseudo code notation can be used in both the preliminary (high

level)and detailed design(low level) phases.
• Code are effective and building block for actual program.
• Using pseudo code, the designer describes system characteristics using
short, concise, English language phrases that are structured by key
words such as If-Then-Else, While-Do, and End.
• Advantage of pseudo code(compare to flow chart)
• Easy to convert in programming language.
• Easy to modify.
• Require less time and effort to write it.
• Easy to write than writing a program in programming language.
• Disadvantage of pseudo code:
• No graphical representation of program logic.
• No standard rule are follows to writing pseudo code
Dr. Amba Mishra ACSE0301 Software Engineering
19/05/2024 76
Unit III
 Pseudo Code

• Problem: find smallest number among three variables

1. read values of a, b and c variables
2. if (a < b)
{
if(a < c)
print “a is small”
else print “c is small”
else if(b < c)
print “b is small”
else print “c is small”
3. end.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 77
Unit III
 STRATEGY OF DESIGN (CO3)

A good system design strategy is to organize the program modules in

such a way that are easy to develop and latter to, change. Structured
design techniques help developers to deal with the size and complexity
of programs. Analysts create instructions for the developers about how
code should be written and how pieces of code should fit together to
form a program. It is important for two reasons:

 First, even pre-existing code, if any, needs to be understood,

organized and pieced together.
 Second, it is still common for the project team to have to write
some code and produce original programs that support the
application logic of the system

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 78

tware Engineering Unit III
 STRATEGY OF DESIGN

 Top down design

 Bottom up design.
 Function oriented design.
 Object oriented design.

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 79

tware Engineering Unit III
 Top Down Design (CO3)

• Top-down design takes the whole software system as one entity and
then decomposes it to achieve more than one sub-system or
component based on some characteristics.
• Each sub-system or component is then treated as a system and
decomposed further. This process keeps on running until the lowest
level of system in the top-down hierarchy is achieved.
• Top-down design starts with a generalized model of system and
keeps on defining the more specific part of it. When all components
are composed the whole system comes into existence.
• Top-down design is more suitable when the software solution needs
to be designed from scratch and specific details are unknown.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 80
Unit III
 Top Down Design

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 81

tware Engineering Unit III
 Bottom up Design (CO3)

• The bottom up design model starts with most specific and basic
components.
• It proceeds with composing higher level of components by using basic or
lower level components. It keeps creating higher level components until the
desired system is not evolved as one single component.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 82
Unit III
 Bottom-up Design

•Bottom-up strategy is more suitable when a system needs

to be created from some existing system, where the basic
primitives can be used in the newer system.

•Hybrid Design :Both, top-down and bottom-up approaches

are not practical individually. Instead, a good combination of
both is used.

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 83

tware Engineering Unit III
 Function oriented Design (CO3)

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. Thus,
system is designed from a functional viewpoint

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 84
Unit III
 Function Oriented Design

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 85
Unit III
 Function oriented Design

• In function-oriented design, the system is comprised of many smaller

sub-systems known as functions. These functions are capable of
performing significant task in the system. The system is considered as
top view of all functions.
• Function oriented design inherits some properties of structured design
where divide and conquer methodology is used.
• This design mechanism divides the whole system into smaller functions.
These functional modules can share information among themselves by
means of information passing and using information available globally.
• Another characteristic of functions is that when a program calls a
function, the function changes the state of the program, which
sometimes is not acceptable by other modules. Function oriented
design works well where the system state does not matter and
program/functions work on input rather than on a state.
19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 86
 Design Process

• The whole system is seen as how data flows in the system by means
of data flow diagram.

• DFD depicts how functions changes data and state of entire system.

• The entire system is logically broken down into smaller units known
as functions on the basis of their operation in the system.

• Each function is then described at large.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 87
Unit III
 FOD notations

• For FOD, the design can be represented graphically and mathematically

by following:
1. Data flow diagram.
2. Data dictionary.
3. Structure chart.
4. Pseudo code.

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 88

tware Engineering Unit III
 Object Oriented concepts (CO3)

• 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 do manipulated by the program.
Important concepts of Object Oriented Design:
• Objects - All entities involved in the solution design are known as
objects. For example, person, banks, company and customers are
treated as objects. Every entity has some attributes methods to
perform on the attributes.
• Classes - A class is a generalized description of an object. An object
is an instance of a class. Class defines all the attributes, which an
object can have and Operations(methods), which defines the
functionality of the object.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 89
Unit III
 Object Oriented Design

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 90

tware Engineering Unit III
 Object Oriented concepts

Attribute
An attributes is a data value held by the objects in a class.
Operation
An operation is a function or transformation that may be applied to or by
objects in a class

Inheritance -
OOD allows similar classes to stack up in hierarchical manner where the
lower or sub-classes can import, implement and re-use allowed variables
and methods from their immediate super classes. This property of OOD
is known as inheritance.

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 91

tware Engineering Unit III
 Object Oriented concepts

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 92

tware Engineering Unit III
 Object Oriented concepts

• Encapsulation - In OOD, the attributes (data variables) and methods (operation on

the data) are bundled together is called encapsulation. Encapsulation restricts
access of the data and methods from the outside world. This is called information
hiding.
• Polymorphism - OOD languages provide a mechanism where methods performing
similar tasks but vary in arguments, can be assigned same name. This is called
polymorphism.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 93
Unit III
 Design Process

• It may have the following steps involved:

• A solution design is created from requirement or previous used system
and/or system sequence diagram.
• Objects are identified and grouped into classes on behalf of similarity in
attribute characteristics.
• Class hierarchy and relation among them is defined.
• Application framework is defined.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 94
Unit III
 Software Measurement and Metrics:

• Software Measurement: A measurement is a

manifestation of the size, quantity, amount or
dimension of a particular attribute of a product
or process.
Software measurement is a titrate impute of a
characteristic of a software product or the software
process.
It is an authority within software engineering.
The software measurement process is defined and
governed by ISO Standard.
19/05/2024 Dr. Amba Mishra ACSE0301 Sof 95
tware Engineering Unit III
 Need of Software Measurement:
• Software is measured to:
 Create the quality of the current product or process.
 Anticipate future qualities of the product or process.
 Enhance the quality of a product or process.
 Regulate the state of the project in relation to budget and schedule.

Classification of Software Measurement:

• There are 2 types of software measurement:
 Direct Measurement: In direct measurement the product, process or
thing is measured directly using standard scale.
 Indirect Measurement: In indirect measurement the quantity or
quality to be measured is measured using related parameter i.e. by
use of reference.

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 96

 Classification of Software Metrics:
There are 2 types of software metrics:
• Product Metrics:
 Product metrics are used to evaluate the state of the product,
tracing risks and under covering prospective problem areas.
 The ability of team to control quality is evaluated.
• Process Metrics:
 Process metrics pay particular attention on enhancing the long term
process of the team or organization.
• Project Metrics: The project matrix describes the project
characteristic and execution process.
 Number of software developer
 Staffing pattern over the life cycle of software
 Cost and schedule
 Productivity
19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 97
 Metrics
A metric is a measurement of the level that any impute belongs to a system product or
process. There are 4 functions related to software metrics:
• Planning
• Organizing
• Controlling
• Improving

Characteristics of software Metrics:

 Quantitative: Metrics must possess quantitative nature i.e. It means metrics can be
expressed in values.
 Understandable: Metric computation should be easily understood ,the method of
computing metric should be clearly defined.
 Applicability: Metrics should be applicable in the initial phases of development of the
software.
 Repeatable: The metric values should be same when measured repeatedly and
consistent in nature.
 Economical: Computation of metrics should be economical.
 Language Independent: Metrics should not depend on any programming language.
19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 98
 Various Size Oriented Measures
• It is the estimation of s/w project parameters such as:
– Effort
– Time duration completing the project
– Total cost for developing the s/w project
• Project size is a measure of the problem complexity in term of effort and
time require to develop the product.
• Two matrices are popularly used to estimate size:
1. Lines of Code(LOC)
2. Function Point(FP)
1. Lines of code:
– it is any line of program text that is not a comment or blank line,
regardless of the number of statements or fragments of statements on
the line.
– This specifically includes all lines containing program header,
declaration, and executable and non-executable statements

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 99
Unit III
 Software Matrices and Measurement

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 100
Unit III
 Function Point Metric (CO3)

• It is a size measurement technique of a problem developed by

Alan Albrecht in 1970.
• Conceptual idea behind it is that size of a s/w product is directly
dependent on the no. of different function.
• Each function when invoked reads input data and transform it to
the corresponding output data.
• s/w size is also dependent on :
• no of files
• No of interfaces.
• Interfaces refer to different mechanisms that need to support for
data transfer with other external systems.

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 101

tware Engineering Unit III
 Function Point Analysis (CO3)

The principle of Albrecht’s function point analysis (FPA) is that a system is

decomposed into functional units.

Inputs : information entering the system

Outputs : information leaving the system
Enquiries : requests for instant access to information
Internal logical files : information held within the system
External interface files : information held by other system that is used by
the system being analyzed

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 102
Unit III
 FPA

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 103
Unit III
 FPA

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.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 104
Unit III
 FPA

(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.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 105
Unit III
 Function Point

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 106

tware Engineering Unit III
 Counting Function Point

Dr. Amba Mishra ACSE0301 Software Engineering Unit III

19/05/2024 107
 UFP table

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 108

tware Engineering Unit III
 UFP

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 109

tware Engineering Unit III
 Function Point

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 110

tware Engineering Unit III
 Special Features of Function Point

• it is independent of the language(PL), tools, or methodologies

used for implementation, data base management systems,
processing hardware or any other data base technology.
• it can be estimated from requirement specification or design
specification, thus making it possible to estimate development
efforts in early phases of development.
• It is directly linked to the statement of requirements; any change
of requirements can easily be followed by a re-estimate.
• it is 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.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 111
Unit III
 Halestead’s Software Science (CO3)

• Introduced by Maurice Howard Halstead in 1977.

• Halstead’s “software science”, essentially counting operators and
operands
• Its goal was to identify measurable properties of software, and the
relations between them. This is similar to the identification of
measurable properties of matter (like the volume, mass, and
pressure of a gas) and the relationships between them.

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 112
Unit III
 Halestead’s Software Science

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 113

tware Engineering Unit III
 Example program

public static void sort(int x []) {

for (int i=0; i < x.length-1; i++) {
for (int j=i+1; j < x.length; j++)
{
if (x[i] > x[j]) { operator, 1 occurrence
int save=x[i];
x[i]=x[j]; x[j]=save
}
}
}
operator, 2 occurrences
}
Dr. Amba Mishra ACSE0301 Software Engineering
19/05/2024
Unit III
 Example program

operator # of occurrences
public 1
sort() 1
int 4
[] 7
{} 4
for {;;} 2
if () 1
= 5
< 2
… …
n1 = 17 N1 = 39

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III

 Example

Dr. Amba Mishra ACSE0301 Software Engineering Unit

19/05/2024 116
III
 Cyclomatic Complexity Measure (CO3)

• Control Flow Graph

– The control flow of a program can be analyzed using a graphical representation
known as control flow graph.
– The flow graph is a directed graph in which nodes are either entire statements
or fragments of a statement, and edges represents flow of control

Dr. Amba Mishra ACSE0301 Software Engineering

19/05/2024 117
Unit III
 Connected component

• Control flow graph with unique entry and exit nodes, all nodes reachable from
the entry, and exit reachable from all nodes then it has only one connected
component.
• imagine a main program M and two called subroutines A and B having
a control flow graph

19/05/2024 Dr. Amba Mishra ACSE0301 Sof 118

tware Engineering Unit III
 Faculty Video Links, Youtube & NPTEL Video Links and
Online Courses Details

• https://nptel.ac.in/courses/106/105/106105182/
• https://
www.youtube.com/watch?v=5q_KBeNlRFk&list=PLbRMhDVUMngf8oZ
R3DpKMvYhZKga90JVt&index=19
• https://
www.youtube.com/watch?v=FTyncRpLd5g&list=PLbRMhDVUMngf8oZR
3DpKMvYhZKga90JVt&index=20
• https://
www.youtube.com/watch?v=OFxBjpE8mT0&list=PLbRMhDVUMngf8oZ
R3DpKMvYhZKga90JVt&index=22

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 119
 Daily Quiz

1) Which one is not a size measure for software

(a) LOC (b) Function Count
(c) Cyclomatic Complexity (d) Halstead’s program length
2) The worst type of coupling is
(a) Content (b) Common (c) External (d) Data coupling
3) The most desirable form of cohesion is
(a) Logical cohesion (b) Procedural cohesion
(c) Functional cohesion (d) Temporal cohesion
4) Which one is not a strategy for design?
(a) Bottom up design (b) Top down design
(c) Embedded design (d) Hybrid design
5)The term module used during design phase refers to
(a) Function (b) Procedure (c) Sub program
(d) All of the above

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 120
 Daily Quiz

6) Fault is
(a) Defect in the program (b) Mistake in the program
(c) Error in the program (d) All of the above
7) The extent to which different modules are dependent upon each other is called
(a) Coupling (b) Cohesion (c) Modularity (d) Stability
8) A system that does not interact with external environment is called
(a) Closed system (b) Logical system
(c) Open system (d) Hierarchal system
9) The worst type of cohesion is
(a) Temporal cohesion (b) Coincidental cohesion
(c) Logical cohesion (d) Sequential cohesion
10) Which one is not a strategy for design?
(a) Bottom up design (b) Top down design
(c) Embedded design (d) Hybrid design

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 121
 Weekly Assignment

1. What is design? Describe the difference between conceptual design and

technical design.
2. Discuss the objectives of software design. How do we
transform an informal design to a detailed design?

3. Do we design software when we “write” a program?

What makes software design different from coding?

4. What is modularity? List the important properties of a modular system.

5. Define module coupling and explain different types of coupling.
6. Define module cohesion and explain different types of cohesion.
7. Discuss the objectives of modular software design. What are the effects of
module coupling and cohesion?
8. If a module has logical cohesion, what kind of coupling is this module
likely to have with others?
9. What problems are likely to arise if two modules have high coupling
19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 122
 MCQ

1. The most desirable form of coupling is

(a) Control Coupling (b) Data Coupling
(c) Common Coupling (d) Content Coupling
2. The worst type of coupling is
(a) Content coupling (b) Common coupling
(c) External coupling (d) Data coupling
3. The most desirable form of cohesion is
(a) Logical cohesion (b) Procedural cohesion
(c) Functional cohesion (d) Temporal cohesion
4. The worst type of cohesion is
(a) Temporal cohesion (b) Coincidental cohesion
(c) Logical cohesion (d) Sequential cohesion
5. Which one is not a strategy for
design? (b) Top down design
(a) Bottom up design (d) Hybrid design
(c) Embedded design
19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 123
 MCQ
6. Temporal cohesion means
(a) Cohesion between temporary variables
(b) Cohesion between local variable
(c) Cohesion with respect to time
(d) Coincidental cohesion
7. Functional cohesion means
(a) Operations are part of single functional task and are placed in same procedures
(b) Operations are part of single functional task and are placed in multiple
procedures
(c) Operations are part of multiple tasks
(d) None of the above
8. When two modules refer to the same global data area, they are related as
(a) External coupled (b) Data coupled
(c) Content coupled (d) Common coupled

9 The module in which instructions are related through flow of control is

(a) Temporal cohesion (b) Logical cohesion
(c) Procedural cohesion (d) Functional cohesion

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 124
 Old Question Papers

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 125
 Old Question Papers

19/05/2024 126
Dr. Amba Mishra ACSE0301 Software Engineering Unit III
 Old Question Papers

19/05/2024 127
Dr. Amba Mishra ACSE0301 Software Engineering Unit III
 Expected Questions for University Exam

1. Explain modularity? Explain Under modularity and over

modularity in a software should be avoided.
2. Describe data design at architectural level.
3. What are different techniques to estimate size of the program?
Which technique is better and why?
4. Discuss the main advantages of using an object-oriented approach
for software design.
5. Discuss the differences between object oriented and function
oriented design

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 128
 Summary

Software Design
• Basic Concept of Software Design
• Architectural Design Low Level Design: Modularization
• Design Structure Charts
• Pseudo Codes
• Flow Charts
• Coupling and Cohesion Measures
Design Strategies:
• Function Oriented Design
• Object Oriented Design
• Top-Down and Bottom-Up Design
• Software Measurement and Metrics
• Various Size Oriented Measures
• Halestead’s Software Science
• Function Point (FP) Based Measures
• Cyclomatic Complexity Measures, Control Flow Graphs

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 129
 References

1. R. S. Pressman, Software Engineering: A Practitioners Approach, McGraw Hill.

2. Rajib Mall, Fundamentals of Software Engineering, PHI Publication.
3. K. K. Aggarwal and Yogesh Singh, Software Engineering, New Age International
Publishers.
4. Pankaj Jalote, Software Engineering, Wiley
5. Deepak Jain,” Software Engineering: Principles and Practices”, Oxford University
Press.
6. Munesh C. Trivedi, Software Engineering, Khanna Publishing House
7. N.S. Gill, Software Engineering, Khanna Publishing House

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 130
 Recap of Unit

a.The cyclomatic complexity of each of the modules X and Y

shown below is 10. What is the cyclomatic complexity of the
sequential integration shown on the right hand side?

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 131
 Example

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 132
 Example

25. Consider a software project with the following information domain characteristic for calculation of function point metric.

Number of external inputs (I) = 30

Number of external output (O) = 60
Number of external inquiries (E) = 23
Number of files (F) = 08
Number of external interfaces (N) = 02
It is given that the complexity weighting factors for I, O, E, F and N are 4, 5, 4, 10 and 7,
respectively. It is also given that, out of fourteen value adjustment factors that influence the
development effort, four factors are not applicable, each of he other four factors have value 3, and
each of the remaining factors have value 4. The computed value of function point metric is

19/05/2024 Dr. Amba Mishra ACSE0301 Software Engineering Unit III 133