Ian Sommerville Exams Series Quizlet

IMPORTANT DIAGRAMS TO LEARN

***Cost distribution for software design models ***Project Management and Milestones ***Insulin Pump ***As many models as possible(All in chapter 8) ***Library System

Project Constraints

*Required delivery date *Staff available *Overall budget

PRINCIPAL DIMENSIONS OF DEPENDABILITY- (RASS)

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 - Deliver services when needed - Reliability - trustworthiness - Safety - Functions without catastrophic failure - Security - prevents unauthorized access

LEGACY SYSTEMS

They are Socio-technical systems that have been developed using old or obsolete technology. Crucial to the operation of a business and it is often too risky to discard these systems

Software design and implementation PHASES

1. Architectural design The sub-systems making up the system and their relationships are identified and documented. 2. Abstract specification For each sub-system, an abstract specification of its ser- vices and the constraints under which it must operate is produced. 3. Interface design For each sub-system, its interface with other sub-systems is designed and documented. This interface specification must be unambiguous as it allows the sub-system to be used without knowledge of the sub-system operation. 4. Component design Services are allocated to components and the interfaces of these components are designed. 5. Data structure design The data structures used in the system implementation are designed in detail and specified. 6. Algorithm design The algorithms used to provide services are designed in detail and specified.

Component-based software engineering PHASES

1. Component analysis Given the requirements specification, a search is made for components to implement that specification. Usually, there is no exact match, and the components that may be used only provide some of the functionality required. . 2. Requirements modification During this stage, the requirements are analysed using information about the components that have been discovered. They are then modified to reflect the available components. Where modifications are impossible, the component analysis activity may be reentered to search for alternative solutions. 3. System design with reuse During this phase, the framework of the system is designed or an existing framework is reused. The designers take into account the components that are reused and organise the framework to cater to this. Some new software may have to be designed if reusable components are not available. 4. Development and integration Software that cannot be externally procured is devel- oped, and the components and COTS systems are integrated to create the new system. System integration, in this model, may be part of the development pro- cess rather than a separate activity.

Two fundamental types of evolutionary development:

1. Exploratory development where the objective of the process is to work with the customer to explore their requirements and deliver a final system. The devel- opment starts with the parts of the system that are understood. The system evolves by adding new features proposed by the customer. 2. Throwaway prototyping where the objective of the evolutionary development process is to understand the customer's requirements and hence develop a bet- ter requirements definition for the system. The prototype concentrates on experimenting with the customer requirements that are poorly understood.

4 SOFTWARE SPECIFICATION PHASES

1. Feasibility study An estimate is made of whether the identified user needs may . be satisfied using current software and hardware technologies. The study con- siders whether the proposed system will be cost-effective from a business point of view and whether it can be developed within existing budgetary constraints. A feasibility study should be relatively cheap and quick. The result should inform the decision of whether to go ahead with a more detailed analysis. 2. Requirements elicitation and analysis This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and procurers, task analysis and so on. This may involve the development of one or more system models and prototypes. These help the ana- lyst understand the system to be specified. 3. Requirements specification The activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. Two types of requirements may be included in this document. User require- ments are abstract statements of the system requirements for the customer and end-user of the system; system requirements are a more detailed description of the functionality to be provided. 4. Requirements validation This activity checks the requirements for realism, con- sistency and completeness. During this process, errors in the requirements doc- ument are inevitably discovered. It must then be modified to correct these problems.

TYPES OF SOFTWARE

1. Generic - developed to be sold to a range of different customers e.g. PC software such as Excel or Word. 2. Bespoke (custom) - developed for a single customer according to their specification.

Two forms of Process Iteration Models

1. Incremental Delivery 2.Spiral Development

Project Plan Structure

