CHAPTER II

2. Literature review

Scope
The scope of this literature review is to determine the effectiveness of the system-software where the researcher aims to verify its reliability and dependability to the users. The researcher also seeks for the comprehension that will catch on the efficiency of system-software in collecting the information needed.

2.1 Reliability and dependability There does exists a denition of dependability that treats reliability as only one among dependability attributes, along with availability, safety, condentiality, integrity and maintainability. While possibly applicable to a computing system as a whole, this classication does not seem right for their software part, as some attributes such as availability are not properties of the software per se, others such as condentiality are included in reliability (through one of its components, security), and the remaining ones such as maintainability are of dubious meaning for software, being better covered by other quality factors such as extendibility and reusability. As a consequence of these observations the present survey interprets dependability as meaning the same thing, for software, as reliability.

2.2 Correctness, robustness, security They correspond to levels of increasing departure from the specication. The specication of any realistic system makes assumptions, explicit or implicit, about the conditions of its use. By nature, the requirements dened by robustness and security are different from those of correctness: outside of the specication, we can no longer talk of performing according to that specication, but only seek the more modest goal of preventing damage; note that this implies the ability to detect attempts at erroneous or hostile use. Security deserves a special mention as in recent years it has assumed a highly visible place in software concerns. This is a phenomenon to be both lamented, as it signals the end of a golden age of software development when we could concentrate on devising the best possible functionality without too much concern about the worlds nastiness, and at the same time taken to advantage, since it has nally brought home to corporations the seriousness of software quality issues, a result that decades of hectoring by advocates of modern software engineering practices had failed to achieve. One of the most visible signs of this phenomenon is Bill Gates edict famously halting all development in February of 2001 in favour of code reviews for hunting down security aws. Many of these aws, such as the most obnoxious, buffer overow, are simply the result of poor software engineering practices. Even if focusing on security means looking at the symptom rather than the cause, xing security implies taking a coherent look at software tools and techniques and requires, in the end, ensuring reliability as a whole.

2.3 Product and Process Any comprehensive discussion of system-software issues must consider two complementary aspects: product and process. The products are the software elements whose reliability we are trying to assess; the process includes the

mechanisms and procedures whereby people and their organizations build these products.

2.4 Products of System-software The products themselves are diverse. In the end the most important one, for which we may assess correctness, robustness and security, is code. But even that simple term covers several kinds of product: source code as programmers see it, machine code as the computer executes it, and any intermediate versions as exist on modern platforms, such as the bytecode of virtual machines. Beyond code, we should consider many other products, which in their own ways are all software: requirements, specications, design diagrams and other design documents, test data but also test plans , user documentation, and teaching aid. To realize why it is important in the search for quality to pay attention to products other than code, it sufces to consider the results of numerous studies, some already decades old [10], showing the steep progression of the cost of correcting an error the later it is identied in the lifecycle.

2.5 Deficiencies In trying to ascertain the reliability of a system-software product or process we must often like a detective or a re prevention engineer adopt a negative mind-set and look for sources of violation of reliability properties. The accepted terminology here distinguishes three levels: A failure is a malfunction of the software. Note that this term does not directly apply to products other than executable code. A fault is a departure of the software product from the properties it should have satised. A failure always comes from a fault, although not necessarily a fault in the code: it could be in the specication, in the

documentation, or in a non-software product such as the hardware on which the system runs. An error is a wrong human decision made during the construction of the system. Wrong is a subjective term, but for this discussion its clear what it means: a decision is wrong if it can lead to a fault (which can in turn cause failures). In a discussion limited to system-software reliability, all faults and hence all failures result from errors, since software is an intellectual product not subject to the slings and arrows of the physical world. The more familiar term for error is bug. The upper crust of the software engineering literature shuns it for its animist connotations. Error has the benet of admitting that our mistakes dont creep into our software: we insert them ourselves. In practice, as may be expected, everyone says bug.

Background
The purpose of this literature review is to synthesize the related prior research discovered by the researcher after the complete review of the literature. All user measures the efficiency of the system-software they used depends on how much they rely on it. Reliability is being able to deliver usable services, while being able to satisfy the requirements of the system.

Importance
Software enables highly complex activities - such satellite precision manoeuvres, autonomous navigation of rovers on a planetary terrain - and provides a means to recover from malfunctions and compensate for hardware equipment defects. Software must work correctly first time in orbit, and getting it right is crucial to mission success: software bugs have been the doom of many spacecraft, going back to the earliest days of space exploration. The added value of software to space systems has increased greatly in recent decades, reflecting the ever growing functionality and autonomy of spacecraft and the amount of mission data to be collected and processed. Software systems engineering is needed to ensure that the software is properly designed, developed and verified, like for any physical equipment.

