Presentation is loading. Please wait.

Presentation is loading. Please wait.

© Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Chap 4 Software Processes.

Similar presentations


Presentation on theme: "© Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Chap 4 Software Processes."— Presentation transcript:

1 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Chap 4 Software Processes

2 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 2 Objectives l To introduce software process models l To describe three generic process models and when they may be used l To describe outline process models for requirements engineering, software development, testing and evolution l To explain the Rational Unified Process model l To introduce CASE technology to support software process activities

3 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 3 Topics covered l 4.1 Software process models l 4.2 Process iteration l 4.3 Process activities l 4.4 The Rational Unified Process l 4.5 Computer-aided software engineering

4 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 4 What is the software process? l A software process is a set of activities that leads to the production of a software product. These activities may involve the development of software from scratch in a standard programming language. Increasingly, however, new software is developed by extending and modifying existing systems and by configuring and integrating off-the-shelf software or system components.

5 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 5 The fundamental activities of software processes. l Although there are many software processes, some fundamental activities are common to all software processes: Software specification : the functionality of the software and constraints on its operation must be defined. Software design and implementation : the software to meet the specification must be produced. Software validation : the software must be validated to ensure that it does what the customer wants. Software evolution : the software must evolve to meet changing customer needs. 64

6 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide The software process l A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective, and thus provides only partial information about that process.

7 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 7 Generic software process models l The waterfall model Separate and distinct phases of specification development, validation and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing and so on. l Evolutionary development This approach interleaves (interchange) the activities of specification, development and validation. An initial system is rapidly developed from abstract specifications. This is then refined with customer input to produce a system that satisfies the customer’s needs. l Component-based software engineering The system is assembled from existing components, the focuses on integrating these components into a system rather than developing them from scratch.

8 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 8 l These generic process models are widely used in current software engineering practice. They are not mutually (interchange) exclusive and are often used together, especially for large systems development. l Sub-system within a larger system may be developed using different approaches, but we should understand that, in practice, they are often combined.

9 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Waterfall model Figure 4.1 the software life cycle

10 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 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 a detail system specification. 2. System and software design Systems design process partitions the requirements 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 Software design is realized (accomplish) as a set of programs or program units. Unit testing involves verifying that each unit meets its specification.

11 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 11 Waterfall model phases 4. Integration and system testing Individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the Customer. 5. Operation and maintenance This is 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. 67

12 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 12 Waterfall model problems l Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. l Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. l Few business systems have stable requirements. l The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites.

13 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Evolutionary development There are two fundamental types of 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 and add new features as proposed by the customer. l Throw-away prototyping Objective is to understand the system requirements. Should start with poorly understood requirements to clarify what is really needed.

14 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Evolutionary development Figure 4.2 Evolutionary development

15 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide l An evolutionary approach to software development is often more effective than the waterfall approach in producing system that meet the immediate needs of customers. l From an engineering and management perspective, the evolutionary approach has two problems: Process is not visible: Managers need regular deliverables (report) to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system. Systems are often poorly structured: Continual change tend to corrupt the software structure. incorporating (combine) software changes becomes increasingly difficult and costly.

16 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Evolutionary development l Problems Lack of process visibility; Systems are often poorly structured; Special skills may be required. l Applicability (suitable) For small or medium-size interactive systems; For parts of large systems (e.g. the user interface); For short-lifetime systems.

17 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 17 l For small and medium-sized systems (up to 500,000 lines of code). I think that the evolutionary approach is the best approach to development. l For large, complex, long-life-time systems, where different teams develop different part of the system, it is difficult to establish a stable system architecture using this approach. Which makes it hard to integrate contributions from the teams.

18 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 18 l For large systems, I recommend a mixed process that incorporates the best features of the waterfall and the evolutionary development models. l This may involve developing a throwaway prototype to resolve uncertainties in the system specification, then re- implement the system using a more structured approach. l Part of the system that are well understood can be specified and developed using a waterfall-based process. l Other part of system, such as the user interface, which are difficult to specify in advance, should always be developed using an exploratory programming approach.

