NEP_Unit1_SE_24-25.pptx

US-SIT-302 Software Engineering Introduction To Software Engineering Unit 1 S.Y. B.Sc IT : Semester 3 NEP 24-25  2 Syllabus : Unit 1 1.1 Introduction: What is software engineering? Software Development Life Cycle, Requi...

US-SIT-302 Software Engineering Introduction To Software Engineering Unit 1 S.Y. B.Sc IT : Semester 3 NEP 24-25  2 Syllabus : Unit 1 1.1 Introduction: What is software engineering? Software Development Life Cycle, Requirements Analysis, Software Design, Coding, Testing, Maintenance etc. 1.2 Software Requirements: Functional and Non-functional requirements, User Requirements, System Requirements, Interface Specification, Documentation of the software requirements. 1.3 Software Processes: Process and Project 1.4 Software Development Process Models- Waterfall Model. Prototyping. Iterative Development./Spiral Model Rational Unified Process. The RAD Model Time boxing Model. 1.5 Agile software development: Agile methods, Plan-driven and agile development, Extreme programming, Agile project management. 1.6 Socio-technical system: Essential characteristics of socio technical systems, Emergent System Properties, Systems Engineering, Components of system such as organization, people and computer, Legacy Systems. 1.7 Critical system: Types of critical system, A simple safety critical system, Dependability of a system, Availability and Reliability, Safety and Security of Software systems. 1.8 System Models: Models and its types, Context Models, Behavioral Models, Data Models, Object Models, Structured Methods.  3 Software engineering Software engineering is concerned with theories, methods and tools for professional software development. Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. Engineering discipline ▫ Using appropriate theories and methods to solve problems bearing in mind organizational and financial constraints. All aspects of software production ▫ Not just technical process of development. Also project management and the development of tools, methods etc. to support software production.  4 Frequently asked questions about software engineering Question Answer What is software? Computer programs and associated documentation. Software products may be developed for a particular customer or may be developed for a general market. What are the attributes of good software? Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable. What is software engineering? Software engineering is an engineering discipline that is concerned with all aspects of software production. What are the fundamental software Software specification, software development, software engineering activities? validation and software evolution. What is the difference between software Computer science focuses on theory and fundamentals; engineering and computer science? software engineering is concerned with the practicalities of developing and delivering useful software. What is the difference between software System engineering is concerned with all aspects of engineering and system engineering? computer-based systems development including hardware, software and process engineering. Software engineering is part of this more general process.  5 Frequently asked questions about software engineering Question Answer What are the key challenges facing Coping with increasing diversity, demands for reduced software engineering? delivery times and developing trustworthy software. What are the costs of software Roughly 60% of software costs are development costs, engineering? 40% are testing costs. For custom software, evolution costs often exceed development costs. What are the best software engineering While all software projects have to be professionally techniques and methods? managed and developed, different techniques are appropriate for different types of system. For example, games should always be developed using a series of prototypes whereas safety critical control systems require a complete and analyzable specification to be developed. You can’t, therefore, say that one method is better than another. What differences has the web made to The web has led to the availability of software services software engineering? and the possibility of developing highly distributed service- based systems. Web-based systems development has led to important advances in programming languages and software reuse.  6 What is a Software? ▫ A collection of computer programs, procedures, rules, associated documentation and data…. Broadly classified in to 2 categories. ▫ Simple software. ▫ Industrial strength software. Various software problems: ▫ Software being expensive ▫ Unreliability ▫ Problem of change & rework. What is Software engineering? ▫ Can be defined as ‘the establishment and use of engineering principles in order to obtain the software that is economical, reliable and works efficiently on real machines.’ ▫ The key objectives are consistency, low cost, high quality, small cycle time and scalability….  7 It contains 3 key elements: ▫ Methods : It has various tasks Project management System requirement analysis S/W requirement analysis Design of data structures Program architecture(algorithms etc)... ▫ Tools CASE (Computer Aided S/W Engineering )… ▫ Procedures Holds methods and tools together Define the sequence of methods, the deliverables required, the necessary controls and the milestones.  8 SDLC The Software Development Life Cycle ( SDLC) , is the entire process of formal , logical steps taken to develop a software product. The concept generally refers to computer or information systems.  9 SDLC Phases Preliminary Investigation System System Operation Analysis & Maintenance System System Implementation n Design System Development  10 Six Phases of the System ( Software ) Development Life Cycle Preliminary Investigation ▫ Assesses feasibility and practicality of system Requirement ( System )Analysis ▫ Study old system and identify new requirements ▫ Defines system from user's view Software (System) Design ▫ Design new/alternative system ▫ Defines system from technical view  11 Six Phases of the System Development Life Cycle System Development : Coding & Testing ▫ New hardware and software is acquired, developed, and tested System Implementation ▫ System installation and training System Operation & Maintenance ▫ Daily operation ▫ Periodic evaluation and updating  12 Software Requirements Functional and non-functional requirements User requirements System requirements Interface Specification The software requirements document  13 Functional and non-functional requirements Functional requirements ▫ Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Non-functional requirements ▫ Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Domain requirements ▫ Requirements that come from the application domain of the system and that reflect characteristics of that domain.  14 Functional requirements Describe functionality or system services. Depend on the type of software, expected users and the type of system where the software is used. Functional user requirements may be high-level statements of what the system should do but functional system requirements should describe the system services in detail.  15 Non-functional requirements Define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular CASE system, programming language or development method Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless  16 User requirements Should describe functional and non- functional requirements so that they are understandable by system users who don’t have detailed technical knowledge User requirements are defined using natural language, tables and diagrams  17 System requirements More detailed specifications of user requirements Serve as a basis for designing the system May be used as part of the system contract System requirements may be expressed using system models.  18 Interface specification Most systems must operate with other systems and the operating interfaces must be specified as part of the requirements Three types of interface may have to be defined ▫ Procedural interfaces ▫ Data structures that are exchanged ▫ Data representations Formal notations are an effective  19 Requirements document requirements Specify external system behaviour Specify implementation constraints Easy to change Serve as reference tool for maintenance Record forethought about the life cycle of the system i.e. predict changes Characterise responses to unexpected events  20 Requirements document structure 1. Introduction 2. Glossary 3. User requirements definition 4. System architecture 5. System requirements specification 6. System models 7. System evolution 8. Appendices 9. Index  21 The software process A structured set of activities required to develop a software system. Many different software processes but all involve: ▫ Specification – defining what the system should do; ▫ Design and implementation – defining the organization of the system and implementing the system; ▫ Validation – checking that it does what the customer wants; ▫ Evolution – changing the system in response to changing customer needs. A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.  22 Software Process and Project This process deals with the technical & mgmt issues of software development. It specifies the method of developing a software. Whereas, a software project is a development project in which a software process is used. The production process is a sequence steps. Each step performs a well defined activity, wherein the output of one step forms the input of the next one. There are various process models available.  23 Software process models 1. The waterfall model ▫ Plan-driven model. Separate and distinct phases of specification and development. 2. Prototyping 3. Incremental development ▫ Specification, development and validation are interleaved. May be plan-driven or agile. 4. Iterative Development 5. Rational Unified Process 6. RAD Model 7. Time boxing Model 8. Reuse-oriented software engineering ▫ The system is assembled from existing components. May be plan-driven or agile. In practice, most large systems are developed using a process that incorporates elements from all of these models.  24 1. The waterfall model  25 Waterfall model phases There are separate identified phases in the waterfall model: ▫ Requirements analysis and definition ▫ System and software design ▫ Implementation and unit testing ▫ Integration and system testing ▫ Operation and maintenance The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. In principle, a phase has to be complete before moving onto the next phase.  26 2. Software prototyping A prototype is an initial version of a system used to demonstrate concepts and try out design options. A prototype can be used in: ▫ The requirements engineering process to help with requirements elicitation and validation; ▫ In design processes to explore options and develop a UI design; ▫ In the testing process to run back-to-back  27 Benefits of prototyping Improved system usability. A closer match to users’ real needs. Improved design quality. Improved maintainability. Reduced development effort.  28 The process of prototype development  29 3. 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. Iteration can be applied to any of the generic process models. Two (related) approaches ▫ Incremental delivery; ▫ Spiral development.  30 3a: 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.  31 Incremental development  32 Incremental development benefits The cost of accommodating changing customer requirements is reduced. ▫ The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model. It is easier to get customer feedback on the development work that has been done. ▫ Customers can comment on demonstrations of the software and see how much has been implemented. More rapid delivery and deployment of useful software to the customer is possible. ▫ Customers are able to use and gain value from the software earlier than is possible with a waterfall process.  33 Incremental development problems The process is not visible. ▫ Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system. System structure tends to degrade as new increments are added. ▫ Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly.  34 3b : 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. Risks are explicitly assessed and resolved throughout the process.  35 Spiral model sectors Objective setting ▫ Specific objectives for the phase are identified. Risk assessment and reduction ▫ Risks are assessed and activities put in place to reduce the key risks. Development and validation ▫ A development model for the system is chosen which can be any of the generic models. Planning ▫ The project is reviewed and the next phase of the spiral is planned.  36 Spiral model of the software process Deter mine objectives, Evalua te alternatives alterna tives and identify, resolve risks constraints Risk analysis Risk analysis Risk Opera- analysis Prototype 3 tional Prototype 2 protoype Risk REVIEW analysis Proto- type 1 Requir ements plan Simulations, models, benchmar ks Life-cycle plan Concept of Oper ation S/W requirements Product design Detailed Requirement design Development plan validation Code Unit test Integration Design V&V Integration and test plan Plan next phase test Acceptance Service test Develop, verify next-level product  37 4. The Rational Unified Process A modern generic process derived from the work on the UML and associated process. Brings together aspects of the 3 generic process models discussed previously. Normally described from 3 perspectives ▫ A dynamic perspective that shows phases over time; ▫ A static perspective that shows process activities;  38 Phases in the Rational Unified Process  39 RUP phases Inception ▫ Establish the business case for the system. Elaboration ▫ Develop an understanding of the problem domain and the system architecture. Construction ▫ System design, programming and testing. Transition ▫ Deploy the system in its operating environment.  40 5. Characteristics of RAD processes The processes of specification, design and implementation are concurrent. There is no detailed specification and design documentation is minimised. The system is developed in a series of increments. End users evaluate each increment and make proposals for later increments. System user interfaces are usually developed using an interactive development system.  41 RAD environment tools Database programming language Interface generator Links to office applications Report generators  42 A RAD environment Interface Office gener ator systems DB Report programming gener ator language Database mana gement system Rapid application development environment  43 6. Timeboxing Time boxing is like Iterative development but ▫ fix an iteration duration, then determine the specs Divide iteration in a few equal stages Use pipelining concepts to execute iterations in parallel  44 Timeboxing Execution Linear Timeboxing Requirements Build Deploy TB1 Requirements Build Deploy TB2 Pipelined Timeboxing Software Requirements Build Deploy TB1 Requirements Build Deploy TB2 Requirements Build Deploy TB3 Requirements Build Deploy TB4  45 Time Boxed Iterations General iterative development – fix the functionality for each iteration, then plan and execute it In time boxed iterations – fix the duration of iteration and adjust the functionality to fit it Completion time is fixed, the functionality to be delivered is flexible  46 6a : Linear Timeboxing This itself very useful in many situations Has predictable delivery times Overall product release and marketing can be better planned Makes time a non-negotiable parameter and helps focus attention on schedule Prevents requirements bloating Overall dev time is still unchanged  47 6b : Pipelined Execution A Team starts executing it-1 A Team finishes, hands over it-1 to B Team, starts executing it-2 A Team finishes it-2, hands over to B Team; B Team finishes it-1, hands over to D Team; AT starts it-3, B Team starts it-2 (and D Team, it-1) …  48 Agile Software Development Agile methods Plan-driven and agile development Extreme programming Agile project management Scaling agile methods  49 Agile methods These methods: ▫ Focus on the code rather than the design ▫ Are based on an iterative approach to software development ▫ Are intended to deliver working software quickly and evolve this quickly to meet changing requirements. The aim of agile methods is to reduce overheads in the software process (e.g. by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework.  50 The principles of agile methods Principle Description Customer involvement Customers should be closely involved throughout the development process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the system. Incremental delivery The software is developed in increments with the customer specifying the requirements to be included in each increment. People not process The skills of the development team should be recognized and exploited. Team members should be left to develop their own ways of working without prescriptive processes. Embrace change Expect the system requirements to change and so design the system to accommodate these changes. Maintain simplicity Focus on simplicity in both the software being developed and in the development process. Wherever possible, actively work to eliminate complexity from the system.  51 Problems with agile methods It can be difficult to keep the interest of customers who are involved in the process. Team members may be unsuited to the intense involvement that characterises agile methods. Prioritising changes can be difficult where there are multiple stakeholders. Maintaining simplicity requires extra work. Contracts may be a problem as with other approaches to iterative development.  52 Plan-driven and agile development Plan-driven development ▫ A plan-driven approach to software engineering is based around separate development stages with the outputs to be produced at each of these stages planned in advance. ▫ Not necessarily waterfall model – plan-driven, incremental development is possible ▫ Iteration occurs within activities. Agile development ▫ Specification, design, implementation and testing are inter-leaved and the outputs from the development process are decided through a process of negotiation during the software development process.  53 Plan-driven and agile specification  54 Extreme programming Perhaps the best-known and most widely used agile method. Extreme Programming (XP) takes an ‘extreme’ approach to iterative development. ▫ New versions may be built several times per day; ▫ Increments are delivered to customers every 2 weeks; ▫ All tests must be run for every build and the build is only accepted if tests run successfully.  55 XP and agile principles Incremental development is supported through small, frequent system releases. Customer involvement means full-time customer engagement with the team. People not process through pair programming, collective ownership and a process that avoids long working hours. Change supported through regular system releases. Maintaining simplicity through constant refactoring of code.  56 The extreme programming release cycle  57 Agile project management The principal responsibility of software project managers is to manage the project so that the software is delivered on time and within the planned budget for the project. The standard approach to project management is plan-driven. Managers draw up a plan for the project showing what should be delivered, when it should be delivered and who will work on the development of the project deliverables. Agile project management requires a different approach, which is adapted to incremental development and the particular strengths of agile methods.  58 Large systems development Large systems are usually collections of separate, communicating systems, where separate teams develop each system. Frequently, these teams are working in different places, sometimes in different time zones. Large systems are ‘brownfield systems’, that is they include and interact with a number of existing systems. Many of the system requirements are concerned with this interaction and so don’t really lend themselves to flexibility and incremental development. Where several systems are integrated to create a system, a significant fraction of the development is concerned with system configuration rather than original code development.  59 Large system development Large systems and their development processes are often constrained by external rules and regulations limiting the way that they can be developed. Large systems have a long procurement and development time. It is difficult to maintain coherent teams who know about the system over that period as, inevitably, people move on to other jobs and projects. Large systems usually have a diverse set of stakeholders.It is practically impossible to involve all of these different stakeholders in the development process.  60 Scaling out and scaling up ‘Scaling up’ is concerned with using agile methods for developing large software systems that cannot be developed by a small team. ‘Scaling out’ is concerned with how agile methods can be introduced across a large organization with many years of software development experience. When scaling agile methods it is essential to maintain agile fundamentals ▫ Flexible planning, frequent system releases, continuous integration, test-driven development and good team communications. SLE Topic Socio-technical Systems 61 Topics covered Essential Characteristics of Socio Technical Systems Emergent system properties Systems engineering Organizations, people and computer systems Legacy systems 62 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. System components are dependent on other system components The properties and behaviour of system components are inextricably inter-mingled 63 System categories Technical computer-based systems Systems that include hardware and software but where the operators and operational processes are not normally considered to be part of the system. The system is not self-aware (TV, mobile phone). Socio-technical systems Systems that include technical systems but also operational processes and people who use and interact with the technical system. Socio- technical systems are governed by organisational policies and rules (air traffic control system) 64 Socio-technical system characteristics Emergent properties Properties of the system of 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. 65 Emergent properties Properties of the system as a whole rather than properties that can be derived from the properties of components of a system Emergent properties are a consequence of the relationships between system components They can therefore only be assessed and measured once the components have been integrated into a system 66 Types of emergent property Functional properties  These appear when all the parts of a system work together to achieve some objective. For example, a bicycle has the functional property of being a transportation device once it has been assembled from its components. Non-functional emergent properties  Examples are reliability, performance, safety, and security. These relate to the behaviour of the system in its operational environment. They are often critical for computer-based systems as failure to achieve some minimal defined level in these properties may make the system unusable. 67 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. 68 The system engineering process Usually follows a ‘waterfall’ model because of the need for parallel development of different parts of the system  Little scope for iteration between phases because hardware changes are very expensive. Software may have to compensate for hardware problems. Inevitably involves engineers from different disciplines who must work together  Much scope for misunderstanding here. Different disciplines use a different vocabulary and much negotiation is required. Engineers may have personal agendas to fulfil. 69 The systems engineering process Requirements System definition decommissioning System System design evolution Sub-system System development installation System integration 70 Organisations/people/ systems Socio-technical systems are organisational systems intended to help deliver some organisational or business goal. If you do not understand the organisational environment where a system is used, the system is less likely to meet the real needs of the business and its users. 71 Human and organisational factors Process changes Does the system require changes to the work processes in the environment? Job changes Does the system de-skill the users in an environment or cause them to change the way they work? Organisational changes Does the system change the political power structure in an organisation? 72 Legacy systems 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  Bank customer accounting system;  Aircraft maintenance system. Legacy systems constrain new business processes and consume a high proportion of company budgets. 73 Logical parts of legacy system Embeds knowledge of Uses Support software Application Business policies Support software software and rules Runs-on Runs-on Uses Uses Constrains System Application Business hardware data processes 74 Legacy system components Hardware - may be obsolete mainframe hardware. Support software - may rely on support software from suppliers who are no longer in business. Application software - may be written in obsolete programming languages. Application data - often incomplete and inconsistent. Business processes - may be constrained by software structure and functionality. Business policies and rules - may be implicit and embedded in the system software. 75 Layered model of legacy system Socio-technical system Business processes Application software Support software Hardware 76 Key points Socio-technical systems include computer hardware, software and people and are designed to meet some business goal. Emergent properties are properties that are characteristic of the system as a whole and not its component parts. The systems engineering process includes specification, design, development, integration and testing. System integration is particularly critical. 77 Key points ( End of SLE ) Human and organisational factors have a significant effect on the operation of socio- technical systems. There are complex interactions between the processes of system procurement, development and operation. A legacy system is an old system that continues to provide essential services. Legacy systems include business processes, application software, support software and system hardware. 78 Critical Systems 79 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. 80 Topics covered Types of Critical Systems A simple safety-critical system System dependability Availability and reliability Safety Security 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; 82 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. 83 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 Discussion here focuses on primary safety-critical systems  Secondary safety-critical systems can only be considered on a one-off basis 84 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. 85 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. 86 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 87 Dimensions of dependability Dependability Availability Reliability Safety Security The ability of the system The ability of the system The ability of the system The ability of the system to deliver services when to deliver services as to operate without to protect itelf against requested specified catastrophic failure accidental or deliberate intrusion 88 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. 89 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 Maintainability is distinct from other dimensions of dependability because it is a static and not a dynamic system attribute. I do not cover it in this course. 90 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 Both of these attributes can be expressed quantitatively 91 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 92 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 Human behaviour that results in the introduction mistake of faults into a system. 93 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 Safety requirements are exclusive requirements i.e. they exclude undesirable situations rather than specify required system services 94 Safety and reliability Safety and reliability are related but distinct In general, reliability and availability are necessary but not sufficient conditions for system safety 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 95 Safety terminology Term Definition Accident (or An unplanned event or sequence of events which results in human death or injury, mishap) 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 An assessment of the worst possible damage that could result from a particular severity hazard. Hazard severity can range from catastrophic where many people are killed to minor where only minor damage results. Hazard The probability of the events occurring which create a hazard. Probability values tend probability 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. 96 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 97 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 98 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 recove ry 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 sys tem 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. 99 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 100 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 101 Key points 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 humans as well as the hardware and software 102 System Models 103 System models: Models are : Abstract descriptions of systems whose requirements are being analysed. Models and its types : 1. Context models 2. Behavioural models 3. Data models 4. Object models 5. Structured Methods 104 System modelling System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers Different models present the system from different perspectives External perspective showing the system’s context or environment Behavioural perspective showing the behaviour of the system Structural perspective showing the system or data architecture 105 Model types Data processing model showing how the data is processed at different stages Composition model showing how entities are composed of other entities Architectural model showing principal sub- systems Classification model showing how entities have common characteristics Stimulus/response model showing the system’s reaction to events 106 1. Context models Context models are used to illustrate the boundaries of a system Social and organisational concerns may affect the decision on where to position system boundaries Architectural models show the a system and its relationship with other systems 107 The context of an ATM system Security system Branch Account accounting database system Auto-teller system Branch Usage counter database system Maintenance system 108 Process models Process models show the overall process and the processes that are supported by the system Data flow models may be used to show the processes and the flow of information from one process to another 109 2. Behavioural models Behavioural models are used to describe the overall behaviour of a system Two types of behavioural model are shown here Data processing models that show how data is processed as it moves through the system State machine models that show the systems response to events Both of these models are required for a description of the system’s behaviour 110 3. Data-processing models Data flow diagrams are used to model the system’s data processing These show the processing steps as data flows through a system Intrinsic part of many analysis methods Simple and intuitive notation that customers can understand Show end-to-end processing of data 111  Order processing DFD Checked and Completed Signed Signed Send to signed order order form order form order form supplier + order Or der notification details + Complete Valida te Record blank order form order order order form Adjust Order available Signed budget details order form Order amount + account details Orders Budget file file 112 Data flow diagrams DFDs model the system from a functional perspective Tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment 113  CASE toolset DFD Input Valid Checked Design User design design design analysis report Design Design Design Report editor cross checker analyser generator and Referenced Checked designs design Output Design Code skeleton code Design database generator database 114 State machine models These model the behaviour of the system in response to external and internal events They show the system’s responses to stimuli so are often used for modelling real-time systems State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another Statecharts are an integral part of the UML 115 Semantic data models Semantic data models describe the logical structure of data processed by the system. An entity-relation-attribute model sets out  the entities in the system,  the relationships between these entities  and the entity attributes Widely used in database design. Can readily be implemented using relational databases. No specific notation provided in the UML but objects and associations can be used (VERY SIMILAR to CLASS HIERARCHY DIAGRAMs) 116 4. Object models Object models describe the system in terms of object classes and their associations. An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object. Various object models may be produced  Simple object models  Inheritance models  Aggregation models  Interaction models. 117 Object Model: Class Diagram Class name System systemID verificationPhoneNumber systemStatus attributes delayTime telephoneNumber masterPassword temporaryPassword numberTries program() display() reset() query() operations modify() call() 118  FloorPlan Class type name outsideDimensions determineType () (Relationsh positionFloorplan scale() change color() is placed within ip) is part of Diagram Camera Wall type type ID wallDimensions location fieldV iew panA ngle ZoomSetting determineType () determineType () computeDimensions () translateLocation () displayID() displayV iew() displayZoom() is used to build is used to build is used to build WallSegment Window Door type type type startCoordinates startCoordinates startCoordinates stopCoordinates stopCoordinates stopCoordinates nextWallSement nextWindow nextDoor determineType () determineType () determineType () draw() draw() draw() 119 5. Structured methods Structured methods incorporate system modelling as an inherent part of the method Methods define a set of models, a process for deriving these models and rules and guidelines that should apply to the models CASE tools support system modelling as part of a structured method 120 Method weaknesses They do not model non-functional system requirements They do not usually include information about whether a method is appropriate for a given problem The may produce too much documentation The system models are sometimes too detailed and difficult for users to understand. ***** End of Unit 1 ****** 121