Software reliability Essay

Software is permeant in today ‘s universe [ 1-2 ] . Many human activities rely on it, like utilizing a nomadic phone, utilizing a personal computing machine, driving a auto, winging an aeroplane or commanding a atomic power works. When it fails, the cost can be high. In 1999 NASA ‘s “ Mars Climate Orbiter ” ballistic capsule crashed on the surface of Mars.

The cause was a package mistake [ 3 ] . The pushers responsible for maintaining the ballistic capsule in orbit were designed based on the criterion metric system. The package which controlled them used the imperial metric system. This led to a misreckoning of the necessary force to maintain the ballistic capsule in orbit. The cost of this package mistake was a batch of money and clip: more than $ 327 million and one twelvemonth for the ballistic capsule to make Mars. Sometimes package mistakes do n’t merely ensue in loss of money and clip ; sometimes they can do the loss of lives.

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!

order now

Two unfortunate incidents were the “ Patriot Missile Defense System Failure ” and the “ Therac-25 ” [ 4 ] . On the 25th of February 1991 in Dhahran Saudi Arabia, the Patriot defence system failed to stop an entrance Iraqi Scud missile. The missile hit the US Army ‘s barracks ensuing in 28 soldiers killed and around 100 wounded. The failure was due to a package mistake in the defence system ‘s clock [ 5 ] . Between 1985 and 1987 in US and Canada, patients with malignant neoplastic disease have been exposed to lethal radiation overdoses during their intervention by the Therac-25 medical system [ 6 ] . 3 peopled died.

One of the causes of this calamity were several mistakes in the package used by Therac-25 [ 7 ] . These illustrations and many more [ 8-9 ] clearly demonstrate the demand for dependable package. Particularly for “ safety-critical ” or “ life-critical ” systems like flight control, medical and defence systems, it is important for the package which controls them to be every bit dependable as possible and of high quality.Software quality is complex construct [ 10-11 ] .

There are different positions of what it is, different theoretical accounts of what its factors are and how they relate to each other and different steps for each lending factor [ 12 ] . Reliability is one of the most of import quality factors of package and it is every bit complex as package quality itself [ 10 ] . It originated from the hardware dependability theory.

Harmonizing to [ 10, 13-16 ] , it is defined as “ the chance of failure-free operation of a computing machine plan for a specified clip and in a specified environment ” . But this is non the lone definition. Boehm in [ 17 ] provinces that “ codification possesses the characteristic dependability to the extent that it can be expected to execute its intended maps satisfactorily ” . Despite the different definitions, theoretical accounts and prosodies of package dependability, research workers agree that: ( a ) it is an of import package quality characteristic [ 13-14 ] , ( B ) it is what users pay attending to when interacting with package [ 11, 13, 18 ] and ( degree Celsius ) it is a utile step in managing and apportioning resources in order to increase package quality [ 19 ] .The duty of bring forthing dependable package lies on the shoulders of package applied scientists. Boehm in [ 20 ] defines package technology to be “ the agencies by which we [ package applied scientists ] effort to bring forth all of this package in a manner that is both cost-efficient and dependable plenty to merit our trust ” . He emphasises on package dependability and at the same clip he takes into history the cost of accomplishing it. The more dependable package needs to be more resources are needed and therefore the production costs rise.

In this effort to unite cost-effectiveness and package dependability, package applied scientists can use two methods during package development: Design-by-Contract and machine-controlled random package proving. These are non the lone methods, but they target specifically on bring forthing dependable package in a cost-efficient mode.

What is design by contract

Design-by-Contract ( DbC ) [ 21-22 ] was introduced by Bertrand Meyer, the interior decorator of the Eiffel scheduling linguistic communication. It is a theory environing the building of quality package based upon the Abstract Data Type ( ADT ) theory [ 23 ] and the conceptual metaphor of human contracts to package. It covers all facets of package development, from analysis to certification, with particular accent on package dependability.

It contains a set of rules, regulations and guidelines for bring forthing package “ in which dependability is constitutional ” .Harmonizing to DbC, package dependability is the combination of two complementary quality factors: rightness and hardiness.

  • Correctness is defined as the ability of package to execute as expected by its specification.
  • Robustness is defined as the ability of package to manage whatever resides outside of its specification.

Therefore package is dependable if it is right and behaves harmonizing to its specification and if it is robust and reacts suitably to conditions non covered by its specification. Software rightness can be achieved through the usage of averments and package hardiness through the usage of exclusion handling.


An averment is a Boolean look that defines the conditions under which package executes right.The first usage of averments is the semantic specification of modus operandis.