19 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Component-based software engineering (CBSE) l Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. l This approach is becoming increasingly used as component standards have emerged.

20 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide l Process stages 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 (consider) the available components. Where modifications are impossible, the component analysis activity may be re-entered to search for alternative solutions.

21 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 21 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 organize the framework to cater ( supply) 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 developed, and the components and COTS systems are integrated to create the new system. System integration, in this model, may be part of the development process rather than a separate activity.

22 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 22 Reuse-oriented development CBSE : Component-based software engineering Figure 4.3 component-based software engineering

23 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 23 Advantage and short-point of Component- based software engineering l Has obvious advantage of reducing the amount of software to be developed and so reducing cost and risks. l Leads to faster delivery of the software. l However, requirements compromises are inevitable and this may lead to a system that does not meet the real needs of users. l Furthermore, some control over the system evolution is lost as new versions of the reusable components are not under the control of the organization using them. 70

24 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Process iteration l Change is inevitable in all large software projects. l The system requirements change as the business procuring the system responds to external pressures. l Management priorities change. l As new technologies become available designs and implementation change. l This means that the software process is not a one- off process; rather, the process activities are regularly repeated as the system is reworked in response to change requests.

25 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide l Two (related) approaches Incremental delivery: The software specification, design and implementation are broken down into a series of increments that are each developed in turn. Spiral development: The development of the system spirals outwards from an initial outline through to the final developed system.

26 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide l The essence of iterative processes is that the specification is developed in the same time with the software developed. l However, this conflicts with the procurement model of many organizations where the complete system specification is part of the system development contract. l In the incremental approach, there is no complete system specification until the final increment is specified. l So which large customers such as government agencies may find difficult to accommodate.

27 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Incremental delivery l The waterfall model of development requires customers for a system to commit (make sure) to a set of requirements before design begins and the designer to commit to particular design strategies before implementation. l An evolutionary approach to development allows requirements and design decisions to be delayed but also leads to software that may be poorly structured and difficult to understand and maintain. l Incremental delivery is an in-between approach that combines the advantages of these models. 71

28 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 28 In the incremental development process l Customer identify, in outline, the services should be provided in the system. l They identify which of the services are most important and which are least important to them. l A number of delivery increments are then defined, with each increment providing a sub-set of the system functionality. l The allocation (assign) of services to increments depends on the service priority with the highest priority services delivered first. 72

29 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 29 Incremental development

30 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Incremental development advantages 1. Customer do not have to wait until the entire system is delivered before they can gain value from it, the first increment satisfies their most critical requirements so they can use the software immediately. 2. Customer can use the early increments as prototypes and gain experience that informs their requirements for later system increments.

31 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide There is a lower risk of overall project failure. Although problems may be encountered in some increments, it is likely that most of them will be successfully delivered to the customer. 4. As the highest priority services are delivered first, and later increments are integrated with them, it is inevitable that the most important system services receive the most testing. This means that customers are less likely to encounter software failures in the most important parts of the system. 72

32 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 32 Incremental delivery problems l Should be relatively small ( no more than 20,000 lines of code ) l Each increment should deliver some system functionality.

33 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 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 Thus the innermost loop might be concerned with system feasibility (practicability), the next loop with requirements definition, the next loop may with system designed.

34 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 34 Spiral model of the software process

35 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 35 Spiral model sectors Each loop in the spiral is split into four sectors: 1.Objective setting Specific objectives for that phase are defined. Constraints on the process and the product are identified and a detailed management plan is drawn up. Project risks are identified. Alternative strategies, depending on these risks, may be planned. 2.Risk assessment and reduction (reduce) For each of the identified project risks, a detailed analysis is carried out. Steps are taken to reduce the risk. For example, if there is risk that the requirements are inappropriate, a prototype system may be developed.

36 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 36 3.Development and validation After risk evaluation, a development model for the system is chosen. If safety risks are the main consideration, development based on Formal Transformations may be the most appropriate. If the main identified risk is sub-system integration then Waterfall model may be the most appropriate development model. 4.Planning The project is reviewed and the next phase of the spiral is planned.