1. Introduction This briefly describes the objectives of the project and sets out the constraints (e.g., budget, time, etc.) that affect the project management. 2. Project organization This describes the way in which the development team is organised, the people involved and their roles in the team. 3. Risk analysis This describes possible project risks, the likelihood of these risks arising and the risk reduction strategies that are proposed. 4. Hardware and software resource requirements This specifies the hardware and the support software required to carry out the development. If hardware has to be bought, estimates of the prices and the delivery schedule may be included. 5. Work breakdown This sets out the breakdown of the project into activities and identifies the milestones and deliverables associated with each activity. 6. Project schedule This shows the dependencies between activities, the estimated time required to reach each milestone and the allocation of people to activities. 7. Monitoring and reporting mechanisms This defines the management reports that should be produced, when these should be produced and the project monitoring mechanisms used.

Spiral model sectors

1. Objective setting Specific objectives for that phase of the project are defined. Constraints on the process and the product are identified and a detailed man- agement plan is drawn up. Project risks are identified. Alternative strategies, depending on these risks, may be planned. 2. Risk assessment and reduction For each of the identified project risks, a detailed analysis is carried out. Steps are taken to reduce the risk. For exam- ple, if there is a risk that the requirements are inappropriate, a prototype system may be developed. 3. Development and validation After risk evaluation, a development model for the system is chosen. For example, if user interface risks are dominant, an appro- priate development model might be evolutionary prototyping. If safety risks are the main consideration, development based on formal transformations may be the most appropriate and so on. The waterfall model may be the most appro- priate development model if the main identified risk is sub-system integration. 4. Planning The project is reviewed and a decision made whether to continue with a further loop of the spiral. If it is decided to continue, plans are drawn up for the next phase of the project.

Waterfall model phaseS

1. Requirements analysis and definition The system's services, constraints and goals are established by consultation with system users. They are then defined in detail and serve as a system specification. 2. System and software design The systems design process partitions the require- ments to either hardware or software systems. It establishes an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships. 3. Implementation and unit testing During this stage, the software design is realised as a set of programs or program units. Unit testing involves verifying that each unit meets its specification. 4. Integration and system testing The individual program units or programs are integrated and tested as a complete system to ensure that the software require- ments have been met. After testing, the software system is delivered to the customer. 5. Operation and maintenance Normally (although not necessarily) this is the longest life-cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the system's services as new requirements are discovered. ************* ************ ● The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. One phase has to be complete before moving onto the next phase.

TPYES OF CASE TOOLS

1. Upper-CASE Tools to support the early process activities of requirements and design; 2.Lower-CASE Tools to support later activities such as programming, debugging and testing

Generic process models

1. Waterfall; 2. Iterative development; 3. Component-based software engineering.

Generic activities in all software processes are:

1.Specification - what the system should do and its development constraints 2.Development - production of the software system 3.Validation - checking that the software is what the customer wants 4. Evolution - changing the software in response to changing demands.

Difference between Software engineering and other Engineering Disciplines

1.The product is intangible . Software is intangible. It cannot be seen or touched. Software project managers cannot see progress unlike in other engineering fields whereby the projects is tangible 2. There are no standard software processes. In engineering disciplines with a long history, the process is tried and tested. The engineering process for some types of system, such as bridges and buildings is well understood. However, software processes vary dramatically from one organisation to another. 3. Large software projects are often 'one-off' projects Large software projects are usually different in some ways from previous projects. Therefore, even managers who have a large body of previous experience may find it difficult to anticipate problems. Furthermore, rapid technological changes in computers and communications can make a manager's experience obsolete. Lessons learned from previous projects may not be transferable to new projects. 4. Software engineering is not recognized as an engineering discipline with the same status as mechanical, electrical engineering, etc. 5.The product is uniquely flexible.

DEPENDABILITY REQUIREMENTS OF THE INSULIN PUMPING SYSTEM

1.The system shall be available to deliver insulin when required to do so. 2.The system shall perform reliability and deliver the correct amount of insulin to counteract the current level of blood sugar. 3.The essential safety requirement is that excessive doses of insulin should never be delivered as this is potentially life threatening.

Examples of process perspectives