Assertion
There is now an increasing usage of system-software in many aspects of society today, especially in areas where the system-software safety is critical. There is an increasing need to for people to see how much they can depend and rely on the system-software.

Overview map
System-software under operational conditions An obvious way to estimate the reliability of a program is to simulate its operational use, noting the times at which failures occur. There has been considerate research on the statistical techniques need to analyse such data, particularly when faults are removed as they are detected. The reliability growth modelling is probably one of the most successful techniques available: it is now generally possible, given the availability of appropriate data, to obtain accurate estimates of reliability and to know that they are accurate. Propagating awareness of dependability issues and the use of existing, useful methods It is common for computer scientists to complain about the poor quality of current system-software, and for vendors to reply that their choices are dictated by their customers. Without judging where the truth lies between these somewhat self-serving positions, it seems clear to us that society would benefit from greater awareness of software dependability problems. There is room for great improvements among users both end users and system integrators. 1. Public perception of software dependability. Since computers are state machines, they may store an erroneous state now which will cause a failure after a long tome of proper service. Knowledge about dependability is always often worthwhile. Increased awareness of these issues would certainly allow users better to address system procurement, to prepare and defend themselves against the effects of failures, and to report problems and requirements to vendors.

2. Design culture. With the blurring of the separation between professional software developers and users, these misperceptions increasingly affect system development. But even professional developers often lack education in dependability, both from academic learning and from their workplace environment. The cultural problems: lack of risk analysis and of provisions of fall-backs and redundancy, focus on a technical subsystem without system-level consideration of risks. Focus on User-Centred, System-Level Dependability Qualities All too often, reliability is described in terms of compliance of a specific program with its written specifications. This may have paradoxical consequences: if a program was written with imprecise, largely unstated requirements, does this simply that we cannot state reliability requirements for it? The sensible way of approaching reliability is to define failure in terms of a systems effect on its user. For instance, in using a computer to write this article, we have a very clear perception of what would constitute a failure, e.g., the computer reacting to a command with an unexpected change to the text, or its crashing or corrupting a stored file. Measuring the reliability of individual components with respect to component-specific requirements is, in other areas of engineering, a convenient step towards assessing the satisfaction of the users dependability requirements. It may also be useful for carefully structured software-based systems. But component-based assessment is not the goal of reliability engineering. For the user, failures are classified by their consequences rather than their causes: it does not matter whether lose the article because the word processor contains a bug. Actually, most users cannot tell whether a certain undesired behaviour of a word processor is due to a bug or to their misunderstanding of the function of the software.

User-oriented requirements have many dimensions. Thus, traditionally, telephone companies established multiple target bounds for the frequency of dropped calls, frequency and total duration of outages, and so on. Users of an office package have distinct requirements regarding the risks of corruption to stored data, of unintended changes to an open file, or interruptions of service. All these needs are served by attention to various aspects of design: reliability of application modules, robustness of the platform, support for proper installation and detection of feature interactions, effective detection of run-time problems, informative error messages and design to facilitate recovery by the user. Design for dependability assessment The difficulties in assessing system-software dependability are due to the complexity of the functions that require from system-software, but also for a large part to design cultures that ignore the need for validation. Engineers have traditionally accepted that the need to validate a design (to implemented system will be serviceable and safe) must constrain design freedom. Structures have been limited to forms that could be demonstrated to be acceptably safe, either by extensive empirical knowledge or by the methods of calculation known at the time. The less a new design could be pre-validated on models and prototypes, the more conservative the design had to be. This restraint has been lost in a large part of the software industries. The researcher list here design practices that have a potential for facilitating validation and thus reliability engineering.

Conclusion
An engineering approach to design must include dependability aspects. In system-software, progress in this direction has been slow, but is necessary for more efficient decisions by both individual actors and society. Increasing dependence on system-software increases the costs of undependability or of not matching dependability to needs. Some current trends, like that towards using more COTS components, create both opportunities and technical challenges for this progress. There are non-technical difficulties to overcome, in terms of education of users and developers and better communication between technical communities. The research challenges include both learning more about the effects of the practices for achieving dependability and learning better to organise knowledge to support judgement and decision-making. In other words, it takes part of our life the importance to know the efficiency of system-software reliability and dependability to users, so that users will be able to have competence on the system-software they use, and also to distinguish its reliability and dependability on their daily lives.

Sources
http://bscw.cs.ncl.ac.uk/pub/bscw.cgi/d18229/Littlewood%20and%20Strigini%20%20Software%20reliability%20and%20dependability:%20a%20roadmap..pdf http://se.ethz.ch/~meyer/publications/lncs/dependability.pdf