©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 1 Chapter 4 Software Processes

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 2 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing software systems.

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 3 Objectives l To introduce software process models. l To describe a number of generic process models and when they may be used. l To outline lower-level process models for (1) requirements engineering, (2) software development, (3) testing, and (4) evolution. l To introduce CASE technology to support software process activities

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 4 Topics covered l Software process models l Process iteration l Software specification l Software design and implementation l Software verification & validation l Software evolution l Automated process support

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 5 The software process l A process is a structured set of activities required to develop a software system, e.g. Specification Design Validation / Verification Evolution l A process model is an abstract representation of a process. It presents a description of a process from some particular perspective l Models should be as simple as possible, but no simpler. – A. Einstein

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 6 The software process l A process is a structured set of activities required to develop a software system, e.g. Specification Design Validation / Verification Evolution l A process model is an abstract representation of a process. It presents a description of a process from some particular perspective l Models should be as simple as possible, but no simpler. – A. Einstein [struhk-cherd] –adjective; having and manifesting a clearly defined structure or organization.

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 7 Generic software process models l The Waterfall Model – separate and distinct phases of specification and development. Traditionally: not iterative. l Evolutionary Development – specification and development are interleaved. l Reuse-Based Development – e.g., component-based: the system is assembled from existing components. (And, at no additional cost: Incremental, eXtreme, and Spiral.)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 8 Waterfall model (W. Royce)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 9 Waterfall model problems l Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. l Thus, this model is only appropriate when the requirements are well-understood (to begin with) l In general, the drawback of the waterfall model is the difficulty of accommodating change after the process is underway. Can we say anything good about the Waterfall model?

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 10 Evolutionary development l Exploratory Development * – objective is to work with customers and to evolve a final system from an initial outline specification. (Development starts with well-understood parts of system.) important theme in Agile Development l Throw-Away Prototyping – objective is to understand the system requirements. (Prototyping focuses on poorly understood requirements.) * also known as exploratory programming, or evolutionary prototyping (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 11 Evolutionary development customer trash (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 12 Evolutionary development l Potential problems Lack of process visibility. (via documents: c.f. Waterfall model) Final version/prototype is often poorly structured. Special skills (e.g., in languages for rapid prototyping) may be required. – working effectively with people l Applicability For small or medium-size interactive systems. For parts of large systems (e.g., the user interface). For short-lifetime systems. (In the case of exploratory development – why?)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 13 Reuse-oriented development l Based on systematic (as opposed to serendipitous) reuse of existing software units. l Units may be: Procedures or functions (common for past 40 years) Components (“component-based development”) Core elements of an application (“application family”) Entire applications -- COTS (Commercial-off-the-shelf) systems l May also be based on use of design patterns. (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 14 Reuse-oriented development Process stages: (following initial requirements specification) Reusable software analysis (what’s available?) Requirements modification – why? System design with reuse Development and integration l This approach is becoming more important, but experience is still limited. “Software Repositories” research was a major DoD thrust in the late 80’s. (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 15 Reuse-oriented development (what’s available?)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 16 Process iteration l For large systems, requirements ALWAYS evolve in the course of a project. l Thus, process iteration is ALWAYS part of the process. l Iteration can be incorporated in any of the generic process models. (but not in keeping with spirit of Waterfall…) l Two other approaches that explicitly incorporate iteration: Incremental delivery Spiral development (Boehm)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 17 Incremental delivery l Rather than deliver the system as a single unit, the development and delivery is broken down into increments, each of which incorporates part of the required functionality. l User requirements are prioritized and the highest priority requirements are included in early increments. l Once the development of an increment is started, its requirements are “frozen” while requirements for later increments can continue to evolve. (Compromise between Waterfall & Evolutionary development) (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 18 Incremental delivery (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 19 Incremental delivery advantages l Useful functionality is delivered with each increment, so customers derive value early. 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. (they're subject to more “validation” steps) (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 20 Potential problem with incremental delivery l Requirements may NOT be partitionable into stand- alone increments. (e.g., a compiler) (A generalization of incremental delivery, known as Incremental Software Development, is discussed in Chap. 17, Rapid Software Development.)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 21 Extreme programming (Beck ’99) l Recent evolution of incremental approach based on Development and delivery of very small increments of functionality Significant customer involvement in process Constant code improvement Egoless, pair-wise programming l NOT document-oriented l Gaining acceptance in some small (and now medium sized) organizations. l Representative of the “Agile” development paradigm.

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 22 Boehm’s spiral development l Process is represented as a spiral rather than a sequence of activities. 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 Explicitly incorporates risk assessment and resolution throughout the process. (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 23 Spiral model of the software process

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 24 Spiral model quadrants 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, Chapter 4 Slide 25 Models for (lower level) fundamental process activities l Software specification/requirements engineering (RE) l Software development (design and implementation) l Software verification and validation l Software evolution

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 26 Software specification / RE l The process of establishing what services are required and the constraints on the system’s operation and development. l Requirements Engineering (RE) process: Feasibility (technical and otherwise) study Requirements elicitation and analysis Requirements specification (documentation) Requirements validation (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 27 The requirements engineering process

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 28 Software design and implementation l The process of producing an executable system based on the specification Software design – design a software structure that realizes the specification. Implementation – translate this structure into an executable program. l The activities of specification, design, and implementation are closely related and may be interleaved.

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 29 Design process activities l “High-Level” design activities Architectural design – subsystems and their relationships are identified Abstract specification – of each sub-system’s services Interface design – among sub-systems l “Low-Level” design activities Component design – services allocated to different components and their interfaces are designed Data structure design Algorithm design

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 30 The software design process

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 31 Design methods l Systematic (canned) approaches to developing a software design. the cookbook approach… 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, Chapter 4 Slide 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 (“unit testing”), and remove faults in the debugging process. (Compare this model with Cleanroom SE.)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 33 The debugging process

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 34 Software verification & validation l Verification and validation (V&V) determines whether or not a system (1) conforms to its specification and (2) meets the needs of the customer. l Involves inspection / review processes and (machine- based) testing. l Testing involves executing system elements with test cases that are derived from specifications and/or program logic.

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 35 Testing stages (topic 14) l Unit/Module testing - individual function/procedures are tested l (unit/module) Integration testing l Component testing - functionally related units/modules are tested together l (component) Integration testing l Sub-system/product testing - sub-systems or products are tested l (product/sub-system) Integration testing l System testing - testing of the system as a whole, including user acceptance test cf “traditional” (i.e., waterfall) model of testing…

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 36 Waterfall model (W. Royce)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 37 Software evolution l Software is inherently flexible and subject to change. l As requirements change through changing business circumstances, the software that supports the business must also evolve and change. l The distinction between development and evolution is increasingly irrelevant as fewer and fewer systems are completely new. (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 38 System evolution e.g., change requests (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 39 The Rational Unified Process l A modern process model derived from the work on the UML and associated process. l Normally described from 3 perspectives A dynamic perspective that shows phases over time; A static perspective that shows process activities; A practice perspective that suggests good practice. A hybrid process model that brings together elements from all of the generic process models…represents a new generation of generic processes (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 40 The Rational Unified Process l A modern process model derived from the work on the UML and associated process. l Normally described from 3 perspectives A dynamic perspective that shows phases over time; A static perspective that shows process activities; A practice perspective that suggests good practice. A hybrid process model that brings together elements from all of the generic process models…represents a new generation of generic processes (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 41 RUP phase model cf Waterfall Model: RUP phases are more closely related to business rather than technical concerns. (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 42 RUP phases l Inception Establish the business case for the system. l Elaboration Develop an understanding of the problem domain and the system architecture. l Construction System design, programming and testing. l Transition Deploy the system in its operating environment. (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 43 The Rational Unified Process l A modern process model derived from the work on the UML and associated process. l Normally described from 3 perspectives A dynamic perspective that shows phases over time; A static perspective that shows process activities; A practice perspective that suggests good practice. A hybrid process model that brings together elements from all of the generic process models…represents a new generation of generic processes (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 44 Static workflows (process activities)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 45 The Rational Unified Process l A modern process model derived from the work on the UML and associated process. l Normally described from 3 perspectives A dynamic perspective that shows phases over time; A static perspective that shows process activities; A practice perspective that suggests good practice. A hybrid process model that brings together elements from all of the generic process models…represents a new generation of generic processes (cont'd)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 46 RUP good practice l Develop software iteratively l Manage requirements l Use component-based architectures l Visually model software (e.g., UML packages, sequence models, state machine models) l Verify software quality l Control changes to software

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 47 Automated process support (CASE) l Computer-aided software engineering (CASE) is software to support software development and evolution processes. l Activity automation (examples): Graphical editors for system model development Data dictionaries for name management GUI builders for user interface construction Debuggers to support program fault finding Automated translators to generate new versions of a program (e.g., restructuring tools)

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 48 CASE technology l CASE technology has led to significant improvements in the software process, but not the order of magnitude improvements that were once predicted. Software engineering involves design activity requiring 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 support this well.

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 49 CASE classification l Classification helps us understand the different types of CASE tools / systems 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 – CASE systems are classified according to their breadth of support for the software process.

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 50 Functional tool classification TOOL TYPES: Planning tools Editing tools Change mgmt tools Configuration mgmt tools Prototyping tools Method-support tools Language-processing tools Program analysis tools Testing tools Debugging tools Documentation tools Reengineering tools EXAMPLES: PERT tools, estimation tools, spreadsheets Text editors, diagram editors, word processors Rqmts traceability tools, change control sys Version mgmt systems, system building tools V. high-level langs, user interface generators Design editors, data dicts, code generators Compilers, interpreters Cross ref generators, static/dynamic analyzers Test data generators, file comparators Interactive debugging systems Page layout programs, image editors Cross-ref systems, program restructuring systems

Activity-based classification Actually far more lower CASE tools than upper CASE

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 52 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, Chapter 4 Slide 53 Tools, workbenches, environments

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 54 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 Fundamental (lower level) activities are specification, design and implementation, validation & verification, and evolution. l Generic models are very general process models representing different approaches to development. l Iterative process models describe the software process as a cycle of activities.

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 55 Key points (cont’d) l Requirements engineering is the process of establishing what services are required and the constraints on the system’s operation and development. l Design and implementation processes produce an executable system based on the specification. l V&V involves checking that the system meets its specification and satisfies user needs. l Evolution is concerned with modifying the system after it is placed in use. l CASE technology supports software process activities.

©Ian Sommerville 2000 Software Engineering, Chapter 4 Slide 56 Chapter 4 Software Processes