1.Workflow perspective - sequence of activities; 2.Data-flow perspective - information flow; 3.Role/action perspective - who does what.

WHAT IS A SYSTEM?

A purposeful collection of inter-related components working together to achieve some common objective A system may include software, mechanical, electrical and electronic hardware and be operated by people.

WHAT IS A SOFTWARE PROCESS?

A set of activities whose goal is the development or evolution of software.

WHAT IS A SOFTWARE PROCESS MODEL?

A simplified representation of a software process, presented from a specific perspective.

Software Process

A structured set of activities required to develop a software system **** 1. Software specification The functionality of the software and constraints on its operation must be defined. 2. Software design and implementation The software to meet the specification must be produced. 3. Software validation The software must be validated to ensure that it does what the customer wants. 4. Software evolution The software must evolve to meet changing customer needs.

SYSTEM REQUIREMENTS DEFINITION

Abstract functional requirements: System functions are defined in an abstract way; System properties:Non-functional requirements for the system in general are defined; Undesirable characteristics : Unacceptable system behaviour is specified.

SAFETY TERMINOLOGIES

Accident / 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.

Normal Accidents

Accidents in complex systems rarely have a single cause as these systems are designed to be resilient to a single point of failure • Designing systems so that a single point of failure does not cause an accident is a fundamental principle of safe systems design It is probably the case that anticipating all problem combinations, especially, in software controlled systems is impossible so achieving complete safety is impossible

SYSTEM INSTALLATION

After completion, the system has to be installed in the customer's environment

SYSTEM MODELLING

An architectural model presents an abstract view of the sub-systems making up a system

WHAT IS SOFTWARE?

Computer programs and associated documentation such as requirements, design models and user manuals

WHAT IS THE DIFFERENCEBETWEEN SOFTWARE ENGINEERING AND COMPUTER SCIENCE?

Computer science is concerned with theory and fundamentals; software engineering is concerned the practicalities of developing and delivering useful software.

Software project management

Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software.

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

SOCIO-TECHNICAL SYSTEM CHARACTERISTICS

Emergent properties- Properties of the systemof a whole that depend on the system components and their relationships Non-deterministic- They do not always produce the same output when presented with the same input because the systems' behaviour is partially dependent on human operators. Complex relationships with organisational objectives- The extent to which the system supports organisational objectives does not just depend on the system itself.

Evolutionary development

Evolutionary development is based on the idea of developing an initial implementation, exposing this to user comment and refining it through many versions until an adequate system has been developed. development and validation activities are interleaved rather than separate, with rapid feedback across activities.

SECURITY TERMINOLOGIES

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. Controls - 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.

Relationship between failures, faults and errors

Failures are a result of system errors that were derived from faults in the system. ***Not all faults 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 )

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 is not the same thing. A system does not have to be trusted to be useful.

SYSTEM OBJECTIVES

Functional objectives- The function of the system Organisational objectives- The reason of the organization for acquiring the system

LAW OF FUNDAMENTAL SECURITY

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 ● Therefore, the reliability and safety assurance is no longer valid

SOCIO-TECHNICAL CRITICAL SYSTEMS (SYSTEM DEPENDABILITY)

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.

Process activities

INDEPTH: ● Software specification ● Software design and implementation ● Software validation ● Software evolution

SYSTEM PROCUREMENT

In acquiring a system for an organization to meet some need, some system specification and architectural design is usually necessary before procurement. - You need a specification to let a contract for system development - The specification may allow you to buy a commercial off-the-shelf (COTS) system. Almost always cheaper than developing a system from scratch Large complex systems usually consist of a mix of off the shelf and specially designed components

SYSTEM EVOLUTION

Large systems have a long lifetime. They must evolve to meet changing requirements. Evolution is inherently costly - Changes must be analysed from a technical and business perspective; - Sub-systems interact so unanticipated problems can arise; - There is rarely a rationale for original design decisions; - System structure is corrupted as changes are made to it.

