Software Design

Software design is a mechanism to transform user requirements into some suitable

form, which helps the programmer in software coding and implementation. It deals with
representing the client's requirement, as described in SRS (Software Requirement
Specification) document, into a form, i.e., easily implementable using programming
language.

The software design phase is the first step in SDLC (Software Design Life Cycle), which
moves the concentration from the problem domain to the solution domain. In software
design, we consider the system to be a set of components or modules with clearly
defined behaviors & boundaries.

Objectives of Software Design

Following are the purposes of Software design:

1. Correctness: Software design should be correct as per requirement.

2. Completeness: The design should have all components like data structures, modules,
and external interfaces, etc.
3. Efficiency: Resources should be used efficiently by the program.
4. Flexibility: Able to modify on changing needs.
5. Consistency: There should not be any inconsistency in the design.
 6. Maintainability: The design should be so simple so that it can be easily maintainable by
other designers.

Architectural Design – Software Engineering

The software needs an architectural design to represent the design of the software.
IEEE defines architectural design as “the process of defining a collection of hardware
and software components and their interfaces to establish the framework for the
development of a computer system.” The software that is built for computer-based
systems can exhibit one of these many architectural styles.

Types of Architecture
There are four types of architecture from the viewpoint of an enterprise and collectively, these
architectures are referred to as enterprise architecture.
 Business architecture − Defines the strategy of business, governance, organization, and
key business processes within an enterprise and focuses on the analysis and design of
business processes.
 Application (software) architecture − Serves as the blueprint for individual application
systems, their interactions, and their relationships to the business processes of the
organization.
 Information architecture − Defines the logical and physical data assets and data
management resources.
 Information technology (IT) architecture − Defines the hardware and software
building blocks that make up the overall information system of the organization.

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 or phases of design:
1. Interface Design
2. Architectural Design
3. Detailed Design

Elements of a System

1. Architecture: This is the conceptual model that defines the structure,

behavior, and views of a system. We can use flowcharts to represent and
illustrate the architecture.
2. Modules: These are components that handle one specific task in a system. A
combination of the modules makes up the system.
3. Components: This provides a particular function or group of related
functions. They are made up of modules.
4. Interfaces: This is the shared boundary across which the components of a
system exchange information and relate.
5. Data: This is the management of the information and data flow.

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:
1. Precise description of events in the environment, or messages from agents to which the
system must respond.
2. Precise description of the events or messages that the system must produce.
3. Specification of the data, and the formats of the data coming into and going out of the
system.
4. 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 include:
1. Gross decomposition of the systems into major components.
2. Allocation of functional responsibilities to components.
3. Component Interfaces.
4. Component scaling and performance properties, resource consumption
properties, reliability properties, and so forth.
5. 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
Detailed 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:
1. Decomposition of major system components into program units.
2. Allocation of functional responsibilities to units.
3. User interfaces.
4. Unit states and state changes.
5. Data and control interaction between units.
6. Data packaging and implementation, including issues of scope and visibility of
program elements.
7. Algorithms and data structures .

What is modularization?
Modularization is a technique to divide a software system into multiple discrete
and independent modules, which are expected to be capable of carrying out task(s)
independently. These modules may work as basic constructs for the entire
software. Designers tend to design modules such that they can be executed and/or
compiled separately and independently.

Modular design unintentionally follows the rules of ‘divide and conquer’ problem-
solving strategy this is because there are many other benefits attached with the
modular design of a software.

Advantage of modularization:

 Smaller components are easier to maintain

 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Cosmponents with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired from security aspect
Structure Charts – Software Engineering



Structure Chart represents the hierarchical structure of modules. It breaks down the
entire system into the lowest functional modules and describes the functions and sub-
functions of each module of a system in greater detail. This article focuses on
discussing Structure Charts in detail.
What is a Structure Chart?
Structure Chart partitions the system into black boxes (functionality of the system is
known to the users, but inner details are unknown).
1. Inputs are given to the black boxes and appropriate outputs are generated.
2. Modules at the top level are called modules at low level.
3. Components are read from top to bottom and left to right.
4. When a module calls another, it views the called module as a black box, passing
the required parameters and receiving results.
Symbols in Structured Chart
1. Module
It represents the process or task of the system. It is of three types:
 Control Module: A control module branches to more than one submodule.
 Sub Module: Sub Module is a module which is the part (Child) of another
module.
 Library Module: Library Module are reusable and invokable from any module.

2. Conditional Call
It represents that control module can select any of the sub module on the basis of
some condition.
3. Loop (Repetitive call of module)
It represents the repetitive execution of module by the sub module. A curved arrow
represents a loop in the module. All the sub modules cover by the loop repeat
execution of module.

