UNIT-3

SOFTWARE
DESIGN
 Software Design

More creative than analysis

Problem solving activity

The goal of the design process is to produce a model or representation

of a system, which can be used later to build that system.

‘HOW’

Software design document (SDD)

2
 Why design is important?

A good design is the key to successful product. Few desirable

characteristics that every good software design must possess are:

1. Correctness
2. Understandability
3. Efficiency
4. Maintainability

Without well-design system, we risk building an unstable system.

• One that will fail when small changes are made.
• One that will be difficult to maintain.
3
 Good design vs Bad Design

Characteristics Good design Bad design

Change Change in one part of One change
the system does not requires changes to
always require a many parts of the
change in another part system.
of the system.
Cost Small High
Nature Simple Complex
Extension System can be System cannot be
extended with changes extended easily.
in only one place
4
 Objectives of Design

It deals with transforming the customer requirements as

described in the SRS document into a form that is
implementable using a programming language. The design
needs to be :

▪ Correct and Complete

▪ Understandable

▪ At the right level

5
▪ Maintainable
Software Design

6
Design Framework

7
Software Design

8
 Software Design
Conceptual Design and Technical Design

9
 Software Design
Conceptual design answers :

▪ Where will the data come from?

▪ What will happen to the data in the system?

▪ How will the system look to users?

▪ What choices will be offered to users ?

▪ What is the timing of events?

1
0

▪ How will the reports and screens look like?

 Software Design

Technical design describes :-

▪ Hardware configuration
▪Software needs
▪Communication Interfaces
▪ I/O of the system
▪ SoftwareArchitecture
▪ NetworkArchitecture

Any other thing that translates the requirements into a solution to the customer’s
problem.
1
1
 HLD and LLD

High Level Design (Architectural) Low Level Design (Detailed)

Also known as macro level/ Also known as micro level/
system design detailed design
Overall architecture of the Detailed description of the each
application and every module
participants are design team, participants are only design team
review team and client
input criteria is Software input criteria is HLD, which are
Requirement Specification(SRS) reviewed and authorized
Output criteria is database design, Output criteria is Program
functional design and review specification and unit test plan
record
1
2
 LOW LEVEL DESIGN

MODULARIZATION

A system is considered modular, if it consists of discrete components so that

each component can be implemented separately and a change to one
component has minimal impact on other components.

1
3
 Advantages of Modular Systems
• Modular systems are easier to understand and explain because their parts are
functionally independent.

• Modular systems are easier to document because each part can be documented
as an independent unit.

• Programming individual modules is easier because the programmer can focus

on just one small, simple problem rather than a large complex problem.

• Testing and debugging individual modules is easier because they can be dealt
with in isolation from the rest of the program.

• Bugs are easier to isolate and understand and they can be fixed without fear
1
of introducing problems outside the module. 4
 DESIGN MODEL
After analyzing and specifying all the requirements, the process of software
design begins. Each of the elements of analysis model is used to create the
design model. The elements of design model are:-

1. Data Design (ER Diagram + Data Dictionary)

2. Architectural Design (DFD)

3. Interface Design (DFD + Control flow diagrams)

4. Component-level Design (Process + Control specification)

1
5
 SOFTWARE DESIGN
➢Software design is a creative process, just like designing anything else

➢To see a wrong design, we can check with the requirements in the
analysis model

➢To see a bad design, we need to assess the design model and analyze the
components, whether the performance can be improved by changing the
modules or the interfaces

➢In analyzing the software Design, many factors are used, out of which
two important factors are –
▪Coupling
▪Cohesion

16
 COUPLING
Coupling is the measure of “the degree of
interdependence between modules".

We aim to minimize coupling – to make modules as

independent as possible.

​Low coupling can be achieve by:

▪eliminating unnecessary relationships
▪reducing the number of necessary relationships
17
 COUPLING

Uncoupled modules have no interconnections at all,

they are completely independent.

(Uncoupled : no dependencies)
(a)
18
 Loosely coupled: Highly coupled:
some dependencies many dependencies
(B) (C)
Fig. : Module coupling

19
Consider the example of editing a student record in a
‘student information system’.

Edit student Edit student

record record
Student name,
Student Student Student
student ID,
record ID record
address,
course
Retrieve Retrieve
student record student record
Poor design: Tight Coupling Good design: Loose Coupling