SYSTEM DESIGN PROCESS

Partition requirements- Organise requirements into related groups. Identify sub-systems- Identify a set of sub-systems which collectively can meet the system requirements. Assign requirements to sub-systems- Causes particular problems when COTS are integrated. Specify sub-system functionality. Define sub-system interfaces- Critical activity for parallel sub-system development.

Types of Project Plan

Quality Plan. Describes the quality procedures and standards that will be used in a project. Validation plan. Describes the approach, resources and schedule used for system validation. Configuration management plan. Describes the configuration management procedures and structures to be used. Maintenance plan. Predicts the maintenance requirements of the system, maintenance costs and effort required. Staff development plan. Describes how the skills and experience of the project team members will be developed.

REVISIT RUP IF THERE IS TIME

RUP

Incremental Delivery

Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. ● User requirements are prioritised and the highest priority requirements are included in early increments. ● Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.

RELATIONSHIP BETWEEN SAFETY AND RELIABILITY

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

OTHER DEPENDABILITY PROPERTIES

Repairability • Reflects the extent to which the system can be repaired in the event of a failure ● 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 ● 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.

CHAPTER 4

SOFTWARE PROCESSES

CRITICAL SYSTEMS

Safety-critical systems - Failure results in loss of life, injury or damage to the environment; EXAMPLE- Chemical plant protection system; Mission-critical systems - Failure results in failure of some goal-directed activity; EXAMPLE- Spacecraft navigation system; Business-critical systems - Failure results in high economic losses; EXAMPLE- Customer accounting system in a bank;

ORGANIZATIONS/PEOPLE/SYSTEMS

Socio-technical systems are organizational systems intended to help deliver some organizational or business goal. If you do not understand the organizational environment where a system is used, the system is less likely to meet the real needs of the business and its users.

WHAT IS SOFTWARE ENGINEERING?

Software engineering is an engineering discipline that is concerned with all aspects of software production.

WHAT IS CASE (COMPUTER-AIDED SOFTWARE ENGINEERING)?

Software systems that are intended to provide automated support for software process activities.

WHAT IS SYSTEMS ENGINEERING?

Specifying, designing, implementing, validating, deploying and maintaining socio-technical systems. Concerned with the services provided by the system, constraints on its construction and operation and the ways in which it is used.

WHAT IS THE DIFFERENCEBETWEEN SOFTWARE ENGIN EERING AND S YSTEM ENGIN EERING?

System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this process concerned with developing the software infrastructure, control, applications and databases in the system.

Reliability terminologies

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.

PROCESS ITERATION

System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems. *****Can be applied to any of the generic process models

Structured methods (DESIGN)

Systematic approaches to developing a software design. ● The design is usually documented as a set of graphical models. ● Possible models: Object model; Sequence model; State transition model; Structural model; Data-flow model.

SYSTEM DECOMMISSIONING

Taking the system out of service after its useful lifetime May require removal of materials (e.g. dangerous chemicals) which pollute the environment Should be planned for in the system design by encapsulation

WHAT ARE THE SYSTEM CATEGORIES?

Technical computer-based systems Are non-self-aware systems that include hardware and software but where the operators and operational processes are not normally considered to be part of the system. Socio-technical systems Systems that include technical systems but also operational processes and people who use and interact with the technical system.

SOFTWARE SPECIFICATION

The process of establishing what services are required and the constraints on the system's operation and development.

SYSTEM INTEGRATION

The process of putting hardware, software and people together to make a system It should be tackled incrementally so that sub-systems are integrated one at a time.

CONTRACTORS AND SUB-CONTRACTORS

The procurement of large hardware/software systems is usually based around some principal contractor. Sub-contracts are issued to other suppliers to supply parts of the system. Customer liaises with the principal contractor and does not deal directly with sub-contractors.

Project Plan

The project plan sets out the resources available to the project, the work breakdown and a schedule for carrying out the work.

ATTRIBUTES OF GOOD SOFTWARE?

