Traceability of Requirements in

Software Development Process

Swapan Bhattacharya

Department of Computer Science & Engineering

Jadavpur University, Kolkata – 700032, India
Email : bswapan2000@yahoo.co.in

January 14, 2011

 Contents
 Software Engineering
 In comparison to Conventional Engineering
 Evolution in SE
 Software Development Process – SRD, SA, ST
 Issues & Challenges
 Traceability of Requirements
 Non-engineering example
 In Software development
 Significance
 Domain of Our Research
 Research Framework – Graph based
 Why Graph based framework ?
 Introduction to OOG
 Application of OOG to Software Development process
 Achieving Requirement Traceability
 Results & Contribution

January 14, 2011

 Contents
 Software Engineering
 In comparison to Conventional Engineering
 Evolution in SE
 Software Development Process – SRD, SA, ST
 Issues & Challenges
 Traceability of Requirements
 Non-engineering example
 In Software development
 Significance
 Domain of Our Research
 Research Framework – Graph based
 Why Graph based framework ?
 Introduction to OOG
 Application of OOG to Software Development process
 Achieving Requirement Traceability
 Results & Contribution

January 14, 2011

 Software Engineering
 Software Engineering vis-à-vis Conventional Engineering (Differences)

 Software engineering is based on Traditional engineering is based on

computer science, information physics, chemistry, and calculus.
science, and discrete math

 Software engineering and Construction and manufacturing

consulting often cost more than 50% costs are high, so traditional
of a project. Even minor software engineering may only cost 15% of a
engineering cost-overruns can cause project. So engineering cost overruns
a project to fail may not affect a project's viability

Software engineers apply new and Traditional engineers apply known

untested elements in many software and tested principles
projects

Ref : http://www.fact-index.com/s/so/software_engineering.html

January 14, 2011

 Software Engineering
Software Engineering vis-à-vis Conventional Engineering(Similarities)

Software engineers aspire to build low-cost, reliable, safe software,

which is much like what traditional engineers do.

Software engineers use terms from traditional engineering

disciplines: requirements analysis, quality control, and project
management techniques

Traditional engineers now use software tools to design and analyze

systems

SE is all pervasive in today’s society - Almost all Conventional

engineering disciplines utilize the benefits of computing for
their business

January 14, 2011

 Software Engineering
Significance

In the USA, software drove 1/4 of all increase in

GDP during the 1990s (about $90 billion per year),
and 1/6 of all productivity growth (efficiency within
GDP) during the late 1990s (about $33 billion per
year).

January 14, 2011

 Software Engineering
Software Development Process

 Requirement Definition
 Requirement Analysis
 Architecture Design
 Detailed Design
 Coding & Implementation
 Testing

Additionally there are several project management

activities around these phases of development

January 14, 2011

 Software Engineering
 Evolution in Software Engineering
- Collection of programs & Data
- Programs, Data & Documentation
- Software & Hardware components integrated to serve a requirement
- Software, Hardware, Personnel & Processes
- Collection of all of above & many more to offer services for providing
solutions

- Above all it is a mix of Art, Science, Philosophy & Engineering

Current directions
• Aspect programming
• Service Oriented paradigm
• Agile process

January 14, 2011

 Software Engineering
Issues and Challenges

 Highly Complex
 Distributed development
 Quality driven
 Use of Tools and Technology
 Model based development and Testing

Software Verification consumes a significant amount of effort and

time of the overall software development process.

Software Traceability ensures development of Quality software

product in the most efficient way

January 14, 2011

 Contents
 Software Engineering
 In comparison to Conventional Engineering
 Evolution in SE
 Software Development Process – SRD, SA, ST
 Issues & Challenges
 Traceability of Requirements
 Definition - Requirement, Trace, Software Requirement Traceability
 Non-engineering example
 In Software development
 Significance
 Motivation
of Our Research
 Research Framework – Graph based
 Why Graph based framework ?
 Introduction to OOG
 Application of OOG to Software Development process
 Achieving Requirement Traceability
 Results & Contribution

January 14, 2011

Definition - Software Requirement

 Documented Need of the business

 An agreement between the
