2008 IEEE Region 10 Colloquium and the Third ICIIS, Kharagpur, INDIA December 8-10.
PAPER IDENTIFICATION NUMBER: 520
Early Quantitative Software Reliability Prediction
Using Petri-nets
K.Krishna Mohan , A.K.Verma, A.Srividya ,
G.Varaprasada Rao
Reliability Engg. Group, Department of Electrical Engineering,
Indian Institute of Technology Bombay,
Mumbai, INDIA
Ravi Kumar Gedela
Centre of Excellence- SAP,
Satyam Computer Services Limited,
Hyderabad, INDIA
Ravikumar_Gedela@satyam.com
kkm@ee.iitb.ac.in, akv@ee.iitb.ac.in, asvidya@ee.iitb.ac,
prasadarao@ee.iitb.ac.in
Abstract— In a competitive business landscape, large
organizations such as insurance companies and banks are under
high pressure to innovate, improvise and distinguish their
products and services while continuing to reduce the time-to
market for new product introductions. Generating a single view
of the customer is vital from different perspectives of the systems
developer over a period of time because of the existence of
disconnected systems within an enterprise. Therefore, to increase
revenues and cost optimization, it is important to build enterprise
systems more closely with the business requirements by reusing
the existing systems. While building distributed based
applications, it is important to take into account the proven
processes like Rational Unified Process (RUP) to mitigate risks
and increase the reliability of systems. Experiences in developing
applications in Java Enterprise Edition (JEE) with customized
RUP have been presented in this paper. RUP is adopted into an
onsite-offshore development model along with ISO 9001and SEI
CMM Level 5 standards. This paper provides an RUP approach
to achieve increased reliability with higher productivity and
lower defect density along with competitiveness through cost
effective custom software solutions.
Quantitative software reliability prediction is done using
Generalized Stochastic Petri Nets, based on the RUP
implemented prototype obtained from the PoC of a financial
application prior to the actual implementation of the application
development.
Keywords- Offshore Development Center (ODC), Petri Nets,
Rational Unified Process (RUP), Time Net 4.0
I.
INTRODUCTION
G
lobalization of software development has expanded
rapidly in recent years and has brought a wake of changes that
impact application development projects [1]. The adoption of a
new process for delivery excellence within an organization is
critical to meet the time-to-market conditions and is a
significant undertaking. It requires careful customization to
match the organization culture, accommodate any existing
procedures, and obtain buy-in among the key stakeholders and
users of the process. Many organizations have initiated a
program to standardize the software development process using
rational tools and RUP. A natural extension of the adoption of
RUP would be its inclusion to the offshore development to
reduce the total cost of ownership (TCO) with improved
reliability that comes with higher productivity. However, with
the comprehensive nature of RUP comes the significant
complexity regarding the process steps and the types of
artefacts produced at each step [2]. Thus, this research paper is
intended to cover the elements of a RUP- based development
process that are vital to successful development projects.
This paper provides an approach for early Quantitative
analysis for the reliability estimation of the application
development based using on the output results of the prototype
development through Rational Unified Process (RUP). It
discusses the approach by citing examples of the work done by
the authors in two areas: requirements gathering/modelling and
testing (manual and automation) phases. National Research
Council Canada [3] and several other organizations reveal that
process oriented development is necessary to improve
reliability and productivity, decreasing the cost, thereby
increasing the operational efficiency.
II.
RATIONAL UNIFIED PROCESS
RUP is a comprehensive framework, more or less a
complete set of process elements that has to be tailored to each
case since no project needs the complete set of elements. IBM
Rational has in fact done some of the tailoring of the original
Unified Process by the development of RUP [4]. RUP product
is a software engineering process [5][6]. It provides a
disciplined approach to assigning tasks and responsibilities
within a development organization. Its goal is to ensure the
production of high-quality software that meets the needs of its
end users within a predictable schedule and budget. Fig. 1
illustrates the overall architecture of the RUP. The life cycle
aspects of the process in terms of iterations/phases, and the
logical group activities by nature are represented on X and Y
axes, respectively.
IEEE Kharagpur Section & IEEE Sri Lanka Section
978-1-4244-2806-9/08/$25.00© 2008 IEEE
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY BOMBAY. Downloaded on June 5, 2009 at 02:58 from IEEE Xplore. Restrictions apply.
1
2008 IEEE Region 10 Colloquium and the Third ICIIS, Kharagpur, INDIA December 8-10.
PAPER IDENTIFICATION NUMBER: 520
Fig. 1. Rational Unified Process (Source: IBM Corporation)
For effective offshore facility, key activities are being
carried out from the Elaboration iteration (X+1), while
Construction (X) will be carried out simultaneously.
The
(X+1)th iteration of Elaboration phase will be carried out onsite
and the X iteration of Construction will be carried out at the
offshore site. After completion of the construction iteration X,
the Transition phase will be initiated. During the Transition
phase, Integration System Testing (IST) execution will be
carried out. After the completion of initial iterations of the
Transition phase, (X+1)th iteration of Construction phase would
start. This phase will be followed by (X+1)th iteration of
Transition phase. After completion of planned iterations,
Quality Assurance Test (QAT) will be conducted in an
integrated environment. After meeting the required QAT
criteria, the project will be deployed/ transitioned to
production.
IV.
III.
CUSTOMIZED RUP FOR ONSITE-OFFSHORE MODEL
DELIVERY
As described above, RUP is iterative, use case-based and
architecture driven process, which can be customized for an
organization. Fig. 2 is an operational customization for a
leading bank in North America.
CASE STUDY
This section explains the work done in building the Proofof-Concept of a financial services application.
To narrate the simplified version of the application, the use
case diagram is depicted in Fig. 3. Use cases drive the whole
development process. With the each iteration, use cases drive
the work in analysis, design, implementation and test [7] [8].
This paper addresses only the requirements phase and the
testing phase as the project is completely developed and
currently in production.
Fig. 2. Customized RUP
Four phases in the following order are defined for a project
lifecycle as follows:
•
Inception: the beginning phase of the project with
priorities on achieving concurrence among all
stakeholders on the lifecycle objectives for the
project.
•
Elaboration: focuses on finalizing the system and
software architecture and requirements
•
Construction: building phase of the project that
implements what has been laid out during the
elaboration phase to produce an alpha-tested stable
system.
•
Transition: final phase of the project that makes
the system production ready and prepares the user
community for use.
Fig.3. Use Cases of the application
A. Logical Architecture of Financial Services Application
with Design Patterns
The implementation model of the PoC with proven design
pattern is as follows: The thin-client application users use the
browser to access the financial services application. The
request from the browser passes (over HTTP) to the
978-1-4244-2806-9/08/$25.00© 2008 IEEE
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY BOMBAY. Downloaded on June 5, 2009 at 02:58 from IEEE Xplore. Restrictions apply.
2
2008 IEEE Region 10 Colloquium and the Third ICIIS, Kharagpur, INDIA December 8-10.
PAPER IDENTIFICATION NUMBER: 520
presentation layer which implements the MVC design pattern.
The industry wide proven open source framework ‘Struts’ is
used to realize the presentation layer. The business layer
implements business processes for different modules as Java
Objects and Enterprise Java Beans (EJB) encapsulate the
business logic. The Data Layer implements the Data Access
Object (DAO) pattern. The data access components
encapsulate the data sources from the business layer as shown
in Fig. 4.
Components and frameworks selected for J2EE version of
PoC are provided in Table 1.
TABLE 1. J2EE SELECTION
Layer
Technology
Options
Presentation
Jakarta
Struts 1.2
Business
Data
Enterprise Java Beans (EJB)
and POJOs
Hibernate
SD modules) over three cycles/builds with RUP
implementation. Results obtained from the PoC for the EFT
module from RUP implementation show the number of defects
as being significantly reduced in incremental cycles, based on
the data collected from the defect consolidation log as shown in
Table 3.
VI.
QUANTITATIVE RELIABILITY PREDICTION USING PETRI
NETS
A. Introduction
Petri nets [9] are found to be powerful in modelling
performance and dependability of computer and
communications systems. Formally, a Petri net (PN) is a 5
tuple PN = (P, T, A, M, µ0) where
P is a finite of places (drawn as a circle)
T is a finite set of transitions (drawn as bars)
A is a set of arcs connecting.
M is a multiplicity associated with the arcs in A
µ0 is the marking that denotes the number of tokens for
each place in c
Execution of a Petri Net is controlled by the multiplicity
associated with the arc and distribution of tokens in the Petri
net. By changing distribution of tokens in places, which may
reflect the occurrence of events or execution of operations,
Petri net executes by firing transitions.
B. Application to the Case Study
Simulation for the quantitative analysis of software
reliability is done by using TIME NET 4.0 [10]. Among all the
phases in every module of the application mentioned earlier,
parallelism exists. This paper focuses on the EFT module
whose reliability is found out for each of its cycles. Table 2(a)
and 2(b) are formed based on the practical data available for
the EFT module. The total defects found and the total defects
repaired are entirely random processes. Assuming underlying
exponential distribution:
Fig. 4. Logical Architecture of financial Services application with Design
Patterns
The application is developed in Java/J2EE running on
Windows XP server with Oracle 9i database. The IBM HTTP
server, IBM Web Sphere application server and the Oracle
database are on different systems with clustering. The
clustering mechanism is chosen to demonstrate the fail-over in
the event that any Web Sphere application server is down.
Failure rate = total no of defects found/total time spent on
review/testing
Repair rate = total no of defects repair/total time spent for
rework
MTTF = 1/ Failure rate; MTTR = 1/ Repair rate
Notations:
P0, P1, T0 and T1 are the Requirements up state, down
state, failure rate and repair rate, respectively.
P2, P3, T2 and T3 are the Design up state, down state,
failure rate and repair rate, respectively.
V.
EXPERIMENTAL ANALYSIS WITH RUP IMPLEMENTATION
A detailed experimental metric analysis of the prototype
has been performed on three different modules (EFT, REP and
P4, P5, T4 and T5 are the Coding up state, down state,
failure rate and repair rate, respectively.
978-1-4244-2806-9/08/$25.00© 2008 IEEE
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY BOMBAY. Downloaded on June 5, 2009 at 02:58 from IEEE Xplore. Restrictions apply.
3
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY BOMBAY. Downloaded on June 5, 2009 at 02:58 from IEEE Xplore. Restrictions apply.
EFT
EFT
EFT
EFT
EFT
Total
Coding
Unit Testing
IST Support
EFT
EFT
EFT
EFT
EFT
Total
EFT
EFT
EFT
EFT
EFT
Total
Cycle 3
Requirements
Design
Cycle 2
Requirements
Design
Coding
Unit Testing
IST Support
Cycle 1
Requirements
Design
Coding
Unit Testing
IST Support
Phase
Unit /
Module
9
2
17
4
1
1
1
2
9
25
7
44
2
5
18
75
11
111
Total
Defects
75
10
10
3
15
5
10
15
16
10
10
15
10
75
10
42
30
48
4
25
6
20
30
40
20
20
25
20
150
60
Time
ReSpent on work
Review / Time (
Testing Hrs)
0
0
0
0
1
0
2
0
5
0
0
5
1
20
1
H
4
0
1
0
0
0
0
6
9
1
1
0
11
20
3
M
5
2
3
1
0
1
0
3
11
6
1
0
6
35
7
L
0
0
0
1
1
1
2
0
5
1
1
5
2
25
2
3
4
10
1
4
5
LG CO IF
3
0
7
2
15
5
UI
2
4
9
4
16
15
0
0
1
1
5
1
2
3
3
0
1
1
ST CF DT SY DC OT
No of Defect – by Type
978-1-4244-2806-9/08/$25.00© 2008 IEEE
200Kloc
20Kloc
325 Kloc
190 Pg
180 Pg
160Pg
130Pg
260Kloc
258Kloc
20Kloc
140Pg
100Pg
200Kloc
200Kloc
20Kloc
Size
No. of Defects by Severity
TABLE 3. DEFECT CONSOLIDATION LOG
2008 IEEE Region 10 Colloquium and the Third ICIIS, Kharagpur, INDIA December 8-10.
PAPER IDENTIFICATION NUMBER: 520
1
0
1
1
2
1
1
1
1
1
4
3
3
8
15
9
25
75
2
7
11
RequirIST
Design Coding Testing
ements
Support
No. of Defects – by Phase of Origin .
4
2008 IEEE Region 10 Colloquium and the Third ICIIS, Kharagpur, INDIA December 8-10.
PAPER IDENTIFICATION NUMBER: 520
P6, P7, T6 and T7 are the Unit Testing up state, down state,
failure rate and repair rate, respectively.
P8, P9, T8 and T9 are the IST Support up state, down state,
failure rate and repair rate, respectively.
T10 to T16 are immediate transitions.
P10 and P11 is the EFT module up and down states
respectively.
TABLE2 (A). SUB SET OF DEFECT CONSOLIDATION LOG OF THE ANALYSIS
S.
No
Phases
Cycle 1
1
Requirements
2
Design
3
Coding
4
Unit Testing
5
IST Support
Cycle 2
1
Requirements
2
Design
3
Coding
4
Unit Testing
5
IST Support
Cycle 3
1
Requirements
2
Design
3
Coding
4
Unit Testing
5
IST Support
Unit/
Module
Total
Defects
Review/
Testing
time (hr)
Rework
Time
(hr)
EFT
EFT
EFT
EFT
EFT
2
5
18
75
11
10
15
10
75
10
20
15
20
150
60
EFT
EFT
EFT
EFT
EFT
1
2
9
25
7
5
10
15
16
10
6
20
30
40
20
EFT
EFT
EFT
EFT
EFT
1
1
4
9
2
3
15
10
75
10
4
25
48
42
30
TABLE 2(B). EXTENSION OF TABLE 2(A)
S. No
Cycle 1
1
2
3
4
5
Cycle 2
1
2
3
4
5
Cycle 3
1
2
3
4
5
Phases
Failure
Rate
Repair
Rate
MTTF
MTTR
Requirements
Design
Coding
Unit Testing
IST Support
0.2
0.3333
1.8
1
1.1
0.1
0.3333
0.9
0.5
0.1833
5
3
0.555
1
0.909
10
3
1.1111
2
5.4545
Requirements
Design
Coding
Unit Testing
IST Support
0.2
0.2
0.6
1.5625
0.7
0.1666
0.1
0.3
0.6255
0.35
5
5
1.666
0.64
1.428
6
10
3.3333
1.6
2.8571
Requirements
Design
Coding
Unit Testing
IST Support
0.3333
0.0666
0.4
0.12
0.2
0.25
0.04
0.08333
0.2142
0.0666
3
15
2.5
8.333
5
4
25
12
4.6666
15
The present module is a Reparability model [11] of
Generalized Stochastic. This model is applicable for each phase
having independent repair facilities only.
All the transition values required for the model are
tabulated in Table 4, a derivative of Tables 2(a) & 2(b). The
entire operation is based on the concept of transition firing.
Inhibitor arcs are not shown (to disable failure transitions after
system failure) for the sake of clarity, but are present in the
model. In the model without repair, the flow of tokens is l-way,
keeping the net simple. However, when repair is introduced,
the flow of tokens is 2-way, which requires more output arcs
and inhibitor arcs in the mesh of immediate transitions and
places.
The EFT module fails if Requirements fails AND Design
fails AND Coding fails AND Unit Testing fails AND IST
Support fails. There will be a token in place P10. After repair,
if the above condition does not hold well, then tokens must be
removed from place P10.
These conditions are complementary to the conditions
which lead to the deposit of a token in place P10, since AND
becomes OR and vice-versa. There is a need to introduce a
complementary mirrored subnet to appropriately remove the
tokens from the places. The complementary subnet modelling
of these conditions is enclosed in the solid rectangular boxes in
Figures 5, 6 and 7. The left most immediate transition T16 in
these boxes has no output place i.e., the tokens disappear when
this transition fires.
TABLE 4. TRANSITION TABLE OF CYCLE 1, 2 &3 FOR EFT
Transition
Rates
Cycle1
Cycle2
Cycle3
T0
T1
0.2
0.2
0.3333
0.1
0.1667
0.25
T2
T3
0.333
0.2
0.06066
0.333
0.1
0.04
T4
1.8
0.6
0.4
T5
0.9
0.3
0.0833
T6
1.0
1.5625
0.12
T7
0.5
0.625
0.2142
T8
1.1
0.7
0.2
T9
0.1833
0.35
0.0666
VII. DISCUSSION FOR PETRINETS ANALYSIS OF
RELIABILITY PREDICTION
The case study application discussed consists of three major
modules namely EFT, REP, and SD modules. In this paper,
software reliability prediction and experimental testing has
been carried only on the EFT module over three cycles/builds
with simulations using Petri nets and RUP implementation.
The results obtained from early software reliability prediction
using petri nets have been considered prior to the actual
implementation of the application development. Table 5
provides the total defects from the RUP implemented
prototype and the simulation results from petri nets.
978-1-4244-2806-9/08/$25.00© 2008 IEEE
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY BOMBAY. Downloaded on June 5, 2009 at 02:58 from IEEE Xplore. Restrictions apply.
5
2008 IEEE Region 10 Colloquium and the Third ICIIS, Kharagpur, INDIA December 8-10.
PAPER IDENTIFICATION NUMBER: 520
TABLE 5. SIMULATION RESULTS FOR EFT MODULE
EFT
Module
Cycle1
Total
Defects
111
%Reliability
%Unreliability
84.12711
15.87289
Cycle2
44
88.45584
11.54416
Cycle3
17
92.04223
7.957777
VIII. CONCLUSIONS
Fig. 5 Petri net model of cycle 1 for EFT module
Based on the work that has been carried out by the team
and the obtained results, it is recommended to use RUP with
careful customization so as to have a significant impact on
productivity. In the inception phase of initial iterations, the
productivity is low, but will improve in the subsequent
iterations. In onsite-offshore model, it is recommended to have
similar infrastructure to adopt the process efficiently with
minimal/no dependency. This process also minimizes the risk
as the dependent components would be addressed in the initial
phases.
Usage of Petri nets acts as a conclusive weighing factor in
deciding upon the taking up of actual project implementation.
In effect, a feasibility study has been conducted, which acts as
a significant pointer towards the capture of quantitative
reliability well before the beginning of the project.
Based on results, quantitative analysis for the reliability
estimation of the application development based on the output
results of the prototype development using RUP with, the
reliability is found to be significantly increased in incremental
cycles.
REFERENCES
[1]
Fig. 6. Petri net model of cycle 2 for EFT module
Fig. 7. Petri net model of cycle 3 for EFT module
The simulation results are shown in Table 5 as below:
P. Iyengar , Application Development Is More Global than Ever,
publication G00124025,Gartner,(2004);
www.gartner.com/resources
/124000/124025/application_dev.pdf
[2] K. Krishna Mohan, A. Srividya, Ravikumar Gedela, “Quality of Service
Prediction Using Fuzzy Logic and RUP Implementation for Process
Oriented Development”, International Journal of Reliability, Quality and
Safety Engineering (IJRQSE), USA, World Scientific Publishers, and
Vol: 15, Issue No.2, pp. 143 – 157, 2008.
[3] Hakan Erdogmus, National Research Council Canada, The Economic
Impact of Learning and Flexibility on Process Decisions, IEEE software,
Vol.22, Issue6, 2005 pp 76-83.
[4] D.Sotirovski, "Heuristics for iterative software development", IEEE
Software, Vol.18 Issue3, 2001, pp.66-73.
[5] Rational Unified Process: http://www.ibm.com
[6] P. Kruchten, the Rational Unified Process: An Introduction, 2e.
Addison-Wesley-Longman, (2000)
[7] Hans Westerheim, Geir Kjetil Hanssen: The Introduction and Use of a
Tailored Unified Process, IEEE Software, pp. 196-203, 2005.
[8] Ivar Jacobson, Shaping Software Development, IEEE Software,
Vol.19,Issue3, pp 93-95, 2002.
[9] Kishore Shridharbhai Trivedi, ” Probability and Statistics with
Reliability, Queuing, and Computer Science Applications”, A WileyInterscience Publication, second edition,2002.
[10] http://pdv.cs.tu-berlin.de/~timenet/
[11] Trivedi, Malhotra, “Dependability modelling using Petri nets” IEEE
Transactions on Reliability Vol.44 Issue3, 1995.
978-1-4244-2806-9/08/$25.00© 2008 IEEE
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY BOMBAY. Downloaded on June 5, 2009 at 02:58 from IEEE Xplore. Restrictions apply.
6