The software should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable. 1. Maintainability- Software must evolve to meet changing needs; 2. Dependability- Software must be trustworthy; 3. Efficiency- Software should not make wasteful use of system resources; 3. Acceptability- Software must accepted by the users for which it was designed. This means it must be understandable, usable and compatible with other systems.

Dependability costs

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 ***Cost increases as reliability increases

FUNCTIONAL TOOL CLASSFICATION TYPES

Tool type Planning tools - PERT tools, estimation tools, spreadsheets Editing tools Text editors, diagram editors, word processors Change management tools Requirements traceability tools, change control systems Configuration management tools Version management systems, system building tools Prototyping tools Very high-level languages, user interface generators Method-support tools Design editors, data dictionaries, code generators Language-processing tools Compilers, interpreters Program analysis tools Cross reference generators, static analysers, dynamic analysers Testing tools Test data generators, file comparators Debugging tools Interactive debugging systems Documentation tools programs Re-engineering tools Cross-reference systems, program re-structuring systems

SUB-SYSTEM DEVELOPMENT

Typically parallel projects developing the hardware, software and communications May involve some COTS (Commercial Off-the-Shelf) systems procurement

EXAMPLES OF EMERGENT PROPERTIES

Volume The volume of a system (the total space occupied) varies depending on how the component assemblies are arranged and connected. Reliability System reliability depends on component reliability but unexpected interactions can cause new types of failure and therefore affect the reliability of the system. Security The security of the system (its ability to resist attack) is a complex property that cannot be easily measured. Attacks may be devised that were not anticipated by the system designers and so may defeat built-in safeguards. Repairability This property reflects how easy it is to fix a problem with the system once it has been discovered. It depends on being able to diagnose the problem, access the components that are faulty and modify or replace these components. Usability This property reflects how easy it is to use the system. It depends on the technical system components, its operators and its operating environment.

software process model

an abstract representation of a process. It presents a description of a process from some particular perspective.

EVOLUTIONARY DEVELOPMENT APPLICABILITY

• For small or medium-size interactive systems; • For parts of large systems (e.g. the user interface); • For short-lifetime systems.

EVOLUTIONARY DEVELOPMENT PROBLEMS

• Lack of process visibility; • Systems are often poorly structured; • Special skills (e.g. in languages for rapid prototyping) may be required.

Perceptions of reliability

• The assumptions that are made about the environment where a system will be used may be incorrect EXAMPLE: Usage of a system in an office environment is likely to be quite different from usage of the same system in a university environment • The consequences of system failures affects the perception of reliability EXAMPLE: Unreliable windscreen wipers in a car may be irrelevant in a dry climate Failures that have serious consequences (such as an engine breakdown in a car) are given greater weight by users than failures that are inconvenient

KEY POINTS

● A critical system is a system where failure can lead to high economic loss, physical damage or threats to life. ● The dependability in a system reflects the user's trust in that system ● The availability of a system is the probability that it will be available to deliver services when requested ● The reliability of a system is the probability that system services will be delivered as specified ● Reliability and availability are generally seen as necessary but not sufficient conditions for safety and security ● Reliability is related to the probability of an error occurring in operational use. A system with known faults may be reliable ● Safety is a system attribute that reflects the system's ability to operate without threatening people or the environment ● Security is a system attribute that reflects the system's ability to protect itself from external attack ● Dependability improvement requires a socio- technical approach to design where you consider the

Extreme programming

● An approach to development based on the development and delivery of very small increments of functionality. ● Relies on constant code improvement, user involvement in the development team and pairwise programming.

Component-based software engineering

● Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems.

Dependability economics

● Because of very high costs of dependability achievement, it may be more cost effective to accept untrustworthy systems and pay for failure costs ● However, this depends on social and political factors. A reputation for products that can't be trusted may lose future business ● Depends on system type - for business systems in particular, modest levels of dependability may be adequate

CASE CLASSIFICATION OR PERSPECTIVES