customer and the developer
regarding the system to be
developed
 Comprises of
 Functional - Functions that the software
system is to execute
 Non-functional requirements - Security,
performance, availability, maintainability,
reliability, etc

 Provided by the relevant

stakeholders of business

January 14, 2011

Definition – Trace, Software Requirement Tracing
 Trace as defined in English dictionary is to -
Follow, discover or ascertain the course of
development of something

 Software Requirement Tracing is the

process of following the course or path of
requirement through the software
development process
 From Requirement elicitation to
Implementation & Use – Both in Forward &
Backward direction

Software Requirement Traceability is the ability to follow a

Software Requirement through its various phases of
development in the life cycle

January 14, 2011

 Requirement Traceability - A Non-Engineering Example
A Tailoring Shop
1. The Customer wants a dress
to be tailor made
2. She chooses the cloth
(material)
3. She chooses the style
4. She provides the size
Customer specifications
5. She also mentions if she is
trying to get slim or gain
weight
1. The Designer checks if there is
enough cloth according to the
measurement.
2. The designer makes her
judgment if the cloth is suitable
for the style chosen
Fashion 3. The designer makes her call to
Designer analyze if the timeline is
practical
4. She provides a cost estimation
to the customer

Requirement 6. She provides the timeline

The customer agrees or Feasibility Cost

negotiates Study Analysis

January 14, 2011

 Requirement Traceability - A Non-Engineering Example

1. The Designer assigns a group of people

(cutting, stitching, finishing)
2. The designer hands over the details
gathered from the customer to the
workforce.

Requirement Analysis
1. The workforce analyzes the requirements gathered.
2. The group of cutters cut the cloth according to the measurements.
Implementation
3. The cutters keep provision so that if there is a change in size

Change management
1. After finishing cutting each part, they go back to the specifications and verifies.
2. After finishing cutting each part, they hand over the part toTesting
the sewing team and
start working on the new part.

Requirement Tracing (backward)

January 14, 2011
Requirement Traceability - A Non-Engineering Example

Requirement Analysis
1.The group of stitchers find the details from the specifications.

2.They stitch each part based on the specifications.

3.The stitchers keep provision so that if there is a change in

size. Change management

4.After finishing stitching each part, they go back to the

specifications and verifies. Testing

5.After finishing stitching each part, they hand over the part to
the finishing team.a Requirement Tracing (backward)
January 14, 2011
Requirement Traceability - A Non-Engineering Example

Requirement Analysis
1. The group of finishing experts find the details from the specifications.

2. They loosely assemble and stitch each part received from the stitchers based
on the specifications. Implementation

3. They keep provision so that if there is a change in size.

Change management
4. After assembling any two parts, they go back to the specifications and verifies.

Testing
5. After finishing integrating all the parts, they hand over the loosely stitched outfit
to the designer.
Requirement Tracing (backward)
January 14, 2011
 Requirement Traceability - A Non-Engineering Example

1. The designer calls the customer for a trial.

2. They customer comes in and tries the outfit .

1. The customer likes it but it does not fit

1. The customer likes it
and it fits her well.
2. The finishing team
makes final stitching
of the parts together.
3. Ironing.
4. Delivery
her well. Testing
1. The customer
2. The finishing team sends the part that does not like it
needs to be altered to the at all (style,
cutting/stitching team. Feedback & Change
size
3. The concerned team makes the everything).
appropriate changes based on the 2. She calls off
specification and customer feedback. the order
Requirement Tracing
4. Assembly.
(forward)
5. Trial
Rework
January 14, 2011

January 14, 2011

Requirement Traceability – Software Development
Process

Requirement
Specification Requirement
Architecture
Analysis
Design
Functional
Implementation
Non-Functional Feasibility Study
Cost Analysis
Integration
Forward
Traceability

Backward
Traceability Testing

Maintenance Delivery Customer

Feedback

January 14, 2011

 Software Requirement Traceability
- in phases of Software development process

January 14, 2011

 Software Requirement Traceability
- Definition

A much cited definition of requirements

traceability

“The ability to describe and follow the life of

a requirement, in both forward and a
backward direction, i.e., from its origins,
through its development and specification,
to its subsequent deployment and use, and
through periods of ongoing refinement and
iteration in any of these phases”.

