Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 2 Software Process Models 1. Process Models Often referred to as “conventional” process models Prescribe a set of process elements – Framework.

Similar presentations

Presentation on theme: "Chapter 2 Software Process Models 1. Process Models Often referred to as “conventional” process models Prescribe a set of process elements – Framework."— Presentation transcript:

1 Chapter 2 Software Process Models 1

2 Process Models Often referred to as “conventional” process models Prescribe a set of process elements – Framework activities – Software engineering actions – Tasks – Work products – Quality assurance and – Change control mechanisms for each project There are a number of process models in operation They are not perfect but they provide a useful roadmap for SW engineering work Each process model also prescribes a workflow 2

3 A Generic Process Model 3

4 Process Flow 4

5 Build & Fix Model Product is constructed without specifications or any attempt at design Adhoc approach and not well defined Simple two phase model 5

6 Build & Fix Model Suitable for small programming exercises of 100 or 200 lines Unsatisfactory for software for any reasonable size Code soon becomes unfixable & unenhanceable No room for structured design Maintenance is practically not possible 6

7 The Waterfall Model Sometimes called classic life cycle Suggests a systematic, sequential approach to software development – It reinforces the notion of “define before design” and “design before code”. Works best when – Requirements of a problem are reasonably well understood – Well-defined adaptations or enhancements to an existing system must be made – Requirements are well-defined and reasonably stable 7

8 The Waterfall Model 8 This model is named “waterfall model” because its diagrammatic representation resembles a cascade of waterfalls.

9 The Waterfall Model - Problems It is difficult to define all requirements at the beginning of a project This model is not suitable for accommodating any change A working version of the system is not seen until late in the project’s life It does not scale up well to large projects. Real projects are rarely sequential. 9

10 The Incremental Model It combines elements of the waterfall model applied in an iterative fashion It delivers a series of releases, called increments, that provide progressively more functionality for customer as each increment is delivered When it is used, the first increment is often a core product. That is, basic requirements are addressed, but many supplementary features remain undelivered The core product is used by customer. As a result, a plan is developed for next increment 10

11 The Incremental Model 11

12 The Incremental Model This model focuses on the delivery of an operational product with each increment Incremental development is particularly useful when staffing is unavailable for a complete implementation by the business deadline. Early increments can be implemented with fewer people, and additional staff can be added to later increments Increments can be planned to manage technical risks 12

13 The RAD Model RAD (Rapid Application Development) is an incremental SW process model that emphasizes a short development cycle RAD model is a “high-speed” adaptation of the waterfall model, in which rapid development is achieved by using a component-based construction approach If a business application can be modularized in a way that enables each major function to be completed in less than 3 months, it is a candidate for RAD – Each major function can be addressed by a separate RAD team and then integrated to form a whole 13

14 The RAD Model 14

15 The RAD Model 15 Developed by IBM in 1980 User participation is essential

16 The RAD Model Build a rapid prototype Give it to user for evaluation & obtain feedback Prototype is refined With active participation of users 16

17 The RAD Model - Drawbacks Not an appropriate model in the absence of user participation. For large, but scalable projects, RAD requires sufficient human resources to create right number of RAD teams – Highly specialized & skilled developers are are not easily available. If a system cannot be properly modularized, building the components necessary or RAD will be problematic – Reusable components are required to reduce development time. RAD may not be appropriate when technical risks are high 17

18 Evolutionary Process Models Evolutionary models are iterative They are characterized in a manner that enables SW engineers to develop increasingly more complete versions of the software Example models – Prototyping model – The Spiral model – Concurrent model 18

19 Evolutionary Models: Prototyping The prototype may be a usable program but is not suitable as the final software product. The code for the prototype is thrown away. However, experience gathered helps in developing the actual system. The development of a prototype might involve extra cost, but overall cost might turnout to be lower than that of an equivalent system developed using the waterfall model. 19

20 Evolutionary Models: Prototyping 20

21 Evolutionary Models: Prototyping The customer sees what appears to be a working version of SW, unaware that in the rush to get it working we haven’t considered overall quality or long-term maintainability The developer often makes implementation compromises in order to get prototype working quickly 21

