Reliability study and analysis on open source enterprise resource planning software package

R.V. College of Engineering

Department of industrial engineering and management Page 1

R.V. COLLEGE OF ENGINEERING, BANGALORE-560059 (Autonomous Institution Affiliated to VTU, Belgaum)

Reliability Study and Analysis on Open Source Enterprise Resource

Planning Software Package

MINI PROJECT REPORT

Submitted by

Under the Guidance of

Mr. Vikram Bahadurdesai Asst. Professor,

IEM Department, R.V. College of Engineering,

Bangalore 560059.

In Partial fulfilment of the academic requirements of VI Semester B.E

Programme in Industrial Engineering and Management

2011-12

Mayank Baheti 1RV09IM024 Deepak Rathod 1RV09IM009

Suraj Soni 1RV09IM044

Tanay Agrawal 1RV09IM046



Sl.No Topic Page. No

Abstract i.

1. Introduction 7

1.1. Overview to Software Reliability 7

1.2

1.3.

1.3.1.

Overview of Open Source ERP Software

Principles of open source architecture

Introduction to open source architecture

7

8

8

1.3.2.

Overview Apache open for business (Ofbiz) 9

1.3.3. Features of Apache open for business(Ofbiz) 10

1.3.4.

1.4.

Different Open Source ERP Software’s

Literature Review

10

13

1.5. Problem Genesis 15

1.6.

2.

2.1.

Objectives

Theoretical Concepts and fundamentals

Software reliability modeling

16

17

18



2.2.

2.3.

2.4.

Software reliability modeling classification

Theoretical Comparison of Techniques

Exponential Model

19

21

23

3. Methodology 25

3.1. Study of Ofbiz ERP software package 25

3.2. Develop Operational Profile 25

3.3. Testing 25

3.3.1.

Performance testing on different operating systems 25

3.3.2.

Performance testing on different web browsers 26

3.4. Data Collection 28

3.4.1. Performance testing of different modules of Ofbiz on

different Web browsers.

29

3.4.2. Functionality Testing 35

3.4.3. Test cases 36

3.4.4. Ofbiz Defect Tracker 39



3.5. Data analysis 46

4. Conclusions 56

5. Future Scope 57

References



Abstract Software reliability turns out to be most important part of business today,

which plays an important role in assuring the quality of software systems. Software

reliability is built in a system by performing exhaustive testing. Testing is an

important phase in software development lifecycle and is generally considered to

be costly and tedious. But it is very much essential to ensure the quality of the

product. The ideal goal of most of the companies is to develop robust software by

testing it cost-effectively. Robustness should be inherently developed along with

product development rather than incorporating it after the implementation phase.

The idea is to test early and to test often.

Software reliability is the probability of failure free software operation for a

specified period of time in a specified environment. The high complexity of the

software is the major contributing factor of software reliability problems. Software

reliability is also important factor affecting system reliability. Software reliability

is an important attribute of software quality, together with functionality, usability,

performance, serviceability, capability, install ability, maintainability and

documentation. Software reliability engineering (SRE) is an emerging discipline,

SRE is the application of statistical techniques to specify, predict, estimate and

assess the reliability of software based systems.

Testing open source apache Ofbiz ERP software gives as opportunity to have

inferences such as reliability, mean time to failure (MTTF) etc, for software system

and gain its credibility in this field. Software Testing is process of executing a

program with the intent of finding error. A good test case is one that uncovers an as

yet undiscovered error. Testing should systematically uncover different classes of

errors in a minimum amount of time and with a minimum amount of effort.

Generating test sequences from usage probability distributions, assessing statistical

inferences based on analytical results associated with test process and also derive



stopping criterion of test process. But the problem associated in this process is to

test the software behavior in different types of environment and measuring the

reliability.

The purpose of testing can be quality assurance, verification and validation, or

reliability estimation. Software testing is a trade-off between budget, time and

quality. To predict reliability of software failure data need to be collected during

testing phase of the software developmental life cycle. So software testing plays a

crucial role in estimating the reliability of software system. In this work, Ofbiz

ERP software package is tested for its performance on different operating systems

and on different web browsers. Finally functionality test has been conducted by

generating test cases. This result in identifying different bugs, using work around

methods bugs has been fixed. Our experimental efforts lead us to a more practical

and effective approach for software reliability.



1.0 INTRODUCTION

1.1 Overview of Software Reliability

Software reliability is one of the major software quality attributes, which quantitatively expresses

the continuity of correct service delivery. Reliability models are typically measurement based

models, and mostly employed in isolation at the later stage of the software development process.

In current practice, early software reliability prediction models are often insufficiently formal to

be analyzable and not usually connected to the target system. Additionally, despite the vast work

that has been done in software reliability, much work is still needed, especially in the

component-based development arena regarding availability of software component reliability

information following a clear failure classification scheme. Aiming at addressing these problems,

this work contributes a novel reliability prediction technique that leverages reliability analysis in

early stages of software development by taking into account, the component structure exhibited

in the scenarios elicited in the requirements phase and the concurrent nature of component-based

systems. Following that contribution, this thesis proposes a means to accomplish reliability

design and analysis for model driven engineering following the Model Driven Architecture

standards. By doing that, this research work contributes to the task of systematically integrating

reliability modeling from the early to the late stages of software engineering and thus

semantically integrating analysis, design and deployment models for reliability into one

environment. Open Source Software adoption in large companies is considered to be a relatively

recent movement. Open Source Software is gaining terrain in large organizations, some see it as

just another development alternative; others see in it a strategic competitive advantage. In spite

of those interests and efforts, techniques available to validate a design against nonfunctional

properties, particularly reliability, often require significant expertise unrelated to the usual

business of engineering software. As reliability measures quantitatively the quality of correct

service delivery, it is probably the most important characteristic for the software engineering

discipline

1.2 Overview of Enterprise Resource Planning (ERP)

An ERP system is fully integrated business management system covering function area of an

enterprise like logistics, finance, accounting, production and human resource. It organize and

integrates operation process and information flow to make an optimum use of resources such as



men, material, money and machine. ERP is global, tightly integrated close loop business solution

package and it’s multifaceted.

ERP promises one database, one application and one user interface for entire enterprise, where

once disparate system ruled, manufacturing, distribution, finance and sales. Taking information

from every function, it is a tool that assists employee and manager plan, monitor and control the

entire business. A modern ERP system enhance a manufacturing ability to accurately schedule

production, fully utilize capacity, reduce inventory and meet promised shipping dates.

Fig1.1:- General Model of ERP

1.3 Principles of Open Source Architecture

1.3.1 Introduction

Open Source Software (OSS) in general refers to any software whose source code is freely

available for distribution. The success and benefits of OSS can be attributed to many factors such

as code modification by any party as the needs arise, promotion of software reliability and



quality due to peer review and collaboration among many volunteer programmers from different

organizations, and the fact that the knowledge-base is not bound to a particular organization,

which allows for faster development and the likelihood of the software to be available for

different platforms.

Characteristics of OSS: It is generally acquired freely. Manufacturer or developer has no right

to claim royalties on the distribution or use. Source code is accessible to the user and distributed

with the software. No denial to an individual or to a group to access source code of the software.

It has provision of modifications and derivations under the programme’s original name. Rights of

facilities attached to the programme must not depend on the programme’s being part of a

particular software distribution. Licensed software can not place restriction on other software

that is distributed with it. Distribution of License should not be specific to a product and License

should be technology neutral, etc.

1.3.2 Overview of Apache Open for Business (OFBiz)

Apache OFBiz (The Apache Open For Business Project) is a community-driven open source

project. For many organizations, OFBiz is also the best e-commerce and enterprise resource

planning (ERP) software available.

1. No Licensing Fees: OFBiz is free and open source.

2. Credibility: OFBiz users can rely on the organizational, legal, and financial stability that

comes with OFBiz being a top-level project at the Apache Software Foundation (ASF).

3. Collaboration: OFBiz is licensed under the Apache 2.0 open source license, which is both

open and business-friendly, facilitating community-driven, meritocratic collaboration while

allowing proprietary derivative applications.

4. Flexibility: Users will have complete access to source code it will eliminate "proprietary

system" limitations. The entire open source community benefits from making OFBiz as clear,

flexible, and reusable as possible.

5. Lower Cost: OFBiz can help user to achieve a system that is as good or better than those

available from major proprietary ERP vendors at a significantly lower total project cost. With