January 14, 2011

Requirement Traceability - Significance

Requirement Traceability techniques answers the following

questions:
Requirement Coverage

 Are all requirements allocated? Are we done?

Redundancy check
 Is this design element necessary?

 Is the implementation compliant with the requirements?

Requirement Sufficiency
 What acceptance test will be used to verify a requirement?
Test Coverage
 What is the impact of changing a requirement?

Change Management
January 14, 2011
Requirement Traceability - Significance
 Verify the conformance of a solution with its needs
 Relate and link all the outputs of intermediate phases to
requirements in beginning &solution in the end
 Ability to identify impact of requirements to manage changes
easily
 In Software development context, Requirment Traceability
offers a viable solution for ensuring –
 Consistency
 Correctness
 Requirement change management
 Early error detection
 Higher quality
 Lesser cost

January 14, 2011

 Software Architecture &
Requirement Traceability

Business Requriements

System Requirements

Functional Non-Functional

Use Cases Architectural Decisions

Business Rules Architectural Designs

Functional Components Technical Components

Ref : http://applicationarchitecture.wordpress.com/2010/05/25/knowledge-
nugget-what-is-requirements-traceability/
January 14, 2011
Software Architecture &
Requirement Traceability

In layered
Architecture
Model, Software
Requirement
Traceability is
gaining significance

January 14, 2011

 Contents
 Software Engineering
 In comparison to Conventional Engineering
 Evolution in SE
 Software Development Process – SRD, SA, ST
 Issues & Challenges
 Traceability of Requirements
 Non-engineering example
 In Software development
 Significance
 Focus of Our Research
 Research Framework – Graph based
 Why Graph based framework ?
 Introduction to OOG
 Application of OOG to Software Development process
 Achieving Requirement Traceability
 Results & Contribution

January 14, 2011

 Focus of Our Research
1. Identification of any error or potential for error as early as
possible
2. Isolation from one phase in production phase from another phase
maintaining the missing links
3. Deployment of appropriate verification tools and techniques at
every phase
4. Integration of customer involvement in software development
process – for better requirement understanding & management
5. Evolutionary approach for accommodating updates and/or new
user requirements

Traceability of Requirements in Software Development Process

addresses these key issues & concerns

January 14, 2011

 Contents
 Software Engineering
 In comparison to Conventional Engineering
 Evolution in SE
 Software Development Process – SRD, SA, ST
 Issues & Challenges
 Traceability of Requirements
 Non-engineering example
 In Software development
 Significance
 Focus of Our Research
 Research Framework – Graph based
 Why Graph based framework ?
 Introduction to OOG
 Application of OOG to Software Development process
 Achieving Requirement Traceability
 Results & Contribution

January 14, 2011

Research Framework – Graph Model
Why Graph ?

 Well-known area of Mathematics

 Vast repository of graph constructs
 Vast repository of algorithms for analyzing graphs
 Capable of modeling related artifacts
 Modeling of complex systems becomes simpler

Hence we propose –
 Graph based framework for modeling all related artifacts of a
Software Development Process

 Graph based Analysis for ensuring Traceability of Requirements

from beginning till the end

January 14, 2011

 Research Framework - OOG
Object Oriented Graph (OOG)

 Hierarchical Directed Graph

 Each layer of the graph abstracts OO systems during different

phases of development

 Nodes in each layer corresponds to the different artifacts

produced in a phase

 Directed edges in each layer models the interconnection or

relations between the artifacts (modeled by Nodes)

January 14, 2011

 Research Framework - OOG
S/W Development UML Models Graph name
Phase used

Requirement Use Case URG

Analysis Diagram (UseCase Relationship Graph)

Detailed Activity ARG

Analysis Diagram (Activity Relationship Graph)

Detailed Sequence D-SG

Design Diagram (Distributed Scenario Graph)

Coding Java code E-CFG

(Classes)

Deployment Component CAG

(Classes to Components) Diagram (Component Architecture Graph)

January 14, 2011

Research Framework
Layered Graph
URG

across the phases of S/W

ARG

Development Process

Trace Requriements
D-SG

ECFG

