Early Quantitative Software Reliability Prediction Using Petri-nets

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

[email protected]

[email protected], [email protected], [email protected], [email protected] 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


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


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


3


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


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


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


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


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


6