37 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 37 Conclusion of Spiral development l The main difference between the spiral model and other software process models is the explicit recognize of risk in the spiral model. l For example, if the intention is to use a new programming language, a risk is that the available compilers are unreliable or do not produce sufficiently efficient object code. So risk in project problems such as schedule and cost overrun so risk minimization is very important project management activity.

38 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 38 l A cycle of the spiral begins by determine clear objectives. such as performance and functionality. l Alternative ways of achieving these objectives and the constraints imposed on each of the loop. l Each alternative is assessed or evaluate. l To resolve these risks by information-gathering activities such as more detailed analysis, prototyping and simulation. l Once risks have been assessed, some development is carried out, followed by a planning activity for the next phase of the process. 74

39 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Process activities 1. Software specification 2. Software design and implementation 3. Software validation 4. Software evolution

40 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 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 1.Feasibility study; An estimate is made of whether the identified user needs may be satisfied using current software and hardware technologies, and whether the proposed system will be cost-effective from a business point of view and within existing budgetary constraints.

41 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 41 2.Requirements elicitation (draw out) and analysis; This is a process of deriving the system requirements through observation of existing systems, discussions with potential users and customer, task analysis and so on. 3.Requirements specification; This activity will translating the information gathered during the analysis activity into a set of requirement documents. 4.Requirements validation. This activity checks the requirements for consistency and completeness.in this stage, error in the requirements document may occur, it must be modified to correct these problems.

42 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 42 The requirements engineering process

43 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Software design and implementation l The process of converting the system specification into an executable system. l Software design Design a software structure that realizes the specification; l Implementation Translate this structure into an executable program; l The activities of design and implementation are closely related and may be interleaved.

44 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 44 Design process activities 1. Architectural design The sub-system making up the system and their relationships are identified and documented. 2. Abstract specification For each sub-system, under its services an abstract specification and the constraints which will be produced. 3. Interface design For each sub-system, its interface with other sub-systems is designed and documented. This interface specification must be clear,

45 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Component design Service are assigned to components and interface of these components are designed. 5. Data structure design To designed a detail and specified Data structure for the implementation system. 6. Algorithm design Detail designed and specified the algorithms that used to provide service.

46 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 46 The software design process

47 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 47 Structured methods Structured methods is approach that rely on producing graphical models of the system , include a design process model , notations to represent the design, report formats, rules and design guidelines, it may support some or all of the following models of a system:

48 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 48 Structured methods l Possible models 1.Object model; that show the object classes used in the system and their dependencies. 2.Sequence model; show how objects in the system interact when the system is executing. 3.State transition model; shows system states and the triggers condition for the transitions from one state to another. 4.Structural model; to documented the system components and their aggregations. 5.Data-flow model. to describe the model when data transformation is processed. 78

49 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 49 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. 79

50 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 50 The debugging process

51 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Software validation l Verification and validation (V & V) is intended to show that a system conforms (obedient) 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 (gain) from the specification of the real data to be processed by the system.

52 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 52 The testing process Figure 4.9 the testing process

53 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 53 Testing stages l Component or unit testing Individual components are tested independently; Components may be simple entities such as functions or objects class. or may be related groupings of these entities. l System testing The components are integrated to make up the system. This process is concerned with finding errors that result from unanticipated (unexpected) interactions between component interface problems. It is also concerned with validating that the system meets its functional and non-functional requirements. For large systems, may be a multistage process where components are integrated to form sub-systems that are individually test before they are themselves integrated to form the final system.

54 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 54 Testing stages l Acceptance testing Testing with customer (real) data to check that the system meets the customer’s needs. It may reveal errors and omissions in the system requirements definition because the real data exercise the system in different ways from the test data. 80 l Usually, system development and testing are interleave. l Figure 4.10, explain how to connect with testing plain between the development and testing

55 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 55 Testing phases Figure 4.10 Testing Phases