CAG

January 14, 2011

 Research Framework - OOG

Constructs of OOG :
 Nodes in Sequence
 Nodes connected to more than one Node
 In Degree > 1
 Out Degree > 1
 Nodes in loop (repetitively referred)
 Many Nodes in iteration
 Single Node in iteration

January 14, 2011

 Research Framework – OOG Constructs
Nodes of OOG in Sequence Nodes of OOG deing called/
Referred More than Once
N1
N1 N2 N3

N2

N4

Nodes of OOG Connected Nodes of OOG in Iteration i.e.

Repeatedly Referred
with More than One Node
N1

N2 N3 N4
Single Group of Nodes (N1-
Node N1 N2 in sequence)

January 14, 2011

 Research Framework – OOG Paths

Paths in OOG in each layer :

 The paths in the graph of each layer gives a measure of

the number of test cases to be executed at each level.
 Path computation is done as per a generic formula
defined for each phase.
 The path is expressed as a function of the paths in each
node of OOG and is referred to as OGP (Object Graph
Path).

Summarizing this in next slide

January 14, 2011

 Research Framework - OOG Paths
Sl. No. Type of Path Metrics Explanation
Construct
Case 1 Nodes are in P= OGP(Gx) if OGP(Gx) > Gx is the graph for Node Nx
sequence OGP(G1), OGP(G2).... which has the maximum no. of
OGP(Gn) and 1< x < n paths among all the nodes G1
… Gn
Case 2 Out degree > 1 P = OGP(G1) + OGP(G2) + (n-1) nodes N2 …Nn whose
…… OGP (Gn) – (n-1) graphs are represented by G1,
G2 …. Gn
Case 3 In Degree > 1 P = (OGP(G1)+ OGP (G2)- is the graph for Node 1 which
1)+ .... ..........+ OGP (Gn) + is called by N2 …..Nn whose
(n-2) graphs are G2 … Gn
Case 4a Iteration/Recursio P = OGP(G1) + 1, where G1 is the graph for
n of one Node Node1, OGP is the paths in N1

Case 4b Iteration/recursion P = OGP(G’) + 1 where G’ is more than one

of more than one node connected as per case 1
node or 2

Path calculation metrics for different constructs of OOG

January 14, 2011
OOG Paths – Significance in different levels
The significance of paths is different for each graph in each layer –

 In URG we do not show/identify any paths since it simply shows the

interconnection of use cases only.
 In ARG, the paths signify the event paths for a requirement.
 This is further detailed out in D-SG where scenario paths can be identified
as a set of sequence messages realizing a requirement.
 Finally in ECFG, the paths denote the independent paths in object-oriented
code similar to McCabe’s basis set in procedural programs.
 Since CAG models the interconnection of components, which does not
have any sequence, the concept of paths does not apply there.

The paths in each layer are analyzed to give a measure of the

number of test cases to be executed at each level.

The different levels are interconnected to trace the path of Requirements

January 14, 2011

 Application of OOG – Case Study

Insurance System – Requirements

◦ Policy Creation
◦ Policy Maintenance
◦ Policy Claim
◦ Policy Termination
Next slide lists the Use cases that model these
Requirements. The Use cases for each requirement is
shown together to indicate the mapping clearly

January 14, 2011

 Case Study: List of Use Cases (Requirements to
Use Case Mapping)
Use Case Use Case
Use Case Name Use Case Name
No. No.
1 Policy Creation 25 Policy Claim
2 Application Entry 26 Accept Claim request
3 Underwriting 27 Validate Claim
4 Underwriting 1 28 Verify initial documents
5 Accept More Details 29 Beneficiary validation
6 Underwriting 2 30 Policy validation
7 Process Error 31 Claim validation
8 Premium Calculation 32 Calculate Claim amount
9 Premium Payment 33 Disburse Claim amount
10 Policy Issuance 34 Policy Termination
11 Certificate Generation 35 Lapse
12 Policy Maintenance 36 Non-payment of premium
13 Policy updation 37 Calculate lapse amount
14 Non-financial update 38 Disburse lapse amount
15 Financial update 39 Surrender
16 Policy Value Calculation 40 Partial/full surrender process
17 Add new premium 41 Calculate surrender amount
18 Calculate interest 42 Disburse surrender amount
19 Deductions 43 Maturity
20 Loan Processing 44 Calculate maturity value
21 Accept Loan request 45 Disburse maturity amount
22 Verify/recalculate Loan amount 46 Calculate
23 Adjust Policy value 47 Disberse
24 Disburse loan
January 14, 2011
 Case Study: URG – 1st Level of OOG