Fig. : Example of coupling

20
 Data coupling Best (Most required)
Stamp coupling
Control coupling
External coupling
Common coupling
Content coupling Worst (Least required)

Fig : The types of module coupling

Given two procedures A & B, we can identify number of

ways in which they can be coupled.
21
Data coupling
The dependency between module A and B is said to be data
coupled if their dependency is based on the fact they
communicate by only passing of data. Other than
communicating through data, the two modules are
independent.
Stamp coupling
Stamp coupling occurs between module A and B when
complete data structure is passed from one module to another.

22
 Control coupling
Module A and B are said to be control coupled if they
communicate by passing of control information. This is usually
accomplished by means of flags that are set by one module and
reacted upon by the dependent module.

External coupling
A form of a coupling in which a module has a dependency to other
module, external to the software being developed or to a particular
type of hardware. This is basically related to the communication to
external tools and devices such as the operating system, shared
libraries or the hardware .
Common coupling
With common coupling, module A and module B have shared data.
Global data areas are commonly found in programming languages.
Making a change to the common data means tracing back to all the23

modules which access that data to evaluate the effect of changes.

Fig : Example of common coupling
24
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.

25
 Impact of Coupling on Design

A good design process should aim at reducing coupling.

Reduction of coupling -> reduction of dependence of one

module on another -> increase the independence of module ->
increase the ability to change or maintain the modules.

26
 COHESION
Cohesion measures how a single module is related to a particular
functionality in the system.
– only one module is involved
– ideally, a highly cohesive module should do only one task/
activity/function
– example:

• a sorting module that contains only one sorting function and this
function sorts integers only.
• a sorting module that contains several sorting functions that implement
various sorting techniques but all sort integers only.
• a sorting module that contains several sorting functions that implement
various sorting techniques but sort integers and floats.

27
 COHESION

Cohesion is a measure of the degree to which the

elements of a module are functionally related.

Module
strength

Fig : Cohesion=Strength of relations within modules

28
 Types of cohesion

➢ Functional cohesion
➢ Sequential cohesion

➢ Procedural cohesion
➢ Temporal cohesion
➢ Logical cohesion
➢ Coincident cohesion

29
Given a procedure that carries out operations A & B, we can
describe various forms of cohesion between A & B.
Functional Cohesion Best (high)

Sequential Cohesion

Communicational Cohesion

Procedural Cohesion

Temporal Cohesion

Logical Cohesion

Coincidental Cohesion Worst (low)

Fig : Types of module cohesion

30
 Functional Cohesion

➢ All elements contribute to the execution of one and only one

problem-related task

➢ Examples of functional cohesive modules:

• Compute cosine of angle
• Read transaction record
• Assign seat to airline passenger

➢A and B are part of a single functional task

31
 Sequential Cohesion

➢Module A outputs some data which forms the input to B. This

is the reason for them to be contained in the same procedure.
➢ Elements are involved in activities such that output data from one
activity becomes input data to the next
➢Usually has good coupling and is easily maintained

32
 Communicational Cohesion

➢ A and B both operate on the same input data or contribute

toward the same output data .
➢ Not flexible, for example, if we need to focus on some activities
and not the others

➢Example of Communicational Cohesion

- module determine customer details

use customer account no

find customer name
find customer loan balance
return customer name, loan balance

end module
33
 Procedural Cohesion

➢ Procedural cohesion occurs in modules whose instructions

accomplish different tasks yet have been combined
because there is a specific order in which the tasks are to be
completed.

➢ Example: an input function receiving a data, a function that

processes the data, and a function that outputs the result of that
computation, all placed in the same module

➢ Example: report module of an examination system includes

the following –
▪ calculate student GPA
▪ print student record
▪ calculate cumulative GPA
▪ print cumulative GPA
34
 Temporal Cohesion

➢ Module exhibits temporal cohesion when it contains tasks that

are related by the fact that all tasks must be executed in the
same time-span.

➢ functions that are related by time, all placed in the same

module

➢ example: the alarm system, automatic telephone dialing unit of a

security system both placed in the same module; these two must
be activated at the same time

➢ moderate level of cohesion

35
 Logical Cohesion

➢ Logical cohesion occurs in modules that contain