56 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 56 Category of Acceptance Testing l Alpha testing: custom system are developed for a single client. The Alpha testing process continues until the system developer and client agree that the delivered system is an acceptable implementation of the system requirements. l Beta testing: when a system is to be marketed as a software product, this testing process called Beta testing, it involves delivering a system to a number of potential customers who agree to use that system. Then report problems to the system developers. This exposes the product to real use and detects errors that may not have been anticipated by the system builders. 81

57 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Software evolution l Once a decision has been made to procure hardware, it is very expensive to make changes to the hardware design, however change can be made to software at any time during or after the system development. l As requirements change through changing business circumstances, the software that supports the business must also evolve and change.

58 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 58 l Distinction between development and evolution (maintenance) is becoming increasingly irrelevant (unrelated). l Fewer and fewer software systems are now completely new systems, l It is more realistic to think of software engineering as an evolutionary process. 82

59 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 59 System evolution Figure 4.11 System evolution

60 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide The Rational Unified Process (RUP) l A modern process model derived from the work on the UML (Unified Modeling Language) and associated process. l Normally described from 3 perspectives (viewpoint) A dynamic perspective that shows phases over time; A static perspective that shows process activities; A practice perspective that suggests good practice.

61 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 61 RUP phases l RUP is a phased model that identifies four discrete (separated) phases in the software process. However, unlike the waterfall model where phases are equated with process activities, the phase of RUP are more closely related to business rather than technical concerns. l Include four stage as followed : (Dynamic view) 1. Inception Establish the business case for the system. You should identify all external entities (people and system) that will interact with the system and define these interactions. You should use this information to assess the contribution that the system makes to the business. In case the contribution is minor then the project may be cancelled.

62 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 62 Dynamic view 2. Elaboration Toe goals is Develop an understanding of the problem domain Establish an architecture framework for the system Identify key project risks when develop project plan When completion of this phase, you have  Requirements model for the system (UML are specified)  Architectural description and software development plan 3. Construction In this phase is essentially concerned System design, programming and testing. Some systems are developed in parallel and integrated during this phase. When completion, you should have a working software system and associated documentation that is ready for delivery to users.

63 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Transition Is final phase, concerned with moving the system from the development environment to the user community and making it work in a real environment. This is a expensive and sometimes problematic activity, but is ignored in the most software process models. 83

64 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 64 Dynamic view l RUP is Iteration activities and supported in two ways. Each phase may be enacted (act) in an interative way with the results (complete) developed incrementally. The whole set of phase may also be enacted an interative way incrementally too, as show by the looping arrow from Tasnsition to Inception in followed next Figure 4.12

65 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 65 RUP phase model

66 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 66 Workflows in the RUP description l The static view of the RUP focuses on the activities during the development process. l These are called workflows in RUP description There are six core process workflows identified in the process and three core supporting workflows. The RUP has been designed in conjunction with the UML (Unified Modeling Language) The workflows show in followed figure 4.13

67 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 67 Static workflows (static view)

68 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 68 RUP describes good SE practice Six fundamental best practices are recommended: 1. Develop software iteratively Plan increments of the system based on customer requirement Develop and deliver the highest priority system features early in the development process. 2. Manage requirements Explicitly the customer’s requirements document keep track of change the requirements Analyse the impact of changes on the system before accepting them.

69 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Use component-based architectures Transfer the system structure into components 4. Visually model software Use graphical UML models to show static and dynamic view of the software system. 5. Verify software quality Ensure that the software meets the organization quality standards. 6. Control changes to software Manage changes to the software using a change management system and configuration management procedures and tools 84

70 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide Computer-aided software engineering (CASE) l Computer-aided software engineering (CASE) is software to support software development and evolution processes activities. l The activities include such requirements engineering, design, program development and testing. l So case tool include design editors, data dictionaries, compilers, debuggers, system building tools and so on.

71 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 71 l Case technology provides software process support by automating some process activities and by providing information about the software that is being developed.

