SOFTWARE DESIGN

INTRODUCTION

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. In
order to be easily implementable in a conventional programming language, the following item
must be designed during the design phase:

 Different modules required to implement the design solution.

 Control relationship among the identified modules.
 Interferes among different modules
 Algorithms required to implement the individual modules.

Thus the goal of design phase is to take the SRS document of the input and to produce the above
mentioned items at the completion stage of the design phase.

Software Design Defination:

 Software design is the process of investing and selecting programs that meet the objective
for a software system.
 Software design is the process of envisioning and defining software solutions to one or
more sets of problems. One of the main components of software design is
software requirements analysis (SRA). SRA is a part of the software
development process that lists specifications used in software engineering.

Software Design Models:

Software designs and problems are often complex and many aspects of software system must be
modeled.

Software design models may be divided into 2 classes:

 Static Model
A static model describes the static structure of the system being modeled, which is considered
less likely to change than the functions of the system. In particular, a static model defines the
classes in the system, the attributes of the classes, the relationships between classes, and the
operations of each class.
 Dynamic Model
Dynamic Modeling is used to represent the behavior of the static constituents of a software , here
static constituents includes, classes , objects, their relationships and interfaces Dynamic
Modeling also used to represents the interaction, workflow, and different states of the static
constituents in a software.
Software Design Process
The design phase of software development deals with transforming the customer
requirements as described in the SRS documents into a form implementable using a
programming language.
The software design process can be divided into the following three levels of phases of
design:
1. Interface Design
2. Architectural Design
3. Detailed Design

InterfaceDesign:
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 focussed 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:

 Precise description of events in the environment, or messages from agents to which the
system must respond.
 Precise description of the events or messages that the system must produce.
 Specification on the data, and the formats of the data coming into and going out of the
system.
 Specification of the ordering and timing relationships between incoming events or
messages, and outgoing events or outputs.

Architectural Design:
Architectural design is the specification of the major components of a system, their
responsibilities, properties, interfaces, and the relationships and interactions between them. In
architectural design, the overall structure of the system is chosen, but the internal details of major
components are ignored.

Issues in architectural design includes:

 Gross decomposition of the systems into major components.
 Allocation of functional responsibilities to components.
 Component Interfaces
 Component scaling and performance properties, resource consumption properties,
reliability properties, and so forth.
 Communication and interaction between components.

The architectural design adds important details ignored during the interface design. Design of the
internals of the major components is ignored until the last phase of the design.

Detailed Design:
Design is the specification of the internal elements of all major system components, their
properties, relationships, processing, and often their algorithms and the data structures.
The detailed design may include:
 Decomposition of major system components into program units.
 Allocation of functional responsibilities to units.
 User interfaces
 Unit states and state changes
 Data and control interaction between units
 Data packaging and implementation, including issues of scope and visibility of program
elements
 Algorithms and data structures

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.

Structure Charts

Structure chart is a chart derived from Data Flow Diagram. It represents the system in more
detail than DFD. It breaks down the entire system into lowest functional modules, describes
functions and sub-functions of each module of the system to a greater detail than DFD.
Structure chart represents hierarchical structure of modules. At each layer a specific task is
performed.
Here are the symbols used in construction of structure charts -

 Module - It represents process or subroutine or task. A control module branches to more

than one sub-module. Library Modules are re-usable and invokable from any

module.
 Condition - It is represented by small diamond at the base of module. It depicts that
control module can select any of sub-routine based on some

condition.
 Jump - An arrow is shown pointing inside the module to depict that the control will jump
in the middle of the sub-module.

 Loop - A curved arrow represents loop in the module. All sub-modules covered by loop

repeat execution of module.

 Data flow - A directed arrow with empty circle at the end represents data

flow.
  Control flow - A directed arrow with filled circle at the end represents control

flow.

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
 Components with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired from security aspect

Modularity

Modularity specifies to the division of software into separate modules which are differently
named and addressed and are integrated later on in to obtain the completely functional software.
It is the only property that allows a program to be intellectually manageable. Single large
programs are difficult to understand and read due to a large number of reference variables,
control paths, global variables, etc.

The desirable properties of a modular system are:

 Each module is a well-defined system that can be used with other applications.
 Each module has single specified objectives.
 Modules can be separately compiled and saved in the library.
  Modules should be easier to use than to build.
 Modules are simpler from outside than inside.