instructions that appear to be related because they fall into
the same category.
- module display record
if record-type is student then
display student record
else if record-type is staff then
display staff record
end module

➢ functions that are logically related to each other, all placed

in the same module
- example: a set of functions that output a given data in various
formats (bar chart, graph, pie-chart, …)
➢ moderate level of cohesion
36
 Coincidental Cohesion

➢Coincidental cohesion exists in modules that

contain instructions that have little or no relationship to one
another.
➢ functions that are not at all related to each other but are placed
in a single module (happen to be a coincidence)
- example: a function that performs sorting and a printer driver,
both in the same module
➢ functions that are somewhat related but do not have much in
common also fall in this category.
- example: a function that computes an average of a sequence
and a function that sorts a sequence, both being placed in the
same module
➢ low-level cohesion
37
 Examples of Cohesion

Function A Function A Time t0

Function Function
B C Function A’ Time t0 + X
logic
Function Function Time t0 + 2X
D E Function A’’

Coincidental Logical Temporal

Parts unrelated Similar functions Related by time

Function A

Function B

Function C

Procedural
Related by order of functions
 Examples of Cohesion
Function A Function A

Function B Function B

Function C Function C

Communicational Sequential
Access same data Output of one is input to another

Function A part 1

Function A part 2

Function A part 3

Functional
Sequential with complete, related functions
 Impact of Cohesion on Design

A good design process should try to maximize cohesion

of each module

maximizing cohesion -> maximizing the use of the module

towards particular functionality -> appropriate modularization of
the design

40
 Relationship between Cohesion & Coupling

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.

Fig : View of cohesion and coupling

41
 Evaluating Coupling and Cohesion

• Coupling can be evaluated using metrics tools.

- metrics will be discussed later.

• Cohesion is generally evaluated manually by experts /

software engineers.
– walk through the design documents and iterate the design
until cohesion is improved to a satisfactory level .

42
 HIGH LEVEL DESIGN
ARCHITECTURAL DESIGN

The HLD, also called architectural design.

Large systems are always decomposed into subsystems that provide some
related set of services. The initial design process of identifying these sub-
systems and establishing a framework for sub-system control and
communication is called architectural design.

Architectural design methods look into various alternate architectural style

of designing a system. These are:

• Data centric architecture

• Data flow architecture
• Object oriented architecture 4
3
• Layered architecture
 ARCHITECTURAL DESIGN
Data centric architecture approach involves the use of a central
database operations of inserting, updating it in the form of a table.

Data flow architecture is applied when input data takes the form of
output after passing through various phases of transformations.
These transformations can be through various computations done on
data.

In Object oriented architecture, the software design moves around

the classes and objects of the system. The class encapsulates the
data and methods.

Layered approach defines the number of layers and each layer

performs tasks. The outermost layer handles the functionality of user
4
interface and the innermost layer handles interaction with the 4

hardware.
 Objective of Architectural Design
• To develop a model of software architecture, this gives overall
organization of program module in the software product.

• To control relationship between modules. One module may

control another module or may be controlled by another
module.

• The organization of module can be represented through a

tree like structure.

•In addition, HLD possess some attributes such as height,

depth, width and module fan-in, fan-out.
4
5
 Attributes
▪The height or depth of the design hierarchy is the number of
modules along the longest path from the top-level module
down to the lowest module in the hierarchy.

▪The width of the design hierarchy is the largest number of

modules existing at a given level of the hierarchy.

▪The no. of components which controls a said component is

called fan-in i.e, the no of incoming edges to a component.

▪The no. of components that are controlled by a module is

called fan-out i.e, the no of outgoing edges.
4
6
 STRATEGY OF DESIGN

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.
47
 Bottom-Up Design

These modules are collected together in the form of a

“library”.

Fig : Bottom-up tree structure

48
 Top-Down Design
• A top down design approach starts by
identifying the major modules of the system,
decomposing them into their lower level
modules and iterating until the desired level of
detail is achieved. This is stepwise refinement;
starting from an abstract design, in each step
the design is refined to a more concrete level,
until we reach a level where no more
refinement is needed and the design can be
implemented directly. 49
 Hybrid Design

For top-down approach to be effective, some bottom-up approach

is essential for the following reasons:

➢ To permit common sub modules.

