Software Engineering - Software Processes Lecture Notes PDF

SOFTWARE ENGINEERING Software Processes Chapter 2 Software Processes 1  Topics covered 2.1. SDLC 2.2. Process activities 2.2.1. Software Specification 2.2.2. Software Design and Implementation 2.2.3. Software Validation 2.2.4. Software Evolution...

SOFTWARE ENGINEERING Software Processes Chapter 2 Software Processes 1  Topics covered 2.1. SDLC 2.2. Process activities 2.2.1. Software Specification 2.2.2. Software Design and Implementation 2.2.3. Software Validation 2.2.4. Software Evolution Chapter 2 Software Processes 2 2.1. Software Development Life Cycle (SDLC) Chapter 2 Software Processes 3  Software Development Life Cycle (SDLC) A structured set of activities required to develop a software system. Specification Many different software processes but all involve: Specification – defining what Evolution Design 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; Implementati Validation Evolution – changing the system on in response to changing customer needs. Chapter 2 Software Processes 4  Plan-driven and agile processes Plan-driven processes are processes where all the process activities are planned, and progress is measured against this plan. In agile processes, planning is incremental, and it is easier to change the process to reflect changing customer requirements. In practice, most practical processes include elements of both plan-driven and agile approaches. There are no right or wrong software processes. Chapter 2 Software Processes 5 2.2. Process activities Chapter 2 Software Processes 6  Process activities Real software processes are inter-leaved sequences of technical, collaborative and managerial activities with the overall goal of specifying, designing, implementing and testing a software system. The four basic process activities of specification, development, validation and evolution are organized differently in different development processes. Chapter 2 Software Processes 7 2.2.1. Software specification Chapter 2 Software Processes 8  Software specification The process of establishing what services are required and the constraints on the system’s operation and development. Requirements engineering process Requirements elicitation and analysis What do the system stakeholders require or expect from the system? Requirements specification Defining the requirements in detail Requirements validation Checking the validity of the requirements Chapter 2 Software Processes 9  What is a requirement? It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. This is inevitable as requirements may serve a dual function May be the basis for a bid for a contract - therefore must be open to interpretation; May be the basis for the contract itself - therefore must be defined in detail; Both these statements may be called requirements. Chapter 2 Software Processes 10  Types of requirement User requirements System requirements Statements in natural language plus A structured document setting out detailed diagrams of the services the system descriptions of the system’s functions, provides and its operational constraints. services and operational constraints. Written for customers. Defines what should be implemented so may be part of a contract between client and contractor. Chapter 2 Software Processes 11  System stakeholders Any person or organization who is Stakeholder types affected by the system in some way and so who has a legitimate interest End users System managers System owners External stakeholders Chapter 2 Software Processes 12  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. May state what the system should not do. Non-functional requirements Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Often apply to the system as a whole rather than individual features or services. Domain requirements Constraints on the system from the domain of operation Chapter 2 Software Processes 13  Requirements engineering The process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed. The system requirements are the descriptions of the system services and constraints that are generated during the requirements engineering process. Chapter 2 Software Processes 14 The requirements engineering process Chapter 2 Software Processes 15  Requirements elicitation Software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc. Stages include: Requirements discovery, Requirements classification and organization, Requirements prioritization and negotiation, Requirements specification. Chapter 2 Software Processes 16 The requirements elicitation and analysis process Chapter 2 Software Processes 17  Requirements specification The process of writing down the user and system requirements in a requirements document. User requirements have to be understandable by end-users and customers who do not have a technical background. System requirements are more detailed requirements and may include more technical information. The requirements may be part of a contract for the system development It is therefore important that these are as complete as possible. Chapter 2 Software Processes 18  Changing requirements The business and technical environment of the system always changes after installation. New hardware may be introduced, it may be necessary to interface the system with other systems, business priorities may change (with consequent changes in the system support required), and new legislation and regulations may be introduced that the system must necessarily abide by. The people who pay for a system and the users of that system are rarely the same people. System customers impose requirements because of organizational and budgetary constraints. These may conflict with end-user requirements, and, after delivery, new features may have to be added for user support if the system is to meet its goals. Chapter 2 Software Processes 19  Changing requirements Large systems usually have a diverse user community, with many users having different requirements and priorities that may be conflicting or contradictory. The final system requirements are inevitably a compromise between them and, with experience, it is often discovered that the balance of support given to different users has to be changed. Chapter 2 Software Processes 20  Requirements validation Concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. Chapter 2 Software Processes 21  Requirements checking Validity. Does the system provide the functions which best support the customer’s needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology Verifiability. Can the requirements be checked? Chapter 2 Software Processes 22  Requirements validation techniques Requirements reviews Systematic manual analysis of the requirements. Prototyping Using an executable model of the system to check requirements. Test-case generation Developing tests for requirements to check testability. Chapter 2 Software Processes 23  Requirements reviews Regular reviews should be held while the requirements definition is being formulated. Both client and contractor staff should be involved in reviews. Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage. Chapter 2 Software Processes 24  Review checks Verifiability Is the requirement realistically testable? Comprehensibility Is the requirement properly understood? Traceability Is the origin of the requirement clearly stated? Adaptability Can the requirement be changed without a large impact on other requirements? Chapter 2 Software Processes 25 2.2.2. Software design and implementation Chapter 2 Software Processes 26  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. Chapter 2 Software Processes 27 A general model of the design process Chapter 2 Software Processes 28  Design activities Architectural design, where you identify the overall structure of the system, the principal components (subsystems or modules), their relationships and how they are distributed. Database design, where you design the system data structures and how these are to be represented in a database. Interface design, where you define the interfaces between system components. Component selection and design, where you search for reusable components. If unavailable, you design how it will operate. Chapter 2 Software Processes 29  System implementation The software is implemented either by developing a program or programs or by configuring an application system. Design and implementation are interleaved activities for most types of software system. Programming is an individual activity with no standard process. Debugging is the activity of finding program faults and correcting these faults. Chapter 2 Software Processes 30 2.2.3. Software validation Chapter 2 Software Processes 31  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. Involves checking and review processes and system testing. System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system. Testing is the most commonly used V & V activity. Chapter 2 Software Processes 32  Verification vs validation Verification: "Are we building the product right”. The software should conform to its specification. Validation: "Are we building the right product”. The software should do what the user really requires. Chapter 2 Software Processes 33  V & V confidence Aim of V & V is to establish confidence that the system is ‘fit for purpose’. Depends on system’s purpose, user expectations and marketing environment Software purpose The level of confidence depends on how critical the software is to an organisation. User expectations Users may have low expectations of certain kinds of software. Marketing environment Getting a product to market early may be more important than finding defects in the program. Chapter 2 Software Processes 34  Program testing Testing is intended to show that a program does what it is intended to do and to discover program defects before it is put into use. When you test software, you execute a program using artificial data. You check the results of the test run for errors, anomalies or information about the program’s non-functional attributes. Can reveal the presence of errors NOT their absence. Testing is part of a more general verification and validation process, which also includes static validation techniques. Chapter 2 Software Processes 35  Program testing goals To demonstrate to the developer and the customer that the software meets its requirements. For custom software, this means that there should be at least one test for every requirement in the requirements document. For generic software products, it means that there should be tests for all of the system features, plus combinations of these features, that will be incorporated in the product release. To discover situations in which the behavior of the software is incorrect, undesirable or does not conform to its specification. Defect testing is concerned with rooting out undesirable system behavior such as system crashes, unwanted interactions with other systems, incorrect computations and data corruption. Chapter 2 Software Processes 36  Validation and defect testing The first goal leads to validation testing You expect the system to perform correctly using a given set of test cases that reflect the system’s expected use. The second goal leads to defect testing The test cases are designed to expose defects. The test cases in defect testing can be deliberately obscure and need not reflect how the system is normally used. Chapter 2 Software Processes 37  Testing process goals Validation testing To demonstrate to the developer and the system customer that the software meets its requirements A successful test shows that the system operates as intended. Defect testing To discover faults or defects in the software where its behaviour is incorrect or not in conformance with its specification A successful test is a test that makes the system perform incorrectly and so exposes a defect in the system. Chapter 2 Software Processes 38 Stages of testing Chapter 2 Software Processes 39  Testing stages Component 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. Customer testing Testing with customer data to check that the system meets the customer’s needs. Chapter 2 Software Processes 40 An input-output model of program testing Chapter 2 Software Processes 41 A model of the software testing process Chapter 2 Software Processes 42 2.2.4. Software Evolution Chapter 2 Software Processes 43  Software evolution Software is inherently flexible and can change. As requirements change through changing business circumstances, the software that supports the business must also evolve and change. Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new. Chapter 2 Software Processes 44 System evolution Chapter 2 Software Processes 45  Software change Software change is inevitable New requirements emerge when the software is used; The business environment changes; Errors must be repaired; New computers and equipment is added to the system; The performance or reliability of the system may have to be improved. A key problem for all organizations is implementing and managing change to their existing software systems. Chapter 2 Software Processes 46  Importance of evolution Organisations have huge investments in their software systems - they are critical business assets. To maintain the value of these assets to the business, they must be changed and updated. The majority of the software budget in large companies is devoted to changing and evolving existing software rather than developing new software. Chapter 2 Software Processes 47 A spiral model of development and evolution Chapter 2 Software Processes 48 Evolution and servicing Chapter 2 Software Processes 49  Evolution and servicing Evolution The stage in a software system’s life cycle where it is in operational use and is evolving as new requirements are proposed and implemented in the system. Servicing At this stage, the software remains useful but the only changes made are those required to keep it operational i.e. bug fixes and changes to reflect changes in the software’s environment. No new functionality is added. Phase-out The software may still be used but no further changes are made to it. Chapter 2 Software Processes 50  Evolution processes Software evolution processes depend on The type of software being maintained; The development processes used; The skills and experience of the people involved. Proposals for change are the driver for system evolution. Should be linked with components that are affected by the change, thus allowing the cost and impact of the change to be estimated. Change identification and evolution continues throughout the system lifetime. Chapter 2 Software Processes 51 Change identification and evolution processes Chapter 2 Software Processes 52 The software evolution process Chapter 2 Software Processes 53 Change implementation Chapter 2 Software Processes 54  Change implementation Iteration of the development process where the revisions to the system are designed, implemented and tested. A critical difference is that the first stage of change implementation may involve program understanding, especially if the original system developers are not responsible for the change implementation. During the program understanding phase, you have to understand how the program is structured, how it delivers functionality and how the proposed change might affect the program. Chapter 2 Software Processes 55  Urgent change requests Urgent changes may have to be implemented without going through all stages of the software engineering process If a serious system fault has to be repaired to allow normal operation to continue; If changes to the system’s environment (e.g. an OS upgrade) have unexpected effects; If there are business changes that require a very rapid response (e.g. the release of a competing product). Chapter 2 Software Processes 56 The emergency repair process Chapter 2 Software Processes 57