Advantages and Disadvantages of Modularity

Advantages of Modularity

There are several advantages of Modularity

 It allows large programs to be written by several or different people

 It encourages the creation of commonly used routines to be placed in the library and used by
other programs.
 It simplifies the overlay procedure of loading a large program into main storage.
 It provides more checkpoints to measure progress.
 It provides a framework for complete testing, more accessible to test
 It produced the well designed and more readable program.

Disadvantages of Modularity

There are several disadvantages of Modularity

 Execution time maybe, but not certainly, longer

 Storage size perhaps, but is not certainly, increased
 Compilation and loading time may be longer
 Inter-module communication problems may be increased
 More linkage required, run-time may be longer, more source lines must be written, and more
documentation has to be done

Modular Design

Modular design reduces the design complexity and results in easier and faster implementation by
allowing parallel development of various parts of a system. We discuss a different section of
modular design in detail in this section:

1. Functional Independence: Functional independence is achieved by developing functions that

perform only one kind of task and do not excessively interact with other modules. Independence
is important because it makes implementation more accessible and faster. The independent
modules are easier to maintain, test, and reduce error propagation and can be reused in other
programs as well. Thus, functional independence is a good design feature which ensures
software quality.

It is measured using two criteria:

o Cohesion: It measures the relative function strength of a module.

o Coupling: It measures the relative interdependence among modules.
 2. Information hiding: The fundamental of Information hiding suggests that modules can be
characterized by the design decisions that protect from the others, i.e., In other words, modules
should be specified that data include within a module is inaccessible to other modules that do not
need for such information.

The use of information hiding as design criteria for modular system provides the most significant
benefits when modifications are required during testing's and later during software maintenance.
This is because as most data and procedures are hidden from other parts of the software,
inadvertent errors introduced during modifications are less likely to propagate to different
locations within the software.

Strategy of Design

A good system design strategy is to organize the program modules in such a method that are easy
to develop and latter too, change. Structured design methods help developers to deal with the
size and complexity of programs. Analysts generate instructions for the developers about how
code should be composed and how pieces of code should fit together to form a program.

To design a system, there are two possible approaches:

1. Top-down Approach
2. Bottom-up Approach

1. Top-down Approach: This approach starts with the identification of the main components
and then decomposing them into their more detailed sub-components.
We know that a system is composed of more than one sub-systems and it contains a number of
components. Further, these sub-systems and components may have their on set of sub-system
and components and creates hierarchical structure in the system.
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.
 2. Bottom-up Approach: A bottom-up approach begins with the lower details and moves
towards up the hierarchy, as shown in fig. This approach is suitable in case of an existing
system.

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. With each higher level, the amount of abstraction is increased.
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.

Both, top-down and bottom-up approaches are not practical individually. Instead, a good
combination of both is used.

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.

Flowchart
Flowchart is a graphical representation of an algorithm. Programmers often use it as a program-planning
tool to solve a problem. It makes use of symbols which are connected among them to indicate the flow of
information and processing. The process of drawing a flowchart for an algorithm is known as
“flowcharting”.

Basic Symbols used in Flowchart Designs

1. Terminal: The oval symbol indicates Start, Stop and Halt in a program’s logic flow. A pause/halt is
generally used in a program logic under some error conditions. Terminal is the first and last symbols in
the flowchart.

2. Input/Output: A parallelogram denotes any function of input/output type. Program instructions that
take input from input devices and display output on output devices are indicated with parallelogram in a
flowchart.

3. Processing: A box represents arithmetic instructions. All arithmetic processes such as adding,
subtracting, multiplication and division are indicated by action or process symbol.

4. Decision Diamond symbol represents a decision point. Decision based operations such as yes/no
question or true/false are indicated by diamond in flowchart.

5. Connectors: Whenever flowchart becomes complex or it spreads over more than one page, it is useful to
use connectors to avoid any confusions. It is represented by a circle.

6. Flow lines: Flow lines indicate the exact sequence in which instructions are executed. Arrows represent
the direction of flow of control and relationship among different symbols of flowchart.
 Pseudocode