72 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 72 l Example of Activity that can be automated : 1.Graphical editors for system model development; 2.Data dictionary that holds information about the entities and relations in a design; 3.Generation of user interfaces from a graphical interface description that is created interactively by the user; 4.Program debugging through the provision of information about an executing program; 5.Automated translators to generate new versions of a program from an old version of a programming, language such as COBOL. 85

73 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 73 Case technology l Case technology has led to significant improvements in the software process, in fact, the improvements have been achieved 40% saved. However, it did not generate huge savings in software process costs.

74 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 74 l CASE are limited by two factor : 1.Software engineering requires creative thought existing CASE system can easily automate routine activities But try to use artificial intelligence technology to provide support for design have not been successful. 2.Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these.

75 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 75 CASE technology is now mature l In the market the CASE tools and workbenches are available from a wide range of suppliers.

76 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 76 CASE classification Classification helps us understand the different types of CASE tools and their support for process activities. 1. Functional perspective Tools are classified according to their specific function. 2. Process perspective Tools are classified according to process activities that are supported. 3. Integration perspective Tools are classified according to their organisation into integrated units.

77 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 77 Figure 4.14 l In figure 4.14, according to functionality to classified the case tool.

78 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 78 Functional tool classification Figure 4.14

79 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 79 Figure 4.15 l It is the other way to classified to show the each step of development when use CASE tools.

80 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 80 Activity-based tool classification Figure 4.15

81 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 81 CASE integration The other classified way for CASE is depending on it can support the how wide of software process 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.

82 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 82 Tools, workbenches, environments

83 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 83 Key points 1. Software processes are the activities involved in producing and evolving a software system. 2. Software process models are abstract representations of these processes. 3. General activities are specification, design and implementation, validation and evolution. 4. Generic process models describe the organisation of software processes. Examples include the waterfall model, evolutionary development and component- based software engineering. 5. Iterative process models describe the software process as a cycle of activities.

84 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 84 Key points 6. Requirements engineering is the process of developing a software specification. 7. Design and implementation processes transform the specification to an executable program. 8. Validation involves checking that the system meets to its specification and user needs. 9. Evolution is concerned with modifying existing system to meet new requirements. This is becoming the normal approach to software development for small and medium-sized systems.

85 More informations l Computer Aided Software Engineering (CASE tool) Computer Aided Software Engineering tools offer many benefits for developers building large-scale systems. As spiralling user requirements continue to drive system complexity to new levels, enabling us to abstract away from the entanglement of source code, to a level where architecture and design become more apparent and easier to understand and modify. The larger a project, the more important it is to use a case tool in software development. As developers interact with portions of a system designed by their colleagues, they must quickly seek a subset of classes and methods and assimilate an understanding of how to interface with them. In a similar sense, management must be able, in a timely fashion and from a high level, to look at a representation of a design and understand what's going on. For these reasons, CASE tools coupled with methodologies give us a way of representing systems too complex to comprehend in their underlying source code or schema-based form. Select Business Solutions has been developing and building these CASE tools since the late 1980s, as well as developing processes and methods to support high quality application development. Solution Breakdown Select Solution Factory a Business Process Modeling - BPM, a Unified Modeling Language - UML modeling tool, and Data Modeling CASE Tool Select Scope Manager a eXtreme Programming and Agile Modeling CASE Tool Select SSADM a Structured Systems Analysis and Design Methodology CASE Tool Select Yourdon a real time CASE Tool supporting the Yourdon, Hatley-Pirbhai and Ward-Mellor real-time extensions. Select Solution FactorySelect Scope ManagerSelect SSADMSelect Yourdon

86 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide The Rational Unified Process is a modern generic process model that is organised into phases (inception, elaboration, construction and transition “Dynamic perspective”) but that separates activities (requirements, analysis and design, etc. ”Static perspective”) 11. CASE technology provides automated supports for software process. CASE tools support individual process activities; workbenches support a set of related activities; environments support all or most software process activities.

87 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 87 End week 6