OFBiz, user can budget for custom features and added value rather than license and

maintenance fees.

6. Scalability: Based on the Java platform, OFBiz has the capacity to scale dramatically as

needed.



7. Third Party Friendly: Enjoy freedom from indefinite vendor lock; with OFBiz, user can fully

leverage internal resources and/or any of the dozens of organizations offering quality OFBiz

implementation and support services.

8. Frequent Updates: Benefit from the active and ongoing contributions of the world-wide

OFBiz community.

9. Feature Rich: Leverage standards-based tools and components are attractive to user

technology staff, yet already integrated into a common framework.

10. Expert Leadership and Support: HotWax Media provides system design, project planning and

management, along with robust technical muscle to deliver the implementation and support

necessary for user’s business.

1.3.3 Features of Apache Open for Business (OFBiz)

Apache OFBiz applications and brief descriptions

Table 1.1: OFBiz applications

Accounting

Manager

Setup your chart of accounts, manage agreements, billing, invoices,

payments, and more.

Catalog Manager Create catalogs and populate products by categories. Maintain product

features, price rules, promotions, subscriptions, reviews, and more.

Content Manager Underlying CMS capability that can be customized to manage website

content, blogs, surveys, and more.

Facility Manager Pick, pack, and ship while maintaining inventory information.

Manufacturing

Manager

MRP, job shop, routing and routing task screens, and BOM screens.

Marketing

Manager

Maintaining mailing lists, manage online marketing campaigns that are

fully integrated with e-commerce.

Order Manager Manage purchase and sales orders, create orders, handle returns

Party Manager Create individuals and groups, manage roles.

Web tools

Application

Track site traffic and related performance metrics.

Work Effort

Manager

Events, calendar, project management, and more ready to be customized

to meet your specific needs.

1.3.4 Different Open Source ERP Software’s

Enterprise Resource Planning (ERP) is most crucial for a business and they really help business

to streamline multisite environment with unified processes across locations. There are so many



proprietary and commercial ERP solutions available like, SAP, Microsoft Dynamics, Oracle e-

Business etc. But, very few know that there is a plethora of Free or Low Cost Open Source

solutions that are extremely competent as well as with proper customer support just like the

proprietary ones. Here is a list of 12 such Open Source ERP/CRM solutions that are either cross

platform or browser/web based so that the solutions run on any platforms. All of them have Free

versions available without support and some of them offer paid support as optional.

a. Compiere: Compiere is a Comprehensive, Adaptable and Low Cost ERP (Java based)

solution. Over 1.35 million downloads indicate the proven ERP package. Compiere has

support for Cloud Infrastructure, Integration with Sales force and much more. Automate

all your business services functions, improve efficiency and customer satisfaction, easy

quick customizations, high quality but with low cost ERP suit that will give other

competitors a run.

b. PostBooks: PostBooks is a full-featured, fully-integrated accounting, ERP, and CRM

system, based on the award winning xTuple ERP Suite. Built with the open source

PostgreSQL database and the open source Qt framework for C++, it provides the ultimate

in power and flexibility for a range of businesses and industries.

c. Open taps: Open taps is a full-featured ERP and CRM suite which incorporates several

open source projects, including Apache Geronimo, Tomcat, and OFBiz for the data

model and transaction framework; Pentaho and Jasper Reports for business intelligence;

Funambol for mobile device and Outlook integration; and the Open taps applications

which provide user-driven applications for CRM, accounting and finance, warehouse and

manufacturing, and purchasing and supply chain management.

d. Adempiere: A Java based ERP-System which started as a fork of Compiere, supports a

lot of features. A fully fledged ERP, CRM and Supply chain management, Point of Sale

suit.

e. WebERP: webERP is a complete web based accounting/ERP system that requires only a

web-browser and pdf reader to use. It has a wide range of features suitable for many

businesses particularly distributed businesses in wholesale and distribution. It is

developed as an open-source application and is available as a free download to use. The

feature set is continually expanding as new businesses and developers adopt it.

http://en.wikipedia.org/wiki/SAP_AG

http://en.wikipedia.org/wiki/Microsoft_Dynamics_AX

http://en.wikipedia.org/wiki/Oracle_e-Business_Suite

http://en.wikipedia.org/wiki/Oracle_e-Business_Suite

http://open-tube.com/salesforce-ready-to-take-on-microsoft/



f. BlueERP: BlueERP is a double entry accounting application for small and medium

business. Written in PHP, it is delivered through a LAMP environment to provide web

access to your accounts.

g. Dolibarr: Dolibarr is an ERP/CRM for small and medium companies but also

independent or foundations. Dolibarr success is probably due to the 3 simple rules

applied on project since the beginning: Easy to install, Easy to use, Easy to develop.

Supports lot of features like Supply chain management, proposal management, order

management, payment management and much more.

h. ERP5: A full featured high end open source ERP designed for better business process,

collaboration and leaner management.

i. JFire: JFire is a new, powerful and free ERP, CRM, eBusiness and SCM /SRM solution

for business enterprises. JFire is entirely free/open-source software, uses the latest Java

technologies (EJB 3, JDO 2, Eclipse RCP 3.3) and is designed to be highly customizable.

It is a complete and extensible solution that fulfills all your business needs like user

management, online trade with business partners, points of sale, various distribution

channels forming a distribution network, store management etc.

j. OpenERP: OpenERP is open source ERP suit that supports Enterprise modules,

Logistics, Accounting and Finance, HRM, CRM, Project Management, Business Process

and more. It is complete package with commercial version available.

k. Apache OFBiz: The Apache Open for Business Project is an open source enterprise

automation software project licensed under the Apache License Version 2.0. As per

OFBiz, Open Source enterprise automation means: Open Source ERP, Open Source

CRM, Open Source E-Business / E-Commerce, Open Source SCM, Open Source MRP,

Open Source CMMS/EAM, and so on.

l. OpenBravo: OpenBravo is a web based ERP solution originally was based on Compeiere

which is also Open Source. It supports standard ERP features like production

information, inventory, customer information, order tracking, and workflow information.

http://en.wikipedia.org/wiki/Supply_chain_management

http://en.wikipedia.org/wiki/Supplier_relationship_management

http://java.sun.com/products/ejb/

http://java.sun.com/products/jdo/index.jsp

http://wiki.eclipse.org/index.php/Rich_Client_Platform



1.4. Literature Review

Parijat Upadhyay et al. made an effort to explore and elaborate the issues in the implementation

and reliability of ERP software small and medium scale enterprise (SMEs) with the help of

Pareto Analysis since the functionality used at SMEs is not the same as in large scales, hence

sacrificing the modules is the secret behind successful implementation of ERP and hence the

reliability. [1]

Poonam Garg et.al. explains the reasons for failure in implementation of ERP packages in Indian

Retail Organizations. The major roadblocks in the implementation of ERP are inadequate

resources and poor involvement of end user. ERP is more of a people project then an IT project

which cannot be reliably implemented unless there is proper involvement and input by the end

user. [2]

Mark C. Van Pul et.al. have provided a general overview of theories and processes that is

followed to check the reliabilities of a software package. With the help of intensive case studies

and mathematical formulas of reliability, it comprehends the fact that no software is complete

and even a zillion dollar satellite has bugs. [3]

Krešimir Fertalj et al. presented the optimal selection of input parameters that should be done in

Software Reliability Growth Model (SRGM). In this particular paper, Weibull model is used to

test the reliability of existing installed ERP software and for its further modification. The study

elaborates the steps that should be taken by an end user to check the reliability and to predict the

trend of the ERP product during its usage. Measurement based analysis represents a good

foundation for the future work in modelling of ERP software. [4]

F. Urem et.al. attempted to model the probability of bugs in the ERP software after completely

upgrading it. The method used is Weibull probability density function (PDF). The up gradation

of ERP software, which is a necessity, evolves the complexity of the software and hence induces

probability of increasing the bugs unless regular work is done to reduce and maintain it. [5]



Chin-Yu Huang et al. studied the testing effort and the efficience on the modeling of software

reliability. The cost of optimal release of the software was another area studied by the author.

Testing efficience and the efforts made in testing were the presentation made by the author. [6]

Kristine B. Walhovd studied about the sample on which reliability testing for ERP measures

were performed comprised of age groups from 21 years to 92 years. The amplitude measures

were more reliable at all electrodes as compared to latency measures. The test was done by