Pseudocode is a set of statements whose aim is to quantify the process without obscuring its functionwith
the syntax and semantics of a particular programming language. We have already seen some examples of
pseudo code in the previous section which was introduced to present the principle of procedures.
In general, the syntax used for pseudo code is arbitrary and user dependent and typically reflects the
programming language the user is most familiar with. The key to using pseudo code is to convey the
process clearly and accurately in a way that real code using some programming language can not
necessarily do as well, otherwise, one might as well write out the code directly - many programmers do!
The following examples illustrate the use of pseudo-code.

Example 1 Pseudo-code to read in a number from the keyboard, square it and write out the result to the
VDU.
Output(“Input number”)
input (number)
number=number*number
output(“Number squared is”, number)
Here, the data I/O is assumed to be controlled by the functions output and input.

Function Oriented Design

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.

Function Oriented Design Strategies:

Function Oriented Design Strategies are as follows:
 Data Flow Diagram (DFD):
A data flow diagram (DFD) maps out the flow of information for any process or system. It uses defined
symbols like rectangles, circles and arrows, plus short text labels, to show data inputs, outputs, storage
points and the routes between each destination.

 Data Dictionaries:
Data dictionaries are simply repositories to store information about all data items defined in DFDs. At
the requirement stage, data dictionaries contains data items. Data dictionaries include Name of the item,
Aliases (Other names for items), Description / purpose, Related data items, Range of values, Data structure
definition / form.

 Structure Charts:
It is the hierarchical representation of system which partitions the system into black boxes (functionality
is known to users but inner details are unknown). Components are read from top to bottom and left to
right. When a module calls another, it views the called module as black box, passing required parameters
and receiving results.
 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 super-
classes. This property of OOD is called an inheritance. This makes it easier to define a specific class and
 to create generalized classes from specific ones.
7. Polymorphism: OOD languages provide a mechanism where methods performing similar tasks but vary
in arguments, can be assigned the same name. This is known as polymorphism, which allows a single
interface is performing functions for different types. Depending upon how the service is invoked, the
respective portion of the code gets executed.

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.

Classification of Software Metrics

Software metrics can be classified into two types as follows:

1. Product Metrics: These are the measures of various characteristics of the software product. The two
important software characteristics are:

1. Size and complexity of software.

2. Quality and reliability of software.

These metrics can be computed for different stages of SDLC.

2. Process Metrics: These are the measures of various characteristics of the software development
process. For example, the efficiency of fault detection. They are used to measure the characteristics of
methods, techniques, and tools that are used for developing software.
 Types of Metrics

 Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed to be of
greater importance to a software developer. For example, Lines of Code (LOC) measure.
 External metrics: External metrics are the metrics used for measuring properties that are viewed to be
of greater importance to the user, e.g., portability, reliability, functionality, usability, etc.
 Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource metrics. For
example, cost per FP where FP stands for Function Point Metric.
 Project metrics: Project metrics are the metrics used by the project manager to check the project's
progress. Data from the past projects are used to collect various metrics, like time and cost; these
estimates are used as a base of new software. Note that as the project proceeds, the project manager will
check its progress from time-to-time and will compare the effort, cost, and time with the original effort,
cost and time. Also understand that these metrics are used to decrease the development costs, time efforts
and risks. The project quality can also be improved. As quality improves, the number of errors and time,
as well as cost required, is also reduced.

Size Oriented Metrics

 LOC Metrics

It is one of the earliest and simpler metrics for calculating the size of the computer program. It is
generally used in calculating and comparing the productivity of programmers. These metrics are derived
by normalizing the quality and productivity measures by considering the size of the product as a metric.

Following are the points regarding LOC measures:

1. In size-oriented metrics, LOC is considered to be the normalization value.

2. It is an older method that was developed when FORTRAN and COBOL programming were very
popular.
3. Productivity is defined as KLOC / EFFORT, where effort is measured in person-months.
4. Size-oriented metrics depend on the programming language used.
5. As productivity depends on KLOC, so assembly language code will have more productivity.
6. LOC measure requires a level of detail which may not be practically achievable.
7. The more expressive is the programming language, the lower is the productivity.
8. LOC method of measurement does not apply to projects that deal with visual (GUI-based) programming.
As already explained, Graphical User Interfaces (GUIs) use forms basically. LOC metric is not
applicable here.
9. It requires that all organizations must use the same method for counting LOC. This is so because some
organizations use only executable statements, some useful comments, and some do not. Thus, the
standard needs to be established.
10. These metrics are not universally accepted.
 Based on the LOC/KLOC count of software, many other metrics can be computed:

 Errors/KLOC.
 $/ KLOC.
 Defects/KLOC.
 Pages of documentation/KLOC.
 Errors/PM.
 Productivity = KLOC/PM (effort is measured in person-months).
 $/ Page of documentation.