A modus operandi is non merely a piece of codification ; as the execution of some map from an abstract information type specification, it should execute a utile undertaking. It is necessary to show this undertaking exactly, both as an assistance in planing it and subsequently as an assistance to understanding its text.You may stipulate the undertaking performed by a everyday by two averments associated with the modus operandi: a stipulation and a postcondition. The stipulation states the belongingss that must keep whenever the modus operandi is called ; the postcondition states the belongingss that the everyday warrants when it returnsThe specification is expressed through averments. Assertions help us measure the rightness of our package.Once we have defined the rightness of a package component as the consistence of its execution with its specification, we should take stairss to include the specification, together with the execution, in the package itself.

To show the specification, we will trust on assertions..PreconditionsProperties that must keep before the call of a modus operandi.

Properties that must keep whenever the modus operandi is called.Requirements that any call must fulfill if it is to be right.A stipulation expresses the restraints under which a modus operandi will work decentlyA stipulation applies to all calls of the modus operandi, both from within the category and from clients. A right system will ne’er put to death a call in a province that does non fulfill the stipulation of the called modus operandi.A stipulation is an averment evaluated at entry to a method before any of the codification in the method organic structure executes. It expresses restraints on message statement values and object province required for right executing.PostconditionsProperties that must keep after the modus operandi is finished put to deathingProperties that the everyday warrants when it returns.

Properties that are ensured in return by the executing of the callA postcondition expresses belongingss of the province ensuing from a modus operandi ‘s executing.The presence of a postcondition clause in a everyday expresses a warrant on the portion of the modus operandi ‘s implementor that the modus operandi will give a province satisfying certain belongingss, presuming it has been called with the stipulation satisfied.A postcondition defines belongingss that must keep when a method completes. It is evaluated after a method finishes put to deathing and before the message consequence is returned to the client. Postcondition look intoing ensures that values bound to the outgoing message statements are acceptable given the current province of the object and the message that activated it.

It verifies that the waiter ‘s promise is met.

What is a contract

A contract specifies the relationship between the client ( company ) and the provider ( called modus operandi ) .In dealingss between people or companies, a contract is a written papers that serves to clear up the footings of a relationship.A precondition-postcondition brace for a modus operandi will depict the contract that the modus operandi ( the provider of a certain service ) defines for its companies ( the clients of the service ) .Possibly the most typical characteristic of contracts as they occur in human personal businesss is that any good contract entails duties every bit good as benefits for both parties – with an duty for one normally turning into a benefit for the other. This is true in contracts between categories, excessively:

  • The stipulation binds the client: it defines the conditions under which a call to the modus operandi is legitimate. It is an duty for the client and a benefit for the provider.
  • The postcondition binds the category: it defines the conditions that must be ensured by the modus operandi on return.

    It is a benefit for the client and duty for the provider.

The benefits are, for the client, the warrant that certain belongingss will keep after the call ; for the provider, the warrant that certain premises will be satisfied whenever the modus operandi is called. The duties are, for the client, to fulfill the demands as stated by the stipulation ; for the provider, to make the occupation as stated by the postcondition.

Two major belongingss characterize human contracts affecting two parties:

  • Each party expects benefits from the contract and is prepared to incur some duties to obtain them
  • These benefits and duties are documented in a contract papers.

A contract papers protects both sides:

  • It protects the client by stipulating how much should be done: The client is entitled to have a certain consequence.
  • It protects the contractor by stipulating how small is acceptable: the contractor must non be apt for neglecting to transport out undertakings outside of the specified range.

Here is a contract ( illustration )

What are averments

A contract is expressed utilizing averments. An averment is a Boolean look. It is distinguished in stipulation, postcondition and category invariant in the context of object oriented scheduling linguistic communications.Let A be some operation.

A correctness expression is an look of the signifier { P } A { Q } denoting the following belongings which may or may non keep: Any executing of A, get downing in a province where P holds, will end in a province where Q holds. ( Hoare triples ) .Assertions as a tool for composing right packageUsing averments for certificationSupport for proving, debugging and quality confidenceSupport for package mistake tolerance.Class invariantsProperties that must keep after the creative activity of an case of a category and before and after the executing of a modus operandiPreconditions and postconditions describe the belongingss of single modus operandis. There is besides a demand for showing planetary belongingss of the case of a category, which must be preserved by all modus operandis.

Such belongingss will do up the category invariant, capturing the deeper semantic belongingss and unity restraints qualifying a category.A category invariant is such an averment, showing general consistence restraints that apply to every category case as a whole ; this is different from stipulations and postconditions, which characterize single modus operandis.An invariant of a category C is set of averments that every case of C will fulfill at all stallss times. Stable times are those in which the case is in discernible stat:

  • On case creative activity,
  • Before and after every remote call to a modus operandi of the category