➢ Near the bottom of the hierarchy, where the intuition is simpler,
and the need for bottom-up testing is greater, because there are
more number of modules at low levels than high levels.
➢ In the use of pre-written library modules, in particular, reuse of
modules.

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

Fig : Hierarchical format of a structure chart 51

Fig. 17 : Structure chart notations

52
A structure chart for “update file” is given in fig.

Fig : Update file

53
A transaction centered structure describes a system that processes a
number of different types of transactions. It is illustrated in Fig.

Fig: Transaction-centered structure

54
In the above figure the MAIN module controls the system operation its
functions is to:

➢ invoke the INPUT module to read a transaction;

➢ determine the kind of transaction and select one of a number
of transaction modules to process that transaction, and
➢ output the results of the processing by calling OUTPUT
module.

55
 Pseudocode
• Pseudocode notation can be used in both the
preliminary and detailed design phases.
• Using pseudocode, the designer describes
system characteristics using short, concise,
English language phrases that are structured by
key words such as If-Then-Else, While-Do, and
End.

56
SOFTWARE
MEASUREMENT
AND METRICS
 Software Measurement

Measurement is the process by which numbers or symbols are

assigned to attributes of entities in the real world in such a way as to
describe them according to clearly defined unambiguous rules.

Metrics and measurements are necessary aspects of managing a

software development project . For effective monitoring, management
needs to get information about the project:

▪ how far it has progressed

▪ how much development has taken place
▪ how far behind schedule it is, and
▪ the quality of the development so far

Based on this information, decisions, can be made about the project.

 Types of Measurement

Measurement can be categorized in two ways :-

1. Direct Measures

2. Indirect Measures
 Software Metrics: What and Why ?

Software metric is defined as a quantitative measure of an

attribute a software system possesses with respect to Cost,
Quality, Size and Schedule.
Example-
Measure - No. of Errors
Metrics - No. of Errors found per person

These are numerical data related to software development.

Metrics strongly support software project management activities.
1. How to measure the size of a software?

2. How much will it cost to develop a software?

3. How many bugs can we expect?

4. When can we stop testing?

5. When can we release the software?

6. What is the complexity of a module?

7. What is the module strength and coupling?

8. What is the reliability at the time of release?

9. Which test technique is more effective?

10. Are we testing hard or are we testing smart?

11. Do we have a strong program or a week test suite?

❖ Pressman explained as “A measure provides a quantitative
indication of the extent, amount, dimension, capacity, or size
of some attribute of the product or process”.
❖ Measurement is the act of determine a measure
❖ The metric is a quantitative measure of the degree to which
a system, component, or process possesses a given
attribute.
❖ Fenton defined measurement as “ it is the process by which
numbers or symbols are assigned to attributes of entities in
the real world in such a way as to describe them according
to clearly defined rules”.
 Areas of Applications

The most established area of software metrics is cost and size

estimation techniques.

The prediction of quality levels for software, often in terms

of reliability, is another area where software metrics have an
important role to play.

The use of software metrics to provide quantitative checks

on software design is also a well established area.
 Categories of Metrics

i. Product metrics: describe the characteristics of the

product such as size, complexity, design features,
performance, efficiency, reliability, portability, etc.
ii. Process metrics: describe the effectiveness and
quality of the processes that produce the software
product. Examples are:
• effort required in the process
• time to produce the product
• effectiveness of defect removal during development
• number of defects found during testing
iii. Project metrics: describe the project characteristics
and execution. Examples are :

• number of software developers

• cost and schedule

• productivity
 Control flow graph

• A control flow graph (CFG) describes:

▪ the sequence in which different instructions

of a program get executed.
▪ the way control flows through the program.

– Control flow depicts a program as a graph

which consists of Nodes and Edges.
In the graph, Nodes represent processing tasks while
edges represent control flow between the nodes.
Flow graph notation for a program:
 How to draw Control flow graph?

▪ Number all the statements of a program.

▪ Numbered statements:
– - represent nodes of the control flow graph.
▪ An edge from one node to another node exists:
– - if execution of the statement representing
the first node can result in transfer of
control to the other node.
 Example

• int f1(int x,int y){

1. while (x != y){
2. if (x>y) then
3. x=x-y;
4. else y=y-x;
5. }
6. return x; }
 Example Control Flow Graph

