Chapter 3 Prescriptive Process Models

SWE311_Ch03 (071)

Software & Software Engineering

Slide 1

Overview

Prescriptive process models prescribe a distinct set of activities, actions, tasks, milestones, and work products required to engineer high quality software. Prescriptive software process models are adapted to meet the needs of software engineers and managers for a specific project. Prescriptive software models provide stability, control, and organization to a process that if not managed can easily get out of control. Framework activities for a particular process model may be organized into a process flow that may be linear, incremental, or evolutionary.
Software & Software Engineering
Slide 2

SWE311_Ch03 (071)

Overview (cont)

The software engineer's work products (programs, documentation, data) are produced as a consequence of the activities defined by the software process. The best indicators of how well a software process has worked are the quality, timeliness, and long-term viability of the resulting software product.

SWE311_Ch03 (071)

Software & Software Engineering

Slide 3

Objectives

Introduce process models and the roles they play in a software engineering environment Give examples of some of the most common process models Provide means of comparing process model

SWE311_Ch03 (071)

Software & Software Engineering

Slide 4

Software Process

Aimed to control the activities of software development and as such improve quality... A structured set of activities for

Specifying, Designing, Implementing and Testing software systems

A software process model is an abstract representation of a process

a description of a process from a particular perspective

Software & Software Engineering

SWE311_Ch03 (071)

Slide 5

Software Process Models

Software process models are general approaches for organizing a project into activities

Help the project manager and his team to decide:

What work should be done In what sequence to perform the work

The models should be seen as aids to thinking, not rigid prescriptions of the way to do things Each project ends up with its own unique plan because Projects differs in the nature of the project, people doing the work, and the work environment

SWE311_Ch03 (071)

Software & Software Engineering

Slide 6

Prescriptive Models

Prescriptive process models advocate an orderly approach to software engineering

Organize framework activities in a certain order Originally proposed to bring order to the chaos of software development They brought order to software engineering work and provide reasonable guidance to software teams

Adopt following activities

Communication Planning Modeling Construction Deployment Emphasis of these activities Manners in which the framework is invoked and its relationship with other activities

Differ in

SWE311_Ch03 (071)

Software & Software Engineering

Slide 7

Prescriptive Models
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?

SWE311_Ch03 (071)

Software & Software Engineering

Slide 8

Software Processes

Every software engineering organization needs to describe a set of framework activities for the processes it adopts
Each framework activity needs to be populated with software engineering actions Each engineering action needs to be defined in terms of a task set that defines the work and work products needed to meet the development goals The resulting process model should be adapted to accommodate the nature of the specific project, people doing the work, and the work environment

SWE311_Ch03 (071)

Software & Software Engineering

Slide 9

Software Processes (cont)

Regardless of the process model selected, software engineers will chose a generic process framework that includes these activities: communication, planning, modeling, construction, and deployment Each process model will prescribe a set of process elements (framework activities, software engineering actions, tasks, work products, quality assurance, and change control mechanisms) and a workflow (the manner in which the process elements are interrelated) All software process models discussed in this chapter can accommodate the generic framework activities described previously
Software & Software Engineering
Slide 10

SWE311_Ch03 (071)

The Waterfall Model

Com m unic a t ion

proje c t init ia t ion re quire m e nt ga t he ring

Planning
es timating sc heduling tra cking

Mode ling
analysis design

Const r uc t ion
code t est

De ploy m e nt
de liv e ry s upport f e e dba c k

Old fashioned but reasonable approach when requirements are well understood

SWE311_Ch03 (071)

Software & Software Engineering

Slide 11

Limitations of the waterfall model

The model implies that you should attempt to complete a given stage before moving on to the next stage

Does not account for the fact that requirements constantly change. It also means that customers can not use anything until the entire system is complete.

The model makes no allowances for prototyping. Assumes understanding of problem and full requirements early on It implies that you can get the requirements right by simply writing them down and reviewing them.
Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.
Software & Software Engineering
Slide 12

SWE311_Ch03 (071)

Critique of Waterfall Model

continued

Followed systematic approach to development The model implies that once the product is finished, everything else is maintenance. Assumes patience from customer Surprises at the end are very expensive Some teams sit ideal for other teams to finish
Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.
Software & Software Engineering

SWE311_Ch03 (071)

Slide 13

The Incremental Model

increment # n
Co m m u n i c a t i o n Pla nning M ode ling analy s is des ign

Co n s t ru c t i o n c ode t es t De p l o y m e n t d e l i v e ry fe e dba c k

increment # 2
Co m m u n i c a t i o n Pla nning M ode ling analy s is des ign

deliv ery of n t h increment

Co n s t ru c t i o n c ode t es t De p l o y m e n t d e l i v e ry fe e dba c k

increment # 1
Co m m u n i c a t i o n Pla nning M ode ling analy s is des ign Co n s t ru c t i o n c ode t es t De p l o y m e n t d e l i v e ry fe e dba c k

deliv ery of 2nd increment

deliv ery of 1st increment

project calendar t ime

Delivers software in small but usable pieces, each piece builds on pieces already delivered
SWE311_Ch03 (071) Software & Software Engineering
Slide 14

The Incremental Model

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. First Increment is often core product

Includes basic requirement Many supplementary features (known & unknown) remain undelivered

First Increment is used or evaluated A plan of next increment is prepared

Modifications of the first increment Additional features of the first increment

It is particularly useful when enough staffing is not available for the whole project Increment can be planned to manage technical risks

SWE311_Ch03 (071)

Software & Software Engineering

Slide 15

The Incremental Model