Two belongingss characterize a category invariant:

  • The invariant must be satisfied after the creative activity of every case of the category
  • The invariant must be preserved by every exported modus operandi of the category. Any such everyday must vouch that the invariant is satisfied on issue if it was satisfied on entry.

In consequence the invariant is added to the stipulation and postcondition of every exported modus operandi of the category. But the invariant characterizes the category as a whole instead than its single modus operandis.Invariants have a clear reading in the contract metaphor. Human contracts frequently contain mentions to general clauses or ordinances that apply to all contracts within a certain class ; invariants play a similar function for package contracts: the invariant of a category affects all the contracts between a modus operandi of the category and a client. The correctness demand on the modus operandi may be expressed, utilizing the notation introduced earlier in this chapter, as: { INV and pre } organic structure { INV and station }A Class invariant specifies belongingss that must be true of every object of a category. The category invariant must be true after instantiation, upon entry and issue signifier every method and merely before devastation. It must keep for all methods, over all activation sequences and for any valid value of incoming statementsThe complete stipulation for a method is pre and inv that is the category invariant and the stipulation must both be true at entry.

The complete postcondition for a method is post and inv. That is the invariant than the postcondition must both be true ate issue.Bibliography1. N. Gupta, Y.L. , J.

Mayer. Proceedings of the 3rd international workshop on Software quality confidence. 2006. Portland, Oregon: ACM.

2. William A, W. , Jr. and B. Venkataraman, Some observations on package quality, in Proceedings of the thirty-seventh one-year Southeast regional conference ( CD-ROM ) .

1999, ACM. p. 2.

3. Wikipedia. Mars_Climate_Orbiter. [ cited 2009 August ] ; Available from: hypertext transfer protocol: //en. Zhivich, M. and R.K. Cunningham, The Real Cost of Software Errors. Security & A ; Privacy, IEEE, 2009.

7 ( 2 ) : p. 87-90.5. Wikipedia. MIM-104_Patriot. [ cited 2009 August ] ; Available from: hypertext transfer protocol: //

6. Wikipedia. Therac-25. [ cited 2009 August ] ; Available from: hypertext transfer protocol: //

Leveson, N.G. and C.S. Turner, An probe of the Therac-25 accidents. Computer, 1993. 26 ( 7 ) : p. 18-41.

8. Pingdom, R. 10 historical package bugs with utmost effects.

March 19th, 2009 [ cited 2009 August ] ; Available from: hypertext transfer protocol: // .9. Garfinkel, S. History ‘s Worst Software Bugs. 11.

08.2005 [ cited 2009 August ] ; Available from: hypertext transfer protocol: // Sommerville, I. , Software Engineering ( 8th Edition ) .

2007: Addison Wesley.11. Kitchenham, B. and S.

L. Pfleeger, Software Quality: The Elusive Target. IEEE Softw. , 1996.

13 ( 1 ) : p. 12-21.12. Wong, B.

, et al. , Second Workshop on Software Quality, in Proceedings of the 26th International Conference on Software Engineering. 2004, IEEE Computer Society. p.

780-782.13. Musa, J.D. , Software quality and dependability rudimentss, in Proceedings of the 1987 Fall Joint Computer Conference on Exploring engineering: today and tomorrow. 1987, IEEE Computer Society Press: Dallas, Texas, United States. p. 114-115.

14. Pressman, R.S. , Software Engineering: A Practitioner ‘s Approach.

5th edition erectile dysfunction. 2001: McGraw-Hill Higher Education.15.

Beizer, B. , Software system proving and quality confidence. 1984: Van Nostrand Reinhold Co. 358.16. Pan, J. Software Reliability.

1999 [ cited 2009 August ] ; Available from: hypertext transfer protocol: // .17.

Boehm, B.W. , J.

R. Brown, and M. Lipow, Quantitative rating of package quality, in Proceedings of the 2nd international conference on Software technology. 1976, IEEE Computer Society Press: San Francisco, California, United States. p.

592-605.18. McConnell, S. , Code Complete, Second Edition.

2004: Microsoft Press.19. Goel, A.L.

, Software Reliability Models: Premises, Limitations, and Applicability. Software Engineering, IEEE Transactions on, 1985. SE-11 ( 12 ) : p. 1411-1423.20. Boehm, B.W.

, Software technology, in Classicss in package technology. 1979, Yourdon Press. p. 323-361.21. Meyer, B.

, Object-oriented package building ( 2nd ed. ) . 1997: Prentice-Hall, Inc. 1254.

22. Meyer, B. , Applying “ Design by Contract ” . Computer, 1992. 25 ( 10 ) : p. 40-51.23.

Wikipedia. Abstract Data Type. [ cited 2009 August ] ; Available from: hypertext transfer protocol: //


I'm Ruth!

Would you like to get a custom essay? How about receiving a customized one?

Check it out