Chapter 3 Process Models

1. Chapter 3Process Models

2. Prescriptive Models • What is it • A prescriptive process model defines a distinct set of activities, actions, tasks, milestones, and work products to engineering high-quality software. • Prescriptive process models advocate an orderly approach to software engineering That leads to a few questions … • If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? • Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

3. Prescriptive Models (cont.) • Regardless of the process model selected, it should accommodate the following generic framework activities: • communication • planning • modeling • construction • deployment

4. Process Models • Waterfall model • Incremental process models • Incremental model • RAD (rapid application development) model • Evolutionary process models • Prototyping model • Spiral model • Concurrent development model

5. The Linear Model • Waterfall model • Winston Royce, 1970 • Also called the software life cycle

6. Problems of Waterfall Model • Real projects rarely follow the sequential flow that the model proposes • It is often difficult for the customer to state all requirements explicitly • The customer must have patience • Applicable only when the requirements are well-defined and stable

7. The Incremental Model • The objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements • This model combines elements of waterfall model applied in an iterative fashion • Particular useful when staffing is limited in initial stage

8. The Incremental Model (cont.)

9. The RAD Model • Rapid Application Development is an incremental software development process model, emphasizing a short development cycle (e.g., 60 to 90 days) • For application’s requirement been well understood

10. The RAD Model (cont.)

11. Drawbacks of RAD Model • Need sufficient RAD teams for large, scalable projects • Easy to fail if developers and users are not committed to rapid-fire activities • The system need to be properly modularized • May not be appropriate if high performance is an issue • May not be appropriate when technical risks are high

12. The Prototyping Model • Objective is to understand the system requirements. Should start with poorly understood requirements • More commonly adopted within the context of any process model • Problems • “prototype” yes, it’s a prototype • Compromise (less-than-ideal) while implementation

13. The Prototyping Model (cont.)

14. The Spiral Model • Originally proposed by Boehm • Emphasize on risk management • Using this model, software is developed in a series of evolutionary releases • The spiral model can be adapted to apply throughout the life of the software • It is a realistic model to the development of large-scale systems

15. The Spiral Model

16. Drawbacks of Spiral Model • May difficult to convince customers to adopt the model – uncertain number of cycles to construct the product • Requires considerable risk assessment expertise • Problems will occur if a major risk is not uncovered and managed

17. Concurrent Development Model • Also known as concurrent engineering • Represented as a series of framework activities, software engineering actions and tasks, and associated states • Define a series of events that will trigger transition from state to state • Provide an accurate picture of project current state

18. Concurrent Development Model

19. Still Other Process Models • Component-based development model • The process to apply when reuse is a development objective • It is evolutionary in nature • It incorporates the following steps • Research and evaluate available component-based products • Consider component integration issues • Design a software architecture to accommodate the components • Integrate components into the architecture • Conduct comprehensive testing

20. Still Other Process Models (cont.) • Formal methods model • The process to apply when a mathematical specification is to be developed • Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily – promise of defect-free software • Drawbacks • Time-consuming and expensive • Need extensive training • Hard to serve as a communication mechanism • Useful for safety-critical software, e.g., Aircraft avionics, medical devices

21. Still Other Process Models (cont.) • Aspect-oriented software development (AOSD) • Aspect – customer concerns that cut across multiple system functions, features and information, e.g., • User interface aspects • Distribution aspects (transport and receiving) • Persistence aspects (data store/retrieve and indexing) • Security aspects • Transaction aspects • AOSD provides a process and methodological approach for defining, specifying, designing, and constructing aspects (modeled as components)

22. The Unified Process • What is UP • Developed by Ivar Jacobson, James Rumbaugh, and Grady Booch • A framework for object-oriented software engineering using UML (the Unified Modeling Language), an industry standard for object-oriented software development • It is a use-case driven, architecture-centric, iterative, and incremental model

23. The Unified Process (cont.) • Phases of UP • Inception • Identify business requirements, described as use-cases • Propose a rough system architecture • Elaboration • Refine and expand the preliminary use-cases • Expand the architecture to include five different views • Use-case model, analysis model, design model, implementation model, deployment model

24. The Unified Process (cont.) • Construction • Develop or acquires the software components to accomplish an initial release • Transition • Software is given to users for beta-testing to collect defects and necessary changes • Create support information, e.g., user manuals, installation procedures, trouble-shooting guides • Production • Monitor the on-going use of the software, and evaluate defect reports and change requests

25. The Unified Process (UP) inception elaboration inception

26. UP Phases

27. UP Work Products