1. 1 Chapter 3 Critical Systems (cont.)

2. 2 Safety Safety is a property of a system that reflects the system’s ability to operate, normally or abnormally, without danger of causing human death and without damage to the system’s environment Software control is much harder than Hardware control to any system.

3. 3 Primary safety-critical systems Embedded software systems whose failure can cause the associated hardware to fail and directly threaten people or environment. Secondary safety-critical systems Software Systems whose failure results in faults in other systems which can threaten people (indirect way) Example: Error in Medical database that holds details about the drugs Discussion here focuses on primary safety-critical systems Safety-criticality software Classes

4. 4 Safety and reliability are related but distinct In general, reliability and availability are necessary but not sufficient conditions for system safety Safety and reliability

5. 5 Specification errors If the system specification is incorrect or incomplete for critical situation then the system can behave as specified but still cause an accident Hardware failures generating spurious inputs Hardware error may generate a signals that are outside the ranges that can be handled by the software. Context-sensitive commands i.e. issuing the right command at the wrong time Often the result of operator error Several reasons why reliable systems are not necessary safe ???

6. 6 Safety achievement (The keys to assuring the safety?) Hazard avoidance تجنب الخطر The system is designed so that some classes of hazard simply cannot arise. Ex: Cutting system. Hazard detection and removal The system is designed so that hazards are detected and removed before they result in an accident Ex: chemical plant system detect excessive pressure and open a valve to reduce the pressure. Damage limitation The system includes protection features that minimise the damage that may result from an accident Ex: aircraft engine include automatic fire extinguisher.

7. 7 Normal accidents Almost all accidents are a result of combinations of malfunctions الأعطال Designing systems so that a single point of failure does not cause an accident is a fundamental principle of safe systems design

8. 8 Security The security of a system is a system property that reflects the system’s ability to protect itself from accidental or external attack Security is becoming increasingly important as systems are networked so that external access to the system through the Internet is possible Security is an essential pre-requisite for availability, reliability and safety

9. 9 Three types of damage that caused from insecurity or external attack?? Denial of service The system is forced into a state where its normal services are unavailable Corruption of programs or data The programs or data in the system may be modified in an unauthorised way, affect on the availability and reliability of system. Disclosure of confidential information Information that is managed by the system may be exposed to people who are not authorised to read or use that information, affect on the availability and reliability of system.

10. 10 Security assurance Vulnerability avoidance The system is designed so that vulnerabilities (weakness in computer-based system) do not occur. For example, if there is no external network connection then external attack is impossible Attack detection and elimination The system is designed to detect vulnerabilities. For example, virus checkers find and remove viruses before they infect a system

11. 11 Chapter 4 - Part 1 Software Processes

12. 12 Software Processes Software Processes is: Coherent (logically connected) sets of activities for specifying, designing, implementing, testing and evolution software systems Specification, functionality and constraints must be defined. Design and implementation, software meet the specification must be produced. Validation, it does what the customer wants. Evolution, must evolve to meet changes.

13. 13 software process model A software process model is an abstract representation of a process. It presents a description of a process. There are two types of modeles: Prescriptive process models advocate an orderly approach to software engineering Dynamic Process Models/ Methodologies Dynamic Methodology = {Dynamic Activity} + {Dynamic CR}

14. 14 Software process models That leads to a few questions … If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?  Dynamic Process Model

15. 15 Generic software process models The waterfall model Separate and distinct phases of specification and development Incremental model RAD model (Rapid Application Development) Evolutionary development Specification and development are interleaved Formal systems development A mathematical system model is formally transformed to an implementation Reuse-based development The system is assembled from existing components

16. 16 Waterfall model

17. 17 Waterfall model phases (activities) Requirements definition: services, constraints, and goals are established. System and software design: partitions requirements, identifying and describing the subsystems of the software and their relationships. Implementation and unit testing: construction of programs and programs testing. Integration and system testing: integrate and test the complete system Operation and maintenance: install the system, correct errors, and enhance the system performance and services. (This is the longest phase.)

18. 18 Waterfall model Linear sequential model Distinct stages with deliverables at the end of each phase The main advantage : Each phase is terminated with the approval of a document. high process visibility—it is easy to see where in the process you are.

19. 19 Waterfall model problems The drawback of the waterfall model is the difficulty of making changes after the process is underway Therefore, this model is only appropriate when the requirements are well-understood The waterfall model is mostly used when the project is part of a larger systems engineering projects where a system is developed at several sites.

20. 20 Evolutionary development Is based on the idea of developing an initial implementation, exposing this to user and refining it through many versions until a system has been developed.

21. 21 Evolutionary Models: Prototyping

22. 22 Evolutionary Models: The Spiral

23. 23 Evolutionary Models: Concurrent

24. 24 Evolutionary Models: Concurrent

25. 25 Evolutionary development-types Exploratory development Should start with well-understood requirements, and work with the customer to explore their requirements to deliver a final system. The system evolves by adding a new feature proposed by the customer. Throw-away prototyping Objective is to understand the customer’s requirements and develop a better requirements for the system. Should start with poorly understood requirements

26. 26 Evolutionary development Advantages: More effective than waterfall because it meets the immediate needs of customers. The specification can be developed incrementally. Problems: Lack of process visibility(manager needs a regular deliverables to measure progress) Systems are often poorly structured (continual changes tend to corrupt the software structure ) Applicability: For small or medium-size interactive systems For parts of large systems (e.g. the user interface)

27. 27 Evolutionary development For large system, it is better to use a mixed process between waterfall and evolutionary. How? We develop a system using throw-away prototyping to resolve the uncertainties in the system specification then re-implement using waterfall for a parts of the system that are well understood and other parts (user interface ) should be developed using the exploratory approach.