1 12
Nodes 1 2 3 4 5 6 7 8 9 10 11

13 16 20 1 1 1 1 0
1 0 0 0 0 0 1a
a a a a
2 3 8 9 10 0
2 0 0 0 0 0 0 0 0 0 0

1 1 1 0
14 15 17 18 19 3 0 0 0 0 0 0 0
a a a
11 1 0
4 5 6 4 0 0 0 0 0 0 0 0 0
a
0
21 22 23 24 5 0 0 0 0 0 0 0 0 0 0

7 1 0
6 0 0 0 0 0 0 0 0 0
47 34 a
46
25 7 0 0 0 0 0 0 0 0 0 0 0

35 43 8 0 0 0 0 0 0 0 0 0 0 0
39
26
9 0 0 0 0 0 0 0 0 0 0 0
45 1a
27 36 37 38 44 10 0 0 0 0 0 0 0 0 0 0

11 0 0 0 0 0 0 0 0 0 0 0
31 42
28 29 30 33 40 41
32

Partial Adjacency matrix for URG

Use Case Relationship Graph (URG)
of Insurance System

January 14, 2011

Analysis Phase : ARG (Activity Relationship Graph)

 In the analysis phase, the flow of events of a use

case is modeled using UML activity diagrams.

 Each use case event maps to an activity state which

may be one of the different types available as per
UML 2.0 standard – Action state, Decision box, fork,
join, etc.

 Use cases may be interrelated through the UML

constructs “includes” and “extends”. Likewise, the
activity diagrams realizing the use cases are also
inter-related as modeled in ARG.

January 14, 2011

Case Study: Use Case traced to Activity diagrams
In some cases, these use cases are interleaved i.e. the flow of events are
interleaved, they are interconnected in a way to serve the purpose of the
overall process – providing software solution for insurance domain.
Use Case No. Use Case Name Activity Diagram Activity Node

1. Policy Creation
2. Application Entry Application Entry Main Application A1 A2, A3
Entry Policy specific
3. Underwriting
4. Underwriting 1 Underwriting1 A4
5. Accept More Details Accept more details A5
6. Underwriting 2 Underwriting2 A6
7. Process Error Data entry error, Business logic error A7 A8

8. Premium Calculation Premium calculation A9

9. Premium Payment Premium payment A10
10. Policy Issuance Issue policy A11
11. Certificate Generation Certificate generation A12
Use Case to Activity Nodes Mapping for “Policy Creation”
January 14, 2011
Case Study: ARG – 2nd level of OOG
A1
 Each node of the ARG is an activity
diagram, which can be further visualized
A3 as a graph like ADG and each ADG has
A2
several independent paths ADP.
A4
A5 It can be noted that the manner in
A7 which the nodes are connected can be
A6
detected from the ARG.
A8

The nodes that are in sequence are

shown by the firm edges.
A9

A10 Likewise the dashed edges denote the

other constructs of ARG.
A11

A12 ARG for the “Policy Creation” of Insurance System

END

January 14, 2011