dividing young and adult age groups into T1 and T2 with a separation of 12-14 months. [7]

Sally Wright et al. revealed an understanding of the risks of enterprise resource planning

systems (ERP) for consideration in providing information systems assurance services. Increase in

the potential for control weaknesses and resulting financial statement errors, inaccurate internal

information due to reengineering techniques and customization efforts are explored in the above

studies. [8]

Yoshinobu Tamura et al. created a fusion of neutral network and software reliability growth

model. The author has presented new approach of software reliability growth model. Numerous

cases and examples have been quoted to analyze the actual fault count. Then, for open source

software the efficiency have been considered in the mention paper. [9]

Wangbong Lee et al. They presented as an approach to software reliability assessment of OSS

adopted software system in the early stage. It shows the inadequacy of the conventional

reliability models to test the reliability of an OSS (Open source software) as OSS can be

modified but the COTS (Commercial off The-Shelf) cannot. [10]

Swapna S. Gokhale et al. A conventional approach followed in the reliability testing of software

is Black Box in which a system is considered as a whole. It is modulated on the basis of

interaction with outside world which seems to neglect the inner structure, predicting the

reliability of a software system based on its architecture, and the failure behavior of its

components, is thus essential. This paper proposes a unifying framework for state-based models

for architecture-based software reliability prediction. [11]



Xiaolin Teng et al. The authors have presented a new methodology for predicting software

reliability in the field environment. Their work differs from some existing models that assume a

constant failure detection rate for software testing and field operation environments, as this new

methodology considers the random environmental effects on software reliability. This new

methodology provides a viable way to model the user environments, and further makes

adjustments to the reliability prediction for similar software products. Based on the generalized

software reliability model, further work may include the development of software cost models

and the optimum software release policies under random field environments. [12]

Table 1.2: Benchmark Reliability Models

Models Proposed by Year Type

J-M-Model[19] Z. Jelinski Paul and B. Moranda 1972 Binomial

G-O-Model[18] Amrit Goel and Kazu Okumoto 1979 Poisson

Execution Time Model[20] John Musa 1975

Hyper Exponential Model[21] Ohba 1984

Weibull Model[22] Weibull 1983 Binomial

S-Shape Model[23] S. Yamada, M. Ohba, and S.Osaki 1983 Gamma

Duane Model[18] J.T Duane 1964

Geometric Model[24] Paul B. Moranda 1979 Binomial

Logarithmic Poisson Model[25] Musa –Okumoto 1984 Poisson

LV Reliability Growth Model[26] A. Ghaly, P. Chan, & B. Littlewood 1986 Gamma

1.5 Problem Genesis

There is currently a need for a creditable end-to-end software reliability model that can be

directly linked to reliability prediction from the very beginning (i.e. software design), so as to

establish a systematic SRE procedure that can be certified, generalized and refined. The cost of

correcting a software error generally increases by magnitudes for every phase of the life cycle.

Ideally most of the errors are detected by the end of the unit testing phase. Ideally, the errors

found during the integration phase are those due to interfaces that could not have been easily or

possibly found during previous phases. Ideally the number of errors detected levels off by the

acceptance test phase. If it is known what the average cost of fixing a bug is during each phase of

the life cycle, it can be estimated what the cost of repair is and also what it could be. If the



average cost is not known, then the relative cost may be found by comparing real errors detected

over time against the ideal. Although, there has been an extensive research work being conducted

in the area of software reliability, but there is extremely less work being focused on open source

software, especially of Enterprise Resource Planning type, which the current business has high

demands. According literature survey many of the previous works on software reliability have

used secondary data source for carrying out their research. There is lot of scope for researchers to

use primary data source and conduct reliability analysis on open source Enterprise resource

planning software. Hence, this poses a high research gap in the area of open source ERP

applications in terms of software reliability.

1.6 Objectives

To study on open source ERP software package and understand various business

processes.

To study different parameters that affects the reliability of an open source ERP software.

To perform black box testing and identify bugs in open source ERP software packages.

To improve precision of estimation of software architect reliability of ERP system of

manufacturing.



2.0 THEORETICAL CONCEPTS AND FUNDAMENTALS

The Institute of Electrical and Electronic Engineers (IEEE) defines software reliability as the

probability that software will not cause a system failure for a specified time under specified

conditions. The probability is a function of the existence of faults in the software. The inputs to

the system determine whether existing faults, if any, are encountered. John Musa of AT&T Bell

Laboratories defines software reliability as the probability that a given software system operates

for some time period without software error, on the machine for which it was designed, given

that it is used within design limits. The measurement and analysis techniques include software

metrics, software reliability models, and software analyses such as fault trees and failure modes

effects and critically (FMECA). Software metrics are measures of some aspect of the software

product or process itself. Software reliability models, for the most part, model the failures

occurring because of the software. Software analysis enables development personnel to find

errors in the software while the software is still in a laboratory environment.

There are at least four major reasons why reliable software has become a very important issue in

the last decade or so.

1. Systems are becoming software intensive. Mainly flight systems are becoming more

software intensive than hardware intensive. Financial systems including teller, automated

teller, and loan processing are software intensive. Defense and energy systems are

becoming more software intensive. Everything from insurance rates to credit histories to

hotel reservations to long-distance telephone calls is performed by software. Software

affects our daily lives.

2. Many software-intensive systems are safety critical. Flight systems, electronic warfare

systems, radar, air traffic control, medical systems, energy systems, and space systems

are all software-intensive systems that are also safety critical. Even systems that are not

safety critical may be mission critical, meaning that success is critical to some end

purpose (such as defeating an enemy at war), or failure is extremely costly financially.

3. Customers are requiring more reliable software. Many government contracts are now

requiring that an established level of software reliability be achieved. Software has also

become part of the system reliability allocations on many government contracts.

Commercial clients are also requiring more reliable systems, and many are attempting to



establish the same criteria as the government for developing of reliable software. At one

time, software reliability was assumed to be 1 for purposes of determining system

reliability. Those days are behind us.

4. Software errors are not being tolerated by end users or by clients of end users. Financial

institutions, medical institutions, the government, communication corporations, and other

corporations are in a position of being legally liable for software that is not accurate, that

causes potential loss of life or loss of mission, that causes inconvenience to end users,

and that causes end users to lose profits. In addition to being liable, users and developers

of software are also facing increasing maintenance costs.

5. The cost of developing software is increasing. Data from a variety of sources show that

for many systems developing the software is becoming one of the major costs of the

system, if not the major cost. Much of the software cost can be associated with corrective

action, particularly corrective action late in the development cycle. The cost of

maintaining software has been shown in some studies to be as much as 40-70% of the

total development cost. Some NASA and Air Forces have estimated it to be 50% of their

development cost.

2.1 Software Reliability Modeling

A software reliability model specifies the general form of the dependence of the failure process

on the principal factors that affect it: fault introduction, fault removal, and the operational

environment. These models are used to predict how much more time the software needs to be

tested to achieve the desired failure intensity and to predict the expected reliability of the

delivered software. The model parameters may be determined by means of the following:

(1) Estimation: measures the reliability by applying statistical inferences to the collected failure

data. This method validates the goodness of the model by assessing its current reliability.

(2) Prediction: measures the future software reliability using the available software metrics.

The failure data that is used in the reliability models may be of two types:

(1) Failure count data which is expressed as the number of failures in each time interval.

(2) Time between failure data which is expressed as the time interval between consecutive

failures.

One type of input data can be transformed to the other to the alternate models either by using the

cumulative failure data or by using some of the existing reliability tools such as CASRE and



SMERFS. A well defined software reliability model can determine important characteristics of

the failure process by incorporating expressions for the average number of failures experienced

at any point in time, the average number of failures in a time interval, the failure intensity at any

point in time, and the probability distribution of failure intervals. A good software reliability

model, based on sound assumptions, gives better projection of future failure behavior, computes

useful quantities, is simple, and is widely applicable.

2.2 Software Reliability Model Classification

One of the early reliability models, which was based on hardware reliability concepts, was

developed by Duane. In the seventies, many software reliability models were proposed,

developed and widely used. Since then, many different software reliability models have been

developed and numerous researchers in software reliability engineering have attempted to

categorize and classify them. Classify the reliability models in terms of five attributes:

(1)Time domain: either calendar or execution time.

(2)Category: either finite or infinite number of failures. For the finite number of failures category

models, there are a number of classes depending on the functional form of the failure intensity in