4. Data Flow
It represents the flow of data between the modules. It is represented by a directed
arrow with an empty circle at the end.
5. Control Flow
It represents the flow of control between the modules. It is represented by a directed
arrow with a filled circle at the end.

5. Physical Storage

It is that where all the information are to be stored.

Example
Structure chart for an Email server
What is pseudocode?
Pseudocode is a detailed yet readable description of what a computer
program or algorithm should do. It is written in a formal yet readable style that
uses a natural syntax and formatting so it can be easily understood by programmers
and others involved in the development process. Pseudocode is not a programming
language and cannot be compiled into an executable program. Instead, it serves as
a blueprint for translating the code's logic into an actual programming language.

Advantages of Pseudocode
 Improves the readability of any approach. It’s one of the best approaches to
start implementation of an algorithm.
 Acts as a bridge between the program and the algorithm or flowchart. Also
works as a rough documentation, so the program of one developer can be
understood easily when a pseudo code is written out. In industries, the
approach of documentation is essential. And that’s where a pseudo-code
proves vital.
 The main goal of a pseudo code is to explain what exactly each line of a
program should do, hence making the code construction phase easier for the
programmer.

How to write a Pseudo-code?

1. Arrange the sequence of tasks and write the pseudocode accordingly.

2. Start with the statement of a pseudo code which establishes the main goal or
the aim. Example:
This program will allow the user to check
the number whether it's even or odd.

The way the if-else, for, while loops are indented in a program, indent the
statements likewise, as it helps to comprehend the decision control and
execution mechanism. They also improve the readability to a great extent.
Example:
if "1"
print response
"I am case 1"
if "2"
print response
"I am case 2"

1. Use appropriate naming conventions. The human tendency follows the

approach to follow what we see. If a programmer goes through a pseudo code,
his approach will be the same as per it, so the naming must be simple and
distinct.
2. Use appropriate sentence casings, such as CamelCase for methods, upper case
for constants and lower case for variables.
3. Elaborate everything which is going to happen in the actual code. Don’t make
the pseudo code abstract.
4. Use standard programming structures such as ‘if-then’, ‘for’, ‘while’, ‘cases’
the way we use it in programming.
5. Check whether all the sections of a pseudo code is complete, finite and clear to
understand and comprehend.
6. Don’t write the pseudo code in a complete programmatic manner. It is
necessary to be simple to understand even for a layman or client, hence don’t
incorporate too many technical terms.
What is FlowChart?
A flowchart is a type of diagram that represents a workflow or process. A
flowchart can also be defined as a diagrammatic representation of an algorithm, a
step-by-step approach to solving a task.
Flowchart symbols
Different types of boxes are used to make flowcharts flowchart Symbols. All the
different kinds of boxes are connected by arrow lines. Arrow lines are used to
display the flow of control. Let’s learn about each box in detail.

Symbol Representation
Symbol Name

Terminal/Terminator

Process
 Symbol Representation
Symbol Name

Decision

Document
 Symbol Representation
Symbol Name

Data or Input/Output

Stored Data

Flow Arrow
 Symbol Representation
Symbol Name

Comment or Annotation

Predefined process
 Symbol Representation
Symbol Name

On-page connector/reference

Off-page connector/reference

Uses of Flowcharts in Computer Programming/Algorithms

The following are the uses of a flowchart:
 It is a pictorial representation of an algorithm that increases the readability
of the program.
 Complex programs can be drawn in a simple way using a flowchart.
 It helps team members get an insight into the process and use this
knowledge to collect data, detect problems, develop software, etc.
 A flowchart is a basic step for designing a new process or adding extra
features.
 Communication with other people becomes easy by drawing flowcharts
and sharing them.

When to Use Flowchart?

Flowcharts are mainly used in the below scenarios:

 It is most importantly used when programmers make projects. As a
flowchart is a basic step to make the design of projects pictorially, it is
preferred by many.
 When the flowcharts of a process are drawn, the programmer
understands the non-useful parts of the process. So flowcharts are used
to separate sound logic from the unwanted parts.
 Since the rules and procedures of drawing a flowchart are universal, a
flowchart serves as a communication channel to the people who are
working on the same project for better understanding.
 Optimizing a process becomes easier with flowcharts. The efficiency of
