DOCSLIB.ORG

Deploying Software Reliability Engineering

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

SENG 637 Dependability, Reliability & Testing of Software Systems SRE Dep loymen t (Chapter 10) Department of Electrical & Computer Engineering, University of Calgary B.H. Far （[email protected]） http://www. enel. ucalgary.ca/People/far/Lectures/SENG637/ [email protected] 1 Contents Quality in requirements phase Quality in design & implementation, testing & release phases SfSoftware Qua lity Assurance (SQA) an d So ftware Reliability Engineering (SRE) Quality, test and data plans Roles and responsibilities Sample quality and test plan Defect reporting procedure Best practices of SRE Quality in post-release and maintenance phase [email protected] 2 Quality vs. Project Costs Cost distribution for a typical software pro jec t Product Integration Design and test Programming 3 Total Cost Distribution Product Design Questions: Programming How to build quality into a system? Maintenance How to Integration andtd test assess quality of a system? Developing better quality system will contribute to lowering maintenance costs 4 Quality in Software Development Process Q. How to include quality concerns in the process? Architectural analysis Quality attributes Software Reliability Software Quality Method: ATAM, CBAM, etc. Engineering (SRE) Assurance (SQA) Requirement & Design & Test & Release AhittArchitecture IlImplemen ttitation Maintenance Software QQyuality Assessment Method: RAM, etc. [email protected] 5 Chapter 10 Section 1 SfSoftware QliQuality: Requirements and Architecture phase [email protected] 6 Quality Challenges Modern software systems are required to meet several quality attributes such as: modifiability, performance, security, interoperability, portability, reliability, etc. Questions for any particular system: What precisely do these quality attributes mean? Can a system bldbe analyzed to didetermine diddesired qua liilities? How soon can such an analysis occur? How do you know if the design is suitable without having to build the system first? SW Architecture Evaluation / Assessment! [email protected] 7 Evaluating SW Architecture Determining whether an architecture satisfies its requ iremen ts oft en i nvol ves: Being very explicit about what the requirements (functional & non-functional) are and how they are reflected in the architecture Understanding where one has to make trade-offs between different design alternatives Applying analysis wherever possible to determine the consequences of an architectural choice Mediating between desires of different stakeholders To achieve these goals an architectural evaltiluation process i s need dded [email protected] 8 SW Architecture Evaluation IfInforma l/dl / ad-hoc architec tura l eva luati on Pros? QQpuick and Cheap Cons? … and Dirty? Incomplete? Unreliable? … Unrepeatable? Poorly documented? [email protected] 9 SW Architecture Evaluation Are there better methods than ad-hoc evaluation? The answer is “YES”: SAAM (Software Architecture Analysis Method) Scenario-based evaluation ATAM (Architecture Tradeoff Analysis Method) Scenario-based evaluation with focus on trade -offs SACAM (Software Architecture Comparison Method) Business goal-driven comparison of architecture alternatives CBAM (Cost-Benefit Analysis Method) Focus on economic aspects etc. [email protected] 10 References Software Architecture Technology Initiative of the SEI: http://www.sei.cmu.edu/architecture/ ATAM: Method for Architecture Evaluation (2000), Rick Kazman, Mark Klein, Paul Clements, Technical Report, CMU/SEI-2000-TR-004. CBAM: M aki ng A rchi tecture D esi gn D eci si ons: A n Economic Approach (2002), Rick Kazman, Jai Asundi, Mark Klein, Technical Report, CMU/SEI- 2002-TR-035. nd Software Architecture in Practice, 2 ed., Len Bass, Paul Clements,,, Rick Kazman, Addison-Wesley, 2003. Evaluating Software Architectures: Methods and Case Studies, Paul Clements, Rick Kazman, Mark Klein, Addison-Wesley, 2001. [email protected] 11 Chapter 10 Section 2 SfSoftware QliDi&Quality: Design & Implementation, Testing & Release Phases [email protected] 12 What is Reliable Software? Reliable software products are those that run correctly and consistently, have fewer remaining defects, handle abnormal situation properly, and need less installation effort The remaining defects should not affect the normal behaviour and the use of the software, they will not do any destructive things to system and its hardware or software environment, and rarely be evident to the users DliDeveloping re liblftliable software requi res: Establishing Software Quality System (SQS) and Software Quality Assurance (SQA) programs Establishing Software Reliability Engineering (SRE) process [email protected] 13 Software Quality System (SQS) Goals: Bu ilding qualit y into the software from the beggginning Keeppging and tracking quality in the software throughout the software life cycle ThTechnol ogy John W. Horch: Practical Guide to Software Quality Management [email protected] 14 Software Quality Assurance (SQA) Software quality Assurance (SQA) is a planned and systematic approach to ensure that both software process and software product conform to the established standards, processes, and procedures. The goals of SQA are to improve software quality by monitoring both software and the development process to ensure full compliance with the established standards and procedures. Steps to establish an SQA program Get the top management’s agreement on its goal and support. Identify SQA issues, write SQA plan, establish standards and SQA functions, implement the SQA plan and evaluate SQA program. [email protected] 15 SRE: Process & Plans Requirement & Design & Test Architecture Implementation Define Necessary Reliability Develop Operational SRE Profile Proc PfTtPrepare for Test Apply Execute Failure Test Data time Quality Test Data Plan Plan Plan There may be many Test and Data (measurement) plans for various parts of the same project [email protected] 16 Defect Handling: Without & With SQS Defect reppg,g,orting, tracking, and closure p rocedure Defect reports DB SCN: software change notice STR: software trouble report John W. Horch: Practical Guide to Software Quality Management [email protected] 17 SRE: Who is Involved? Senior management Test coordinator (manager) Data coordinator (manager) Customer or user [email protected] 18 SRE: Management Concerns Perception and specification of a customer’s real needs. Translilation of specifi ifiication i nto a conf ormi ng d diesign. Maintaining conformity throughout the development processes. Product and sub-product demonstrations which provide convincing indications of the product and project having met their requirements. Ensuring that the tests and demonstrations are designed and controlled, so as to be both achievable and manageable. [email protected] 19 Roles & Responsibilities /1 Test Coordinator (Manager): Test coordinator is expected to ensure that every specific statement of intent in the product requirement, specification and design, is matched by a well designed (cost-effective, convincing, self-reporting, etc.) test, measurement or demonstration. Data Coordinator (Manager) : Data coordinator ensures that the physical and administrative structures fdfor data co llillection exi st and are d ocumented dih in the quali lilty plan, recei ves and validates the data during development, and through analysis and communication ensures that the meaning of the information is known to all, in time, for effective application. [email protected] 20 Roles & Responsibilities /2 Customer or User: Actively encouraging the making and following of detailed quality plans for the products and projects. Requiring access to previous quality plans and their recorddded outcomes bfbefore accept ing t he figures an d methods quoted in the new plan. Enquiring into the sources and validity of synthetics and formulae used in estimating and planning . Appointing appropriate personnel to provide authoritative responses to queries from the developer and a managed interface to the developer. Receiving and reviewing reports of significant audits, reviews, tests and demonstrations. Making any queries and objections in detail and in writing, at the earliest possible time. [email protected] 21 Quality Plans /1 The most promising mechanisms fiidiifor gaining and improving predictability and controllability of software qualities are quality Test plan and its subsidiary documents, including test plans Plan and data (measurement) plans. Quality The creation of the quality plan Plan can be instrumental in raising project effectiveness and in ppgpreventing expensive and time- Data consuming misunderstandings Plan during the project, and at release/acceptance time. [email protected] 22 Quality Plan /2 Quality plan and quality record, provide guidelines fitdtllithfllifor carrying out and controlling the followings: Requirement and specification management. Development processes . Documentation management. Design evaluation. Product testing. SRE related Data collection and interpretation. activities Acceptance and release processes. [email protected] 23 Quality Plan /3 Quality planning should be made at the very earliest point in a project, preferably before a final decision is made on feasibility, and before a software development contract is signed. Quality plan should be devised and agreed between all the concerned parties: senior management, software development management (both administrative and technical) , software development team, customers, and any involved general support functions such as resource
Recommended publications
  • Balancing Dependability Quality Attributes Relationships for Increased Embedded Systems Dependability

    Balancing Dependability Quality Attributes Relationships for Increased Embedded Systems Dependability

    Master Thesis Software Engineering Thesis no: MSE-2009:17 September 2009 Balancing Dependability Quality Attributes Relationships for Increased Embedded Systems Dependability Saleh Al-Daajeh Supervisor: Professor Mikael Svahnberg School of Engineering Blekinge Institute of Technology Box 520 SE – 372 25 Ronneby Sweden This thesis is submitted to the School of Engineering at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Software Engineering. The thesis is equivalent to 2 x 20 weeks of full time studies. Contact Information: Author: Saleh Al-Daajeh E-mail: [email protected] University advisor: Prof. Miakel Svahnberg School of Engineering Internet : www.bth.se/tek Blekinge Institute of Technology Phone : +46 457 385 000 Box 520 Fax : +46 457 271 25 SE – 372 25 Ronneby Sweden II Abstract Embedded systems are used in many critical applications of our daily life. The increased complexity of embedded systems and the tightened safety regulations posed on them and the scope of the environment in which they operate are driving the need for more dependable embedded systems. Therefore, achieving a high level of dependability to embedded systems is an ultimate goal. In order to achieve this goal we are in need of understanding the interrelationships between the different dependability quality attributes and other embedded systems’ quality attributes. This research study provides indicators of the relationship between the dependability quality attributes and other quality attributes for embedded systems by identify- ing the impact of architectural tactics as the candidate solutions to construct dependable embedded systems. III Acknowledgment I would like to express my gratitude to all those who gave me the possibility to complete this thesis.
  • A Reasoning Framework for Dependability in Software Architectures Tacksoo Im Clemson University, Tim@Cs.Clemson.Edu

    A Reasoning Framework for Dependability in Software Architectures Tacksoo Im Clemson University, [email protected]

    Clemson University TigerPrints All Dissertations Dissertations 12-2010 A Reasoning Framework for Dependability in Software Architectures Tacksoo Im Clemson University, [email protected] Follow this and additional works at: https://tigerprints.clemson.edu/all_dissertations Part of the Computer Sciences Commons Recommended Citation Im, Tacksoo, "A Reasoning Framework for Dependability in Software Architectures" (2010). All Dissertations. 618. https://tigerprints.clemson.edu/all_dissertations/618 This Dissertation is brought to you for free and open access by the Dissertations at TigerPrints. It has been accepted for inclusion in All Dissertations by an authorized administrator of TigerPrints. For more information, please contact [email protected]. A Reasoning Framework for Dependability in Software Architectures A Dissertation Presented to the Graduate School of Clemson University In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy Computer Science by Tacksoo Im August 2010 Accepted by: Dr. John D. McGregor, Committee Chair Dr. Harold C. Grossman Dr. Jason O. Hallstrom Dr. Pradip K. Srimani Abstract The degree to which a software system possesses specified levels of software quality at- tributes, such as performance and modifiability, often have more influence on the success and failure of those systems than the functional requirements. One method of improving the level of a software quality that a product possesses is to reason about the structure of the software architecture in terms of how well the structure supports the quality. This is accomplished by reasoning through software quality attribute scenarios while designing the software architecture of the system. As society relies more heavily on software systems, the dependability of those systems be- comes critical.
  • Writing Quality Software

    Writing Quality Software

    Writing Quality Software About this white paper: This whitepaper was written by David C. Young, an employee of General Dynamics Information Technology (GDIT). Dr. Young is part of a team of GDIT employees who maintain, and support high performance computing systems at the Alabama Supercomputer Center (ASC). This was written in 2020. This paper is written for people who want to write good software, but don’t have a master’s degree in software architecture (or someone managing the project who does). Much of what is here would be covered in a software development practices class, often taught at the master’s degree level. Writing quality software is not only about the satisfaction of a job well done. It is also reflects on you and your professional reputation amongst your peers. In some cases writing quality software can be a factor in getting a job, losing a job, or even life or death. Furthermore, writing quality software should be considered an implicit requirement in every software development project. If the intended useful life of the software is many years, that is yet another reason to do a good job writing it. Introduction Consider this situation, which is all too common. You have written a really neat piece of software. You put it out on github, then tell your colleagues about it. Soon you are bombarded with a series of complaints from people who tried to install, and use your software. Some of those complaints might be; • It won’t install on their version of Linux. • They did the same thing you reported, but got a different answer.
  • Studying the Feasibility and Importance of Software Testing: an Analysis

    Studying the Feasibility and Importance of Software Testing: an Analysis

    Dr. S.S.Riaz Ahamed / Internatinal Journal of Engineering Science and Technology Vol.1(3), 2009, 119-128 STUDYING THE FEASIBILITY AND IMPORTANCE OF SOFTWARE TESTING: AN ANALYSIS Dr.S.S.Riaz Ahamed Principal, Sathak Institute of Technology, Ramanathapuram,India. Email:[email protected], [email protected] ABSTRACT Software testing is a critical element of software quality assurance and represents the ultimate review of specification, design and coding. Software testing is the process of testing the functionality and correctness of software by running it. Software testing is usually performed for one of two reasons: defect detection, and reliability estimation. The problem of applying software testing to defect detection is that software can only suggest the presence of flaws, not their absence (unless the testing is exhaustive). The problem of applying software testing to reliability estimation is that the input distribution used for selecting test cases may be flawed. The key to software testing is trying to find the modes of failure - something that requires exhaustively testing the code on all possible inputs. Software Testing, depending on the testing method employed, can be implemented at any time in the development process. Keywords: verification and validation (V & V) 1 INTRODUCTION Testing is a set of activities that could be planned ahead and conducted systematically. The main objective of testing is to find an error by executing a program. The objective of testing is to check whether the designed software meets the customer specification. The Testing should fulfill the following criteria: ¾ Test should begin at the module level and work “outward” toward the integration of the entire computer based system.
  • Fundamental Concepts of Dependability

    Fundamental Concepts of Dependability

    Fundamental Concepts of Dependability Algirdas Avizˇ ienis Jean-Claude Laprie Brian Randell UCLA Computer Science Dept. LAAS-CNRS Dept. of Computing Science Univ. of California, Los Angeles Toulouse Univ. of Newcastle upon Tyne USA France U.K. UCLA CSD Report no. 010028 LAAS Report no. 01-145 Newcastle University Report no. CS-TR-739 LIMITED DISTRIBUTION NOTICE This report has been submitted for publication. It has been issued as a research report for early peer distribution. Abstract Dependability is the system property that integrates such attributes as reliability, availability, safety, security, survivability, maintainability. The aim of the presentation is to summarize the fundamental concepts of dependability. After a historical perspective, definitions of dependability are given. A structured view of dependability follows, according to a) the threats, i.e., faults, errors and failures, b) the attributes, and c) the means for dependability, that are fault prevention, fault tolerance, fault removal and fault forecasting. he protection and survival of complex information systems that are embedded in the infrastructure supporting advanced society has become a national and world-wide concern of the 1 Thighest priority . Increasingly, individuals and organizations are developing or procuring sophisticated computing systems on whose services they need to place great reliance — whether to service a set of cash dispensers, control a satellite constellation, an airplane, a nuclear plant, or a radiation therapy device, or to maintain the confidentiality of a sensitive data base. In differing circumstances, the focus will be on differing properties of such services — e.g., on the average real-time response achieved, the likelihood of producing the required results, the ability to avoid failures that could be catastrophic to the system's environment, or the degree to which deliberate intrusions can be prevented.
  • Dependability Assessment of Software- Based Systems: State of the Art

    Dependability Assessment of Software- Based Systems: State of the Art

    Dependability Assessment of Software- based Systems: State of the Art Bev Littlewood Centre for Software Reliability, City University, London [email protected] You can pick up a copy of my presentation here, if you have a lap-top ICSE2005, St Louis, May 2005 - slide 1 Do you remember 10-9 and all that? • Twenty years ago: much controversy about need for 10-9 probability of failure per hour for flight control software – could you achieve it? could you measure it? – have things changed since then? ICSE2005, St Louis, May 2005 - slide 2 Issues I want to address in this talk • Why is dependability assessment still an important problem? (why haven’t we cracked it by now?) • What is the present position? (what can we do now?) • Where do we go from here? ICSE2005, St Louis, May 2005 - slide 3 Why do we need to assess reliability? Because all software needs to be sufficiently reliable • This is obvious for some applications - e.g. safety-critical ones where failures can result in loss of life • But it’s also true for more ‘ordinary’ applications – e.g. commercial applications such as banking - the new Basel II accords impose risk assessment obligations on banks, and these include IT risks – e.g. what is the cost of failures, world-wide, in MS products such as Office? • Gloomy personal view: where it’s obvious we should do it (e.g. safety) it’s (sometimes) too difficult; where we can do it, we don’t… ICSE2005, St Louis, May 2005 - slide 4 What reliability levels are required? • Most quantitative requirements are from safety-critical systems.
  • Reliability: Software Software Vs

    Reliability: Software Software Vs

    Reliability Theory SENG 521 Re lia bility th eory d evel oped apart f rom th e mainstream of probability and statistics, and Software Reliability & was usedid primar ily as a tool to h hlelp Software Quality nineteenth century maritime and life iifiblinsurance companies compute profitable rates Chapter 5: Overview of Software to charge their customers. Even today, the Reliability Engineering terms “failure rate” and “hazard rate” are often used interchangeably. Department of Electrical & Computer Engineering, University of Calgary Probability of survival of merchandize after B.H. Far （[email protected]） 1 http://www. enel.ucalgary . ca/People/far/Lectures/SENG521/ ooene MTTF is R e 0.37 From Engineering Statistics Handbook [email protected] 1 [email protected] 2 Reliability: Natural System Reliability: Hardware Natural system Hardware life life cycle. cycle. Aging effect: Useful life span Life span of a of a hardware natural system is system is limited limited by the by the age (wear maximum out) of the system. reproduction rate of the cells. Figure from Pressman’s book Figure from Pressman’s book [email protected] 3 [email protected] 4 Reliability: Software Software vs. Hardware So ftware life cyc le. Software reliability doesn’t decrease with Software systems time, i.e., software doesn’t wear out. are changed (updated) many Hardware faults are mostly physical faults, times during their e. g., fatigue. life cycle. Each update adds to Software faults are mostly design faults the structural which are harder to measure, model, detect deterioration of the and correct. software system. Figure from Pressman’s book [email protected] 5 [email protected] 6 Software vs.
  • Software Reliability and Dependability: a Roadmap Bev Littlewood & Lorenzo Strigini

    Software Reliability and Dependability: a Roadmap Bev Littlewood & Lorenzo Strigini

    Software Reliability and Dependability: a Roadmap Bev Littlewood & Lorenzo Strigini Key Research Pointers Shifting the focus from software reliability to user-centred measures of dependability in complete software-based systems. Influencing design practice to facilitate dependability assessment. Propagating awareness of dependability issues and the use of existing, useful methods. Injecting some rigour in the use of process-related evidence for dependability assessment. Better understanding issues of diversity and variation as drivers of dependability. The Authors Bev Littlewood is founder-Director of the Centre for Software Reliability, and Professor of Software Engineering at City University, London. Prof Littlewood has worked for many years on problems associated with the modelling and evaluation of the dependability of software-based systems; he has published many papers in international journals and conference proceedings and has edited several books. Much of this work has been carried out in collaborative projects, including the successful EC-funded projects SHIP, PDCS, PDCS2, DeVa. He has been employed as a consultant to industrial companies in France, Germany, Italy, the USA and the UK. He is a member of the UK Nuclear Safety Advisory Committee, of IFIPWorking Group 10.4 on Dependable Computing and Fault Tolerance, and of the BCS Safety-Critical Systems Task Force. He is on the editorial boards of several international scientific journals. 175 Lorenzo Strigini is Professor of Systems Engineering in the Centre for Software Reliability at City University, London, which he joined in 1995. In 1985-1995 he was a researcher with the Institute for Information Processing of the National Research Council of Italy (IEI-CNR), Pisa, Italy, and spent several periods as a research visitor with the Computer Science Department at the University of California, Los Angeles, and the Bell Communication Research laboratories in Morristown, New Jersey.
  • Manual on Quality Assurance for Computer Software Related to the Safety of Nuclear Power Plants

    Manual on Quality Assurance for Computer Software Related to the Safety of Nuclear Power Plants

    SIMPLIFIED SOFTWARE LIFE-CYCLE DIAGRAM FEASIBILITY STUDY PROJECT TIME I SOFTWARE P FUNCTIONAL I SPECIFICATION! SOFTWARE SYSTEM DESIGN DETAILED MODULES CECIFICATION MODULES DESIGN SOFTWARE INTEGRATION AND TESTING SYSTEM TESTING ••COMMISSIONING I AND HANDOVER | DECOMMISSION DESIGN DESIGN SPECIFICATION VERIFICATION OPERATION AND MAINTENANCE SOFTWARE LIFE-CYCLE PHASES TECHNICAL REPORTS SERIES No. 282 Manual on Quality Assurance for Computer Software Related to the Safety of Nuclear Power Plants f INTERNATIONAL ATOMIC ENERGY AGENCY, VIENNA, 1988 MANUAL ON QUALITY ASSURANCE FOR COMPUTER SOFTWARE RELATED TO THE SAFETY OF NUCLEAR POWER PLANTS The following States are Members of the International Atomic Energy Agency: AFGHANISTAN GUATEMALA PARAGUAY ALBANIA HAITI PERU ALGERIA HOLY SEE PHILIPPINES ARGENTINA HUNGARY POLAND AUSTRALIA ICELAND PORTUGAL AUSTRIA INDIA QATAR BANGLADESH INDONESIA ROMANIA BELGIUM IRAN, ISLAMIC REPUBLIC OF SAUDI ARABIA BOLIVIA IRAQ SENEGAL BRAZIL IRELAND SIERRA LEONE BULGARIA ISRAEL SINGAPORE BURMA ITALY SOUTH AFRICA BYELORUSSIAN SOVIET JAMAICA SPAIN SOCIALIST REPUBLIC JAPAN SRI LANKA CAMEROON JORDAN SUDAN CANADA KENYA SWEDEN CHILE KOREA, REPUBLIC OF SWITZERLAND CHINA KUWAIT SYRIAN ARAB REPUBLIC COLOMBIA LEBANON THAILAND COSTA RICA LIBERIA TUNISIA COTE D'lVOIRE LIBYAN ARAB JAMAHIRIYA TURKEY CUBA LIECHTENSTEIN UGANDA CYPRUS LUXEMBOURG UKRAINIAN SOVIET SOCIALIST CZECHOSLOVAKIA MADAGASCAR REPUBLIC DEMOCRATIC KAMPUCHEA MALAYSIA UNION OF SOVIET SOCIALIST DEMOCRATIC PEOPLE'S MALI REPUBLICS REPUBLIC OF KOREA MAURITIUS UNITED ARAB
  • Software Quality Assurance Activities in Software Testing

    Software Quality Assurance Activities in Software Testing

    Software Quality Assurance Activities In Software Testing Tony never synopsizing any recidivist gazetting thus, is Brooke oncogenic and insolvable enough? Monogenous Chadd externalises, his disciplinarians denudes spring-clean Germanically. Spindliest Antoni never humors so edgewise or attain any shells lyingly. Each module performs one or two tasks, and thenpasses control to another module. Perform test automation for web application using Cucumber. Identify and describe safety software procurement methods, including supplier evaluation and source inspection processes. He previously worked at IBM SWS Toronto Lab. The information maintained in status accounting should enable the rebuild of any previous baseline. Beta Breakers supports all industry sectors. Thank you save time for all the lack of that includes test software assurance and must often. Focus on demonstrating pos next column containing algorithms, activities in software quality assurance testing activities of testing programs for their findings from his piece of skills, validate features to refresh teh page object. XML data sets to simulate production, using LLdap and ALTOVA. Schedule information should be expressed as absolute dates, as dates relative to either SCM or project milestones, or as a simple sequence of events. Its scope of software quality assurance and the correct email list all testshave been completely correct, in software quality assurance activities to be precisely known about its process on a familiarity level. These exercises are performed at every step along the way in the workshop. However, you have to balance driving out quality with production value. The second step is the validation of the computer system implementation against the computer system requirements. Software development tools, whose output becomes part of the program implementation and which can therefore introduce errors.
  • Critical Systems

    Critical Systems

    Critical Systems ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 3 Slide 1 Objectives ● To explain what is meant by a critical system where system failure can have severe human or economic consequence. ● To explain four dimensions of dependability - availability, reliability, safety and security. ● To explain that, to achieve dependability, you need to avoid mistakes, detect and remove errors and limit damage caused by failure. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 3 Slide 2 Topics covered ● A simple safety-critical system ● System dependability ● Availability and reliability ● Safety ● Security ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 3 Slide 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; ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 3 Slide 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. ● Usefulness and trustworthiness are not the same thing. A system does not have to be trusted to be useful. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 3 Slide 5 Importance of dependability ● Systems that are not dependable and are unreliable, unsafe or insecure may be rejected by their users.
  • A Practical Framework for Eliciting and Modeling System Dependability Requirements: Experience from the NASA High Dependability Computing Project

    A Practical Framework for Eliciting and Modeling System Dependability Requirements: Experience from the NASA High Dependability Computing Project

    The Journal of Systems and Software 79 (2006) 107–119 www.elsevier.com/locate/jss A practical framework for eliciting and modeling system dependability requirements: Experience from the NASA high dependability computing project Paolo Donzelli a,*, Victor Basili a,b a Department of Computer Science, University of Maryland, College Park, MD 20742, USA b Fraunhofer Center for Experimental Software Engineering, College Park, MD 20742, USA Received 9 December 2004; received in revised form 21 March 2005; accepted 21 March 2005 Available online 29 April 2005 Abstract The dependability of a system is contextually subjective and reflects the particular stakeholderÕs needs. In different circumstances, the focus will be on different system properties, e.g., availability, real-time response, ability to avoid catastrophic failures, and pre- vention of deliberate intrusions, as well as different levels of adherence to such properties. Close involvement from stakeholders is thus crucial during the elicitation and definition of dependability requirements. In this paper, we suggest a practical framework for eliciting and modeling dependability requirements devised to support and improve stakeholdersÕ participation. The framework is designed around a basic modeling language that analysts and stakeholders can adopt as a common tool for discussing dependability, and adapt for precise (possibly measurable) requirements. An air traffic control system, adopted as testbed within the NASA High Dependability Computing Project, is used as a case study. Ó 2005 Elsevier Inc. All rights reserved. Keywords: System dependability; Requirements elicitation; Non-functional requirements 1. Introduction absence of failures (with higher costs, longer time to market and slower innovations) (Knight, 2002; Little- Individuals and organizations increasingly use wood and Stringini, 2000), everyday software (mobile sophisticated software systems from which they demand phones, PDAs, etc.) must provide cost effective service great reliance.