● Classification helps us understand the different types of CASE tools and their support for process activities. ● Functional perspective Tools are classified according to their specific function. ● Process perspective Tools are classified according to process activities that are supported. ● Integration perspective Tools are classified according to their organization into integrated units.

STAGES IN THE TESTING PROCESS

● Component or unit testing Individual components are tested independently; *Components may be functions or objects or coherent groupings of these entities. ● System testing Testing of the system as a whole. Testing of emergent properties is particularly important. ● Acceptance testing • Testing with customer data to check that the system meets the customer's needs.

CASE TOOLS AND THEIR USES

● Computer-aided software engineering (CASE) is software to support software development and evolution processes. USES: ● Activity automation • Graphical editors for system model development; • Data dictionary to manage design entities; • Graphical UI builder for user interface construction; • Debuggers to support program fault finding; • Automated translators to generate new versions of a program.

Incremental development advantages

● Customer value can be delivered with each increment so system functionality is available earlier. ● Early increments act as a prototype to help elicit requirements for later increments. ● Lower risk of overall project failure. ● The highest priority system services tend to receive the most testing.

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

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

Waterfall model problems

● Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. ● Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. ● Few business systems have stable requirements. ● The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites.

Safety criticality

● 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

Spiral development

● Process is represented as a spiral rather than as a sequence of activities with backtracking. ● Each loop in the spiral represents a phase in the process. ● No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.

Management activities

● Proposal writing. The first stage in a software project may involve writing a proposal to win a contract to carry out the work. The proposal describes the objectives of the project and how it will be carried out. It usually includes cost and schedule estimates, and justifies why the project contract should be awarded to a particular organisation or team. ● Project planning and scheduling. Project planning is concerned with identifying the activities, milestones and deliv- erables produced by a project. A plan is drawn up to guide the development towards the project goals. ● Project costing. Cost estimation is a related activity of project planning that is concerned with estimating the resources required to accomplish the project plan. ● Project monitoring and reviews. Project monitoring is a continuing project activity in which manager keeps track of the progress of the project and compare actual and planned progress and costs. ● Personnel selection and evaluation. Project managers usually have to select people to work on their project. *In most cases the manager will have to settle for a less that ideal project-team. Some of the reasons are:*** 1. Budget cannot accommodate experienced and highly paid staff therefore less experienced and less-paid will have to be used. 2. Unavailability of experiences staff 3. The organization may wish to develop the skills of their employees. In such cases less-experienced staff may be assigned to projects ● Report writing and presentations.

DEPENDABILITY CAN BE DEFINED BY THESE TWO PROPERTIES:

● 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 **It's sometimes possible to subsume availability under system reliability (i.e: Availability > Reliability)

Reliability improvement

● Removing X% of the faults in a system will not necessarily improve the reliability by X%. EXAMPLE: 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

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

Unsafe reliable systems

● Specification errors If the system specification is incorrect then the system can behave as specified but still cause an accident ● Hardware failures generating spurious inputs • Hard to anticipate in the specification ● Context-sensitive commands i.e. issuing the right command at the wrong time. • Often the result of operator error

Software design and implementation

● The process of converting the system specification into an executable system. ● Software design Design a software structure that realises the specification; ● Implementation Translate this structure into an executable program; ● The activities of design and implementation are closely related and may be inter-leaved.

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 an essential pre-requisite for availability, reliability and safety

GENERIC SOFTWARE PROCESS MODELS

● The waterfall model Separate and distinct phases of specification and development. ● Evolutionary development Specification, development and validation are interleaved. ● Component-based software engineering The system is assembled from existing components.

Programming and debugging

● Translating a design into a program and removing errors from that program. ● Programming is a personal activity - there is no generic programming process. ● Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process.

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

Software validation

● Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer. ●It Involves checking and review processes and system testing. ● System testing also involves executing the system with test cases that are derived from the sample of the real data to be processed by the system.

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

RELIABILITY MODELING

● 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