Critical systems developmentObjectivesTopics coveredSoftware dependabilityDependability achievementDiversity and redundancyDiversity and redundancy examplesFault-free softwareFault-free software developmentFault removal costsDependable processesDependable process characteristicsValidation activitiesDependable programmingInformation protectionA queue specification in JavaSignal declaration in JavaSafe programmingStructured programmingError-prone constructsSlide 21Exception handlingExceptions in Java 1Exceptions in Java 2A temperature controllerFreezer controller 1Freezer controller 2Fault toleranceFault tolerance actionsFault detection and damage assessmentInsulin pump state constraintsFault detectionType system extensionPositiveEvenInteger 1PositiveEvenInteger 2Damage assessmentRobust array 1Robust array 2Damage assessment techniquesFault recovery and repairForward recoveryBackward recoverySafe sort procedureSafe sort 1Safe sort 2Fault tolerant architectureHardware fault toleranceHardware reliability with TMROutput selectionFault tolerant software architecturesDesign diversitySoftware analogies to TMRN-version programmingOutput comparisonSlide 55Recovery blocksSlide 57Problems with design diversitySpecification dependencyKey pointsSlide 61©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide 1Critical systems development©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide 2ObjectivesTo explain how fault tolerance and fault avoidance contribute to the development of dependable systemsTo describe characteristics of dependable software processesTo introduce programming techniques for fault avoidanceTo describe fault tolerance mechanisms and their use of diversity and redundancy©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide 3Topics coveredDependable processesDependable programmingFault toleranceFault tolerant architectures©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide 4Software dependabilityIn general, software customers expect all software to be dependable. However, for non-critical applications, they may be willing to accept some system failures.Some applications, however, have very high dependability requirements and special software engineering techniques may be used to achieve this.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide 5Dependability achievementFault avoidance•The system is developed in such a way that human error is avoided and thus system faults are minimised.•The development process is organised so that faults in the system are detected and repaired before delivery to the customer.Fault detection•Verification and validation techniques are used to discover and remove faults in a system before it is deployed.Fault tolerance•The system is designed so that faults in the delivered software do not result in system failure.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide 6Diversity and redundancyRedundancy•Keep more than 1 version of a critical component available so that if one fails then a backup is available.Diversity•Provide the same functionality in different ways so that they will not fail in the same way.However, adding diversity and redundancy adds complexity and this can increase the chances of error.Some engineers advocate simplicity and extensive V & V is a more effective route to software dependability.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide 7Diversity and redundancy examplesRedundancy. Where availability is critical (e.g. in e-commerce systems), companies normally keep backup servers and switch to these automatically if failure occurs.Diversity. To provide resilience against external attacks, different servers may be implemented using different operating systems (e.g. Windows and Linux)©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide 8Fault-free softwareCurrent methods of software engineering now allow for the production of fault-free software, at least for relatively small systems.Fault-free software means software which conforms to its specification. It does NOT mean software which will always perform correctly as there may be specification errors.The cost of producing fault free software is very high. It is only cost-effective in exceptional situations. It is often cheaper to accept software faults and pay for their consequences than to expend resources on developing fault-free software.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide 9Fault-free software developmentDependable software processesQuality managementFormal specificationStatic verificationStrong typingSafe programmingProtected information©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide 10Fault removal costsFewNumber of residual errorsMany Very few©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide 11Dependable processesTo ensure a minimal number of software faults, it is important to have a well-defined, repeatable software process.A well-defined repeatable process is one that does not depend entirely on individual skills; rather can be enacted by different people.For fault detection, it is clear that the process activities should include significant effort devoted to verification and validation.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide 12Dependable process characteristicsDocumentable The process should have a defined process model that sets outthe activities in the process and the documentation that is to beproduced during these activities.Standardised A comprehensive set of software development standards thatdefine how the software is to be produced and documentedshould be available.Auditable The process should be understandable by people apart fromprocess participants who can check that process standards arebeing followed and make suggestions for process improvement.Diverse The process should include redundant and diverse verificationand validation activities.Robust The process should be able to recover from failures ofindividual process activities.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 20 Slide