1
2
3 4
5
6

Cyclomatic complexity = 7 – 6 + 2 = 3.
 CYCLOMATIC COMPLEXITY
This metric was developed by Thomas J. McCabe in 1976 and it is based
on a control flow representation of the program.

McCabe's cyclomatic complexity is a software quality metric that

quantifies the complexity of a software program. Complexity is inferred
by measuring the number of linearly independent paths through the
program. The higher the number the more complex the code.

Independent path is defined as a path that has atleast one edge which
has not been traversed before in any other paths.

Cyclomatic complexity can be calculated with respect to functions,

modules, methods or classes within a program.
 Different ways to compute CC
There are three methods:-

Method1: Cyclomatic complexity is derived from the

control flow graph of a program as follows:
Cyclomatic complexity(CC), V(G) = E - N + 2P
Where:

E = number of edges (transfers of control)

N = number of nodes (sequential group of statements
containing only one transfer of control)
P = number of disconnected parts of the flow graph (e.g. a
calling program and a subroutine) or number of strongly
connected components
 Different ways to compute CC
Method 2: An alternative way of computing the
Cyclomatic complexity of a program from an inspection of
its control flow graph is as follows:-

V(G) = Total number of bounded areas + 1

•Any region enclosed by nodes and edges can be called as
a bounded area.

Method 3: Cyclomatic complexity can also be computed

by computing the number of decision statements.

V (G) = Π + 1
Where Π = number of decision statement of a program.
Flow graph for program will be
Flow graph notation

Computing mathematically,
V(G) = 9 - 7 + 2 = 4
V(G) = 3 + 1 = 4 (Condition nodes are 1,2 and 3 nodes)

Basis Set - A set of possible execution path of a program

or
There will be four independent paths for the flow graph.
Path1: 1, 7
Path2: 1, 2, 6, 1, 7
Path3: 1, 2, 3, 4, 5, 2, 6, 1, 7
Path4: 1, 2, 3, 5, 2, 6, 1, 7
Properties of Cyclomatic complexity:

Following are the properties of Cyclomatic complexity:

1. V (G) >=1
2. V (G) is the maximum number of independent paths in the
graph
3. Inserting and deleting functional statements to G does not
affect V(G)
4. G will have only one path if and only if V (G) = 1
5. Inserting a new row in G increases V(G) by unity.
Example
 SOLUTION

It can be calculated by any of the three methods

1. V(G) = E – N + 2P
= 13 – 10 + 2
=5

2. V(G) = Π + 1
=4+1=5

3. V(G) = no. of regions + 1;

=4+1=5
 HALSTEAD’s SOFTWARE
SCIENCE METRICS

It is an analytical technique to measure size, development effort

and development cost of software products.

Halstead used a few primitive program parameters to develop the

expressions for overall program length, potential minimum value,
actual volume, effort and development time.
 Token Count

The size of the vocabulary of a program, which consists of the

number of unique tokens used to build a program is defined as:

 =  1+  2
 : vocabulary of a program
where
 1 : number of unique operators
 2 : number of unique operands
The length of the program in the terms of the total number of
tokens used is

N = N1+N2
N : program length
where
N1 : total occurrences of operators
N2 : total occurrences of operands
Program Volume

V = N * log2
The unit of measurement of volume is the common unit for
size “bits”. It is the actual size of a program if a uniform
binary encoding for the vocabulary is used.

Program Length Equation

N` =  1 log2 1 +  2 log2 2
` on N means it is calculated rather than counted
Potential Volume

V* = ( 1* +  2*) log2 ( 1* +  2*) where  1* = 2

 2* represents the no. of conceptually unique input and

output parameters.

Program Level
L = V* / V
The value of L ranges between zero and one, with L=1
representing a program written at the highest possible level
(i.e., with minimum size).
Program Difficulty
D=1/L
As the volume of an implementation of a program increases,
the program level decreases and the difficulty increases.
Thus, programming practices such as redundant usage of
operands, or the failure to use higher-level control constructs
will tend to increase the volume as well as the difficulty.

Effort Equation

E=V/L=D*V
The unit of measurement of E is elementary mental
discriminations.
Time equation
T’ = E/S

John Stroud defined a moment as the time required by