the code is improved with the flowchart drawing.
Types of Flowcharts
Three types of flowcharts are listed below:
1. Process flowchart: This type of flowchart shows all the activities that are
involved in making a product. It provides a pathway to analyze the
product to be built. A process flowchart is most commonly used in process
engineering to illustrate the relation between the major as well as minor
components present in the product. It is used in business product
modeling to help understand employees about the project requirements
and gain some insight into the project.
2. Data flowchart: As the name suggests, the data flowchart is used to
analyze the data, specifically it helps in analyzing the structural details
related to the project. Using this flowchart, one can easily understand the
data inflow and outflow from the system. It is most commonly used to
manage data or to analyze information to and fro from the system.
3. Business Process Modeling Diagram: Using this flowchart or diagram,
one can analytically represent the business process and help simplify the
concepts needed to understand business activities and the flow of
information. This flowchart illustrates the business process and models
graphically which paves the way for process improvement.
What is Coupling and Cohesion?
Coupling refers to the degree of interdependence between software
modules. High coupling means that modules are closely connected and
changes in one module may affect other modules. Low coupling means that
modules are independent, and changes in one module have little impact on
other modules.

Cohesion refers to the degree to which elements within a module work

together to fulfill a single, well-defined purpose. High cohesion means that
elements are closely related and focused on a single purpose, while low
cohesion means that elements are loosely related and serve multiple
purposes.
Coupling and Cohesion
Module Coupling
In software engineering, the coupling is the degree of interdependence between
software modules. Two modules that are tightly coupled are strongly dependent on
each other. However, two modules that are loosely coupled are not dependent on each
other. Uncoupled modules have no interdependence at all within them.

The various types of coupling techniques are shown in fig:

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

1. No Direct Coupling: There is no direct coupling between M1 and M2.

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

coupling.

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

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

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

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

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

7. Content Coupling: Content Coupling exists among two modules if they share code,
e.g., a branch from one module into another module.
Module Cohesion
In computer programming, cohesion defines to the degree to which the elements of a
module belong together. Thus, cohesion measures the strength of relationships
between pieces of functionality within a given module. For example, in highly cohesive
systems, functionality is strongly related.

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

cohesion" or "low cohesion."

Types of Modules Cohesion

1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of a

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

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

Coupling shows the relationships between Cohesion shows the relationship within the module.
modules.

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

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

In coupling, modules are linked to the other In cohesion, the module focuses on a single thing.
modules.

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

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

Top-Down Design Model:

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. For example: Writing a University system program, writing a
word processor. Complicated issues may be resolved victimization high down
style, conjointly referred to as Stepwise refinement where,
1. We break the problem into parts,
2. 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. Object-oriented language such as C++ or java uses a bottom-up
approach where each object is identified first.

Advantage:
 Make decisions about reusable low-level utilities then decide how there will be
put together to create high-level construct. ,

Difference between Top-Down Approach and Bottom-Up Approach

The following table highlights all the major differences between top-down
approach and bottom-up approach −
S.No Top-Down Approach Bottom-Up Approach
.

In this approach, the problem In this approach, the smaller

1. is broken down into smaller problems are solved.
parts.

It is generally used by It is generally used with object

structured programming oriented programming paradigm
2.
languages such as C, such as C++, Java, Python, etc.
COBOL, FORTRAN, etc.

It is generally used with It is generally used in testing

3. documentation of module and modules.
debugging code.

It does not require It requires relatively more

4. communication between communication between modules.
modules.

It contains redundant It does not contain redundant

5.
information. information.

Decomposition approach is Composition approach is used

6.
used here. here.

The implementation depends Data encapsulation and data hiding

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

Cons-
 There is no representation of
Cons-
the working model once several
 Difficulty in observing the
modules have been
output of test case.
constructed.
 Stub writing is quite crucial
 There is no existence of the
as it leads to setting of
program as an entity without
9 output parameters.
the addition of the last module.
Software Metrics
A software metric is a measure of software characteristics which are measurable or
countable. Software metrics are valuable for many reasons, including measuring
software performance, planning work items, measuring productivity, and many
other uses.

Within the software development process, many metrics are that are all connected.
Software metrics are similar to the four functions of management: Planning,
Organization, Control, or Improvement.

Types of Software Metrics

Types of Software Metrics

1. 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,
cyclomatic complexity, code coverage, defect density, and code
maintainability index.
2. 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.
3. 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
1. It is expensive and difficult to implement the metrics in some cases.
2. Performance of the entire team or an individual from the team can’t be
determined. Only the performance of the product is determined.
3. Sometimes the quality of the product is not met with the expectation.
4. It leads to measure the unwanted data which is wastage of time.
5. Measuring the incorrect data leads to make wrong decision making.

What is Size Oriented Metrics?

