14.9 Software Reliability:


Published on

  • if u have any report on software reliability analysis then pls mail me on shethpari4@gmail.com
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

14.9 Software Reliability:

  1. 1. 14.9 Software Reliability www.ICT-Teacher.com
  2. 2. Objectives <ul><li>Describe methods of ensuring that software is reliable: α testing, β testing, agreements between software houses and purchaser for testing. </li></ul><ul><li>Understand the reasons why fully-tested software may fail to operate successfully when implemented as part of an information technology system. </li></ul><ul><li>Understand the need for maintenance release(s). </li></ul>
  3. 3. Software Reliability <ul><li>Testing of the reliability is done before it is released to remove errors or bugs, or if a bespoke software to test it meets all of the users requirements. </li></ul><ul><li>Software is run in simulated conditions of real use to test how it works. </li></ul><ul><li>Debugging is where specific parts of the program is checked it performs properly. </li></ul><ul><li>Bugs are hard to find as they may only present themselves in certain conditions. </li></ul><ul><li>While it can never be guaranteed that all bugs are removed, there comes a point where the searching is not cost effective. </li></ul>
  4. 4. Bugs <ul><li>It is important to remove as many as possible as some could have far reaching effects. </li></ul><ul><li>The software developer may lose credibility if it gets a name for unreliable software, and one that produces almost faultless software will gain credibility. </li></ul><ul><li>Likely areas where bugs may occur, i.e. difficult to program areas, need more vigorous testing. </li></ul><ul><li>Traces of how the software runs are also important. </li></ul>
  5. 5. Objectives of Testing <ul><li>The software should run faultlessly with other software systems on the computers. </li></ul><ul><li>The software should be checked on how it will be used, to predict where errors could occur, and design tests for these areas. </li></ul><ul><li>The software should be tested for portability on different hardware and software platforms it is likely to come in contact with. </li></ul><ul><li>The software should be reviewed by managers and other users to determine if it passes the various tasks it has to perform at different levels. </li></ul>
  6. 6. Testing <ul><li>Unit testing: </li></ul><ul><ul><li>Individual components are tested. </li></ul></ul><ul><li>Module testing: </li></ul><ul><ul><li>A collection of dependent components are tested. </li></ul></ul><ul><li>Subsystem testing: </li></ul><ul><ul><li>Collections of modules are tested. </li></ul></ul><ul><li>System testing: </li></ul><ul><ul><li>Integrated subsystems into the full system tested. </li></ul></ul><ul><li>Acceptance testing: </li></ul><ul><ul><li>System tested with bits of real data by the buyer. </li></ul></ul>
  7. 7. Testing New Software Unit Testing Module Testing Sub-System Testing System Testing Acceptance Testing
  8. 8. Alpha Testing ά <ul><li>Alpha testing is done on software products before leaving the factory. </li></ul><ul><li>Alpha testing done to ensure the developer and the purchaser agree that everything required is present and working effectively. </li></ul><ul><li>Errors in the system requirements are identified at this stage, and some slight modifications are usually necessary as a compromise. </li></ul><ul><li>The purchaser may have asked for something that cannot have been done or the developer may have missed some details. </li></ul><ul><li>Alpha testing is normally simulated using the actual hardware and software configurations. </li></ul>
  9. 9. Beta Testing β <ul><li>Beta Testing is where a developed system is distributed to a few potential users for them to use and report back on the effectiveness and problems. </li></ul><ul><li>Generic software is tested in this way before being released for general sale. </li></ul><ul><li>Bespoke software will undergo a period of use to test all the function likely to be used under real conditions, problems are rectified and the product is sold to the purchasers. The product may be tested and modified a number of times before it is ready to be sold. </li></ul>
  10. 10. Software Maintenance <ul><li>All software needs maintenance. </li></ul><ul><li>Maintenance may be required for a number of reasons: </li></ul><ul><ul><li>New errors discovered, </li></ul></ul><ul><ul><li>The original requirements have changed, </li></ul></ul><ul><ul><li>New hardware system in place, </li></ul></ul><ul><ul><li>New legislation meaning changes to the software system. </li></ul></ul>
  11. 11. Maintenance Categories <ul><li>Perfective Maintenance: </li></ul><ul><ul><li>The system can be improved without changing the functionality. </li></ul></ul><ul><li>Adaptive Maintenance: </li></ul><ul><ul><li>The system can be adapted due to changing needs or changing procedures. </li></ul></ul><ul><li>Corrective Maintenance: </li></ul><ul><ul><li>The system can be corrected of its previously undetected errors, done by maintenance releases (patches). </li></ul></ul>
  12. 12. Maintenance Releases <ul><li>A maintenance release is done to improve the quality of the existing software, (speed, functions), and to remove bugs. </li></ul><ul><li>Patches of code is normally downloaded from the developers’ websites and is saved alongside the original program. </li></ul><ul><li>Organisations may receive these direct from the developers, or programmers may install them. </li></ul>
  13. 13. Maintenance <ul><li>Maintenance is very costly, it can become the greatest cost in the systems lifecycle. </li></ul><ul><li>It is cost effective to put time and effort into developing systems which match the requirements with the least amount of bugs possible. </li></ul><ul><li>It is also cost effective to see into the future and choose a system that will evolve with the needs of the organisations that use them. </li></ul>
  14. 14. Lehman and Belady 1985 <ul><li>Laws of Software maintenance: </li></ul><ul><li>Law of continuing change: - change or become progressively useless. </li></ul><ul><li>Law of increasing complexity: - evolution creates more complex programs. </li></ul><ul><li>Law of large program evolution: - evolution creates larger programs which contain more bugs. </li></ul><ul><li>Law of organisational stability: - development is constant and independent of the resources devoted. </li></ul><ul><li>Law of conservation of familiarity: - the incremental change in each release is approximately constant. </li></ul>
  15. 15. <ul><li>Pages: </li></ul><ul><li>Doyle: 285 - 287. </li></ul><ul><li>Heathcote: 335 - 339. </li></ul><ul><li>Activity: 287. </li></ul>