SWE311_Ch03 (071) Software & Software Engineering Slide 1 Chapter 3 Prescriptive Process Models

SWE311_Ch03 (071) Software & Software Engineering Slide 1

Chapter 3Chapter 3Prescriptive Process ModelsPrescriptive Process Models


Overview 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.


Overview (cont)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.


ObjectivesObjectives

Introduce process models and the roles they play Introduce process models and the roles they play in a software engineering environmentin a software engineering environment

Give examples of some of the most common Give examples of some of the most common process modelsprocess models

Provide means of comparing process modelProvide means of comparing process model


Software ProcessSoftware Process

Aimed to control the activities of software Aimed to control the activities of software development and as such improve quality...development and as such improve quality...

A structured set of activities for A structured set of activities for Specifying, Specifying, Designing, Designing, Implementing and Implementing and Testing software systemsTesting software systems

A A software process modelsoftware process model is an abstract is an abstract representation of a processrepresentation of a process a description of a process from a particular perspectivea description of a process from a particular perspective


Software Process ModelsSoftware Process Models

Software process models are general approaches Software process models are general approaches for organizing a project into activities for organizing a project into activities Help the project manager and his team to decide:Help the project manager and his team to decide:

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

The models should be seen as The models should be seen as aids to thinkingaids to thinking, not rigid , not rigid prescriptions of the way to do thingsprescriptions of the way to do things

Each project ends up with its own unique plan becauseEach project ends up with its own unique plan because Projects differs in the nature of the project, people Projects differs in the nature of the project, people

doing the work, and the work environmentdoing the work, and the work environment


Prescriptive ModelsPrescriptive Models Prescriptive process models advocate an orderly approach to Prescriptive process models advocate an orderly approach to

software engineeringsoftware engineering Organize framework activities in a certain orderOrganize framework activities in a certain order

Originally proposed to bring order to the chaos of software development Originally proposed to bring order to the chaos of software development They brought order to software engineering work and provide reasonable They brought order to software engineering work and provide reasonable

guidance to software teamsguidance to software teams Adopt following activitiesAdopt following activities

CommunicationCommunication PlanningPlanning ModelingModeling ConstructionConstruction DeploymentDeployment

Differ inDiffer in Emphasis of these activitiesEmphasis of these activities Manners in which the framework is invoked and its relationship with Manners in which the framework is invoked and its relationship with

other activitiesother activities


Prescriptive ModelsPrescriptive Models

That leads to a few questions …That leads to a few questions … If prescriptive process models strive for If prescriptive process models strive for

structure and order, structure and order, are they inappropriate for a are they inappropriate for a software world that thrives on change?software world that thrives on change?

Yet, if we reject traditional process models (and Yet, if we reject traditional process models (and the order they imply) and replace them with the order they imply) and replace them with something less structured, something less structured, do we make it do we make it impossible to achieve coordination and impossible to achieve coordination and coherence in software work?coherence in software work?


Software Processes Software Processes Every software engineering organization needs to Every software engineering organization needs to

describe a set of framework activities for the describe a set of framework activities for the processes it adopts processes it adopts

Each framework activity needs to be populated Each framework activity needs to be populated with software engineering actions with software engineering actions

Each engineering action needs to be defined in Each engineering action needs to be defined in terms of a task set that defines the work and work terms of a task set that defines the work and work products needed to meet the development goals products needed to meet the development goals

The resulting process model should be adapted to The resulting process model should be adapted to accommodate the nature of the specific project, accommodate the nature of the specific project, people doing the work, and the work environment people doing the work, and the work environment


Software Processes (cont)Software Processes (cont) Regardless of the process model selected, software Regardless of the process model selected, software

engineers will chose a generic process framework engineers will chose a generic process framework that includes these activities: communication, that includes these activities: communication, planning, modeling, construction, and deployment planning, modeling, construction, and deployment

Each process model will prescribe a set of process Each process model will prescribe a set of process elements (framework activities, software elements (framework activities, software engineering actions, tasks, work products, quality engineering actions, tasks, work products, quality assurance, and change control mechanisms) and a assurance, and change control mechanisms) and a workflow (the manner in which the process workflow (the manner in which the process elements are interrelated) elements are interrelated)

All software process models discussed in this All software process models discussed in this chapter can accommodate the generic framework chapter can accommodate the generic framework activities described previouslyactivities described previously


