Lectures Software Engineering - Chapter 3: Software Processes

ppt 48 trang hoanguyen 2930
Bạn đang xem 20 trang mẫu của tài liệu "Lectures Software Engineering - Chapter 3: Software Processes", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

  • pptlectures_software_engineering_chapter_3.ppt

Nội dung text: Lectures Software Engineering - Chapter 3: Software Processes

  1. Software Processes l Coherent sets of activities for specifying, designing, implementing and testing software systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1
  2. Objectives l To introduce software process models l To describe a number of different process models and when they may be used l To describe outline process models for requirements engineering, software development, testing and evolution l To introduce CASE technology to support software process activities ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 2
  3. Topics covered l Software process models l Process iteration l Software specification l Software design and implementation l Software validation l Software evolution l Automated process support ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 3
  4. The software process l A structured set of activities required to develop a software system • Specification • Design • Validation • Evolution l A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 4
  5. Generic software process models l The waterfall model • Separate and distinct phases of specification and development l Evolutionary development • Specification and development are interleaved l Formal systems development • A mathematical system model is formally transformed to an implementation l Reuse-based development • The system is assembled from existing components ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 5
  6. Waterfall model ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 6
  7. Waterfall model phases l Requirements analysis and definition l System and software design l Implementation and unit testing l Integration and system testing l Operation and maintenance l The drawback of the waterfall model is the difficulty of accommodating change after the process is underway ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 7
  8. Waterfall model problems l Inflexible partitioning of the project into distinct stages l This makes it difficult to respond to changing customer requirements l Therefore, this model is only appropriate when the requirements are well-understood ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 8
  9. Evolutionary development l Exploratory development • Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements l Throw-away prototyping • Objective is to understand the system requirements. Should start with poorly understood requirements ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 9
  10. Evolutionary development ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 10
  11. Evolutionary development l Problems • Lack of process visibility • Systems are often poorly structured • Special skills (e.g. in languages for rapid prototyping) may be required l Applicability • For small or medium-size interactive systems • For parts of large systems (e.g. the user interface) • For short-lifetime systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 11
  12. Formal systems development l Based on the transformation of a mathematical specification through different representations to an executable program l Transformations are ‘correctness-preserving’ so it is straightforward to show that the program conforms to its specification l Embodied in the ‘Cleanroom’ approach to software development ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 12
  13. Formal systems development ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 13
  14. Formal transformations ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 14
  15. Formal systems development l Problems • Need for specialised skills and training to apply the technique • Difficult to formally specify some aspects of the system such as the user interface l Applicability • Critical systems especially those where a safety or security case must be made before the system is put into operation ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 15
  16. Reuse-oriented development l Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems l Process stages • Component analysis • Requirements modification • System design with reuse • Development and integration l This approach is becoming more important but still limited experience with it ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 16
  17. Reuse-oriented development ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 17
  18. Process iteration l 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 l Iteration can be applied to any of the generic process models l Two (related) approaches • Incremental development • Spiral development ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 18
  19. Incremental development l 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 l User requirements are prioritised and the highest priority requirements are included in early increments l Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 19
  20. Incremental development ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 20
  21. Incremental development advantages l Customer value can be delivered with each increment so system functionality is available earlier l Early increments act as a prototype to help elicit requirements for later increments l Lower risk of overall project failure l The highest priority system services tend to receive the most testing ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 21
  22. Extreme programming l New approach to development based on the development and delivery of very small increments of functionality l Relies on constant code improvement, user involvement in the development team and pairwise programming ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 22
  23. Spiral development l Process is represented as a spiral rather than as a sequence of activities with backtracking l Each loop in the spiral represents a phase in the process. l No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required l Risks are explicitly assessed and resolved throughout the process ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 23
  24. Spiral model of the software process ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 24
  25. Spiral model sectors l Objective setting • Specific objectives for the phase are identified l Risk assessment and reduction • Risks are assessed and activities put in place to reduce the key risks l Development and validation • A development model for the system is chosen which can be any of the generic models l Planning • The project is reviewed and the next phase of the spiral is planned ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 25
  26. Software specification l The process of establishing what services are required and the constraints on the system’s operation and development l Requirements engineering process • Feasibility study • Requirements elicitation and analysis • Requirements specification • Requirements validation ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 26
  27. The requirements engineering process ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 27
  28. Software design and implementation l The process of converting the system specification into an executable system l Software design • Design a software structure that realises the specification l Implementation • Translate this structure into an executable program l The activities of design and implementation are closely related and may be inter-leaved ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 28
  29. Design process activities l Architectural design l Abstract specification l Interface design l Component design l Data structure design l Algorithm design ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 29
  30. The software design process ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 30
  31. Design methods l Systematic approaches to developing a software design l The design is usually documented as a set of graphical models l Possible models • Data-flow model • Entity-relation-attribute model • Structural model • Object models ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 31
  32. Programming and debugging l Translating a design into a program and removing errors from that program l Programming is a personal activity - there is no generic programming process l Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 32
  33. The debugging process ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 33
  34. Software validation l Verification and validation is intended to show that a system conforms to its specification and meets the requirements of the system customer l Involves checking and review processes and system testing l 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 34
  35. The testing process ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 35
  36. Testing stages l Unit testing • Individual components are tested l Module testing • Related collections of dependent components are tested l Sub-system testing • Modules are integrated into sub-systems and tested. The focus here should be on interface testing l System testing • Testing of the system as a whole. Testing of emergent properties l Acceptance testing • Testing with customer data to check that it is acceptable ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 36
  37. Testing phases ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 37
  38. Software evolution l Software is inherently flexible and can change. l As requirements change through changing business circumstances, the software that supports the business must also evolve and change l Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 38
  39. System evolution ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 39
  40. Automated process support (CASE) l Computer-aided software engineering (CASE) is software to support software development and evolution processes l 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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 40
  41. Case technology l Case technology has led to significant improvements in the software process though not the order of magnitude improvements that were once predicted • Software engineering requires creative thought - this is not readily automatable • Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 41
  42. CASE classification l Classification helps us understand the different types of CASE tools and their support for process activities l Functional perspective • Tools are classified according to their specific function l Process perspective • Tools are classified according to process activities that are supported l Integration perspective • Tools are classified according to their organisation into integrated units ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 42
  43. Functional tool classification ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 43
  44. Activity-based classification
  45. CASE integration l Tools • Support individual process tasks such as design consistency checking, text editing, etc. l Workbenches • Support a process phase such as specification or design, Normally include a number of integrated tools l Environments • Support all or a substantial part of an entire software process. Normally include several integrated workbenches ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 45
  46. Tools, workbenches, environments ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 46
  47. Key points l Software processes are the activities involved in producing and evolving a software system. They are represented in a software process model l General activities are specification, design and implementation, validation and evolution l Generic process models describe the organisation of software processes l Iterative process models describe the software process as a cycle of activities ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 47
  48. Key points l Requirements engineering is the process of developing a software specification l Design and implementation processes transform the specification to an executable program l Validation involves checking that the system meets to its specification and user needs l Evolution is concerned with modifying the system after it is in use l CASE technology supports software process activities ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 48