This document discusses software configuration management (SCM). It provides definitions of SCM from sources like IEEE standards and the SWEBOK. SCM is defined as the process of managing changes to software projects through their lifecycle. Key aspects of SCM discussed include configuration items, versions and variants, baselines, change requests, SCM tools, and the unified change management process.
The document discusses software quality assurance. It defines SQA as using planned and systematic methods to evaluate software quality, standards, processes, and procedures. This ensures development follows standards and procedures through continuous monitoring, product evaluation, and audits. SQA activities include product evaluation and monitoring to ensure adherence to development plans, as well as product audits to thoroughly review products, processes, and documentation against established standards. Software reviews are used to uncover errors and defects during development in order to "purify" software requirements, design, code, and testing data before release.
System dependability is a composite system property that reflects the degree of trust users have in a system. It is determined by availability, reliability, safety, and security. Dependability is subjective as it depends on user expectations - a system deemed dependable by one user may be seen as unreliable by another if it does not meet their expectations. Formal specifications of dependability do not always capture real user experiences.
This document provides an overview of software maintenance. It discusses that software maintenance is an important phase of the software life cycle that accounts for 40-70% of total costs. Maintenance includes error correction, enhancements, deletions of obsolete capabilities, and optimizations. The document categorizes maintenance into corrective, adaptive, perfective and preventive types. It also discusses the need for maintenance to adapt to changing user requirements and environments. The document describes approaches to software maintenance including program understanding, generating maintenance proposals, accounting for ripple effects, and modified program testing. It discusses challenges like lack of documentation and high staff turnover. The document also introduces concepts of reengineering and reverse engineering to make legacy systems more maintainable.
Maintenance involves keeping software or assets in working condition. There are four main types of maintenance: corrective, adaptive, preventive, and perfective. Maintenance is needed to fix problems, adapt to new environments, prevent issues, and improve performance. While necessary, maintenance is costly due to the work required to modify existing software. Efforts like designing for change and documentation can help reduce these costs. Overall, maintenance plays a critical role in maximizing the usefulness of software over its lifetime.
Reliability testing is critical for new component qualification, design change validation, or field failure simulation for root cause analysis. In many cases, with tight project schedules and scarce available resources, some important critical characteristics of a component or subsystem are overlooked. This will potentially result in new failure modes after implementing changes in production. The author will explain how to develop an effective test plan using the 6σ (Six Sigma) problem solving process, IDOV (Identify, Design, Optimize and Validation), to make the testing simple but efficient.
Quality, quality concepts
Software Quality Assurance
Software Reviews
Formal Technical Reviews
SQA Group Plan
ISO 9000, 9001
Example
Internal and external attributes
This document discusses software configuration management (SCM). It provides definitions of SCM from sources like IEEE standards and the SWEBOK. SCM is defined as the process of managing changes to software projects through their lifecycle. Key aspects of SCM discussed include configuration items, versions and variants, baselines, change requests, SCM tools, and the unified change management process.
The document discusses software quality assurance. It defines SQA as using planned and systematic methods to evaluate software quality, standards, processes, and procedures. This ensures development follows standards and procedures through continuous monitoring, product evaluation, and audits. SQA activities include product evaluation and monitoring to ensure adherence to development plans, as well as product audits to thoroughly review products, processes, and documentation against established standards. Software reviews are used to uncover errors and defects during development in order to "purify" software requirements, design, code, and testing data before release.
System dependability is a composite system property that reflects the degree of trust users have in a system. It is determined by availability, reliability, safety, and security. Dependability is subjective as it depends on user expectations - a system deemed dependable by one user may be seen as unreliable by another if it does not meet their expectations. Formal specifications of dependability do not always capture real user experiences.
This document provides an overview of software maintenance. It discusses that software maintenance is an important phase of the software life cycle that accounts for 40-70% of total costs. Maintenance includes error correction, enhancements, deletions of obsolete capabilities, and optimizations. The document categorizes maintenance into corrective, adaptive, perfective and preventive types. It also discusses the need for maintenance to adapt to changing user requirements and environments. The document describes approaches to software maintenance including program understanding, generating maintenance proposals, accounting for ripple effects, and modified program testing. It discusses challenges like lack of documentation and high staff turnover. The document also introduces concepts of reengineering and reverse engineering to make legacy systems more maintainable.
Maintenance involves keeping software or assets in working condition. There are four main types of maintenance: corrective, adaptive, preventive, and perfective. Maintenance is needed to fix problems, adapt to new environments, prevent issues, and improve performance. While necessary, maintenance is costly due to the work required to modify existing software. Efforts like designing for change and documentation can help reduce these costs. Overall, maintenance plays a critical role in maximizing the usefulness of software over its lifetime.
Reliability testing is critical for new component qualification, design change validation, or field failure simulation for root cause analysis. In many cases, with tight project schedules and scarce available resources, some important critical characteristics of a component or subsystem are overlooked. This will potentially result in new failure modes after implementing changes in production. The author will explain how to develop an effective test plan using the 6σ (Six Sigma) problem solving process, IDOV (Identify, Design, Optimize and Validation), to make the testing simple but efficient.
Quality, quality concepts
Software Quality Assurance
Software Reviews
Formal Technical Reviews
SQA Group Plan
ISO 9000, 9001
Example
Internal and external attributes
This document discusses defect prevention as a way to reduce costs and enhance quality in software development. It notes that preventing defects is better than fixing them later. The key points made include:
- Defects are imperfections that cause software to fail to meet expectations. Most defects are introduced early but found later in the process.
- Defect prevention identifies root causes through analysis of past defects to prevent recurrences. This improves productivity and reduces rework.
- Fixing defects gets significantly more expensive later in the process, from design to maintenance. Methods of prevention include reviews, inspections, walkthroughs, logging defects, and root cause analysis techniques like Pareto analysis and fishbone diagrams.
-
The document discusses establishing a Testing Center of Excellence (TCoE) to address issues like lack of uniform testing processes, inadequate automation, and lack of metrics. It outlines the key components of a TCoE including expertise, process improvement, knowledge management, and tools. It also discusses how to build a TCoE through proof of concept, knowledge management, training, measurement, and continuous improvement. Finally, it emphasizes the importance of fully understanding objectives, having a pragmatic roadmap, positioning the TCoE as evolutionary, and defining a strong business case to show value.
The document discusses software quality management and outlines five units: introduction to software quality; software quality assurance; quality control and reliability; quality management systems; and quality standards. It defines quality, discusses hierarchical models of quality including those proposed by Boehm and McCall, and explains techniques for improving software quality like metrics, reviews, and standards.
This document discusses the fundamentals of software quality assurance including ethical bases, quality concepts, quality control, quality assurance, cost of quality, and total quality management principles. It defines key terms like quality, quality control, quality assurance, defines two types of quality (design and conformance), and describes the goals and tasks of quality assurance groups to help software engineering teams achieve high quality products.
Develop a Defect Prevention Strategy—or Else!TechWell
This document discusses the importance of defect prevention in software development. It notes that testing schedules are longer and more costly for low-quality projects compared to high-quality projects. The document advocates shifting investments from failure activities like testing to prevention activities earlier in the lifecycle like requirements reviews and static analysis. A framework is presented for establishing a defect prevention program that includes establishing teams, providing training, and measuring prevention efforts. Specific prevention techniques discussed include code reviews, static analysis, and addressing requirement ambiguities.
The document discusses various types of non-functional testing including performance, reliability, maintainability, availability, recovery, usability, configuration, and security testing. It provides definitions and examples of how to test each type of non-functional requirement. Performance testing aims to evaluate how well a system performs under different loads, and involves measuring response times, throughput, and resource utilization. Non-functional requirements are as important as functional requirements in building quality software.
This document discusses software testability. It defines testability and explains why it is important. High testability results in more effective testing and lower costs. Testability is improved by controllability, observability, availability, simplicity, stability, information, and operability. A tool called Testability-Explorer can analyze testability and produce a testability report. The document concludes that designing for testability helps produce high quality software.
Verification ensures software meets specifications, while validation ensures it meets user needs. Both establish software fitness for purpose. Verification includes static techniques like inspections and formal methods to check conformance pre-implementation. Validation uses dynamic testing post-implementation. Techniques include defect testing to find inconsistencies, and validation testing to ensure requirements fulfillment. Careful planning via test plans is needed to effectively verify and validate cost-efficiently. The Cleanroom methodology applies formal specifications and inspections statically to develop defect-free software incrementally.
Software Reliability is the probability of failure-free software operation for a specified period of time in a specified environment. Software Reliability is also an important factor affecting system reliability. ... The high complexity of software is the major contributing factor of Software Reliability problems.
The document provides an overview of testing practices and services at Birlasoft focused on the financial services industry. It lists key service areas including application development, validation, verification, and maintenance. It also lists industry experience in areas like mortgages, loans, credit cards, and wealth management. Finally, it outlines various testing types and solutions offered as well as examples of clients.
Power point presentation on backup and recovery.
A good presentation cover all topics.
For any other type of ppt's or pdf's to be created on demand contact -dhawalm8@gmail.com
mob. no-7023419969
This document discusses requirements specification for critical systems. It covers dependability requirements, risk-driven specification, safety specification, security specification, system reliability specification, and non-functional reliability requirements. For risk-driven specification, it describes the stages of risk identification, analysis and classification, decomposition, and risk reduction assessment. It provides examples of applying this process to an insulin pump. For safety specification, it discusses safety requirements, the safety life cycle, and the IEC 61508 standard. For security specification, it outlines a similar process to safety with stages of asset identification, threat analysis, and security requirements specification. It also discusses different types of security requirements.
The document summarizes topics related to real-time software engineering including embedded system design, architectural patterns for real-time software, timing analysis, and real-time operating systems. It discusses key characteristics of embedded systems like responsiveness, the need to respond to stimuli within specified time constraints, and how real-time systems are often modeled as cooperating processes controlled by a real-time executive. The document also outlines common architectural patterns for real-time systems including observe and react, environmental control, and process pipeline.
The document provides information on various quality models and standards including Six Sigma, Total Quality Management (TQM), ISO 9001. It discusses the goals, methodology, and evolution of Six Sigma. It explains the key principles and structure of TQM and ISO 9001. It also provides a case study on how Toyota has implemented TQM based on principles of customer focus, continuous improvement, and total participation.
This document discusses software reliability growth models, which use system test data to predict the number of defects remaining in software and determine if the software is ready to ship. Most models have a parameter related to the total number of defects. Knowing the number of residual defects helps decide how much more testing is needed. Examples of models include the Goel-Okumoto model, which models the failure rate as approaching a total number of defects over time. The assumptions of the Goel-Okumoto model include that failure times are exponentially distributed and the number of failures follows a non-homogeneous Poisson process.
The document discusses various software testing strategies and techniques including unit testing, integration testing, validation testing, and smoke testing. It also covers test team roles, documenting test cases, debugging approaches, and when testing is considered complete. The main goals of testing are to find defects, validate that requirements have been met, and ensure proper functionality and performance. A variety of testing tools and strategies can be used including simulators, monitors, analyzers, and test data generators.
The document provides an overview of software design principles and system models. It discusses the objectives of understanding software design principles and following a structured approach. It describes different system models including data processing, composition, classification, and stimulus-response models. It also covers architectural design, explaining that it is the initial design process that identifies subsystems and establishes a framework for control and communication. It discusses system structuring, control models, and modular decomposition as part of the architectural design process.
This document provides an overview of advanced software engineering and software process improvement (SPI). It discusses SPI frameworks like the Capability Maturity Model (CMM) and defines what SPI entails. The document outlines the five activities in the SPI process: assessment and gap analysis, education and training, selection and justification, installation/migration, and evaluation. It also discusses SPI risks, success factors, maturity models, and returns on investment. Finally, it covers the People CMM and trends toward more agile SPI approaches.
Software re-engineering is a process of examining and altering a software system to restructure it and improve maintainability. It involves sub-processes like reverse engineering, redocumentation, and data re-engineering. Software re-engineering is applicable when some subsystems require frequent maintenance and can be a cost-effective way to evolve legacy software systems. The key advantages are reduced risk compared to new development and lower costs than replacing the system entirely.
This document discusses software quality assurance. It defines software quality and describes two types - quality of design and quality of conformance. It discusses quality concepts at the organizational, project, and process levels. It also describes software reviews, their types and purposes. Software quality assurance aims to establish organizational procedures and standards to achieve high quality software. Key SQA activities include applying technical methods, reviews, testing, enforcing standards and measurement.
This document discusses defect prevention as a way to reduce costs and enhance quality in software development. It notes that preventing defects is better than fixing them later. The key points made include:
- Defects are imperfections that cause software to fail to meet expectations. Most defects are introduced early but found later in the process.
- Defect prevention identifies root causes through analysis of past defects to prevent recurrences. This improves productivity and reduces rework.
- Fixing defects gets significantly more expensive later in the process, from design to maintenance. Methods of prevention include reviews, inspections, walkthroughs, logging defects, and root cause analysis techniques like Pareto analysis and fishbone diagrams.
-
The document discusses establishing a Testing Center of Excellence (TCoE) to address issues like lack of uniform testing processes, inadequate automation, and lack of metrics. It outlines the key components of a TCoE including expertise, process improvement, knowledge management, and tools. It also discusses how to build a TCoE through proof of concept, knowledge management, training, measurement, and continuous improvement. Finally, it emphasizes the importance of fully understanding objectives, having a pragmatic roadmap, positioning the TCoE as evolutionary, and defining a strong business case to show value.
The document discusses software quality management and outlines five units: introduction to software quality; software quality assurance; quality control and reliability; quality management systems; and quality standards. It defines quality, discusses hierarchical models of quality including those proposed by Boehm and McCall, and explains techniques for improving software quality like metrics, reviews, and standards.
This document discusses the fundamentals of software quality assurance including ethical bases, quality concepts, quality control, quality assurance, cost of quality, and total quality management principles. It defines key terms like quality, quality control, quality assurance, defines two types of quality (design and conformance), and describes the goals and tasks of quality assurance groups to help software engineering teams achieve high quality products.
Develop a Defect Prevention Strategy—or Else!TechWell
This document discusses the importance of defect prevention in software development. It notes that testing schedules are longer and more costly for low-quality projects compared to high-quality projects. The document advocates shifting investments from failure activities like testing to prevention activities earlier in the lifecycle like requirements reviews and static analysis. A framework is presented for establishing a defect prevention program that includes establishing teams, providing training, and measuring prevention efforts. Specific prevention techniques discussed include code reviews, static analysis, and addressing requirement ambiguities.
The document discusses various types of non-functional testing including performance, reliability, maintainability, availability, recovery, usability, configuration, and security testing. It provides definitions and examples of how to test each type of non-functional requirement. Performance testing aims to evaluate how well a system performs under different loads, and involves measuring response times, throughput, and resource utilization. Non-functional requirements are as important as functional requirements in building quality software.
This document discusses software testability. It defines testability and explains why it is important. High testability results in more effective testing and lower costs. Testability is improved by controllability, observability, availability, simplicity, stability, information, and operability. A tool called Testability-Explorer can analyze testability and produce a testability report. The document concludes that designing for testability helps produce high quality software.
Verification ensures software meets specifications, while validation ensures it meets user needs. Both establish software fitness for purpose. Verification includes static techniques like inspections and formal methods to check conformance pre-implementation. Validation uses dynamic testing post-implementation. Techniques include defect testing to find inconsistencies, and validation testing to ensure requirements fulfillment. Careful planning via test plans is needed to effectively verify and validate cost-efficiently. The Cleanroom methodology applies formal specifications and inspections statically to develop defect-free software incrementally.
Software Reliability is the probability of failure-free software operation for a specified period of time in a specified environment. Software Reliability is also an important factor affecting system reliability. ... The high complexity of software is the major contributing factor of Software Reliability problems.
The document provides an overview of testing practices and services at Birlasoft focused on the financial services industry. It lists key service areas including application development, validation, verification, and maintenance. It also lists industry experience in areas like mortgages, loans, credit cards, and wealth management. Finally, it outlines various testing types and solutions offered as well as examples of clients.
Power point presentation on backup and recovery.
A good presentation cover all topics.
For any other type of ppt's or pdf's to be created on demand contact -dhawalm8@gmail.com
mob. no-7023419969
This document discusses requirements specification for critical systems. It covers dependability requirements, risk-driven specification, safety specification, security specification, system reliability specification, and non-functional reliability requirements. For risk-driven specification, it describes the stages of risk identification, analysis and classification, decomposition, and risk reduction assessment. It provides examples of applying this process to an insulin pump. For safety specification, it discusses safety requirements, the safety life cycle, and the IEC 61508 standard. For security specification, it outlines a similar process to safety with stages of asset identification, threat analysis, and security requirements specification. It also discusses different types of security requirements.
The document summarizes topics related to real-time software engineering including embedded system design, architectural patterns for real-time software, timing analysis, and real-time operating systems. It discusses key characteristics of embedded systems like responsiveness, the need to respond to stimuli within specified time constraints, and how real-time systems are often modeled as cooperating processes controlled by a real-time executive. The document also outlines common architectural patterns for real-time systems including observe and react, environmental control, and process pipeline.
The document provides information on various quality models and standards including Six Sigma, Total Quality Management (TQM), ISO 9001. It discusses the goals, methodology, and evolution of Six Sigma. It explains the key principles and structure of TQM and ISO 9001. It also provides a case study on how Toyota has implemented TQM based on principles of customer focus, continuous improvement, and total participation.
This document discusses software reliability growth models, which use system test data to predict the number of defects remaining in software and determine if the software is ready to ship. Most models have a parameter related to the total number of defects. Knowing the number of residual defects helps decide how much more testing is needed. Examples of models include the Goel-Okumoto model, which models the failure rate as approaching a total number of defects over time. The assumptions of the Goel-Okumoto model include that failure times are exponentially distributed and the number of failures follows a non-homogeneous Poisson process.
The document discusses various software testing strategies and techniques including unit testing, integration testing, validation testing, and smoke testing. It also covers test team roles, documenting test cases, debugging approaches, and when testing is considered complete. The main goals of testing are to find defects, validate that requirements have been met, and ensure proper functionality and performance. A variety of testing tools and strategies can be used including simulators, monitors, analyzers, and test data generators.
The document provides an overview of software design principles and system models. It discusses the objectives of understanding software design principles and following a structured approach. It describes different system models including data processing, composition, classification, and stimulus-response models. It also covers architectural design, explaining that it is the initial design process that identifies subsystems and establishes a framework for control and communication. It discusses system structuring, control models, and modular decomposition as part of the architectural design process.
This document provides an overview of advanced software engineering and software process improvement (SPI). It discusses SPI frameworks like the Capability Maturity Model (CMM) and defines what SPI entails. The document outlines the five activities in the SPI process: assessment and gap analysis, education and training, selection and justification, installation/migration, and evaluation. It also discusses SPI risks, success factors, maturity models, and returns on investment. Finally, it covers the People CMM and trends toward more agile SPI approaches.
Software re-engineering is a process of examining and altering a software system to restructure it and improve maintainability. It involves sub-processes like reverse engineering, redocumentation, and data re-engineering. Software re-engineering is applicable when some subsystems require frequent maintenance and can be a cost-effective way to evolve legacy software systems. The key advantages are reduced risk compared to new development and lower costs than replacing the system entirely.
This document discusses software quality assurance. It defines software quality and describes two types - quality of design and quality of conformance. It discusses quality concepts at the organizational, project, and process levels. It also describes software reviews, their types and purposes. Software quality assurance aims to establish organizational procedures and standards to achieve high quality software. Key SQA activities include applying technical methods, reviews, testing, enforcing standards and measurement.
IncQuery gets Sirius: faster and better diagramsÁkos Horváth
This document discusses using EMF-IncQuery (IQPL) as a query language for defining viewpoints in Sirius. It provides an overview of Sirius and EMF-IncQuery, demonstrates using IncQuery to define viewpoints over a model, and evaluates the performance of incremental updates. The integration allows for live synchronization of derived view models using incremental model queries.
Software Development for Safety Critical SystemsÁkos Horváth
This document discusses software development for safety critical systems. It covers:
- Special considerations for safety critical systems where malfunctions can cause injury, including design, verification, validation, certification to standards.
- The increasing complexity of avionics software over time with aircraft like the A380 and B787 having hundreds of millions of lines of code.
- Key aeronautical certification bodies and standards like the FAA, EASA, ICAO, DO-178B/C, and ARP-4754.
- Methodologies used in aeronautical system certification like fault tree analysis, common cause analysis, and design assurance levels (DAL).
- How certification aspects apply to both software and hardware and
This document discusses safety critical systems, which are systems whose failure or malfunction may result in death, serious injury, environmental harm, or severe damage. It provides examples of safety critical systems from the aviation industry, such as air traffic control systems, avionics like fly-by-wire systems, and engine control systems. The document outlines some key characteristics of safety critical systems, including constraints, specific/proprietary users, complexity, quality attributes, and volatility. It also discusses impacts like development methods and disciplines, as well as the role of automation.
Safety is defined as a system's ability to operate without causing human injury or environmental damage. Safety and reliability are related but distinct, as a reliable system can still be unsafe if requirements are incorrect. There are three approaches to safety critical systems development: hazard avoidance through design, hazard detection and removal before accidents occur, and damage limitation to minimize harm from any accidents.
This document discusses availability and reliability in systems. Availability is defined as the probability that a system will be operational to deliver requested services, while reliability is the probability of failure-free operation over time. Both can be expressed as percentages. Availability takes into account repair times, whereas reliability does not. Faults can lead to errors and failures if not addressed through techniques like fault avoidance, detection, and tolerance.
The document discusses dependability in systems. It covers topics like dependability properties, sociotechnical systems, redundancy and diversity, and dependable processes. Dependability reflects how trustworthy a system is and includes attributes like reliability, availability, and security. Dependability is important because system failures can have widespread impacts. Both hardware and software failures and human errors can cause systems to fail. Techniques like redundancy, diversity, and formal methods can help improve dependability. Regulation is also discussed as many critical systems require approval from regulators.
The document describes an insulin pump that measures a patient's blood sugar levels and automatically injects insulin to maintain safe levels. It functions by taking periodic glucose readings and comparing them to determine if insulin should be injected to counter rising sugar levels. The goal is to keep sugar within a safe band like a healthy pancreas would. The pump hardware, software requirements, and safety considerations are discussed to minimize risks like overdose or underdose from failures.
The chapter discusses software evolution, including that software change is inevitable due to new requirements, business changes, and errors. It describes how organizations must manage change to existing software systems, which represent huge investments. The majority of large software budgets are spent evolving, rather than developing new, systems. The chapter outlines the software evolution process and different approaches to evolving systems, including addressing urgent changes. It also discusses challenges with legacy systems and their management.
The document discusses critical systems and system dependability. It defines critical systems as systems where failure could result in significant economic losses, damage, or threats to human life. It describes four dimensions of dependability for critical systems: availability, reliability, safety, and security. It emphasizes that critical systems require trusted development methods to achieve high dependability.
This document introduces occupational safety and health (OSH). It defines OSH and explains its importance in protecting workers' basic human rights. The history of OSH is discussed, from early tragedies in the 1900s that led to new laws in 1970. Major safety terms are described, such as hazard, risk assessment, and proper safety procedures and monitoring. Accidents are classified as usually resulting from unsafe workplace conditions or unsafe acts by employees.
Safety-critical systems are computer systems whose failure could result in injury, death, or environmental damage. Examples include aircraft control systems, nuclear power plant controls, medical devices like pacemakers, and railway signaling systems. These systems require high integrity to avoid hazards and ensure safety. Techniques like developing diverse redundant systems can improve safety by detecting and tolerating a wider range of faults.
Dialysis various modalities and indices usedAbhay Mange
Dialysis is a process used to remove waste and excess water from the blood of patients with kidney failure. There are various modalities of dialysis including intermittent hemodialysis, peritoneal dialysis, and continuous renal replacement therapy. Hemodialysis uses diffusion and ultrafiltration across a semi-permeable membrane in a dialyzer to clean the blood. Proper vascular access and anticoagulation are also important aspects of hemodialysis treatment.
Industrial safety is primarily a management activity concerned with reducing, controlling, and eliminating hazards from industries. It is important because accidents can cause great losses to both employers and employees through costs of compensation, medical aid, training, lost time, investigations, and damage to machinery. The objectives of industrial safety are to prevent accidents, eliminate work stoppages, achieve lower insurance rates, prevent injury and disability, and promote safety awareness. Common causes of industrial accidents include unsafe conditions, equipment, acts, and psychological factors. Measures to ensure safety include safety policies, committees, engineering controls, training, and government oversight.
The Airport Authority of India operates most aspects of airports including air traffic control. It owns 122 airports, including 11 international and 82 domestic airports. The Authority's functions include controlling air traffic, operating and maintaining airports, and providing navigational aids to guide pilots. Radar systems are a key part of air traffic control and use radio waves to detect and track the range, altitude, direction or speed of aircraft and other objects. The Authority operates various types of radar systems and navigation aids to guide aircraft and measure distances.
The document discusses various methods for controlling hazards and minimizing damage from accidents. It describes approaches such as eliminating hazards, isolating hazards, using fail-safe designs, providing warning systems, establishing safe procedures, enabling recovery from near-misses, installing protective barriers, employing personal protective equipment, incorporating weak links, and planning escape and rescue procedures. The overall aim is to prevent accidents and further reduce damage if accidents do occur.
The document discusses industrial safety. It outlines the importance of industrial safety in reducing costs for employers and employees. It then discusses causes of industrial accidents, measures to ensure safety like safety policies and committees, and methods for measuring and recording accidents. Key safety rules from the Factories Act are also summarized.
The document discusses critical systems where failures can have severe consequences. It defines four dimensions of dependability - availability, reliability, safety, and security. Development methods for critical systems aim to avoid mistakes, detect and remove errors, and limit damage from failures. The dependability of a system reflects how much users trust that it will operate as expected without failures.
The document discusses critical systems where failures can have severe consequences. It defines four dimensions of dependability - availability, reliability, safety, and security. Development methods for critical systems aim to avoid mistakes, detect and remove errors, and limit damage from failures. The dependability of a system reflects how much users trust that it will operate as expected without failures.
Depandability in Software Engineering SE16koolkampus
The document discusses key concepts related to dependability in critical systems, including reliability, availability, safety, and security. It defines each concept and explains how they are related but distinct. For example, reliability is the probability that a system operates as intended, while safety ensures a system can operate without threatening people or the environment. The document also outlines approaches for achieving dependability, such as avoiding faults, detecting and removing errors, and limiting damage from failures or attacks.
This document outlines the syllabus for a course on Software Engineering and Project Management. It discusses various software development process models including the waterfall model, incremental process models, evolutionary process models, and agile development approaches. Specific models covered include the unified process, extreme programming, and scrum methodology. The document provides details on each model's phases and approach to software development. It also discusses topics like critical systems, system dependability, and reliability.
This document discusses the topics of security and dependability in computer systems. It defines dependability as comprising reliability, availability, safety, and security. These properties are interdependent and important for systems where failures could significantly impact users. The document outlines various dependability properties and how they are measured. It discusses how dependability is achieved through techniques like fault avoidance and tolerance. It also distinguishes between safety and reliability, defining safety as preventing harm even if a system fails. Key aspects of safety-critical systems and achieving safety are also covered.
Unit 2-software development process notes arvind pandey
Critical systems must be dependable to avoid catastrophic failures. Dependability encompasses availability, reliability, safety, and security. Availability refers to a system's ability to deliver services when requested, while reliability means delivering services correctly. Safety ensures excessive errors do not occur, as even one failure could endanger life. Development methods for critical systems aim to formally prove correctness due to high failure costs. An insulin pump example demonstrated how software controls a medical device, requiring stringent dependability to safely regulate insulin doses.
This document discusses software security engineering. It covers security concepts like assets, vulnerabilities and threats. It discusses why security engineering is important to protect systems from malicious attackers. The document outlines security risk management processes like preliminary risk assessment. It also discusses designing systems for security through architectural choices that provide protection and distributing assets. The document concludes by covering system survivability through building resistance, recognition and recovery capabilities into systems.
This document discusses the key aspects of system dependability, including availability, reliability, safety, and security. It notes that dependability reflects the degree to which users trust a system and defines it as covering attributes like availability, reliability, and security. It also discusses factors that influence perceptions of reliability and availability, such as usage patterns, outage length and number of users affected.
Reliability is the ability of a system or component to function under stated conditions for a specified period of time. There are several reasons why failures occur, including design flaws, overstressing, wear and tear, vibration, incorrect specifications, misuse, and operating outside intended environments. The objectives of reliability engineering are to prevent or reduce failures, identify and correct causes of failures, determine ways to cope with failures, and estimate reliability of new designs. Reliability is defined as the probability of success and avoids downtime, repair costs, and warranty claims. Modes of failure include initial infant mortality failures, random stable failures, and wear-out failures over time depicted by a bathtub curve. Reliability influences system
This document provides an overview of key topics from Chapter 11 on security and dependability, including:
- The principal dependability properties of availability, reliability, safety, and security.
- Dependability covers attributes like maintainability, repairability, survivability, and error tolerance.
- Dependability is important because system failures can have widespread effects and undependable systems may be rejected.
- Dependability is achieved through techniques like fault avoidance, detection and removal, and building in fault tolerance.
This document discusses critical systems and system dependability. It defines critical systems as those where failure could have severe consequences, such as safety-critical systems where failure could result in loss of life. It describes four dimensions of dependability for critical systems: availability, reliability, safety, and security. Availability and reliability refer to a system operating properly and delivering services as expected. Safety ensures a system cannot cause harm or damage. Security protects a system from external attacks. The document uses an insulin pump as an example of a safety-critical system to illustrate dependability requirements and discusses techniques for achieving dependability.
The document discusses faults, errors, and failures in systems. A fault is a defect, an error is unexpected behavior, and a failure occurs when specifications are not met. Fault tolerance allows a system to continue operating despite errors. Fault tolerant systems are gracefully degradable and aim to ensure small failure probabilities. Faults can be hardware or software issues. Various failure types and objectives of fault tolerance like availability and reliability are also described.
This document provides an overview of reliability engineering topics including software reliability, fault tolerance, and reliability requirements. It discusses key concepts such as availability, reliability, faults, errors and failures. It also describes different fault-tolerant system architectures and reliability metrics including probability of failure on demand, rate of occurrence of failures, and availability. Functional reliability requirements and examples are also presented relating to checking requirements, recovery requirements, redundancy requirements and development process requirements.
Reliability is a measure of how well a system performs its intended function under stated conditions for a specified period of time. It is dependent on factors like the operational profile, fault consequences, and perceived by different users. Various metrics can be used to measure reliability including probability of failure-free operation, mean time between failures, and availability. Reliability models help predict how reliability changes as faults are removed through testing, but no single model is universally applicable.
The document discusses reliability engineering and fault tolerance. It covers topics like availability, reliability requirements, fault-tolerant architectures, and reliability measurement. It defines key terms like faults, errors, and failures. It also describes techniques for achieving reliability like fault avoidance, fault detection, and fault tolerance. Specific architectures discussed include redundant systems and protection systems that can take emergency action if failures occur.
The document discusses validation of critical systems, including reliability validation using operational profiles and reliability growth models, safety assurance through arguments and dependability cases, and security assessment. It explains that validation costs for critical systems are higher due to additional validation processes needed to demonstrate a system meets its dependability requirements through a dependability case.
This document discusses fault tolerance in computing systems. It defines fault tolerance as building systems that can continue operating satisfactorily even in the presence of faults. It describes different types of faults like transient, intermittent, and permanent hardware faults. It also discusses concepts like errors, failures, fault taxonomy, attributes of fault tolerance like availability and reliability. It explains various techniques used for fault tolerance like error detection, system recovery, fault masking, and redundancy.
Software reliability is influenced by fault count and operational profile. Key factors include fault avoidance, fault tolerance, fault removal and fault forecasting. Dependability is measured by metrics such as MTTF, MTTR, MTBF, POFOD, ROCOF and availability. Software reliability is defined as the probability of failure-free operation of a software system for a specified time period in a given environment.
The document discusses how to specify requirements for critical systems based on risk analysis. It explains how to identify risks, analyze and classify them, then derive safety, security, and reliability requirements to reduce risks. For reliability, it describes metrics like probability of failure on demand and mean time to failure that can be used to specify quantitative reliability levels. The goal is to develop requirements that eliminate intolerable risks and minimize other risks given cost and schedule constraints.
The document discusses stacks, which are data structures that follow the LIFO (last in, first out) principle. It describes basic stack operations like push, pop, and peeking at the top element. Stacks can be implemented using arrays, vectors, or linked lists. In assembly language, the stack segment register SS and stack pointer SP are used to manage the call stack, temporarily storing return addresses and register values. PUSH adds an item to the top of the stack, while POP removes the top item.
This document discusses the components of the extracellular matrix (ECM), focusing on glycosaminoglycans. It explains that glycosaminoglycans are large heteropolysaccharide chains that bind water to form a gel-like matrix. They associate with small amounts of protein to form proteoglycans. Glycosaminoglycans provide flexibility and structure to the ECM and influence movement through it. They bind with water and structural proteins like collagen and elastin to form the body's ground substance and ECM. Most glycosaminoglycans are found attached to core proteins to form proteoglycan monomers in a "bottle brush" structure.
This document discusses rules related to derivatives. Derivatives are financial instruments whose value is based on an underlying asset such as a stock or bond. The rules outline how derivatives are priced, traded, and regulated in financial markets.
Hybrid Cars , Autonomous Cars and future trends and Technologies Usman Bin Saad
Hybrid and autonomous vehicles are becoming more common. Hybrid vehicles use both an electric motor and gasoline engine, with the electric motor handling lower speeds for improved fuel efficiency and environmental friendliness. Fully autonomous vehicles can drive themselves using sensors and computer systems. Technologies like adaptive cruise control, lane departure warning, and automatic emergency braking are improving safety and autonomy. While autonomous vehicles promise benefits, cybersecurity risks require addressing to ensure safe operation.
The document discusses several software development process models including:
- The waterfall model which separates development into distinct phases but is inflexible to change.
- Evolutionary development which interleaves specification, development and validation but can lack structure.
- Component-based development which focuses on reuse but requires component standards.
- Iterative models like incremental delivery and spiral development which incorporate feedback loops and risk analysis to accommodate changing requirements.
This document discusses project management for software development projects. It covers topics such as the need for project management due to budget and schedule constraints. It also discusses distinguishing aspects of software project management compared to other engineering disciplines. Additional topics covered include project planning activities like proposal writing, scheduling, and reviews. It discusses challenges like estimating tasks, scheduling dependencies, and allocating staff. It also covers risk management activities like identifying risks, analyzing risks, planning strategies to address risks, and monitoring risks throughout the project.
Hybrid cars use two or more engines, typically a gasoline engine and an electric motor. The electric motor is more efficient at lower speeds while the gasoline engine operates at higher speeds. Hybrid cars are more environmentally friendly since they run primarily on electric power and use regenerative braking to charge the batteries. However, hybrids also have some disadvantages like higher maintenance costs and safety issues with high-voltage batteries during accidents. Popular hybrid models include the Toyota Prius, Ford Fusion, and Lexus RX 450h.
This document provides information about system engineering. It defines system engineering as an approach to design, implement, and evaluate complex systems. It lists several jobs that system engineers can have, such as system engineer, safety engineer, and space craft system engineer. It describes some of the duties of system engineers, which include ensuring everything works properly, creating new ideas, and coordinating with others. The document discusses elements of computer-based systems, including software, hardware, people, databases, documentation, and procedures. It also covers topics like system modeling, business process engineering, system architectures, product engineering, and requirements engineering.
The document discusses several environmental issues affecting Pakistan, including air pollution. It defines air pollution as dangerous contaminants found in the atmosphere, either as gases or particles. The fundamental causes of air pollution are identified as industrialization and the widespread use of fossil fuels, population growth increasing demand for goods produced through natural resource use, and globalization allowing polluting industries to move to developing countries. The effects of air pollution are described as harmful to humans, animals, trees and the environment through entering the body primarily via the respiratory system.
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...XfilesPro
Wondering how X-Sign gained popularity in a quick time span? This eSign functionality of XfilesPro DocuPrime has many advancements to offer for Salesforce users. Explore them now!
Preparing Non - Technical Founders for Engaging a Tech AgencyISH Technologies
Preparing non-technical founders before engaging a tech agency is crucial for the success of their projects. It starts with clearly defining their vision and goals, conducting thorough market research, and gaining a basic understanding of relevant technologies. Setting realistic expectations and preparing a detailed project brief are essential steps. Founders should select a tech agency with a proven track record and establish clear communication channels. Additionally, addressing legal and contractual considerations and planning for post-launch support are vital to ensure a smooth and successful collaboration. This preparation empowers non-technical founders to effectively communicate their needs and work seamlessly with their chosen tech agency.Visit our site to get more details about this. Contact us today www.ishtechnologies.com.au
Mobile App Development Company In Noida | Drona InfotechDrona Infotech
Drona Infotech is a premier mobile app development company in Noida, providing cutting-edge solutions for businesses.
Visit Us For : https://www.dronainfotech.com/mobile-application-development/
What to do when you have a perfect model for your software but you are constrained by an imperfect business model?
This talk explores the challenges of bringing modelling rigour to the business and strategy levels, and talking to your non-technical counterparts in the process.
Microservice Teams - How the cloud changes the way we workSven Peters
A lot of technical challenges and complexity come with building a cloud-native and distributed architecture. The way we develop backend software has fundamentally changed in the last ten years. Managing a microservices architecture demands a lot of us to ensure observability and operational resiliency. But did you also change the way you run your development teams?
Sven will talk about Atlassian’s journey from a monolith to a multi-tenanted architecture and how it affected the way the engineering teams work. You will learn how we shifted to service ownership, moved to more autonomous teams (and its challenges), and established platform and enablement teams.
Using Query Store in Azure PostgreSQL to Understand Query PerformanceGrant Fritchey
Microsoft has added an excellent new extension in PostgreSQL on their Azure Platform. This session, presented at Posette 2024, covers what Query Store is and the types of information you can get out of it.
Measures in SQL (SIGMOD 2024, Santiago, Chile)Julian Hyde
SQL has attained widespread adoption, but Business Intelligence tools still use their own higher level languages based upon a multidimensional paradigm. Composable calculations are what is missing from SQL, and we propose a new kind of column, called a measure, that attaches a calculation to a table. Like regular tables, tables with measures are composable and closed when used in queries.
SQL-with-measures has the power, conciseness and reusability of multidimensional languages but retains SQL semantics. Measure invocations can be expanded in place to simple, clear SQL.
To define the evaluation semantics for measures, we introduce context-sensitive expressions (a way to evaluate multidimensional expressions that is consistent with existing SQL semantics), a concept called evaluation context, and several operations for setting and modifying the evaluation context.
A talk at SIGMOD, June 9–15, 2024, Santiago, Chile
Authors: Julian Hyde (Google) and John Fremlin (Google)
https://doi.org/10.1145/3626246.3653374
Consistent toolbox talks are critical for maintaining workplace safety, as they provide regular opportunities to address specific hazards and reinforce safe practices.
These brief, focused sessions ensure that safety is a continual conversation rather than a one-time event, which helps keep safety protocols fresh in employees' minds. Studies have shown that shorter, more frequent training sessions are more effective for retention and behavior change compared to longer, infrequent sessions.
Engaging workers regularly, toolbox talks promote a culture of safety, empower employees to voice concerns, and ultimately reduce the likelihood of accidents and injuries on site.
The traditional method of conducting safety talks with paper documents and lengthy meetings is not only time-consuming but also less effective. Manual tracking of attendance and compliance is prone to errors and inconsistencies, leading to gaps in safety communication and potential non-compliance with OSHA regulations. Switching to a digital solution like Safelyio offers significant advantages.
Safelyio automates the delivery and documentation of safety talks, ensuring consistency and accessibility. The microlearning approach breaks down complex safety protocols into manageable, bite-sized pieces, making it easier for employees to absorb and retain information.
This method minimizes disruptions to work schedules, eliminates the hassle of paperwork, and ensures that all safety communications are tracked and recorded accurately. Ultimately, using a digital platform like Safelyio enhances engagement, compliance, and overall safety performance on site. https://safelyio.com/
Flutter is a popular open source, cross-platform framework developed by Google. In this webinar we'll explore Flutter and its architecture, delve into the Flutter Embedder and Flutter’s Dart language, discover how to leverage Flutter for embedded device development, learn about Automotive Grade Linux (AGL) and its consortium and understand the rationale behind AGL's choice of Flutter for next-gen IVI systems. Don’t miss this opportunity to discover whether Flutter is right for your project.
How Can Hiring A Mobile App Development Company Help Your Business Grow?ToXSL Technologies
ToXSL Technologies is an award-winning Mobile App Development Company in Dubai that helps businesses reshape their digital possibilities with custom app services. As a top app development company in Dubai, we offer highly engaging iOS & Android app solutions. https://rb.gy/necdnt
2. Topics covered
A simple safety-critical system
System dependability
Availability and reliability
Safety
Security
3. Critical Systems
Safety-critical systems
• Failure results in loss of life, injury or damage to the
environment;
• Chemical plant protection system;
Mission-critical systems
• Failure results in failure of some goal-directed activity;
• Spacecraft navigation system;
Business-critical systems
• Failure results in high economic losses;
• Customer accounting system in a bank;
4. System dependability
For critical systems, it is usually the case that the
most important system property is the
dependability of the system.
The dependability of a system reflects the user’s
degree of trust in that system. It reflects the
extent of the user’s confidence that it will operate
as users expect and that it will not ‘fail’ in normal
use.
5. Importance of dependability
Systems that are not dependable and are
unreliable, unsafe or insecure may be rejected by
their users.
The costs of system failure may be very high.
Undependable systems may cause information
loss with a high consequent recovery cost.
6. Socio-technical critical systems
Hardware failure
• Hardware fails because of design and manufacturing
errors or because components have reached the end
of their natural life.
Software failure
• Software fails due to errors in its specification, design
or implementation.
Operational failure
• Human operators make mistakes. Now perhaps the
largest single cause of system failures.
7. A software-controlled insulin pump
Used by diabetics to simulate the function of the
pancreas which manufactures insulin, an
essential hormone that metabolizes blood
glucose.
Measures blood glucose (sugar) using a micro-
sensor and computes the insulin dose required to
metabolize the glucose.
10. Dependability requirements
The system shall be available to deliver insulin
when required to do so.
The system shall perform reliably and deliver the
correct amount of insulin to counteract the current
level of blood sugar.
The essential safety requirement is that
excessive doses of insulin should never be
delivered as this is potentially life threatening.
11. Dependability
The dependability of a system equates to its
trustworthiness.
A dependable system is a system that is trusted
by its users.
Principal dimensions of dependability are:
• Availability;
• Reliability;
• Safety;
• Security
12. Dimensions of dependability
Dependability
Availability Reliability Security
The ability of the system
to deliver services when
requested
The ability of the system
to deliver services as
specified
The ability of the system
to operate without
catastrophic failure
The ability of the system
to protect itelf against
accidental or deliberate
intrusion
Safety
13. Other dependability properties
Repairability
• Reflects the extent to which the system can be repaired in the
event of a failure
Maintainability
• Reflects the extent to which the system can be adapted to new
requirements;
Survivability
• Reflects the extent to which the system can deliver services
whilst under hostile attack;
Error tolerance
• Reflects the extent to which user input errors can be avoided
and tolerated.
14. Maintainability
A system attribute that is concerned with the ease
of repairing the system after a failure has been
discovered or changing the system to include
new features
Very important for critical systems as faults are
often introduced into a system because of
maintenance problems
15. Survivability
The ability of a system to continue to deliver its
services to users in the face of deliberate or
accidental attack
This is an increasingly important attribute for
distributed systems whose security can be
compromised
Survivability subsumes the notion of resilience -
the ability of a system to continue in operation in
spite of component failures
16. Dependability vs performance
Untrustworthy systems may be rejected by their users
System failure costs may be very high
It is very difficult to tune systems to make them more
dependable
It may be possible to compensate for poor performance
Untrustworthy systems may cause loss of valuable
information
17. Dependability costs
Dependability costs tend to increase exponentially as
increasing levels of dependability are required
There are two reasons for this
• The use of more expensive development techniques and
hardware that are required to achieve the higher levels of
dependability
• The increased testing and system validation that is required to
convince the system client that the required levels of
dependability have been achieved
18. Costs of increasing dependability
Low Medium High Very
high
Ultra-high
Dependability
19. Availability and reliability
Reliability
• The probability of failure-free system operation over a
specified time in a given environment for a given
purpose
Availability
• The probability that a system, at a point in time, will
be operational and able to deliver the requested
services
20. Availability and reliability
It is sometimes possible to subsume system
availability under system reliability
• Obviously if a system is unavailable it is not delivering
the specified system services
However, it is possible to have systems with low
reliability that must be available. So long as
system failures can be repaired quickly and do
not damage data, low reliability may not be a
problem
Availability takes repair time into account
21. Reliability terminology
Term Description
System failure An event that occurs at some point in time when
the system does not deliver a service as expected
by its users
System error An erroneous system state that can lead to system
behaviour that is unexpected by system users.
System fault A characteristic of a software system that can
lead to a system error. For example, failure to
initialise a variable could lead to that variable
having the wrong value when it is used.
Human error or
mistake
Human behaviour that results in the introduction
of faults into a system.
22. Faults and failures
Failures are a usually a result of system errors that are
derived from faults in the system
However, faults do not necessarily result in system errors
• The faulty system state may be transient and ‘corrected’ before
an error arises
Errors do not necessarily lead to system failures
• The error can be corrected by built-in error detection and
recovery
• The failure can be protected against by built-in protection
facilities. These may, for example, protect system resources
from system errors
23. Reliability achievement
Fault avoidance
• Development technique are used that either minimise the
possibility of mistakes or trap mistakes before they result in the
introduction of system faults
Fault detection and removal
• Verification and validation techniques that increase the
probability of detecting and correcting errors before the system
goes into service are used
Fault tolerance
• Run-time techniques are used to ensure that system faults do
not result in system errors and/or that system errors do not lead
to system failures
24. Reliability modelling
You can model a system as an input-output
mapping where some inputs will result in
erroneous outputs
The reliability of the system is the probability that
a particular input will lie in the set of inputs that
cause erroneous outputs
Different people will use the system in different
ways so this probability is not a static system
attribute but depends on the system’s
environment
27. Reliability improvement
Removing X% of the faults in a system will not necessarily
improve the reliability by X%. A study at IBM showed that
removing 60% of product defects resulted in a 3%
improvement in reliability
Program defects may be in rarely executed sections of
the code so may never be encountered by users.
Removing these does not affect the perceived reliability
A program with known faults may therefore still be seen
as reliable by its users
28. Safety
Safety is a property of a system that reflects the
system’s ability to operate, normally or
abnormally, without danger of causing human
injury or death and without damage to the
system’s environment
It is increasingly important to consider software
safety as more and more devices incorporate
software-based control systems
29. Primary safety-critical systems
• Embedded software systems whose failure can
cause the associated hardware to fail and directly
threaten people.
Secondary safety-critical systems
• Systems whose failure results in faults in other
systems which can threaten people
Discussion here focuses on primary safety-critical
systems.
Safety criticality
30. Safety and reliability are related but distinct
Reliability is concerned with conformance to a
given specification and delivery of service
Safety is concerned with ensuring system cannot
cause damage irrespective of whether
or not it conforms to its specification
Safety and reliability
31. Safety terminology
Term Definition
Accident (or
mishap)
An unplanned event or sequence of events which results in human death or injury,
damage to property or to the environment. A computer-controlled machine injuring its
operator is an example of an accident.
Hazard A condition with the potential for causing or contributing to an accident. A failure of
the sensor that detects an obstacle in front of a machine is an example of a hazard.
Damage A measure of the loss resulting from a mishap. Damage can range from many people
killed as a result of an accident to minor injury or property damage.
Hazard
severity
An assessment of the worst possible damage that could result from a particular
hazard. Hazard severity can range from catastrophic where many people are killed to
minor where only minor damage results.
Hazard
probability
The probability of the events occurring which create a hazard. Probability values tend
to be arbitrary but range from probable (say 1/100 chance of a hazard occurring) to
implausible (no conceivable situations are likely where the hazard could occur).
Risk This is a measure of the probability that the system will cause an accident. The risk is
assessed by considering the hazard probability, the hazard severity and the probability
that a hazard will result in an accident.
32. Safety achievement
Hazard avoidance
• The system is designed so that some classes of hazard simply
cannot arise.
Hazard detection and removal
• The system is designed so that hazards are detected and
removed before they result in an accident
Damage limitation
• The system includes protection features that minimise the
damage that may result from an accident
33. Security
The security of a system is a system property that
reflects the system’s ability to protect itself from
accidental or deliberate 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
34. Fundamental security
If a system is a networked system and is insecure
then statements about its reliability and its safety
are unreliable
These statements depend on the executing
system and the developed system being the
same. However, intrusion can change the
executing system and/or its data
35. Security terminology
Term Definition
Exposure Possible loss or harm in a computing system. This can be loss or
damage to data or can be a loss of time and effort if recovery is
necessary after a security breach.
Vulnerability A weakness in a computer-based system that may be exploited to
cause loss or harm.
Attack An exploitation of a system vulnerability. Generally, this is from
outside the system and is a deliberate attempt to cause some damage.
Threats Circumstances that have potential to cause loss or harm. You can
think of these as a system vulnerability that is subjected to an attack.
Control A protective measure that reduces a system vulnerability. Encryption
would be an example of a control that reduced a vulnerability of a
weak access control system.
36. Damage from insecurity
Denial of service
• The system is forced into a state where normal services are
unavailable or where service provision is significantly degraded
Corruption of programs or data
• The programs or data in the system may be modified in an
unauthorised way
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
37. Security assurance
Vulnerability avoidance
• The system is designed so that vulnerabilities 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 so that attacks on vulnerabilities are
detected and neutralised before they result in an exposure. For
example, virus checkers find and remove viruses before they
infect a system
Exposure limitation
• The system is designed so that the adverse consequences of a
successful attack are minimised. For example, a backup policy
allows damaged information to be restored