User requirements are prioritised and the highest priority requirements are included in early increments.

Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve. Customer value can be delivered with each increment so system functionality is available earlier.
Early increments act as a prototype to help elicit requirements for later increments.

Lower risk of overall project failure.

The highest priority system services tend to receive the most testing.

SWE311_Ch03 (071)

Software & Software Engineering

Slide 16

The RAD Model

Team # n
M o d e lin g
business m odeling dat a m odeling process m odeling

C o n s t r u c t io n

Com m unicat ion

Team # 2
Mo d eling
b u si n e ss m o d e l i n g dat a m odeling p ro ce ss m o d e l i n g

com ponent reuse aut om at ic code generat ion t est ing

Planning
Co nst r uct io n

De ploym e nt
int egrat ion deliv ery feedback

Team # 1 Mode ling

business modeling dat a modeling process modeling

co m p o n e n t re u se a u t o m a t i c co d e g e n e ra t i o n t e st i n g

Const r uct ion

component reuse aut omat ic code generat ion t est ing

6 0 - 9 0 days

Makes heavy use of reusable software components with an extremely short development cycle
SWE311_Ch03 (071) Software & Software Engineering
Slide 17

Critique of RAD

If requirements are well understood and project scope is constrained

Very short development time

Construction emphasizes the reuse and the automatic code generation For large but scalable projects

RAD requires sufficient human resources

Projects fail if developers and customers are not committed in a much abbreviated time-frame Problematic if system can not be modularized Not appropriate when technical risks are high
Software & Software Engineering
Slide 18

SWE311_Ch03 (071)

Evolutionary Models: Prototyping

Good first step when customer has a legitimate need, but is clueless about the details, developer needs to resist pressure to extend a rough prototype into a production product
Quick plan ion Com m unicat
Qu ick p lan

Modeling Quick design

Mo d e lin g Qu ick d e sig n

Deployment De live r y & Fe e dback Construction

of prototype

Const r uct ion of pr ot ot ype

SWE311_Ch03 (071)

Software & Software Engineering

Slide 19

Evolutionary Models: The Spiral

planning
estimation sch eduling risk analysis

communication modeling
analysis design start

deployment
delivery feedback

construction
code test

Couples iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model
SWE311_Ch03 (071) Software & Software Engineering
Slide 20

SWE311_Ch03 (071)

Software & Software Engineering

Slide 21

Evolutionary Models: Concurrent

none Modeling act ivit y

Under

Similar to spiral model often used in development of client/server applications

development

represents the state of a software engineering activity or task

A wait ing changes

Under review Under revision Baselined

Done

SWE311_Ch03 (071)

Software & Software Engineering

Slide 22

Specialized Process Component based development spiral model variation in Models

which applications are built from prepackaged software components called classes Formal methodsemphasizes the mathematical specification of requirements. Rigorous mathematical notation used to specify, design, and verify computer-based systems Aspect-Oriented Software Development (AOSD)provides a process and methodological approach for defining, specifying, designing, and constructing aspects like user interfaces, security, and memory management that impact many parts of the system being developed
Software & Software Engineering

SWE311_Ch03 (071)

Slide 23

Unified Process

Use-case driven, architecture centric, iterative, and incremental software process closely aligned with the Unified Modeling Language (UML)
Attempts to draw on best features of traditional software process models and implements many features of agile software development Phases

Inception phase (customer communication and planning) Elaboration phase (communication and modeling) Construction phase Transition phase (customer delivery and feedback) Production phase (software monitoring and support)

SWE311_Ch03 (071)

Software & Software Engineering

Slide 24

The Unified Process (UP)

Elab o r at io n elaboration Incep t io n inception

inception

co nst r uct io n
Release
soft ware increment

t r ansit io n

p r o d uct io n

SWE311_Ch03 (071)

Software & Software Engineering

Slide 25

UP Phases
UP Phase s
Incept ion Elaborat ion Const ruct ion Transit ion Product ion

Wor kflows Requirements Analysis Design

Implementation Test Support Iterations #1 #2 #n-1 #n

SWE311_Ch03 (071)

Software & Software Engineering

Slide 26

UP Work Products
Incept ion phase
Vision document Init ial use-case model Init ial project glossary Init ial business case Init ial risk assessment . Project plan, phases and it erat ions. Business model, if necessary . One or more prot ot y pes
I nc e pt i o n

Elaborat ion phase

Use-case model Supplement ary requirement s including non-funct ional Analy sis model Soft ware archit ect ure Descript ion. Execut able archit ect ural prot ot y pe. Preliminary design model Rev ised risk list Project plan including it erat ion plan adapt ed workflows milest ones t echnical work product s Preliminary user manual

Const ruct ion phase

Design model Soft ware component s Int egrat ed soft ware increment Test plan and procedure Test cases Support document at ion user manuals inst allat ion manuals descript ion of current increment

Transit ion phase

Deliv ered soft ware increment Bet a t est report s General user feedback

SWE311_Ch03 (071)

Software & Software Engineering

Slide 27

Attributes for Comparing Process Models

Overall flow and level of interdependencies among tasks Degree to which work tasks are defined within each framework activity Degree to which work products are identified and required Manner in which quality assurance activities are applied

SWE311_Ch03 (071)

Software & Software Engineering

Slide 28

Attributes for Comparing Process Models (cont)

Manner in which project tracking and control activities are applied Overall degree of detail and rigor of process description Degree to which stakeholders are involved in the project Level of autonomy given to project team Degree to which team organization and roles are prescribed
Software & Software Engineering
Slide 29

SWE311_Ch03 (071)