The Waterfall The Waterfall ModelModel

Communication Planning

ModelingConstruction

Deployment analysis design code

test

project initiation requirement gathering estimating

scheduling tracking

delivery support feedback

Old fashioned but reasonable approach when requirements are well understood


Limitations of the waterfall modelLimitations of the waterfall model The model implies that you should attempt to The model implies that you should attempt to

complete a given stage before moving on to the next complete a given stage before moving on to the next stagestage Does not account for the fact that requirements constantly Does not account for the fact that requirements constantly

change. change. It also means that customers can not use anything until the It also means that customers can not use anything until the

entire system is complete.entire system is complete. The model makes no allowances for prototyping.The model makes no allowances for prototyping. Assumes understanding of problem and full Assumes understanding of problem and full

requirements early onrequirements early on It implies that you can get the requirements right by It implies that you can get the requirements right by

simply writing them down and reviewing them.simply writing them down and reviewing them. Inflexible partitioning of the project into distinct stages Inflexible partitioning of the project into distinct stages

makes it difficult to respond to changing customer makes it difficult to respond to changing customer requirements.requirements.


Critique of Waterfall ModelCritique of Waterfall Model continuedcontinued

Followed systematic approach to Followed systematic approach to developmentdevelopment

The model implies that once the product is The model implies that once the product is finished, everything else is maintenance.finished, everything else is maintenance.

Assumes patience from customerAssumes patience from customer Surprises at the end are very expensiveSurprises at the end are very expensive Some teams sit ideal for other teams to finishSome teams sit ideal for other teams to finish Therefore, this model is only appropriate when the Therefore, this model is only appropriate when the

requirements are well-understood and changes will be requirements are well-understood and changes will be fairly limited during the design process.fairly limited during the design process.


The Incremental The Incremental ModelModel

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e ry f e e d b a c k

analys is

des ign code

t es t

increment # 1

increment # 2

delivery of 1st increment

delivery of 2nd increment

delivery of nth increment

increment # n

project calendar time

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g


De p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

des ign code

t es t

C o m m u n i c a t i o nP l a n n i n g

M o d e l i n g


D e p l o y m e n t

d e l i v e r y

f e e d b a c k

analys is

des igncode t es t

Delivers software in small but usable pieces, each piece builds on pieces already delivered


The Incremental ModelThe Incremental Model Rather than deliver the system as a single delivery, the Rather than deliver the system as a single delivery, the

development and delivery is broken down into increments development and delivery is broken down into increments with each increment delivering part of the required with each increment delivering part of the required functionality.functionality.

First Increment is often core productFirst Increment is often core product Includes basic requirementIncludes basic requirement Many supplementary features (known & unknown) remain Many supplementary features (known & unknown) remain

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

Modifications of the first incrementModifications of the first increment Additional features of the first incrementAdditional features of the first increment

It is particularly useful when enough staffing is not available It is particularly useful when enough staffing is not available for the whole projectfor the whole project

Increment can be planned to manage technical risksIncrement can be planned to manage technical risks


The Incremental ModelThe Incremental Model User requirements are prioritised and the highest User requirements are prioritised and the highest

priority requirements are included in early increments.priority requirements are included in early increments.

Once the development of an increment is started, the Once the development of an increment is started, the requirements are frozen though requirements for later requirements are frozen though requirements for later increments can continue to evolve.increments can continue to evolve.

Customer value can be delivered with each increment so Customer value can be delivered with each increment so system functionality is available earlier.system functionality is available earlier.

Early increments act as a prototype to help elicit Early increments act as a prototype to help elicit requirements for later increments.requirements for later increments.

Lower risk of overall project failure.Lower risk of overall project failure.

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


The RAD ModelThe RAD Model

Communication

Planning

Modelingbusiness modeling data modeling process modeling

Constructioncomponent reuse automatic code generation testing

Deployment

60 - 90 days

Team # 1

Modelingbusiness modeling

data modeling process modeling

Constructioncomponent reuse automatic code

generation test ing

Modelingbusiness modeling data modeling process modeling

Const ruct ioncomponent reuse automatic code generation testing

Team # 2

Team # n

integration delivery feedback

Makes heavy use of reusable software components with an extremely short development cycle


Critique of RADCritique of RAD If requirements are well understood and project If requirements are well understood and project

scope is constrainedscope is constrained Very short development timeVery short development time