terms of time. For infinite failure category models, there are a number of families depending on

the functional form of the failure intensity in term of the expected number of failures

experienced.

(3) Type: the distribution of the number of failures experienced as a function of t.

(4) Class: functional form of the failure intensity expressed in terms of time (for finite failure

category only).

(5) Family: functional form of the failure intensity expressed in terms of the expected number of

failures experienced (for infinte failure category only).

For the sake of simplicity, first separate the finite from the infinite models. Then they incorporate

the five attributes as a guide to finding the relationship between the models; thus clarifying the

comparison between the models. The simplicity of this classification explains its popularity of

usage. Two main categories of software reliability models:

(1) software growth reliability models that estimate reliability using the error history.

(2) statistical models that estimate the reliability using the results (success or failure) of

executing test cases.



The software growth reliability models are classified based on the nature of the failures. The time

between failures models, failure counts models, and fault seeding and input domain based

models. Categorize models into two major types:

(1) Type I : time between successive failures models, which breaks down to failure rate Type I-1

and random function Type I-2.

(2) Type II : the number of failures up to a given time.

Classify reliability models as follows:

(1) Data-domain models: A better reliability estimate can be achieved if all of the combinations

of the inputs are identified and the outcomes are well observed. To implement this theory, this

model category is decomposed into fault-seeding models and input-domain models. (2) Time-

domain models: model the failure process using the failure history to estimate the number of

faults and the required test time to uncover these faults. Homogeneous Markov, non-

homogeneous Markov, semi-Markov are models that belong to the time-domain model. Classify

software reliability according to software development life cycle phases. Their classification is

well defined and comprehensive.

Table 2.1. Software Reliability Growth Model Examples

Model

Name

Model

Type

μ(t) Reference Comments

Goel-Oku

moto (G-O)

Concave a(l-e-bt

)

a 0, b>O

Goel,79 Also called Musa model or

exponential model

G-OS-

Shaped

S-Shaped a( 1-(1+bt)e-bt

)

a 0, b>O

Yamada,83 Modification of G-O model to

make it S-shaped (Gamma

function instead of

exponential)

Hossain-

Dahiya/G-

O

Concave a( l-e-bt

)/(1+ce-bt

)

a 0, b>O, c>0

Hossain,93 Solves a technical condition

with the G-O model. Becomes

same as G-O as c approaches

O.

Gompertz S-Shaped a(bct)

a 0, 0 b 1, 0<c<1

Kececioglu,,

91

Used by Fujitsu, Numazu

Works