Advantages of LOC

1. Simple to measure

Disadvantage of LOC

1. It is defined on the code. For example, it cannot measure the size of the specification.
2. It characterizes only one specific view of size, namely length, it takes no account of functionality or
complexity
3. Bad software design may cause an excessive line of code
4. It is language dependent
5. Users cannot easily understand it

Functional Point (FP) Analysis

Allan J. Albrecht initially developed function Point Analysis in 1979 at IBM and it has been further
modified by the International Function Point Users Group (IFPUG). 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:

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 th
 3. The effort required to develop the project depends on what the software does.

4. FP is programming language independent.

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

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 3 4 6

(EIF)

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 ∑(f i)

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 =

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

COCOMO Model

Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.COCOMO is one of the
 most generally used software estimation models in the world. COCOMO predicts the efforts and
schedule of a software product based on the size of the software.

The necessary steps in this model are:

1. Get an initial estimate of the development effort from evaluation of thousands of delivered lines of
source code (KDLOC).
2. Determine a set of 15 multiplying factors from various attributes of the project.
3. Calculate the effort estimate by multiplying the initial estimate with all the multiplying factors i.e.,
multiply the values in step1 and step2.

The initial estimate (also called nominal estimate) is determined by an equation of the form used in the
static single variable models, using KDLOC as the measure of the size. To determine the initial effort
Ei in person-months the equation used is of the type is shown below

Ei=a*(KDLOC)b

The value of the constant a and b are depends on the project type.

In COCOMO, projects are categorized into three types:

1. Organic
2. Semidetached
3. Embedded

1.Organic: A development project can be treated of the organic type, if the project deals with
developing a well-understood application program, the size of the development team is reasonably small,
and the team members are experienced in developing similar methods of projects. Examples of this type
of projects are simple business systems, simple inventory management systems, and data
processing systems.

2. Semidetached: A development project can be treated with semidetached type if the development
consists of a mixture of experienced and inexperienced staff. Team members may have finite experience
in related systems but may be unfamiliar with some aspects of the order being developed. Example of
Semidetached system includes developing a new operating system (OS), a Database Management
System (DBMS), and complex inventory management system.

3. Embedded: A development project is treated to be of an embedded type, if the software being

developed is strongly coupled to complex hardware, or if the stringent regulations on the operational
method exist. For Example: ATM, Air Traffic control.

For three product categories, Bohem provides a different set of expression to predict effort (in a unit of
person month)and development time from the size of estimation in KLOC(Kilo Line of code) efforts
estimation takes into account the productivity loss due to holidays, weekly off, coffee breaks, etc.
 According to Boehm, software cost estimation should be done through three stages:

1. Basic Model
2. Intermediate Model
3. Detailed Model

1. Basic COCOMO Model: The basic COCOMO model provide an accurate size of the project
parameters. The following expressions give the basic COCOMO estimation model:

Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months

Where

KLOC is the estimated size of the software product indicate in Kilo Lines of Code,

a1,a2,b1,b2 are constants for each group of software products,

Tdev is the estimated time to develop the software, expressed in months,

Effort is the total effort required to develop the software product, expressed in person months (PMs).

Estimation of development effort

For the three classes of software products, the formulas for estimating the effort based on the code size
are shown below:

Organic: Effort = 2.4(KLOC) 1.05 PM

Semi-detached: Effort = 3.0(KLOC) 1.12 PM

Embedded: Effort = 3.6(KLOC) 1.20 PM

Estimation of development time

For the three classes of software products, the formulas for estimating the development time based on the
effort are given below:

Organic: Tdev = 2.5(Effort) 0.38 Months

Semi-detached: Tdev = 2.5(Effort) 0.35 Months

Embedded: Tdev = 2.5(Effort) 0.32 Months

Some insight into the basic COCOMO model can be obtained by plotting the estimated characteristics
for different software sizes. Fig shows a plot of estimated effort versus product size. From fig, we can
observe that the effort is somewhat superliner in the size of the software product. Thus, the effort
 required to develop a product increases very rapidly with project size.

