Prescriptive Process Models Chapter 3 Prescriptive Process Models Discussion of the Software Process models:

Software Process Models (1) Prescriptive process models evolved over the years to bring some order to the software development (structure, order, consistency)… But, the software industry is fast changing! A prescriptive process model is a strategy/paradigm that prescribes a set of process elements (activities, actions, work tasks, product, QA, CM) and a workflow. Different software projects require different process models! Why? - nature of the application - complexity - methods and tools - required control - expected quality - outcomes/products

Software Process Models (2) Key phases of a software process model:

The Waterfall Model (1) Known as classic life cycle or sequential model. Communication Planning Modeling Deployment Development

The Waterfall Model (2) Life cycle phases: 1. Communication (Requirements Analysis): Good understanding of the system (databases, performance, interface/user, functions). Document: SRS - What the system will do. 2. Planning: Developing project development plan (estimation, scheduling, tracking, and risk management). Document: SDP – The project development plan.

The Waterfall Model (3) 3. Modeling (Design): Translating requirement specifications of a software systems that can be assessed for against requirements. Design elements: data structures, software architecture, interfaces, implementation (algorithmic) details. Document: SDD - How the system will work. 4. Coding: Translation design into code (programming task). Document: generated code (modules, procedures, packages, classes, etc..)

The Waterfall Model (4) 5. Testing: Process of finding unknown errors and defects using a test plan that consist of test cases. Testing begins before coding starts! Test cases are traceable to requirements Testing begins in the small Unit testing Integration testing System testing Acceptance testing Document: Test Plan and Test Cases

The Waterfall Model (5) 5. Deployment (Support): Delivery, support, and feedback. Application of previous phases when making a change to deployed system (new requirements, environment changes, interface/user changes, etc…). Potential Problems: - Incomplete requirements - Long waiting for a working version (client perspective) - Critical path - blocking states and waiting time - Projects do not follow sequential flow! Too many changes BUT, the model defines essential activities for software development...

The Incremental Model (1) It is an iterative linear process that produces functional increments (usable modules) of the system. a n l y s i d e g c o t increment 1 delivery of 1st increment increment 2 2nd increment increment 3 3rd increment calendar time Core Product Additional Features

The Incremental Model (2) - It is an evolutionary model. - First increment is the core product (focus on the essential requirements of the system) - Plans for future increments (additional requirements) must be developed. Advantages: - Increments are functional products (unlike prototyping) - Staffing is not an issue, adjusted as needed - Facilitates managing technical and other risks Any disadvantages?

The RAD Model (1) - Incremental process that uses component-based development for business applications, and emphasizes short life cycle. Ideally, each business function is completed in 2 to 3 months. Business Modeling Data Process modeling Application generation Testing and turnover b u s i n e m o d l g a t p r c & v team #1 team #2 team #3 60 - 90 days

The RAD Model (2) RAD phases: (Applied to modeling and development phases) 1. Business modeling - identify business functions, processes, and what/how/who generates information. 2. Data modeling - redefine business information to data objects, and define object attributes and relationships among objects. 3. Process modeling - describe how processes manipulate (add, delete, retrieve, update) data objects to implement business functions. 4. Application generation - automated tools (4th generation techniques) are used to create the application by using component reuse.

The RAD Model (3) 5. Testing - mainly component integration and system testing since components are already tested. Challenges: - Requires sufficient human resources - Require careful planning for multiple teams - Requires commitment (developer and customer) - Limited to specific systems (with modularity nature) (business applications) - Inappropriate when technical risks are high (technology and interoperability)

The Prototyping Model (1) - Evolutionary model - iterative - Incomplete requirements? Go prototyping! - The prototype shows software aspects visible to the user. Listen to customer Quick Plan Design/Build /Revise mock-up Customer test-drives

The Prototyping Model (2) The purpose: - to satisfy customer needs - to understand system requirements What to do with the prototype? - throw it away or reuse it? Must decide before you build it. Potential problems: - Pressure to extend the prototype to a working system! - The “less-than-ideal choice” becomes part of the system! Prototyping keeps everyone happy! Only if the customer agrees to its purpose and what you will do with it...

The Spiral Model (1) An evolutionary iterative process (with controlled step-wise waterfall) that produces incremental releases of the system (not necessarily functional increments!) Engineering Customer Communication Construction & Release Risk Analysis Planning Customer Evaluation SRS Prototype Working Version Complete System

The Spiral Model (2) - Each release goes through task regions, each task region defines a set of work tasks relevant to the project type and size. - It is appropriate for large-scale evolving software projects. - It facilitates prototyping (in early passes) to reduce risks! - Allows constant risk assessment in all region - Each pass thought the planning region, the project plan, schedule, and cost are adjusted accordingly. Drawback: - Less popular than sequential and prototype models - Does not appeal to the customer! - Require considerable risk assessment expertise

The Concurrent Process Model An evolutionary iterative concurrent process where all process activities are concurrent, but at different states. Appropriate for system engineering (different engineering teams) Similar to RAD model, but at the system level! Uses events and states to represent process activities. Defines a “network” of activities with changing states (via events) See figure 3.6, page 57 - States of modeling activity.

The Unified Process (1) A “use-case driven, architecture-centric, iterative and incremental” software process. It integrates different component-based development models into one scenario-based unified model. It emphasizes customer communications through use-cases. It is a framework for OO development with UML modeling. Developed by James Rumbaugh, Grady Booch, and Ivar Jacobson in early 1990s, by combing the best of their individual OOA and OOD methods.

Unified Process (2) Phase: inception E l a b o r a t i o n I n c e p t Planning Modeling Communication Construction Deployment c o n s t r u c t i o n R e l e a s e t r a n s i t i o n s o f t w a r e i n c r e m e n t p r o d u c t i o n

Unified Process (3)

Unified Process (4) See Figure 3.8, page 67: UP Work Products.

Other Process Models (1) Component-Based Development model: A specialized model that Integrates OO technology to the engineering and construction activities of the spiral model. Used when reuse of COTS components is the main objective. This model aims to improve software development. (70% saving in time, 84% saving in cost, 26.2 productive index (the norm is 16.9) (see page 60)

Other Process Models (2) Formal Methods (Cleanroom SE): The application of formal mathematical specifications to develop safety-critical software applications. The emphasis is on defect-free software using formal methods during analysis and design. Issues: cost is high, training is extensive, communication with customer is difficult. Aspect-Oriented Model: New “immature” process model that focus on modeling aspects as customer concerns that cut cross multiple system functions, features, and information. (self-reading)

Suggested Problems Try to work problems 2, 3, 4, 5, 6, 7, 8, 10, 11, 14, and 15 from Chapter 3, page 69. No submission is required for practice assignments. Work it for yourself!

Last Slide End of chapter 3