Pareto Concave a(l-(l+t/ )l- Littlewood,

81

Assumes failures have

different failure rates and



a 0, >0, 0 1 failures with highest rates

removed first

Weibull Concave a(l-e-btC

)

a 0, b>0,c>0

Musa,87 Same as G-O for c=1

Yamada

Exponential

Concave a(1-e-r (1-e- t)

)

a 0, r >0, >0

Yamada,86 Attempts to account for testing

effort

Yamada

Raleigh

S-Shaped )1( )1( )2/2( terea

Yamada,86 Attempts to account for testing

effort

Log

Poisson

Infinite

Failure

(l/c)ln(c t+l)

c>O, >O

Musa,87 Failure rate decreases but does

not approach 0

2.3 Theoretical Comparison of Techniques

This section compares the three parameter estimation techniques from a theoretical perspective.

We focus on their ease of use, confidence interval shape, and parameter scalability. Since

optimization packages are readily available, maximum likelihood, classical least squares, and

alternative least squares are all straightforward to solve. However, maximum likelihood only

applies to the G-O model, and a new maximum likelihood equation must be derived for each

software reliability growth model. These equations can be difficult to derive, especially for the

more complex models. Classical least squares applies to the exponential family of models that

includes the G-O model. It is fairly easy to modify this equation for similar models. Alternative

least squares are the easiest to use since it applies to any software reliability growth model, so the

alternative least squares method is the easiest to apply. Confidence intervals for all of the

estimation techniques are based on assuming that estimation errors are normally distributed. For

the maximum likelihood technique, this assumption is good for large sample sizes because of the

asymptotically normal properties of this estimator. However, it is not as good for the smaller

samples that we typically have. Nevertheless, the maximum likelihood technique provides the

best confidence intervals because it requires less normality assumptions and because it provides

asymmetric confidence intervals for the total defect parameter. The lower confidence limit is

larger than the number of experienced defects, and the upper confidence limit is farther from the

point estimate than the lower confidence limit to represent the possibility that there could be

many defects that have gone undetected by testing. Conversely, for the least squares techniques,

the lower confidence limit can be less than the number of experienced defects (which is



obviously impossible), and the confidence interval is symmetric. Also, additional assumptions

pertaining to the normality of the parameters are necessary to derive confidence intervals for the

least squares techniques. The transformation technique consists of multiplying the test time by an

arbitrary (but convenient) constant and multiplying the number of defects observed by a different

arbitrary constant. For this technique to work, the predicted number of total defects must be

unaffected by the test time scaling and must scale the same amount as the defect data. For

example, we may experience 50 total defects during test and want to scale that to 100 for

confidentiality or ease of reporting. To do that transformation, the number of defects reported

each week must be multiplied by 2. If 75 total defects were predicted by a model based on the un

scaled data, then the total defects predicted from the scaled data should be 150.

Reliability growth models are categorized as hardware models and software models.

Hardware models – using for electronics systems, functions blocks, electronics components

without connections to software. Basic terms are a reliability operating state and a failure.

There are two basic types of failures during the development phase – random failures, early

failures.

Software models –using for software.

Probabilistic reliability growth models – because of no unknown parameters associated with

these models, the data obtained during the program cannot be incorporated.

Statistical reliability growth models – unknown parameters are associated with these models.

In addition, these parameters are estimated throughout the development of the product in

question.

Time independent reliability growth models – number of failures or repairs in definite time

interval are not depended on time.

Time dependent reliability growth models – a reliability growth model is function of time.

Continuous reliability growth models – these are time models.

Discrete reliability growth models – these are useful for unrecoverable objects, there are two

discrete states – a reliability operating state or a failure.

Classically reliability growth models – mathematical equipment is theory of probability,

Duane reliability growth model and its modifications – these are continuous, time dependent

and statistical models,



Stochastic reliability growth models – a reliability growth is non-stationary stochastic

process – non-stationary stochastic Poisson process.

Bayes and quasi-Bayes reliability growth models

Unconventional reliability growth models – there are all reliability growth models, for which

is no existing possibility to arrange in classification categories.

2.4. Exponential Models

All software reliability models of the exponential class have a common set of assumptions. In

addition to these common assumptions, each model has its own unique set of assumptions. The

standard assumptions are (Lyu 1995): The software is operated in a similar manner as that for

which reliability predictions are to be made. This assumption is to ensure that the data collected

in that particular environment is applicable to the environment in which the reliability

projections are to be made. Every fault has the same chance of being encountered and is of the

same severity as any other faults. This assumption is to ensure that the various failures all have

the same distributional properties. One severity class might have different failure rates which

may require separate reliability analysis. The failures are independent. A failure occurs when the

faults are encountered, so having independent failures simplifies the maximum likelihood

estimates. Exponential class models have two major types: binomial-type and Poisson-type. In

addition to the common assumptions for the exponential class models, the binomial-type models

assume that the failures are removed from the software as soon as they occur and introduce no

more faults during the fix. The Poisson-type models assume that the faults remaining in the

software is a Poisson random variable. The principal difference between the binomial and

Poisson type models is how the remaining number of faults are treated. Considering equations

(3) and (4), binomial- type models treat the number of remaining faults as a fixed number. While

in the Poisson-type models, the number of remaining faults is treated as random variable (Musa,

Iannino, Okumoto 1987). Jelinski-Moranda, Musa and Schneidewind models are some the

different reliability models. Table 1 summaries the reliability functions for these models.



Table 2.2: Summary of reliability functions for Jelinski-Moranda, Musa and schn. Models

Reliability

Functions

Jelinski-Moranda

Model

Musa’a Model Schneidewind’s

Model

F(t) te 1 t

e 11

/ te 1

f(t) te

t

e

1

te

z(t) 1

t

t

e

e

1/1

)(t N te 1 te 1

0 1 / te 1

)(t Nte

te 1

10

te



3.0 METHODOLOGY

The following methodology is used to identify error data in the Ofbiz ERP software package.

The data collection process is the most critical prerequisites to measuring software reliability.

The effectiveness of any reliability measurement will be directly related to the effectiveness of

collecting the data necessary for measurement.

Study of Ofbiz ERP software package.

Develop operational profile.

Testing

Data analysis

3.1 Study of Ofbiz ERP software package.

The first step in methodology is to thoroughly understand various business processes existing in

Ofbiz ERP software package. It is very much essential to understand various business processes

before the testing of the software. They are various modules available in Ofbiz software such as

catalog manager, bill of materials, purchase module, sales module etc. Key is to understand the

integration of all modules.

3.2 Develop operational profile

An Operational Profile is simply the set of Operations and their probabilities of occurrence. Most

frequently used modules are given more emphasis. More Test cases have to be generated for

those modules which are frequently used. In this work the modules which are identified are

catalog manager, bill of materials, purchase module and sales module.

3.3 Testing

Software testing is an important technique for assessing the quality of software product. Two

basic software testing methods are Black Box testing and White Box testing. In this work the

software is tested using black box testing. Black Box testing includes performance testing and

functionality testing.

3.3.1 Performance testing on different operating systems

The performance test is carried to identify how this Ofbiz ERP software package operates on

different operating systems such as Windows XP, Windows Vista, Windows 7, Ubuntu.



Table 3.1: Evaluations of Ofbiz in OS

Name of Evaluation Evaluation of OFBiz On OS

Object of Evaluation OFBiz running on OS on 3GB RAM

Test Case Used Execution of OFBiz in 64 bit OS

a. Windows XP

b. Windows Vista

c. Windows 7 Home Basic

d. Ubuntu

Actual Output In Execution of OFBiz in bit 64Windows professional OS

a. The performance is better compared to previous

version. But optimum performance varies if RAM is

enhanced.

b. Performance is much better w.r.t installation,

navigation, configuration

c. Same as previous versions of Windows.

d. Performance is much better compared to windows

Remarks Successful performance in windows XP , Vista, 7 and Ubuntu

3.3.2 Performance testing on different web browsers.

After testing the performance of software on different operating systems next step is to test Ofbiz

software performance on different web browsers. Mozilla Firefox, Internet Explorer and Google

Chrome are identified browsers for testing.



Table 3.2: Ofbiz performance for Browser

Name of

Evaluation

Testing OFBiz

performance on Mozilla

Firefox version 13.0

Testing OFBiz

performance on Internet

Explorer 9

Testing OFBiz

performance on Google

Chrome

Object of

Evaluation

Firefox performance with

OFBiz

IE-9.0 performance with

OFBiz

Google Chrome

performance with OFBiz

Test Case

Used

1. Navigation of

pages

2. Cookies

Clearance

3. History Scrutiny

4. Page

Visualization

5. Navigation of

pages

6. Cookies Clearance

7. History Scrutiny

8. Page Visualization

9. Navigation of

pages

10. Cookies Clearance

11. History Scrutiny

12. Page Visualization

Actual

Output

1. Navigation of

Pages are very

smooth

2. Proper cookie

management

3. Proper history and

cache

management

4. The pages are

visually better to

experience

5. Navigation of

Pages are very

smooth

6. Cookies are not

managed properly

7. No proper history

and cache

management

8. The pages are

visually not so

better to

experience as user

9. Navigation of

pages are quite

faster

10. In Google chrome,

incognito window

enables the better

cookies clearance.

11. Better history

management due

to incognito

window.

12. The pages

visualization is

better compare to

internet explorer 9

Remarks Mozilla Firefox seems to

be best compatible with

OFBiz

IE-9.0 seems not to be best

compatible with OFBiz

Google chrome is also

found to be best

compatible browser after

Firefox Mozilla.



3.4 Data collection

Software testing is an important technique for assessing the quality of software product. Two

basic software testing are Black Box testing and White Box testing. Black Box testing includes

performance testing and functionality testing. In performance testing, data is collected on basis

of working of modules in different browsers in single operating system and also in different

operating system.

From the study found that software failure follows exponential distribution, for example suppose

we test to failure a large number of software operation, for each small unit of time, if we

calculate the failure rate and plot the same against time t, the resulting graph is the failure rate

curve.

The value of reliability R(t) is 1 at

t = 0 and it decreases continuously

with time when (t) is large, all the

software will have failed giving

R(t) = 0 at t ∞

It can be proved that in case of

constant failure rate,

R =

λ = constant failure rate

T = mission time.

We conducted experiment on

oFbiz open source software

creating bill of material ,purchase order, sales order and purchase order through MRP run are

some of certain operations which has been frequently used in many organizations. By creating

bill of material and time is noted down, these has been repeated for ten times and tabulated,

average time of ten reading have calculated and standard time has been found, standard time is

sum of average time and 10% of average time. Then based on standard time failure rate (λ) is

calculated, failure rate is number of time creating a bill of material exceeded standard time, same



procedure is been carried to other ERP modules and then the reliability of software in particular

web browser for particular operating system is calculated.

Standard time = Basic average time + (10%* Basic average time)

Failure rate (λ) = No. Of operations exceeds standard time/total no. of trails

3.4.1 Performance testing of different modules of Ofbiz on different Web

browsers.

The important modules which are identified in operational profile stage are being tested on

different web browsers. Time taken to create bill of materials, purchase order, sales order and

purchase order through MRP are noted down for different web browsers.

Readings of 10 trails for different browsers with different operating system for processing time

of different operations shown in below tables :-

Table 3.3: Windows XP –Internet Explorer

Sl.no

Bill of

material

Purchase

order

Sales

order

Purchase order

through

MRP

1 9.3 4.2 4.2 5.6

2 9 4.1 4 5.4

3 8.9 3.8 3.8 5.1

4 8.4 3.7 3.5 4.9

5 8.2 3.5 3.4 4.6

6 8.1 3.4 3.1 4.4

7 7.9 3.2 2.8 4.2

8 7.8 2.9 2.7 4

9 7.7 2.6 2.3 3.9

10 7.7 2.6 2.2 3.9

sum 83 34 32 46

Avg 8.3 3.4 3.2 4.6

Note all readings are in minutes



Table 3.4: Windows XP –Mozilla Firefox

Sl.no

Bill of

material

Purchase

order

Sales

order

Purchase order

through

MRP

1

9.3 4.3 4.3 5.6

2

9 4.2 4.1 5.4

3

8.9 3.9 3.9 5.1

4

8.4 3.8 3.6 4.9

5

8.2 3.6 3.5 4.6

6

8.1 3.5 3.2 4.4

7

7.9 3.3 2.9 4.2

8

7.8 3 2.8 4

9

7.7 2.7 2.4 3.9

10

7.7 2.7 2.3 3.9

sum

83 35 33 46

Avg

8.3 3.5 3.3 4.6

Note all readings are in minutes.

Table 3.5: Windows XP –Google Chrome

Sl.no

Bill of

material

Purchase

order

Sales

order

Purchase order

through

MRP

1 9.2 4.3 4.3 5.5

2 8.9 4.2 4.1 5.3

3 8.8 3.9 3.9 5

4 8.3 3.8 3.6 4.8

5 8.1 3.6 3.5 4.5

6 8 3.5 3.2 4.3

7 7.8 3.3 2.9 4.1

8 7.7 3 2.8 3.9

9 7.6 2.7 2.4 3.8

10 7.6 2.7 2.3 3.8

sum 82 35 33 45

Avg 8.2 3.5 3.3 4.5




Table 3.6: Windows Vista – Internet Explorer

Sl.no

Bill of

material

Purchase

order

Sales

order

Purchase order

through

MRP

1

9.3

4 4.5

5.7

2

9

3.9 4.3

5.6

3

8.7

3.6 4.1

5.4

4

8.6

3.5 3.8

5.1

5

8.5

3.3 3.7

4.8

6

8.3

3.2 3.4

4.6

7

8.2

3 3.1

4.4

8

8.2

2.7 3

4.2

9

8.1

2.4 2.6

4.1

10

8.1

2.4 2.5

4.1

sum

85

32 35

48

Avg

8.5

3.2 3.5

4.8


Table3.7: Windows Vista –Mozilla Firefox

Sl.no

Bill of

material

Purchase

order

Sales

order

Purchase

order through

MRP

1 9.6

4.2 4.6

6

2 9.4

4.1 4.4

5.9

3 9.2

3.8 4.2

5.7

4 8.9

3.7 3.9

5.4

5 8.6

3.5 3.8

5.1

6 8.5

3.4 3.5

4.9

7 8.3

3.2 3.2

4.7

8 8.2

2.9 3.1

4.5

9 8.1

2.6 2.7

4.4

10 8.2

2.6 2.6

4.4

sum 87

34 36

51

Avg 8.7

3.4 3.6

5.1




Table 3.8: Windows Vista –Google Chrome

Sl.no Bill of material

Purchase

order

Sales

order

Purchase

order through

MRP

1 9.6 4.3 4.3 5.9

2 9.3 4.2 4.1 5.8

3 9.2 3.9 3.9 5.6

4 8.7 3.8 3.6 5.2

5 8.5 3.6 3.5 5.1

6 8.4 3.5 3.2 4.8

7 8.2 3.3 2.9 4.7

8 8.1 3 2.8 4.3

9 8 2.7 2.4 4.3

10 8 2.7 2.3 4.3

sum 86 35 33 50

Avg 8.6 3.5 3.3 5


Table 3.9: Windows 7 – Google Chrome.


Purchase

order

Sales

order

Purchase

order

through

MRP

1 9.5 3.8 4.2 5.1

2 9.2 3.7 4 4.8

3 9.1 3.4 3.8 4.7

4 8.6 3.3 3.5 4.6

5 8.4 3.1 3.4 4.4

6 8.3 3 3.1 4.2

7 8.1 2.8 2.8 3.7

8 8 2.5 2.7 3.6

9 7.9 2.2 2.3 3.5

10 7.9 2.2 2.2 3.4

sum 85 30 32 42

Avg 8.5 3 3.2 4.2




Table 3.10: Windows 7 – Mozilla Firefox


Purchase

order

Sales

order

Purchase

order

through

MRP

1 8.9 4.3 4.7 5.4

2 8.7 4.2 4.5 5.1

3 8.6 3.9 4.3 5

4 8.1 3.8 4 4.9

5 7.9 3.6 3.9 4.7

6 7.8 3.5 3.6 4.5

7 7.6 3.3 3.3 4

8 7.5 3 3.2 3.9

9 7.5 2.7 2.8 3.8

10 7.4 2.7 2.7 3.7

sum 80 35 37 45

Avg 8 3.5 3.7 4.5


Table 3.11: Windows 7 – Internet Explorer


Purchase

order

Sales

order

Purchase

order

through

MRP

1 8.5 3.3 3.6 4.3

2 8.3 3.2 3.4 3.8

3 8.3 2.9 3.2 3.7

4 7.7 2.8 2.9 3.6

5 7.5 2.6 2.8 3.4

6 7.4 2.5 2.5 3.3

7 7.2 2.3 2.2 2.7

8 7.1 2 2.1 2.5

9 7.1 1.7 1.7 2.4

10 6.9 1.7 1.6 2.3

sum 76 25 26 32

Avg 7.6 2.5 2.6 3.2




Table 3.12: Ubuntu– Internet Explorer Firefox

Sl.no

Bill of

material Sales order Purchase Order

1 8.2 3.2 3.2

2 8.1 3 3.1

3 8 2.9 2.9

4 7.6 2.7 2.5

5 7.4 2.6 2.5

6 7.2 2.5 2.3

7 7.1 2.1 2.2

8 7 1.9 1.9

9 6.8 1.7 1.7

10 6.6 1.4 1.7

Sum 74 24 24

Avg 7.4 2.4 2.4


Table 3.13:Ubutu– Internet Explorer Firefox

Sl.no

Bill of

material

Sales

order

Purchase

Order

1 8.4

4 3.9

2 8.3

3.8 3.8

3 8.2

3.7 3.6

4 7.8

3.5 3.2

5 7.6

3.4 3.2

6 7.4

3.3 3

7 7.3

2.9 2.9

8 7.2

2.7 2.6

9 7

2.5 2.4

10 6.8

2.2 2.4

Sum 76

32 31

Avg 7.6

3.2 3.1




Table 3.14 : Ubuntu– Internet Explorer Firefox

Sl.no

Bill of

material

Sales

order Purchase Order

1 8.3

3.7 3.7

2 8.2

3.5 3.6

3 8.1

3.4 3.4

4 7.7

3.2 3

5 7.5

3.1 3

6 7.3

3 2.8

7 7.2

2.6 2.7

8 7.1

2.4 2.4

9 6.9

2.2 2.2

10 6.7

1.9 2.2

Sum 75

29 29

Avg 7.5

2.9 2.9


3.4.2 Functionality Testing

Functional testing is a type of black box testing that bases its test cases on the specifications of

the software component under test. Functions are tested by feeding them input and examining the

output, and internal program structure is rarely considered.

Functional testing differs from system testing in that functional testing " a program by checking

it against design document or specification", while system testing " a program by checking it

against the published user or system requirements"

Functional testing typically involves five steps:-

1. The identification of functions that the software is expected to perform

2. The creation of input data based on the function's specifications

3. The determination of output based on the function's specifications

4. The execution of the test case

5. The comparison of actual and expected outputs

http://en.wikipedia.org/wiki/Black_box_testing

http://en.wikipedia.org/wiki/System_testing



3.4.2.1 TEST CASES

Table 3.15: Test cases

Step.

no

Step Description Test Data Actions Expected

Results

Actual

Result

Status

T01 Examine entering

username &

password

Business

12345

Click on

Login

Loged-in Loged-in Pass


correct username

& wrong

password

Business

12366

Click on

Login

Pop-up box Pop-up box Pass


wrong username

& correct

password

Business

12345

Click on

Login



wrong username

& wrong

password

Business

12356

Click on

Login


T05 Ensure after log-in

should go to

homepage

Business

12345

Click on

Login

Open

homepage

Open

homepage

Pass

T06 Check BOM on

screen

Create all

product

give price,

supplier

and

facilities

Click on

BOM

simulation

BOM pdf BOM pdf Pass

T07 Check BOM on

screen

Create

product

Click on

BOM

Should not

show BOM

Should not

show BOM

Pass



Without

giving

facilities

simulation

T08 Examine sales

enquiry

Input

enquiry

number

Click on

supplier

Should

give

supplier

sales

Should give

supplier

sales

Pass

T09 Examine product

detail

Input

product

name/ID

Click on

product

detail

Display

product

detail

Display

product

detail

Pass


same product id &

product name

Id: cap

name: cap

Click on

create

product

Show error

that

duplicate

key arise

Show error

that

duplicate

key arise

Pass


different product

id & product name

Id: cap

name: caps

Click on

create

product

Product

created

Product

created

Pass

T12 Edit product detail Product

detail

Click on

edit

product

Go to edit

screen

Go to edit

screen

Pass

T13 Examine product

ID

Engine

lathe

Click on

create

product


T14 Examine product

ID without space

Engine

_lathe

Click on

create

product

Product

created

Product

created

Pass

T15 Examine product

without internal

name

Without

internal

name

Click on

create

product


T16 Examine product

with internal name

With

internal

Click on

create




name product

T17 Creating suppliers

for subassemblies

without product id

& name

Product

id:__

Product

name:__

Click on

create

Pop-u box Pop-u box Pass

T18 Creating suppliers

for subassemblies

with product id &

name

Product

id:chuck9

Product

name:

chuck

Click on

create

Pop-u box Pop-u box Pass

T19 Changing

currency in price

module

Indian

rupee to

USD

Click on

edit

product

price

update

Not

applicable

Not

applicable

Pass

T20 Creating

manufacturing

BOM

Select

facility has

manufactu

ring BOM

Click on

BOM

simulation

Should

show all

elements

Should

show all

element

Pass

T21 Creating

engineering BOM

Select

facility has

engineerin

g BOM

Click on

BOM

simulation

Should

show only

parent

element

Should

show only

parent

element

Pass

T22 Examine without

selecting shipping

address

Create

sales or

purchase

order

without

selecting

address

Click on

finalize

order

Pop-up box Pop-up box pass

T23 Examine selecting Create Click on Sales order Sales order Pass



shipping address sales or

purchase

order with

selecting

address

finalize

order

or purchase

order is

created

or purchase

order is

created

T24 Examine payment

mode

Create

sales or

purchase

order with

selecting

address

Select

shipping

address

Should

show the

payment

mode

Should

show the

payment

mode

Pass

T25 Examine payment

mode

Create

sales or

purchase

order

without

selecting

address

without

Selecting

shipping

address

Should not

show the

payment

mode

Should not

show the

payment

mode

Pass

3.4.2.2 Ofbiz Defect Tracker

1. Problem Description

While creating sales order through order entry, how shall we ship it? Mode for USPS standard

shown calculated offline. This is to be selected but by selecting will not allow us to carry out the

sales order.

Bug severity:- Minor

Found By :- Managing Maniac

Date :- 2-4-2012

Steps to Reproduce

• Go to application-select order manager

• Select order entry-give product ID and click on add to order



• Finalize the order-select the shipping address-shipping mode with USPS standard-payment

mode

• Click on continue to finalize order and it should show the order conformation page.

Fig.3.1: Quick finalize order

Work Around

Sales order is created using order entry in order manager, by selecting any other shipping mode

and then click on continue to final order after creating order we can change the shipping mode to

USPS standard by updating the shipping information.

2. Problem description

When a Purchase Order is received manually using the ‘receive functionality’ of Facility

Manager module, the invoice entry in accounting is not automatically raised.

Bug severity:- Minor

Found by :- Managing Maniac

Date:- 6-4-2012



Fig. 3.2: Shows how to receive quick purchase order

Steps to reproduce

• Create a purchase order using the order entry screen of Order Manager

• Once the order is created, approve the purchase order

• In the Facility Manager, select the facility as Kamakshi Palya Plant and receive the

inventory using ‘Receive Inventory’ option

• Once receive inventory is successful, check the status of the PO in Order Manager. It will

be shown as ‘Complete’

• Check for a Purchase Order Invoice entry in accounting module using the functionality

‘Find Purchase Invoice’. There should be a PO invoice corresponding to the amount of the PO

fulfilled.



Fig.3.3: Finding Invoice

Work Around – When a purchase order is created using the order entry functionality of Order

manager, there is an option to quick receive purchase order. When a PO is received using this

option the purchase order invoice entry is made automatically. Shown below is the screenshot of

Quick receive PO functionality.

3. Problem description

When a Purchase Order is raised and approved, in the Quick Receive option, newly created

facility is not listed.

Bug Severity – Minor, data related issue

Found by – Managing Maniac

Date – 10-4-2012

Steps to reproduce –

• Create a new facility ‘Kamakshi palya Plant’ of facility type ‘Plant’

• During the creation of the PO, in the order entry ship to settings, though the newly

created plant is listed, there is no option to select it.



Fig.3.4: Order Entry

Work Around-In the Facility Manager, select the facility as Kamakshi Palya Plant and create a

contact mechanism of type ‘Postal Address’ and save the details

Fig.3.5: Facility Manager



Try to create the purchase order again, as you can see in the screenshot below the newly created

plant is visible as an option to be selected for shipment

Fig.3. 6: Shipping addresses update

4. Problem description – When creating a Purchase Order, in the ‘Add Item’ screen the top

menu bar is not clearly visible as shown in the screenshot below

Bug Severity – Low, Cosmetic

Found by – Managing Maniac

Date – 21-4-2012

Steps to reproduce

• Create a purchase order using the order entry screen

• Select the supplier and click continue



• Enter the order name and order number and click continue

• In the add items screen displayed below the text is not clearly visible in top menu

Fig.3.7: Screen Visuality

Files Modified:

ofbiz-trunk\applications\order\webapp\ordermgr\entry\OrderEntryTabBar.ftl

Verification: After fixing the defect, it can be seen that the options in top menu bar are

clearly visible.



Fig.3. 8: Screen after solving

3.5 Data Analysis

Analysis of data is a process of inspecting, cleaning, transforming, and modelling data with the

goal of highlighting useful information, suggesting conclusions, and supporting decision making.

Data analysis has multiple facets and approaches, encompassing diverse techniques under a

variety of names, in different business, science, and social science domains.

Data mining is a particular data analysis technique that focuses on modelling and knowledge

discovery for predictive rather than purely descriptive purposes. Business intelligence covers

data analysis that relies heavily on aggregation, focusing on business information. In statistical

applications, some people divide data analysis into descriptive statistics, exploratory data

analysis (EDA), and confirmatory data analysis (CDA). EDA focuses on discovering new

features in the data and CDA on confirming or falsifying existing hypotheses. Predictive

http://en.wikipedia.org/wiki/Data

http://en.wikipedia.org/wiki/Information

http://en.wikipedia.org/wiki/Data_mining

http://en.wikipedia.org/wiki/Business_intelligence

http://en.wikipedia.org/wiki/Statistics

http://en.wikipedia.org/wiki/Statistics

http://en.wikipedia.org/wiki/Descriptive_statistics

http://en.wikipedia.org/wiki/Exploratory_data_analysis

http://en.wikipedia.org/wiki/Exploratory_data_analysis

http://en.wikipedia.org/wiki/Confirmatory_data_analysis

http://en.wikipedia.org/wiki/Predictive_analytics



analytics focuses on application of statistical or structural models for predictive forecasting or

classification, while text analytics applies statistical, linguistic, and structural techniques to

extract and classify information from textual sources, a species of unstructured data. All are

varieties of data analysis.

Data integration is a precursor to data analysis, and data analysis is closely linked to data

visualization and data dissemination. The term data analysis is sometimes used as a synonym for

data modelling

Analysis is done by above collected data as follow:-

For Operating System : Windows XP

Fig.3.9: Comparison graph in windows XP

http://en.wikipedia.org/wiki/Text_analytics

http://en.wikipedia.org/wiki/Unstructured_data

http://en.wikipedia.org/wiki/Data_integration

http://en.wikipedia.org/wiki/Data_visualization

http://en.wikipedia.org/wiki/Data_visualization

http://en.wikipedia.org/wiki/Data_modeling



Fig.3.10: Avg. time graph in windows XP

Basic Avg. Time =No. of trials/N

Basic Avg. Time = (9.3+9+8.9+8.4+8.2+8.1+7.9+7.8+7.7+7.7)/10

Basic Avg. Time = 8.3 minutes

Standard Time = Basic Avg. Time * 10% allowance of basic Avg. Time

Standard Time = 8.3 * (8.3*0.1)

Standard Time = 9.13 minutes

Reliability(R) =

R= e -0.4*1 = 0.6703

Avg.reliability = (R1 + R2+ R3)/n

Avg.reliability = 0.7173

Avg.reliability ==71.73%



Table.3.16: Reliability calculation in windows XP

Explorer Mozilla Chrome

Basic

avg.

time

Std.

time

Failure

rate(λ)

Basic

avg.

time

Std.

time

Failure

rate(λ)

Basic

avg.

time

Std.

Time

Failure

rate(λ)

B.O.M 8.3 9.13 0.1 8.3 9.13 0 8.2 9.02 0

S.O 3.2 3.5 0.2 3.3 3.63 0.1 3.3 3.63 0.1

P.O 3.4 3.74 0.1 3.5 3.85 0.2 3.5 3.85 0.2

Reliability 0.6703

0.7408

0.7408

Average

Reliability

0.7173

For Operating System: Windows Vista

Fig.3.11: comparison graph in windows vista



Fig.3.12:Avg.time graph in window vista


Basic Avg. Time = (9.3+9+8.7+8.6+8.5+8.3+8.2+8.2+8.1+8.1)/10



Standard Time = 8.5 * (8.5*0.1)


Reliability(R) =

R= e -0.5*1 = 0.6065


Avg.reliability = 0.6725 = 67.25%



Table.3.17: Reliability calculation in window vista


Basic

avg.

time

Std.

time

Failure

rate(λ)

Basic

avg.

time

Std.

time

Failure

rate(λ)

Basic

avg.

time

Std.

time

Failure

rate(λ)

B.O.M 8.5 9.35 0.1 8.7 9.57 0.1 8.6 9.46 0

S.O 3.5 3.85 0.2 3.6 3.96 0.1 3.3 3.63 0.1

P.O 3.2 3.52 0.2 3.4 3.74 0.2 3.5 3.85 0.2

Reliability 0.6065

0.6725

0.7408

Average

Reliability

0.6725

For Operating System: Windows 7

Fig.3.13: Comparison graph in windows 7



Fig.3.14:Avg.time graph in windows 7


Basic Avg. Time = (8.5+8.3+8.3+7.7+7.5+7.4+7.2+7.1+7.1+6.9)/10



Standard Time = 7.63 * (7.63*0.1)


Reliability(R) =

R= e -0.2*1 = 0.8187





Table.3.18: Reliability calculation in windows 7


Basic

avg.

time

Std.

time

Failure

rate(λ)

Basic

avg.

time

Std.

time

Failure

rate(λ)

Basic

avg.

time

Std.

time

Failure

rate(λ)

B.O.M 7.63 8.39 0 8.0 8.8 0 8.5 9.35 0

S.O 2.6 2.86 0.1 3.5 3.85 0.1 3.2 3.52 0.1

P.O 2.5 2.75 0.1 3.5 3.85 0.2 3 3.3 0.1

Reliability 0.8187 0.7400 0.8187

Average

Reliability

0.7924

For Operating System: Ubuntu

Fig.3.15: comparison graph in ibuntu



Fig.3.16: Avg. time graph in ibuntu


Basic Avg. Time = (8.3+8.2+8.1+7.7+7.5+7.3+7.2+7.1+6.9+6.7)/10



Standard Time = 7.4 * (7.4*0.1)


Reliability(R) =

R= e -0.2*1 = 0.8187





Table3.19: Reliability calculation in Ubuntu


Basic

avg.

time

Std.

time

Failure

rate(λ)

Basic

avg.

time

Std.

time

Failure

rate(λ)

Basic

avg.

time

Std.

time

Failure

rate(λ)

B.O.M 7.4 8.14 0 7.6 8.36 0 7.5 8.25 0

S.O 2.4 2.64 0.1 3.2 3.52 0.1 2.9 3.19 0

P.O 2.4 2.64 0.1 3.1 3.41 0.1 2.9 3.19 0.1

Reliability 0.8187

0.8187

0.9048

Average

Reliability

0.8474



4.0 Conclusions

By analysis of above data we can say using OFBiz on Mozilla Firefox is more compatible

than using on Internet Explorer or Google Chrome

Reliability of Ofbiz in different operating system is:-

Table 4.1: Reliability in different OS

Windows XP Vista 7 Ubuntu

Reliability 71.73% 67.25% 79.24% 84.74%

By above data we can say that using of Ofbiz in operating system Ubuntu is more reliable

compare to other windows OS. Ubuntu is an open source software operating system and

apache open of business Ofbiz is also open source ERP software, ubuntu support very highly

to this software. So it is best use to open source apache OFBiz ERP package in ubuntu that a

small scale industries and educational intuitions can implement this software.



5.0. FUTURE SCOPE

Improving Parameter Estimation: - Maximum likelihood estimation of parameters based

on failure data taken during execution yields reasonable results, but there appears to be

considerable room for improvement.

Fault Density Prediction: - Accurate means of predicting fault density are needed if we are

to predict the parameters of the exponential model so that it can be used prior to program

execution. At the present time investigators have identified some of the factors that appear to

affect fault density, based on a moderate number of projects.

Fault Exposure Ratio: - The fault exposure ratio is the ratio of the initial failure intensity at

the start of system test to the product of the linear execution frequency and the number of

inherent faults. The linear execution frequency is the average instruction execution rate

divided by the object program size. It relates reliability to fault density.

Fault exposure ration may be constant or close to it. This must be verified over a larger

sample of projects. If it is not constant, then the factors that influence it need to be identified

and relationship determined.

Fault Reduction Factor: - the fault reduction factor is the ratio of net fault reduction to

failures experienced as time of execution approaches infinity. We need to determine its value

over a wide variety of projects and determine factors that affect it.

The main research requirement is data on net faults removed and failures experienced. If

factors that affect fault reduction factor are identified, we need to determine their values.

There is no need for software tools.

Resource Usage Parameters: - Information on resource usage parameters is needed on a

wide variety of projects. Either they will be constant, or they will vary with factors which

must be determined.

The requirements for research here are data on resource usage (failure identification effort,

failure resolution effort, computer time) as a function of execution time and failures



experienced. Data will also be required on the values of any variables that may affect

resource usage.

SRE and Unit Test: - there is a good chance that software reliability estimation could be

extended to unit test. There are problem that must be addressed. First, the size of the sample

of failures may be solved in grouping the failures of a number of units in some way. Second,

the operational profile for the unit must be related to the system operational profile in some

way or one must compensate for the difference.

Homogeneity of Failure Severity Classification: - Some evidence indicates that the

proportion of failures in each failure classification on a given project remains approximately

constant over the life of the project. Checking this hypothesis will require failure data from a

variety of projects, with the execution time and severity classification of failure recorded.

Relationship between Reliability and Problems Found During Inspection: - Reliability

estimation and prediction during the coding phase or earlier is an open research question.

Some suggestions can however put forth. All of these suggestions will not guarantee good

results if followed. These are only recommendations based upon the experience of software

developers.



References

1. Parijat Upadhyay et al “A Comparative Study of Issues Affecting ERP Implementation in

Large Scale and Small Medium Scale Enterprises in India: A Pareto Approach”

International Journal of Computer Applications (0975 – 8887) Volume 8– No.3, October

2010

2. Poonam Garg, “Critical Failure Factors For Enterprise Resource Planning

Implementations in Indian Retail Organizations: An Exploratory Study” Institute of

Management Technology, Ghaziabad – India. Vol. 10, No. 1, pp. 35-44, 2010.

3. Mark C. Van Pul “A General Introduction to Software Reliability” Measurement and

Computational Applications Volume 7 (3) 1994. Pp 203-244.

4. Krešimir Fertalj et al. “Optimal parameter choice in modelling of ERP system reliability”

5. F. Urem “The Impact of Upgrades on ERP System Reliability” World Academy of

Science, Engineering and Technology 2011.

6. Chin-Yu Huang” Cost-reliability-optimal release policy for software reliability models

incorporating improvements in testing efficiency” Department of Computer Science,

National Tsing Hua University. The Journal of Systems and Software 77 (2005) 139–155.

7. Kristine B. Walhovd “One-year test–retest reliability of auditory ERPs in young and old

Adult,2001” University of Oslo, Institute of Psychology, International Journal of

Psychophysiology 46 (2002) 29–40.

8. Sally Wright et al. “Information System Assurance for Enterprise Resource Planning

Systems :Unique Risk Considerations” University of Massachusetts Boston, Journal of

Information Systems Vol. 16 Plement pp. 99.113

9. Yoshinobu Tamura et. al. “Component- Oriented Reliability Analysis and Optimal

Versionupgrade Problems for Open Source Software”, Journal of Software, Vol. 3, No. 6,

pp. 1-8, June 2008

10. Dr. Ali E. Kashef et.al “ERP: The Primary Solution Provider for Industrial Companies”

Journal of Industrial Technology , Volume 17, Number 3 ,May 2001 to July 2001.

11. Swapna S. Gokhale et. al “Models for Architecture-based Software Reliability Prediction:

A Unification Framework Dept. of CSE,University of Connecticut Duke University.



12. Xiaolin Teng et.al “Reliability modeling of hardware and software interactions and its

application” IEEE, and Daniel R. Jeske, vol. 55, No 4, December 2006 pp 571-577

13. Boo Young Chung et.al “Analyzing Enterprise Resource Planning System

Implementation Success Factors In The Engineering–construction Industry” journal of

computing in civil engineering Vol. 22, No. 6, November 1, 2008.

14. Rao S et.al “Enterprise resource planning: Business needs and technologies”, Industrial

Management & Data Systems, Vol 100, Issue 2, pp 81–88, 2000.

15. Zhenyu Huang “A Compilation Research Of ERP Implementation Critical Success

Factors” Central Michigan University Volume XI, No. 1, 2010.

16. Shih-Wen Chien et all “Investigating the success of ERP systems: Case studies in three

Taiwanese high-tech industries. Computers in Industry 58 (2007)”

17. Shi, J. J., and Halpin, D. W. _2003_. “Enterprise resource planning for construction

business management.” J. Constr. Eng. Manage., 129-2-214–221.

18. Kumar, V., Maheshwari, B. and Kumar, U., “An investigation of critical management

issues in ERP implementation: empirical evidence from Canadian organizations,”

Technovation, vol. 23, no. 10,pp.793–807, 2003.

19. Avritzer A., and Weyuker E.J., The role of modeling in the performance testing of E-

commerce applications. IEEE Transactions on software engineering, 30, 12, Dec. 2004,

pp. 1072-1083.