The development time versus the product size in KLOC is plotted in fig. From fig it can be observed that
the development time is a sub linear function of the size of the product, i.e. when the size of the product
increases by two times, the time to develop the product does not double but rises moderately. This can be
explained by the fact that for larger products, a larger number of activities which can be carried out
concurrently can be identified. The parallel activities can be carried out simultaneously by the engineers.
This reduces the time to complete the project. Further, from fig, it can be observed that the development
time is roughly the same for all three categories of products. For example, a 60 KLOC program can be
developed in approximately 18 months, regardless of whether it is of organic, semidetached, or embedded
type.
From the effort estimation, the project cost can be obtained by multiplying the required effort by the
manpower cost per month. But, implicit in this project cost computation is the assumption that the entire
project cost is incurred on account of the manpower cost alone. In addition to manpower cost, a project
would incur costs due to hardware and software required for the project and the company overheads for
administration, office space, etc.

It is important to note that the effort and the duration estimations obtained using the COCOMO model are
called a nominal effort estimate and nominal duration estimate. The term nominal implies that if anyone
tries to complete the project in a time shorter than the estimated duration, then the cost will increase
drastically. But, if anyone completes the project over a longer period of time than the estimated, then
there is almost no decrease in the estimated cost value.

Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and development time
for each of the three model i.e., organic, semi-detached & embedded.

Solution: The basic COCOMO equation takes the form:

Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 400 KLOC
(i)Organic Mode

E = 2.4 * (400)1.05 = 1295.31 PM

D = 2.5 * (1295.31)0.38=38.07 PM

(ii)Semidetached Mode

E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM

(iii) Embedded Mode

E = 3.6 * (400)1.20 = 4772.81 PM

D = 2.5 * (4772.8)0.32 = 38 PM

Cyclomatic Complexity

Cyclomatic complexity is a software metric used to measure the complexity of a program. Thomas J.
McCabe developed this metric in 1976.McCabe interprets a computer program as a set of a strongly
connected directed graph. Nodes represent parts of the source code having no branches and arcs
represent possible control flow transfers during program execution. The notion of program graph has
been used for this measure, and it is used to measure and control the number of paths through a program.
The complexity of a computer program can be correlated with the topological complexity of a graph.

How to Calculate Cyclomatic Complexity?

McCabe proposed the cyclomatic number, V (G) of graph theory as an indicator of software complexity.
The cyclomatic number is equal to the number of linearly independent paths through a program in its
graphs representation. For a program control graph G, cyclomatic number, V (G), is given as:

V (G) = E - N + 2 * P

E = The number of edges in graphs G

N = The number of nodes in graphs G

P = The number of connected components in graph G.

Example:
 Properties of Cyclomatic complexity:

Following are the properties of Cyclomatic complexity:

1. V (G) is the maximum number of independent paths in the graph

2. V (G) >=1
3. G will have one path if V (G) = 1
4. Minimize complexity to 10

Control Flow Graph (CFG)

A Control Flow Graph (CFG) is the graphical representation of control flow or computation during the
execution of programs or applications. Control flow graphs are mostly used in static analysis as well as
compiler applications, as they can accurately represent the flow inside of a program unit. The control
flow graph was originally developed by Frances E. Allen.

Characteristics of Control Flow Graph:

 Control flow graph is process oriented.
 Control flow graph shows all the paths that can be traversed during a program execution.
 Control flow graph is a directed graph.
 Edges in CFG portray control flow paths and the nodes in CFG portray basic blocks.

There exist 2 designated blocks in Control Flow Graph:

1. Entry Block:
Entry block allows the control to enter into the control flow graph.
2. Exit Block:
Control flow leaves through the exit block.

Hence, the control flow graph is comprised of all the building blocks involved in a flow diagram such as the
start node, end node and flows between the nodes.
General Control Flow Graphs:
Control Flow Graph is represented differently for all statements and loops. Following images describe it:
1. If-else:

2. while:

3. do-while:

4. for:
 Example:
if A = 10 then
if B > C
A=B
else A = C
endif
endif
print A, B, C
Flowchart of above example will be:

Control Flow Graph of above example will be:

Advantage of CFG:
There are many advantages of a control flow graph. It can easily encapsulate the information per each
basic block. It can easily locate inaccessible codes of a program and syntactic structures such as loops
are easy to find in a control flow graph.