88 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 88 Week 8 testing l Could you explain how many Software process models in this chapter, and detail explain them?

89 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 89 Ans l p65

90 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 90 Exercises 4.1 l giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems: A system to control anti-lock braking in a car. Anti-lock braking system: Safety-critical system so method based on formal transformations with proofs of equivalence between each stage, therefore waterfall model is appropriate.

91 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 91 A virtual reality system to support software maintenance : Virtual reality system, the system whose requirements cannot be predicted in advance so exploratory programming model is appropriate. (4.1.2) 68 A university accounting system that replaces an existing system : System whose requirements should be stable because of existing system therefore waterfall model is appropriate.

92 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 92 An interactive system that allows railway passengers to find train times from terminals installed in stations. System with a complex user interface but which must be stable and reliable. Should be based on throw- away prototyping to find requirements then either incremental development or waterfall model. (4.1.2) 68

93 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 93 Exercises 4.2 l Explain why programs that are developed using evolutionary development are likely to be difficult to maintain. From an engineering and management perspective, the evolutionary approach has two 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. Systems are often poorly structured: continual change tends to corrupt the software structure. Incorporating software changes becomes increasingly difficult and costly.

94 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 94 Exercises 4.5 l Suggest why it is important to make a distinction between developing the user requirements and developing system requirements in the requirements engineering process. User requirements (high-level abstract requirements): are statement, in a natural language plus diagrams, of what services the system is expected to provide and the constraints under which it must operate. System requirements (detailed description of what the system should do, sometimes call a functional specification): set out the system’s functions, services and operational constraints in detail. The system requirements document should be precise (exact). It should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.

95 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 95 Exercises 4.6 l Describe the main activities in the software design process and the outputs of these activities. Using a diagram, show possible relationships between the outputs of these activities.

96 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 96 Answer Architectural design 2. Abstract specification 3. Interface design 4. Component design 5. Data structure design 6. Algorithm design The diagram as show on page 77, figure 4.7

97 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 97 Exercises 4.8 l Design a process model for running system tests and recording their results. Running programRecording resultError occur Input new data for test Yes No System stop

98 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 98 Exercises 4.9 l Explain why a software system that is used in real- world environment must change or become progressively less useful. Systems must change because as they are installed in an environment the environment adapts to them and this adaptation naturally generates new/different system requirements. Furthermore, the system's environment is dynamic and constantly generates new requirements as a consequence (result) of changes to the business, business goals and business policies. Unless the system is adapted to reflect these requirements, its facilities will become out-of-step with the facilities needed to support the business and, hence, it will become less useful

99 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 99 Exercises 4.10 l Suggest how a CASE technology classification scheme may be helpful to managers responsible for CASE system procurement A classification scheme can be helpful for system procurement because it helps identify gaps in the CASE tool coverage in an organization. Procurement may be aimed at filling these gaps. Alternatively, a classification scheme may be used to find tools which support a range of activities - these may represent the most cost effective purchases if funds are limited.

100 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 100 Exercises 4.12 l Historically, the introduction of technology has caused profound (deep) changes in the labour market and, temporarily at least, displaced (replace) people from jobs. Discuss whether the introduction of advanced CASE technology is likely to have the same consequences for software engineers. If you don’t think it will, explain why not. If you think that it will reduce job opportunities, is it ethical (moral) for the engineers affected to passively (inactive) or actively resist the introduction of this technology?

101 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 101 l Ans: There are obviously (easy understand) different views here and a lot depends on the development of CASE technology in the future. A major difference between the introduction of CASE technology and, for example, the introduction of CAD technology which made draftsmen redundant, is that the routine elements in the design and development of software are relatively minor parts of the whole development process. Therefore, savings are not that large. However, if AI (Artificial Intelligent) technology develops so that truly intelligent tools can be developed than, obviously, this situation will change. By the way, new technology will change some job to become redundant, but in the same time, it will create new opportunity and new jobs for the new century.

102 © Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 102 End


Download ppt "© Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Chap 4 Software Processes."

Similar presentations


Ads by Google