Abstract: Software packages play an important role in our lives. Products and services that affect people’s lives must have quality attributes. Therefore, good quality software package is required and in order to determine the quality of software package we need methods to measure it reliability. An interesting point here is that the quality of software may change over time and software package is no exception. In the early days of computing, software costs represented a small percentage of the overall cost of a computer-based system. Hence, a sizable error in estimates of software cost had relatively little impact. Today, software is the most expensive element in many computer-based systems. Therefore, steps taken to reduce the cost of software can make the difference between the profit and loss of a company. So, by determining the quality attributes of software, more precise, predictable and repeatable control over the software development process and product will be achieved. We propose a formal approach from the problem oriented software engineering point of view, for estimating the reliability of a software package by determining the error rate.

INTRODUCTION

As an apparent statement, engineering is considered as a step-wise problem solving activity that yields a product (Krabbel et al., 1997). The use of problem-oriented method to requirements engineering is gradually becoming well established, mostly for software intensive systems. In recent years, the foundation of problem-oriented method is being laid (Rapanotti et al., 2004). Developing software has been viewed as a problem and the solution as a machine that is, a program running in a computer that will ensure satisfaction of requirement in the given problem world or environment. Because, the requirement typically concerns properties and behaviours that are located in the problem world at some distance from its interface with the machine, requirements are distinguished from specifications (Brier et al., 2004).

Amongst other concerns of software engineers is on how to handle change, which in most cases is inevitable. Changes occur as a result of fixing bugs, or adding and deleting requirement or functionality. Although, these are not the only sources of change, but the need for change is evolving as software packages evolves.

Very often, the terms errors, faults and failures are used interchangeable, but do have different meanings. In reference to software, an error is usually a programmer action or omission that results in a fault. While, a fault is a software defect that causes a failure and a failure refers to the unacceptable departure of a program operation from program requirements. When measuring reliability, we are usually measuring only defects found and defects fixed (Ekabua and Adigun, 2008).

Software failures may result from errors, ambiguities, oversights or misinterpretation of the specification that the software is supposed to satisfy, carelessness or incompetence in writing code, inadequate testing, incorrect or unexpected usage of the software or other unforeseen problems (Hall et al., 2002). While, it is tempting to draw an analogy between software reliability and hardware reliability, software and hardware have basic differences that make them different in failure mechanisms. Hardware faults are mostly physical faults, while software faults are design faults, which are harder to visualize, classify, detect and correct. Design faults are closely related to fuzzy human factors and the design process, which we don't have a solid understanding. In hardware, design faults may also exist, but physical faults usually dominate. In software, we can hardly find a strict corresponding counterpart for manufacturing as hardware manufacturing process, if the simple action of uploading software modules into place does not count. Therefore, the quality of software will not change once it is uploaded into the storage and start running. Trying to achieve higher reliability by simply duplicating the same software modules will not work, because design faults can not be masked off by voting (Michael, 1995).

Software packages are being rolled by the day into the market, some evolving from the modification of a previous package. Developing (Hall et al., 2005) a software package is engineering in the traditional sense, as it involves the creation of an artefact, which transforms the physical world by meeting recognised needs. This poses challenges that logic alone cannot address, but can be met only by sharply focused specialisms practicing highly developed normal design disciplines, in line with those that characterise the established engineering disciplines.

These being well known difficulties in established branches of engineering, have sometimes led to harmful dichotomy in approaches to software package development. Some approaches are address as formal concerns, while others as non-formal concerns-creating difficulties in reconciling the two.

A key challenge therefore, is for software engineers to develop methods on how to reconcile the formal world of the machine and its software with the non-formal real world. This is where Problem Oriented Software Engineering (POSE) becomes necessary. Unquestionably, engineering is a problem solving activity (Ekabua and Adigun, 2008). Our focus is not only on requirements engineering, where the problem-oriented software engineering has its origins, but more generally with software engineering leading to the development of a reliable software package. Along with other views (Hall et al., 2005), software engineering includes the identification and clarification of system requirements, the identification, structuring and analysis of the problem world, the structuring and specification of a hardware/software machine that can ensure satisfaction of the requirements in the problem world, the creation of the software product and the construction of formal arguments, convincing to developers, customers, users and other interested people, that the system will satisfy its real world requirements.

RELATED WORK

A formal conceptual framework for software development based on a problem-oriented perspective that stretches from requirements engineering through to program code was introduced. The research regarded development steps as transformations, by which problems are moved towards software solutions. The framework follows, the form of a sequent calculus, which can accommodate both formal and informal steps in development (Rapanotti et al., 2004).

Also, issues of producing and managing the safety reasoning involved in critical system development was addressed through POSE. In particular, the study provided some evidence on how POSE may contribute to those elements of a safety case arguing requirements validity and satisfaction, explicit context assumptions, design judgment and rationale and safety risk management and demonstrated the approach on a real world example (Hall et al., 2005).

OUR PROBLEM FRAME