the human brain to perform the most elementary
discrimination. The Stroud number S is 18.

.
 Advantages of Halstead Metrics
➢ Simple to calculate

➢ Do not require in-depth analysis of programming structure.

➢ Measure overall quality of programs.

➢ Predicts maintenance efforts.

➢ Useful in scheduling the projects.

 Function Point
• The function point is a "unit of
measurement" to express the amount of
business functionality an information
system (as a product) provides to a user.
Function points are used to compute a
functional size measurement (FSM) of
software.
 Function Point Analysis
• FPA provides a standardized method to
functionally size the software work product.
This work product is the output of software
new development and improvement projects
for subsequent releases. It is the software that
is relocated to the production application at
project implementation. It measures
functionality from the user’s point of view i.e.
on the basis of what the user requests and
receives in return.
 Function Point Analysis
• Function Point Analysis (FPA) is a method or
set of rules of Functional Size Measurement. It
assesses the functionality delivered to its
users, based on the user’s external view of the
functional requirements. It measures the
logical view of an application, not the
physically implemented view or the internal
technical view.
 Objectives of FPA
• The objective of FPA is to measure the
functionality that the user requests and receives.
• The objective of FPA is to measure software
development and maintenance independently of
the technology used for implementation.
• It should be simple enough to minimize the
overhead of the measurement process.
• It should be a consistent measure among various
projects and organizations.
 Types of FPA
Transactional Functional Type –
• External Input (EI): EI processes data or control
information that comes from outside the application’s
boundary. The EI is an elementary process.

• External Output (EO): EO is an elementary process that

generates data or control information sent outside the
application’s boundary.

• External Inquiries (EQ): EQ is an elementary process

made up of an input-output combination that results in
data retrieval.
 Types of FPA
Data Functional Type –
• Internal Logical File (ILF): A user identifiable
group of logically related data or control
information maintained within the boundary of
the application.

• External Interface File (EIF): A group of users

recognizable logically related data allusion to the
software but maintained within the boundary of
another software.
Function Point
 Function Point
Measurement Weighing Factors
parameter
Count Simple Average Complex Total
Number of external - * 3 4 6 =
inputs (EI)
Number of external - * 4 5 7 =
outputs (EO)
Number of external - * 3 4 6 =
inquiries (EQ)
Number of internal - * 7 10 15 =
files (ILF)
Number of external - * 5 7 10 =
interfaces (EIF)

Count Total ………

 Function Point
• The Function Point (FP) is calculated with the
following formula
FP = Count-total * [0.65 + 0.01 * S(Fi ) ]
= Count-total * CAF
CAF = [0.65 + 0.01 * S(Fi )] and S(Fi ) is the sum
of all 14 questionnaires and show the
complexity adjustment value/ factor-CAF (where
i ranges from 1 to 14).
 Function Point
• Problem1: Compute the function point value for a
project with the following information domain
characteristics:
(1) No. of user inputs = 32
(2) No. of user outputs = 60
(3) No. of user inquiries = 24
(4) No. of files = 8
(5) No. of external interfaces = 2
Assume all complexity adjustment values are average.
Assume that 14 algorithms have been counted as
average.
 Function Point
Measurement Weighing Factors
parameter
Count Simple Average Complex Total
Number of external 32 * 3 4 6 =128
inputs (EI)
Number of external 60 * 4 5 7 =300
outputs (EO)
Number of external 24 * 3 4 6 =96
inquiries (EQ)
Number of internal 4 * 7 10 15 =40
files (ILF)
Number of external 2 * 5 7 10 =14
interfaces (EIF)

Count Total
Now Fi for average case = 3.
So sum of all Fi (i = 1 to 14) = 14 * 3 = 42
FP = Count-total * [0.65 + 0.01 * S (Fi ) ]
= 578 * [0.65 + 0.01 * 42]
= 578 * [0.65 + 0.42] = 578 * 1.07
= 618.46
 Function Point
• Problem2: Compute the function point value for a
project with the following information domain
characteristics:
(1) No. of user inputs = 30
(2) No. of user outputs = 20
(3) No. of user inquiries = 8
(4) No. of files = 7
(5) No. of external interfaces = 6
Assume all complexity adjustment values are average.
Assume that 14 algorithms have been counted as
average.