Case Study: ARG Node conflict resolution
Cases of Interleaving Case# Conflict
AD No ADP
(Node#) Resolution
1 Case 1 (3), Case 2 (2) Case 1 2
2 Case 4 (4, 7) Case 4 2
3 Case 1 (1) - 3
Case 2 (5, 7, 8, 9), Case 3 (2, 3),
4 Case 4 6
Case 4 (2, 7)
5 Case 1 (6), Case 2 (4) Case 2 2
6 Case 1 (5), Case 2 (7, 8, 9) Case 2 4
7 Case 3 (4, 6), Case 4 (2, 7) Case 4 4
8 Case 3 (4, 6) - 2
9 Case 3 (4, 6) - 3
10 Case 1 (9, 11) - 2
11 Case 1 (10, 12) - 3
12 Case 1 (11) - 4

Activity Nodes Conflict Resolution and ADP Values

January 14, 2011
 Case Study: Events Paths from ARG
Calculation of EP A1

We divide the ARG into subgraphs where each A2

A3

comprises of a set of nodes with a type of connection as

per the Table.
A4
A5

Subgraph 1: Node 1 calling Node 2, 3 as per Case 2. A7

A6
EP (SG1) = ADP (Node1) + ADP (Node2) + ADP (Node3) – (3-
1) A8

Therefore EP= ADP (Node1) + ADP (Node2) + ADP (Node3) -2

= 2 + 2+ 3 – 2 = 5
A9
Subgraph 4: Node 10, 11 and 12 in series
EP (SG4) = Max (ADP (10), ADP (11), ADP (12)) + 1 A10

= Max (2, 3, 4) + 1
A11
=4+1=5
A12
In total there are 34 scenario paths based on END

the ARG for “Policy Creation” requirement –

Req Traced to events
January 14, 2011
Design Phase : D-SG (Distributed Scenario Graph)

 In the design phase, sequence diagrams are commonly used

to implement the sequence of events of an activity diagram.
 The event-method mapping is also done here and based on
that the methods are formulated in the design phase.
 Sequence diagrams essentially depict the interaction between
objects of different classes through the use of methods
corresponding to an event in activity diagram.
 In the next section we discuss the relationship between
activity diagrams and sequence diagrams.
 This forms the basis of translation of ARG to the next level
graph D-SG.

January 14, 2011

 D-SG : Relationship between Activity &
Sequence Diagram
The different cases of mapping between these two commonly used
diagrams.

 One–to-one – When there is a single sequence diagram

corresponding to each activity diagram. Here every event maps
to one or more messages
 One –to-many - When there are many sequence diagrams
corresponding to one activity diagram. Here again every event
maps to one or more messages. There may be different reasons
for this mapping as explained below –
 When alternate flow of events in activity diagram are depicted by
separate sequence diagram
 When separate sequence diagrams are used to depict the same
Activity events. This is required in distributed development scenario
where region specific events interleave with generic or common events
to fulfill a requirement scenario.

January 14, 2011

 D-SG: Sequence Diagrams in Distributed
Environment
 Global distributed model for development introduces complexity
 Software architecture involves lot of interleaving between the sequence
diagrams
 We apply the concept of OOG at this level for modeling the interleaving of
sequence diagram capturing all possible scenarios of a system.
 We name it as Distributed Scenario graph (D-SG).
 It is a hierarchical directed graph where the top level identifies
connections between sequence diagrams and direction denotes the
sequence or order in which they are connected.
 The next level models the object interactions within a sequence diagram
as a graph.
 Optimum Scenario Path (OSP) metrics that measures the minimum
number of independent path in the D-SG can be calculated.

January 14, 2011

 Case Study: D-SG – 3rd level of OOG
S1

S2 S3 S4

S8

S5
S6 S7

D-SG of “Policy S9

Creation”
S10

S12

S11

In total there are 71 S13

scenario paths based

S14

on all the related

sequence diagrams S15 S16 S17

modeling the
requirement. S18

S19 S20 S21

Trace Requirements
S22

to Sequence
Diagrams at Design S23

Phase
S24 END

January 14, 2011

 Case Study: Activity events traced to
Sequence messages
Activity Diagram Activity Node Sequence Diagram Sequence Node
Application Entry A1 A2, A3 Application Entry Main S1 S2, S3, S4 S5, S6, S7,
Main Application Application Entry Policy specific S8
Entry Policy specific Application Entry Location
Specific
Underwriting1 A4 Underwriting1 S9
Accept more details A5 Accept more details S10
Underwriting2 A6 Underwriting2 S11
Data entry error, A7 A8 Data Entry Error Business Logic S12 S13
Business logic error Error
Premium calculation A9 Premium Calculation main S14 S15, S16, S17 S18,
Premium Calculation Policy S19, S20, S21
Specific Premium calculation
Location Specific
Premium payment A10 Premium payment S22
Issue policy A11 Issue policy S23
Certificate generation A12 Certificate generation S24

Activity Diagram to Sequence Diagram Mapping

January 14, 2011
Coding Phase : ECFG (Extended Control
Flow Graph)
 White-box testing based on Control Flow Graph (CFG) though widely
used for procedural systems fails to be applicable as it is in case of Object
Oriented systems.

 A new model Extended Control Flow Graph (ECFG) has been proposed
which is a layered graph with a collection of CFG’s of the individual
operations of the OO software.

 A new metrics Extended Cyclomatic Complexity (E-CC) has been

proposed which gives a measurement of the minimum number of test cases
that should be designed for ensuring covergae of all the independent control
paths in the code.

January 14, 2011

 Coding Phase : ECFG (Extended Control
Flow Graph)
In an E-CFG, the nodes are Methods and each method is represented by
McCabe’s CFG. The nodes may be connected in one of these ways -

• Operations/Methods connected in series

• Method calling one/more methods one/many times
• Many methods calling one particular method
• Method is recursively called

Extended Cyclomatic Complexity number (E-CC) is derived

based on the McCabe’s Cyclomatic Complexity of the
individual operations/methods. Represents the minimum no. of test
paths in the Object oriented code
Case Study: ECFG – 4th level of OOG

ECFG for part of the system

E-CC (Extended Cyclomatic Complexity measures the minimum

number of test paths through the OO code
 Deployment Phase : Component Diagram for
Case Study
Classes developed during coding phase are packaged into components
and each component interact with others through well defined interfaces

Component Diagram of Insurance System

 Case Study : CAG – 5th Level of OOG
Component Architecture Graph
Component Diagram Modeled as a Graph named
C1 C2
C5

8
1 7 3

C3 2 C4
4
C6

C7

C11
C8 C10
C9

Component Architecture Graph (CAG)

 Deployment Phase : CAG Metrics
Component Level Metrics
 Component Fan-in Factor (CFIF)
 Component Fan-out Factor (CFOF)
 Component Interaction Factor (CIF) ( Average of CFIF & CFOF)

Component to Component Coupling Metrics

 Interface Count (IC)
 Component Paths (CP)

Architecture Level Metrics

 Architecture Component Interaction Factor (ACIF)
 Architecture Interface Count (AIC)
 Architecture Paths (AP)

Overall Complexity – ACIF + AIC + AP

Named as -
Component Architecture Complexity Measurement Metrics (CACMM)
 References
Books :
1. Ananya Kanjilal, Sabnam Sengupta and Swapan Bhattacharya, “Graph Based Analysis of
Object Oriented Systems: An Integrated Approach”, Nova publishers
2. Swapan Bhattacharya, Ananya Kanjilal and Sabnam Sengupta, “Tools and Techniques for
Model Based Testing”, “Handbook of Research on Software Engineering and Productivity
Technologies: Implications of Globalization”, Information Science Reference (Imprint of IGI
Global), pp 226-249, August 2009
Journals:
3. Sabnam Sengupta, Ananya Kanjilal, Swapan Bhattacharya,“A Graph Based Approach to
Measure Complexity of Component Based Architecture”, to be published in ACM Sigsoft
Software Engineering Notes (SEN), Vol. , Issue , pp , Jan 2011.
4. Dipankar Majumdar, Sabnam Sengupta, Ananya Kanjilal, Swagata Kundu, “A Mathematical
Reusability Model for Quantifying the Reduction in Development Effort”, ACM Sigsoft
Software Engineering Notes (SEN), Vol. 35, Issue 4, pp 1-8, July 2010.
5. Ananya Kanjilal, Goutam Kanjilal and Swapan Bhattacharya, “Metrics based analysis of
requirements for object-oriented systems: An empirical approach”, INFOCOMP Journal of
Computer Science, Vol 7, No. 2, pp 26-36, June 2008.
6. Swapan Bhattacharya and Ananya Kanjilal “Code Based Analysis of Object Oriented
Systems”, Journal of Computer Science & Technology JCST, Springer-Verlag, Vol 21, No. 6,
pp 965-972, November 2006.
January 14, 2011
Thank You

January 14, 2011