As earlier mention, our problem domain is on estimating software package reliability. During the development of a new software package, a step-wise procedure is always put in place to eliminate earlier faults or bugs found in the package. An often implemented procedure is to allow the package to run on a set of well known problems to see if any errors result. This can go on for a fix time, while recording all resulting errors. After a while, the testing stops and the package carefully examine to determine the specific bugs responsible for the observed errors. Changes will now be effected in the package to remove these bugs.

Software reliability improvement is hard. The difficulty of the problem stems from insufficient understanding of software reliability and in general, the characteristics of software. Until, now there is no good way to conquer the complexity problem of software. Complete testing of a moderately complex software module is infeasible. Defect-free software product can not be assured. Realistic constraints of time and budget severely limits the effort put into software reliability improvement.

The POSE concept of problem requires a separation of context, requirement and clarification, with explicit descriptions of what is given, what is required and what is designed. This enhances the traceability of artifacts and their relation, as well as exposing all assumptions to scrutiny and validation. That all descriptions are generated through problem transformation forces the inclusion of an explicit justification that such assumptions are realistic and reasonable (Hall et al., 2005).

FORMAL PROBLEM FRAME

TRANSFORMATION

A proliferation of software reliability models have emerged as people try to understand the characteristics of how and why, software fails and try to quantify software reliability. Over 200 models have been developed since, the early 1970s, but how to quantify software reliability still remains largely unsolved. Interested readers may refer to Ekabua et al. (2007). As many models as there are and many more emerging, none of the models can capture a satisfying amount of the complexity of software; constraints and assumptions have to be made for the quantifying process. Therefore, there is no single model that can be used in all situations. No model is complete or even representative. One model may research well for a set of certain software, but may be completely off track for other kinds of problems.

Most software models contain the following parts: assumptions, factors and a mathematical function that relates the reliability with the factors. The mathematical function is usually higher order exponential or logarithmic. Software modeling techniques can be divided into 2 subcategories: prediction modeling and estimation modeling (Bleistein et al., 2004). Both kinds of modeling techniques are based on observing and accumulating failure data and analyzing with statistical inference.

Following our problem frame, it becomes possible to visualise that not all the bugs in the package have been eliminated and this introduces the great challenge of estimating the error rate of the revised software package.

To introduce a formal modelling method to the above scenario, we need to first suppose that the package initially contains an unknown number, M, of bugs, which herein is considered as bug 1, bug 2… bug M. Therefore, we make three assumptions as follows: First, we would like to assume that bug I will generate errors in accordance to a Poisson process with an unknown rate λ_i, i = 1. . . m. Then, for instance, the number of errors due to bug I that occur in any s units of operating time is Poisson distributed with mean λ_iS. Secondly, we will like to also, assume that these Poisson processes caused by bugs i, i = 1… M is independent. Thirdly, we assume the package is to be run for t time units with all resulting errors being noted. At the end of this period, debugging process takes place where a careful check of the package is made to determine the specific bugs that caused the errors. These bugs are removed and the problem is then to determine the error rate for the revised package.

If we let:

(1)

then

(2)

is the error rate of the final package. The expectation of the above can then be stated as:

(3)

We assume that each of the bugs discovered is responsible for a certain number of errors. Therefore, we denote M_i (t) as the number of bugs that were responsible for j errors, where, j≥1. That is M_i (t) caused exactly 1 error, M_i (t) caused exactly 2 errors and so on with Σ_j JM_j (t) equating the total number of errors that resulted. To compute E [M₁ (t)], we define I_i(t), where i≥1, by the relation:

(4)

Then,

(5)

and so

(6)

(7)

Using Eq. 2 and 5, we obtain the intriguing result that:

(8)

From Eq. 6, we can possibly use M₁ (t)/t as an estimate of ∧ (t) requires us to consider how far apart these two quantities tend to be. Therefore, we compute:

(9)

Now,

(10)

(11)

(12)

(13)

(14)

From Eq. 13 and 14, ψ_i(t) and I_j (t) are independent variables when i ≠ j because they refer to different Poisson processes and

(15)

Therefore from Eq. 7, we obtain that

(16)

(17)

Following Eq. 17 and 5 and the identity, we have

(18)

We can therefore, estimate the average square of the difference between ∧¸ (t) and

by the observed value of

CONCLUSION

The aim of the research reported here, is to bring both non-formal and formal aspects of software package development together in a step-wise formal mathematical models, so as to estimate software package reliability by determining error rate. The formal approach is intended to provide a structure within, which the results of different development activities can be combined and reconciled.

Essentially, the structure is the structure of the progressive solution of a system development problem; it is also, the structure of the argument that must eventually justify the adequacy of the developed software package. The model is itself formal, but it is designed to accommodate both formal and informal descriptions of problem domains and requirements and arguments justifying claimed relationships between development artifacts. Therefore, this study, has approached the problem of estimating software package reliability by determining error rate in software through formal mathematical methods.