22 Evolutionary Models: Spiral Couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model It provides the potential for rapid development of increasingly more complete versions of the software It is a risk-driven process model generator It has two main distinguishing features – Cyclic approach Incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk – A set of anchor point milestones A combination of work products and conditions that are attained along the path of the spiral 22

23 Evolutionary Models: Spiral 23

24 Evolutionary Models: Spiral Unlike other process models that end when software is delivered, the spiral model can be adapted to apply throughout the life of the computer s/w The circuits around the spiral might represent – Concept development project – New Product development project – Product enhancement project The spiral model demands a direct consideration of technical risks at all stages of the project 24

25 Evolutionary Models: Spiral Difficult to convince customers that evolutionary approach is controllable Demands considerable risk assessment expertise and relies on this expertise for success If major risks are uncovered and managed, problems will occur 25

26 Evolutionary Models: Concurrent Sometimes called concurrent engineering Can be represented schematically as a series of framework activities, s/w engineering actions and tasks, and their associated states Defines a series of events that will trigger transitions from state to state for each of the s/w engineering activities, actions, or tasks Defines a network of activities E. g. The modeling activity which existed in none state while initial communication was completed, now makes a transition into under development state. If customer indicates that changes in requirements must be made, modeling activity moves from under development state into awaiting changes state 26

27 Evolutionary Models: Concurrent 27

28 Evolutionary Models: Concurrent Is applicable to all types of software development and provides an accurate picture of the current state of project All activities exist concurrently but reside in different states Events generated at one point in the process network trigger transitions among the states 28

29 Other Process Models Component-based development—the process to apply when reuse is a development objective Formal methods—emphasizes the mathematical specification of requirements AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Process—a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) 29

30 The Unified Process (UP) Developed by I.Jacobson, G.Booch and J.Rumbaugh It is a use-case driven, architecture-centric, iterative and incremental software process UP is an attempt to draw on the best features and characteristics of conventional s/w process models Also implements many of the best principles of agile software development UP is a framework for object-oriented software engineering using UML (Unified Modeling Language) 30

31 Phases of The Unified Process 31

32 Phases of UP - Inception Defines scope of the project Encompasses both customer communication and planning activities Fundamental business requirements are described through a set of preliminary use-cases – A use-case describes a sequence of actions that are performed by an actor (e.g., a person, a machine, another system) as the actor interacts with the software A rough architecture for the system is also proposed 32

33 Phases of UP - Elaboration Encompasses customer communication and modeling activities Refines and expands the preliminary use-cases Expands the architectural representation to include five different views of the software – The use-case model – The analysis model – The design model – The implementation model – The deployment model In some cases, elaboration creates an “executable architectural baseline” that represents a “first cut” executable system 33

34 Phases of UP - Construction Makes each use-case operational for end-users As components are being implemented, unit tests are designed and executed for each Integration activities (component assembly and integration testing) are conducted Use-cases are used to derive a suite of acceptance tests 34

35 Phases of UP - Transition Involves many activities like delivering, training, supporting, and maintaining the product. Software is given to end-users for beta testing The software team creates the necessary support information – User manuals – Trouble-shooting guides – Installation procedures At the conclusion of the transition phase, the software increment becomes a usable software release 35

36 Phases of UP - Production Coincides with the deployment activity of the generic process The on-going use of the software is monitored Support for the operating environment (infrastructure) is provided Defect reports and requests for changes are submitted and evaluated 36

37 Unified Process Work Products Inception – Vision document – Initial use-case model Elaboration – Analysis model, design model Construction – Implementation model, deployment model, test model Transition – Delivered software, beta test reports, general user feedback 37

38 Initial Development & Evolution Cycles 38

39 Iterations & Workflow of Unified Process 39

40 Selection of a Life Cycle Model Selection of a model is based on: a) Requirements b) Development team c) Users d) Project type and associated risk 40

41 Based On Characteristics Of Requirements 41

42 Based On Status Of Development Team 42

43 Based On User’s Participation 43

44 Based On Type Of Project With Associated Risk 44

Download ppt "Chapter 2 Software Process Models 1. Process Models Often referred to as “conventional” process models Prescribe a set of process elements – Framework."

Similar presentations

Ads by Google