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

R.V. College of Engineering

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
Mayank Baheti 1RV09IM024
Deepak Rathod 1RV09IM009
Suraj Soni 1RV09IM044
Tanay Agrawal 1RV09IM046

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

Department of industrial engineering and management Page 1


Sl.No Topic Page. No

Abstract i.

1. Introduction 7

1.1. Overview to Software Reliability 7

1.2 Overview of Open Source ERP Software 7

1.3. Principles of open source architecture 8

Introduction to open source architecture 8
1.3.1.

Overview Apache open for business (Ofbiz) 9
1.3.2.

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

1.3.4. Different Open Source ERP Software’s 10

1.4. Literature Review 13

1.5. Problem Genesis 15

1.6. Objectives 16

2. Theoretical Concepts and fundamentals 17

2.1. Software reliability modeling 18



2.2. Software reliability modeling classification 19

2.3. Theoretical Comparison of Techniques 21

2.4. Exponential Model 23

3. Methodology 25

3.1. Study of Ofbiz ERP software package 25

3.2. Develop Operational Profile 25

3.3. Testing 25

Performance testing on different operating systems 25
3.3.1.

Performance testing on different web browsers 26
3.3.2.

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 Setup your chart of accounts, manage agreements, billing, invoices,
Manager 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 MRP, job shop, routing and routing task screens, and BOM screens.
Manager
Marketing Maintaining mailing lists, manage online marketing campaigns that are
Manager 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 Track site traffic and related performance metrics.
Application
Work Effort Events, calendar, project management, and more ready to be customized
Manager 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.



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.



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 Model μ(t) Reference Comments
Name Type
Goel-Oku Concave a(l-e-bt) Goel,79 Also called Musa model or
moto (G-O) a  0, b>O exponential model
G-OS- S-Shaped a( 1-(1+bt)e-bt) Yamada,83 Modification of G-O model to
Shaped a  0, b>O make it S-shaped (Gamma
function instead of
exponential)
Hossain- Concave a( l-e-bt)/(1+ce-bt) Hossain,93 Solves a technical condition
Dahiya/G- a  0, b>O, c>0 with the G-O model. Becomes
O same as G-O as c approaches
O.
Gompertz S-Shaped a(bct) Kececioglu,, Used by Fujitsu, Numazu
a  0, 0  b  1, 0<c<1
91 Works
Pareto Concave a(l-(l+t/  )l-  Littlewood, Assumes failures have
81 different failure rates and



a  0,  >0, 0    1 failures with highest rates
removed first
Weibull Concave a(l-e-btC) Musa,87 Same as G-O for c=1
a  0, b>0,c>0
Yamada Concave a(1-e-r  (1-e-  t)) Yamada,86 Attempts to account for testing
Exponential a  0, r  >0,  >0 effort

Yamada S-Shaped (  t 2 / 2 ) Yamada,86 Attempts to account for testing
a(1  e  r (1e )
)
Raleigh effort
Log Infinite (l/c)ln(c  t+l) Musa,87 Failure rate decreases but does
Poisson Failure c>O,  >O 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 Jelinski-Moranda Musa’a Model Schneidewind’s
Functions Model Model
F(t) 1  e t
1 e

1t 
 /   1  e  t 
f(t) e t 1e 
t
e t
z(t)  1 e  t
1   /    e  t 
1
 (t ) 
N 1  e t   0 1  e   1t   /   1  e  t 
 (t ) N e t  0 1e   1t e  t



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 Testing OFBiz Testing OFBiz Testing OFBiz
Evaluation performance on Mozilla performance on Internet performance on Google
Firefox version 13.0 Explorer 9 Chrome
Object of Firefox performance with IE-9.0 performance with Google Chrome
Evaluation OFBiz OFBiz performance with OFBiz
Test Case 1. Navigation of 5. Navigation of 9. Navigation of
Used pages pages pages
2. Cookies 6. Cookies Clearance 10. Cookies Clearance
Clearance 7. History Scrutiny 11. History Scrutiny
3. History Scrutiny 8. Page Visualization 12. Page Visualization
4. Page
Visualization
Actual 1. Navigation of 5. Navigation of 9. Navigation of
Output Pages are very Pages are very pages are quite
smooth smooth faster
2. Proper cookie 6. Cookies are not 10. In Google chrome,
management managed properly incognito window
3. Proper history and 7. No proper history enables the better
cache and cache cookies clearance.
management management 11. Better history
4. The pages are 8. The pages are management due
visually better to visually not so to incognito
experience better to window.
experience as user 12. The pages
visualization is
better compare to
internet explorer 9
Remarks Mozilla Firefox seems to IE-9.0 seems not to be best Google chrome is also
be best compatible with compatible with OFBiz found to be best
OFBiz 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
Purchase order
Bill of Purchase Sales through
Sl.no material order order 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

Purchase order
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
Purchase order
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
Purchase order
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
Purchase
Bill of Purchase Sales order through
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
Purchase
Purchase Sales order through
Sl.no Bill of material order order 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
Purchase Sales through
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
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
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
Bill of
Sl.no 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
Bill of Sales Purchase
Sl.no material order 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
Bill of Sales
Sl.no material 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



3.4.2.1 TEST CASES

Table 3.15: Test cases

Step. Step Description Test Data Actions Expected Actual Status
no Results Result
T01 Examine entering Business Click on Loged-in Loged-in Pass
username & 12345 Login
password
T02 Examine entering Business Click on Pop-up box Pop-up box Pass
correct username 12366 Login
& wrong
password
wrong username 12345 Login
& correct
password
wrong username 12356 Login
& wrong
password
T05 Ensure after log-in Business Click on Open Open Pass
should go to 12345 Login homepage homepage
homepage
T06 Check BOM on Create all Click on BOM pdf BOM pdf Pass
screen product BOM
give price, simulation
supplier
and
facilities
T07 Check BOM on Create Click on Should not Should not Pass
screen product BOM show BOM show BOM



Without simulation
giving
facilities
T08 Examine sales Input Click on Should Should give Pass
enquiry enquiry supplier give supplier
number supplier sales
sales
T09 Examine product Input Click on Display Display Pass
detail product product product product
name/ID detail detail detail
T10 Examine entering Id: cap Click on Show error Show error Pass
same product id & name: cap create that that
product name product duplicate duplicate
key arise key arise
T11 Examine entering Id: cap Click on Product Product Pass
different product name: caps create created created
id & product name product
T12 Edit product detail Product Click on Go to edit Go to edit Pass
detail edit screen screen
product
T13 Examine product Engine Click on Pop-up box Pop-up box Pass
ID lathe create
product
T14 Examine product Engine Click on Product Product Pass
ID without space _lathe create created created
product
T15 Examine product Without Click on Pop-up box Pop-up box Pass
without internal internal create
name name product
T16 Examine product With Click on Pop-up box Pop-up box Pass
with internal name internal create



name product
T17 Creating suppliers Product Click on Pop-u box Pop-u box Pass
for subassemblies id:__ create
without product id Product
& name name:__
T18 Creating suppliers Product Click on Pop-u box Pop-u box Pass
for subassemblies id:chuck9 create
with product id & Product
name name:
chuck
T19 Changing Indian Click on Not Not Pass
currency in price rupee to edit applicable applicable
module USD product
price
update
T20 Creating Select Click on Should Should Pass
manufacturing facility has BOM show all show all
BOM manufactu simulation elements element
ring BOM
T21 Creating Select Click on Should Should Pass
engineering BOM facility has BOM show only show only
engineerin simulation parent parent
g BOM element element
T22 Examine without Create Click on Pop-up box Pop-up box pass
selecting shipping sales or finalize
address purchase order
order
without
selecting
address
T23 Examine selecting Create Click on Sales order Sales order Pass



shipping address sales or finalize or purchase or purchase
purchase order order is order is
order with created created
selecting
address
T24 Examine payment Create Select Should Should Pass
mode sales or shipping show the show the
purchase address payment payment
order with mode mode
selecting
address
T25 Examine payment Create without Should not Should not Pass
mode sales or Selecting show the show the
purchase shipping payment payment
order address mode mode
without
selecting
address

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



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



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 Std. Failure Basic Std. Failure Basic Std. Failure
avg. time rate(λ) avg. time rate(λ) avg. Time rate(λ)
time time time
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 0.7173
Reliability

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
avg. time rate(λ) avg. time rate(λ) avg. time rate(λ)
time time time
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 0.6725
Reliability

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
time time time
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 0.7924
Reliability

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
time time time
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 0.8474
Reliability



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 eﬃciency” 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 Uniﬁcation 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.


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

More Related Content

What's hot (19)

Viewers also liked (6)

Similar to Reliability study and analysis on open source enterprise resource planning software package (20)

Recently uploaded (20)

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