Size Oriented Metrics are used for measuring and comparing the
productivity of programmers. It is a direct measure of a Software. The
size measurement is based on lines of code computation. The lines of
code are defined as one line of text in a source file. While counting
lines of code, the simplest standard is:
 Don’t count blank lines
 Don’t count comments
 Count everything else
 The size-oriented measure is not a universally accepted method.

A simple set of size measures that can be developed is given below:

Size = Kilo Lines of Code (KLOC)
Effort = Person / month
Productivity = KLOC / person-month
Quality = Number of faults / KLOC
Cost = $ / KLOC
Documentation = Pages of documentation / KLOC

Advantages of Size-Oriented Metrics

 This measure is dependent upon programming language.
 This method is well designed upon programming language.
 It does not accommodate non-procedural languages .
 Sometimes, it is very difficult to estimate LOC in early stage of
development.
 Though it is simple to measure but it is very hard to understand it for
users.
 It cannot measure size of specification as it is defined on code.

Function Point Analysis:

FPA is used to make estimate of the software project, including its

testing in terms of functionality or function size of the software product.
However, functional point analysis may be used for the test estimation
of the product. The functional size of the product is measured in terms of
the function point, which is a standard of measurement to measure the
software application.

Objectives of FPA
The basic and primary purpose of the functional point analysis is to measure and
provide the software application functional size to the client, customer, and the
stakeholder on their request. Further, it is used to measure the software project
development along with its maintenance, consistently throughout the project
irrespective of the tools and the technologies.

Following are the points regarding FPs

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

Types of FP Attributes

Measurements Parameters Examples

1.Number of External Inputs(EI) Input screen and tables

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

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

4. Number of internal files (ILF) Databases and directories

5. Number of external interfaces (EIF) Shared databases and shared routines.

All these parameters are then individually assessed for complexity.

The FPA functional units are shown in Fig:

2. FP characterizes the complexity of the software system and hence can be used to
depict the project time and the manpower requirement.
3. The effort required to develop the project depends on what the software does.

4. FP is programming language independent.

. FP method is used for data processing systems, business systems like information
systems.

6. The five parameters mentioned above are also known as information domain
characteristics.

7. All the parameters mentioned above are assigned some weights that have been
experimentally determined and are shown in Table

Weights of 5-FP Attributes

Measurement Parameter Low Average High

1. Number of external inputs (EI) 7 10 15

2. Number of external outputs (EO) 5 7 10

3. Number of external inquiries (EQ) 3 4 6

4. Number of internal files (ILF) 4 5 7

5. Number of external interfaces (EIF) 3 4 6

The functional complexities are multiplied with the corresponding weights against each
function, and the values are added up to determine the UFP (Unadjusted Function Point)
of the subsystem.
Here that weighing factor will be simple, average, or complex for a measurement
parameter type.

The Function Point (FP) is thus calculated with the following formula.

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

= Count-total * CAF

where Count-total is obtained from the above Table.

CAF = [0.65 + 0.01 *∑(fi)]

and ∑(fi) is the sum of all 14 questionnaires and show the complexity adjustment value/
factor-CAF (where i ranges from 1 to 14). Usually, a student is provided with the value of
∑(fi)

Also note that ∑(fi) ranges from 0 to 70, i.e.,

0 <= ∑(fi) <=70

and CAF ranges from 0.65 to 1.35 because

a. When ∑(fi) = 0 then CAF = 0.65

 b. When ∑(fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35

Based on the FP measure of software many other metrics can be computed:

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

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

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

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

a. Degree of Influence (DI) for each of these 14 GSCs is assessed on a scale of 0 to 5.

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

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

a. When TDI = 0, VAF = 0.65

b. When TDI = 70, VAF = 1.35
c. VAF is then multiplied with the UFP to get the final FP count: FP = VAF * UFP
Example: Compute the function point, productivity, documentation, cost per function for the
following data:

1. Number of user inputs = 24

2. Number of user outputs = 46
3. Number of inquiries = 8
4. Number of files = 4
5. Number of external interfaces = 2
6. Effort = 36.9 p-m
7. Technical documents = 265 pages
8. User documents = 122 pages
9. Cost = $7744/ month

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

Solution:

Measurement Parameter Count Weighing factor

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

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

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

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

5. Number of external interfaces (EIF) Count-total → 2 * 5 = 1

378

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

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

= 378 * [0.65 + 0.01 * 43]
= 378 * [0.65 + 0.43]
= 378 * 1.08 = 408
Total pages of documentation = technical document + user document
= 265 + 122 = 387pages
Documentation = Pages of documentation/FP
= 387/408 = 0.94

Differentiate between FP and LOC

FP LOC

1. FP is specification based. 1. LOC is an analogy based.

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

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

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