Construction emphasizes the reuse and the Construction emphasizes the reuse and the automatic code generationautomatic code generation

For large but scalable projectsFor large but scalable projects RAD requires sufficient human resourcesRAD requires sufficient human resources

Projects fail if developers and customers are not Projects fail if developers and customers are not committed in a much abbreviated time-framecommitted in a much abbreviated time-frame

Problematic if system can not be modularizedProblematic if system can not be modularized Not appropriate when technical risks are highNot appropriate when technical risks are high


Evolutionary Models: Evolutionary Models: PrototypingPrototyping

Quickplan

ModelingQuick design

Constructionof prototype

Communication

Quick plan

Construction of prototype

Modeling Quick design

Delivery & Feedback

Deployment

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


Evolutionary Models: The Evolutionary Models: The SpiralSpiral

communication

planning

modeling

constructiondeployment delivery feedback

start

analysis design

code test

estimation scheduling risk analysis

Couples iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model



Evolutionary Models: ConcurrentEvolutionary Models: Concurrent

Under review

Baselined

Done

Under

revision

Awaiting

changes

Under

development

none

Modeling activity

represents the stateof a software engineeringactivity or task

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


Specialized Process Specialized Process Models Models Component based developmentComponent based development— spiral model — spiral model

variation in which applications are built from variation in which applications are built from prepackaged software components called classes prepackaged software components called classes

Formal methodsFormal methods—emphasizes the mathematical —emphasizes the mathematical specification of requirements. Rigorous mathematical specification of requirements. Rigorous mathematical notation used to specify, design, and verify computer-notation used to specify, design, and verify computer-based systemsbased systems

Aspect-Oriented Software Development (AOSD))——provides a process provides a process and methodological approach for defining, specifying, and methodological approach for defining, specifying, designing, and constructing designing, and constructing aspects aspects like user like user interfaces, security, and memory management that interfaces, security, and memory management that impact many parts of the system being developed impact many parts of the system being developed


Unified Process Unified Process Use-case driven, architecture centric, iterative, and incremental software Use-case driven, architecture centric, iterative, and incremental software

process closely aligned with the Unified Modeling Language (UML)process closely aligned with the Unified Modeling Language (UML)

Attempts to draw on best features of traditional software process models Attempts to draw on best features of traditional software process models and implements many features of agile software development and implements many features of agile software development

PhasesPhases Inception phase (customer communication and Inception phase (customer communication and

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


inceptioninception

The Unified Process (UP)The Unified Process (UP)

software increment

Release

Inception

Elaboration

construction

transition

production

inception

elaboration


UP PhasesUP Phases

Inception Elaboration Construction Transition Production

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support


UP Work ProductsUP Work ProductsInception phase

Elaboration phase

Construction phase

Transition phase

Vision document Init ial use-case model Init ial project glossaryInit ial business case Init ial risk assessment. Project plan, phases and iterations. Business model, if necessary. One or more prototypes Incept io n

Use-case modelSupplementary requirements including non-functional Analysis model Software architecture Descript ion. Executable architectural prototype. Preliminary design model Revised risk listProject plan including iteration plan adapted workflows milestones technical work products Preliminary user manual

Design modelSoftware components Integrated software increment Test plan and procedure Test cases Support documentation user manuals installat ion manuals descript ion of current increment

Delivered software increment Beta test reports General user feedback


Attributes for Comparing Process Attributes for Comparing Process ModelsModels

Overall flow and level of interdependencies Overall flow and level of interdependencies among tasks among tasks

Degree to which work tasks are defined Degree to which work tasks are defined within each framework activity within each framework activity

Degree to which work products are identified Degree to which work products are identified and required and required

Manner in which quality assurance activities Manner in which quality assurance activities are applied are applied


Attributes for Comparing Process Attributes for Comparing Process Models (cont)Models (cont)

Manner in which project tracking and control Manner in which project tracking and control activities are applied activities are applied

Overall degree of detail and rigor of process Overall degree of detail and rigor of process description description

Degree to which stakeholders are involved in Degree to which stakeholders are involved in the project the project

Level of autonomy given to project team Level of autonomy given to project team Degree to which team organization and roles Degree to which team organization and roles

are prescribedare prescribed

Documents

SWE311_Ch03 (071) Software & Software Engineering Slide 1 Chapter 3 Prescriptive Process Models