Presentation is loading. Please wait.

Presentation is loading. Please wait.

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.

Similar presentations


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

1 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes

2 ©Ian Sommerville 2004Software Engineering, 7th 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 2004Software Engineering, 7th edition. Chapter 4 Slide 3 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.

4 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 4 Generic software process models l The waterfall model Separate and distinct phases of specification and development. l Evolutionary development Specification, development and validation are interleaved. l Component-based software engineering The system is assembled from existing components. l There are many variants of these models e.g. formal development where a waterfall-like process is used but the specification is a formal specification that is refined through several stages to an implementable design.

5 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 5 Waterfall model

6 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 6 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 main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. One phase has to be complete before moving onto the next phase.

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

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

9 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 9 Evolutionary development

10 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 10 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.

11 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 11 Component-based software engineering 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 increasingly used as component standards have emerged.

12 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 12 Reuse-oriented development

13 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 13 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 delivery; Spiral development.

14 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 14 Incremental delivery 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.

15 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 15 Incremental development

16 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 16 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.

17 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 17 Extreme programming l An 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. l Covered in Chapter 17

18 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 18 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.

19 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 19 Spiral model of the software process

20 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 20 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.

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

22 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 22


Download ppt "©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes."

Similar presentations


Ads by Google