2-processmodels new 6-2-12

8/13/2019 2-ProcessModels New 6-2-12

1/73

Sofware Process 1

Software Processes


2/73

Sofware Process 2

Software Process Process is distinct from product

products are outcomes of executing a

process on a project.

SW Engg. focuses on process.

Proper processes will help to achieve

project objectives of high Q Product.


3/73

Sofware Process 3

Software Process Process:A particular method, generally involving a

number of activities Software Process: A set of activities, along with

ordering constraints on execution, to producesoftware with desired result. Process that deals with the technical and

management issues of software development iscalled a software process.

Many types of activities performed by differentpeople in a software project Better to view software process as comprising of

many component processes. Component processes ????


4/73

Sofware Process 4

Component Software Processes Two major processes

Developmentfocuses on development andquality steps needed to engineer the software

Project managementfocuses on planning andcontrolling the development process

Development process is the heart of softwareprocess; other processes revolve around it

These are executed by different people developers execute engg. process

project manager executes the mgmt process


5/73

Sofware Process 5

Component Processes Other processes affect software development

activity.

Configuration management process:manages the evolution of artifacts

Change management process: how changesare incorporated

Process management process: management

of processes themselves Inspection process:How inspections are

conducted on artifacts


6/73

Sofware Process 6

Process Specification

Process is generally a set of phases(steps / activitities)

Each phase performs a well defined task and generallyproduces an output

Intermediate outputswork products(SRS,SDD,Code, Prototype..etc)

Having too many steps, results in too many workproducts or documents.Due to this,

At top level, a process typically consists of a few steps,each satisfying a clear objective and producing adocument which can be verified.

How to perform a particular phase /step is addressedby methodologiesfor that activity.


7/73

Sofware Process 7

ETVX Specification ETVX approach to specify a step

Entry criteria: what conditions must be

satisfied for initiating this phase Task: what is to be done in this phase

Verification: the checks done on theoutputs of this phase

eXit criteria: when can this phase beconsidered done successfully

A phase also produces info for mgmt


8/73


9/73

Sofware Process 9

Desired Characteristics of Software

process

Predictability

Support testability and Maintainability

Support change

Early defect removal

Process improvement and feedback


10/73

Sofware Process 10

Predictability

Process should repeat its performancewhen used on different projects

i.e. outcome of a project should bepredictable using a process

Without predictability, cannot estimate, or

say anything about quality or productivity With predictability, past performance can

be used to predict future performance


11/73

Sofware Process 11

Predictability Predictable process is said to be under

statistical control A process is under control if following the

same process produces similar results-resultswill have some variation, but the variation ismostly due to random causes and not due toprocess issues.

Repeatedly using the process produces similarresults To consistently develop sw with high Q&P, process

must be in control


12/73

Sofware Process 12

Example (estimating the cost of B

from the project A)

Cost of B is similar to Cost of A (done 2years back)

Implies that process used to implementB is same as A

That is, it assumes that process is

predictable.


13/73

Sofware Process 13

Support testability andmaintainability

Goal of the process should not be to reduce theeffort of design and coding,but to reduce thecost of testing and maintenance.

Both testing and maintenance depend heavily onquality of design and code.

Hence , during the early phases of developmentprocess the prime issues should be

Can it be easily tested ? Can it be easily modified?


14/73

Sofware Process 14

Contd.. Support testability as testing is the most

expensive task; testing can consume 30 to

50% of total development effort Support maintainability as maintenance

can be more expensive some times thandevelopment; over life up to 80% of total

cost


15/73

Sofware Process 15

example Requirement ----10%

Design -----------10%

Coding------------30%

Testing-----------50%

(depends on organization)


16/73

Sofware Process 16

Support Change

Software changes for various reasons

Requirements change is a key reason

Requirement changes cannot be wishedaway or treated as bad

They must be accommodated in theprocess for sw development


17/73

Sofware Process 17

Early Defect Removal

Remove defects early, as cost of removingdefects increases with latency

i.e. fixing a requirement defect in operationcan cost a 100 times the cost of fixing it inrequirements itself

Hence, for high Q&P, the process must

support early defect removal That is why there is a Verification in ETVX,

and quality control tasks in the sw process


18/73


19/73

Sofware Process 19

Process improvement and feedback

Process is not a static entity. To satisfy the objectives of quality improvement and

cost reduction, the software process must be

improved. Software process is considered as closed loop

process. That is, the process must be improved based on

previous experiences, and each project done using

the existing process must feed information back tofacilitate this improvement.


20/73

Sofware Process 20

Contd..

Process mgmt process involves inprocess improvement by :

- Taking feedback from other processesand improve it.

- Taking feedback from early parts of

projects and improve the rest of theproject.


21/73

Sofware Process 21

Summary

Processmethod for doing something

Process typically has stages, each stage

focusing on an identifiable task Stages have methodologies

Software process consists of methods

for developing software

Best to view it as comprising of multipleprocesses


22/73

Sofware Process 22

Summary

Goal is to produce software with highquality and productivity

Development process is central process Mgmt process is for controlling

development.

Other processes support development. Sw process should have high Q&P,

predictability, and support for change


23/73

Sofware Process 23

Development Process andProcess Models


24/73

Sofware Process 24

Process Models

A model provides generic structure ofthe process that can be followed by

some projects to achieve their goals


25/73

Sofware Process 25

Process model

If a project chooses a model, it will generallytailor it to suit the project

I.e. process is what is actually executed;process specification is plan about whatshould be executed; process model is ageneric process specification

Many models have been proposed for thedevelopment process


26/73

Sofware Process 26

Typical Student Process Model

Get problem stmtCodedo sometestingdeliver/demo

Why this process model cannot be usedfor commercial projects?

Produces student-software, which is not

what we are after Cannot ensure desired quality for

industrial-strength software


27/73

Sofware Process 27

Common Process Models

1. Waterfallthe oldest and widelyused

2. Prototyping

3. Iterativecurrently used widely

4. Timeboxing


28/73

Sofware Process 28

Waterfall Model

Phases are organized in Linearsequence of stages/phases

A phase starts only when the previoushas completed; no feedback

The phases partition the project, each

addressing a separate concern


29/73

Sofware Process 29


30/73

Sofware Process 30

Waterfall

Linear ordering implies each phase should havesome output

The output must be verified and validated Outputs of earlier phases: work products Planning usually overlaps with the requirements

analysis. It has to be prepared before the otherphase begins.

Common outputs of a waterfall: SRS, projectplan, design docs, test plan and reports, finalcode, software manuals


31/73


32/73

Sofware Process 32

Waterfall disadvantages

Assumes that requirements can be specified and frozen beforedesign begins

Follows thebig bang(one shot at end)approachall or

nothing delivery; too risky as the user doesnot know until the veryend what they are getting

Very document oriented, requiring docs at the end of each phase

May choose outdated hardware technology as requirements needto be freezed earlier

User feedback not allowed

Cycle time is too long


33/73

Sofware Process 33

Waterfall Usage

Has been used widely

Well suited for well understood

problems, short duration project,automation of existing manual systems


34/73

Sofware Process 34

Prototyping

Prototyping addresses the requirementspecification limitation of waterfall

Instead of freezing requirements only bydiscussions before design and coding phase,a prototype is built to understand therequirements

Helps alleviate(ease) the requirements risk


35/73

Sofware Process 35

Prototyping


36/73

Sofware Process 36

Prototyping

Development of prototype

Starts with initial known requirements

Only key features which need betterunderstanding are included in prototype

Feedback from users taken to improve the

understanding of the requirements


37/73

Sofware Process 37

Prototype

The phases like designing,coding & testing are notdone formally.

Using prototype, the client get an actual feel of the

system quick and dirty quality not important

Because the prototype is to be thrown away, onlyminimal documentation needs to be produced during

prototyping.For example, design documents, a test plan, and atest case specification are not needed during thedevelopment of the prototype


38/73

Sofware Process 38

Advantages

Helps in requirements elicitation(betterunderstanding).

Effective method of demonstrating the feasibility of a

certain approaches ( not clear, to meet certainconstraints and algorithms)

Reduces risk

Costs incurred due to later changes in the

requirements are substantially reduced due to laterchanges in the requirements are substantiallyreduced.

Leads to a better system


39/73

Sofware Process 39

Disadvantages

Possibly higher cost and schedule. socost can be kept low By building only

features needing clarification Disallows later changes


40/73

Sofware Process 40

Usage of prototype

Suitable for complicated and largesystems for which there is no manual

process or existing system to helpdetermine the requirements

Systems with novice users

When GUI is very important


41/73

Sofware Process 41

Iterative Development

Counters the all or nothing drawback of thewaterfall model (i.e the output/product isproduced only at the end is solved in this

model) Combines benefit of prototyping and waterfall Develop and deliver software in increments Each increment is complete in itself Can be viewed as a sequence of waterfalls Feedback from one iteration is used in the

future iterations


42/73

Sofware Process 42

Iterative development.

1. Iterative enhancement model

2. Spiral model


43/73

Sofware Process 43

Iterative Enhancement


44/73

Sofware Process 44

Iterative enhancement First simple initial implementation is done for a

subset of the overall problem

Each increment provide a feedback to the client thatis useful for determining the final requirements of the

system A project control list is prepared which contain the

tasks that must be performed to obtain the finalimplementation

Each iteration removes the next task from the listand implements the task which include design phase,implementation phase and analysis phase.


45/73

Sofware Process 45

Contd

Each iteration gives feedback to the nextiteration

Selection of tasks in this manner will minimize

the chances of error and reduce the redesignwork.

The process is iterated until the projectcontrol list is empty.

The design and implementation phases ofeach step can be performed in a top-downmanner or by using some other technique.


46/73

Sofware Process 46

Spiral development

Process is represented as a spiral rather than as a sequence ofactivities with backtracking.

Each loop in the spiral represents a phase in the process.

No fixed phases such as specification or design - loops in thespiral are chosen depending on what is required.

Risks are explicitly assessed and resolved throughout theprocess.

Inner most loop is concerned with the system feasibility, next

loop with the requirement specification, the next loop withsystem design & so on

Spiral model of the software


47/73

Sofware Process 47

Spiral model of the softwareprocess


48/73

Sofware Process 48

Spiral model sectors

Objective setting

Specific objectives for the phase are identified.

Risk assessment and reduction

Risks are assessed and activities put in place toreduce the key risks.

Development and validation

A development model for the system is chosen

which can be any of the generic models. Planning

The project is reviewed and the next phase ofthe spiral is planned.


49/73

Sofware Process 49

Advantages

Get-as-you-pay, customer need not wait untilentire system is implemented. Provide regular

/ quick deliveries.

feedback for improvement

Accommodates changes,

Reduces risks

Avoids requirements bloating(excess),Priorities requirements

Better product


50/73

Sofware Process 50

Disadvantages

Architecture/design may change due tofrequent changes. It may not be

optimal, rework may increase. total cost may be more as we need to

undo the things

Each iteration may have planningoverhead


51/73

Sofware Process 51

Usage

For business where time is of essence

Risks are more

Where requirements are not known andwill be known only with time


52/73

Sofware Process 52

Timeboxing

Iterative is linear sequence of iterations

Each iteration is a mini waterfall

decide the specs, then plan the iteration Time boxingfix an iteration duration,

then determine the specs

Divide iteration in a few equal stages Use pipelining concepts to execute

iterations in parallel


53/73

Sofware Process 53

Time Boxed Iterations

General iterative developmentfix thefunctionality for each iteration, then

plan and execute it In time boxed iterationsfix the

duration of iteration and adjust the

functionality to fit it Completion time is fixed, the

functionality to be delivered is flexible


54/73

Sofware Process 54

Time boxed Iteration

This itself very useful in many situations

Has predictable delivery times

Overall product release and marketingcan be better planned

Makes time a non-negotiable parameter

and helps focus attention on schedule

Prevents requirements bloating

Overall dev time is still unchanged


55/73

Sofware Process 55

TimeboxingTaking Time BoxedIterations Further

What if we have multiple iterationsexecuting in parallel

Can reduce the average completiontime by exploiting parallelism

For parallel execution, can borrow

pipelining concepts from hardware This leads to Timeboxing Process Model


56/73

Sofware Process 56

Timeboxing ModelBasics

Development is done iteratively in fixedduration time boxes

Each time box divided in fixed stages

Each stage performs a clearly defined taskthat can be done independently

Each stage approximately equal in duration

There is a dedicated team for each stage When one stage team finishes, it hands over

the project to the next team


57/73

Sofware Process 57

Timeboxing

With this type of time boxes, can usepipelining to reduce cycle time

Like hardware pipeliningview eachiteration as an instruction

As stages have dedicated teams,

simultaneous execution of differentiterations is possible


58/73

Sofware Process 58

Example

An iteration with three stagesAnalysis, Build, Deploy

These stages are appx equal in manysituations

Can adjust durations by determining theboundaries suitably

Can adjust duration by adjusting the teamsize for each stage

Have separate teams for A, B, and D


59/73

Sofware Process 59

Pipelined Execution

AT starts executing it-1

AT finishes, hands over it-1 to BT,

starts executing it-2AT finishes it-2, hands over to BT; BT

finishes it-1, hands over to DT; AT

starts it-3, BT starts it-2 (and DT, it-1)


60/73

Sofware Process 60

Timeboxing Execution

Software

Requirements Build DeployTB1

TB2Requirements Build Deploy

TB2




61/73

Sofware Process 61

Timeboxing execution

First iteration finishes at time T

Second finishes at T+T/3; third at

T+2 T/3, and so on In steady state, delivery every T/3 time

If T is 3 weeks, first delivery after 3

wks, 2ndafter 4 wks, 3rdafter 5 wks, In linear execution, delivery times will

be 3 wks, 6 wks, 9 wks,


62/73

Sofware Process 62

Timeboxing execution

Duration of each iteration still the same

Total work done in a time box is also

the same Productivity of a time box is same

Yet, average cycle time or delivery time

has reduced to a third


63/73

Sofware Process 63

Team Size

In linear execution of iterations, thesame team performs all stages

If each stage has a team of S, in linearexecution the team size is S

In pipelined execution, the team size isthree times (one for each stage)

I.e. the total team size in timeboxing islarger; and this reduces cycle time


64/73

Sofware Process 64

Team Size

Merely by increasing the team size wecannot reduce cycle time - Brooks law

Timeboxing allows structured way toadd manpower to reduce cycle time

Note that we cannot change the time of

an iterationBrooks law still holds Work allocation different to allow larger

team to function properly


65/73

Sofware Process 65

Work Allocation of Teams

Requirements

Team

Requirements

Analysis for TB1

Requirements

Analysis for TB3

Requirements

Analysis for TB2

Requirements

Analysis for TB4

Build Team

DeploymentTeam

Build for TB1 Build for TB2 Build for TB3

Deployment for TB1Deployment for TB2

Build for TB4

Deployment for TB3

Requirements

Team

Requirements

Analysis for TB1

Requirements

Analysis for TB3

Requirements

Analysis for TB2

Requirements

Analysis for TB4

Build Team

DeploymentTeam

Build for TB1 Build for TB2 Build for TB3

Deployment for TB1Deployment for TB2

Build for TB4

Deployment for TB3


66/73

Sofware Process 66

Advantages

Shortened delivery times

Planning and negotiations are easy


67/73

Sofware Process 67

Disadvantages

Larger teams,

project mgmt is harder,

high synchronization needed,

Possibly increased cost

Not suitable for projects where differentiterations require different stages ofdifferent time length.


68/73

Sofware Process 68

Usage

When short delivery times very imp.;

architecture is stable;

flexibility in feature grouping


69/73

Sofware Process 69

Summary

Process is a means to achieve projectobjectives of high QP

Process models define generic process,which can form basis of project process

Process typically has stages, each stage

focusing on an identifiable task Many models for development process

have been proposed


70/73

Sofware Process 70

Summarywaterfall

Strength Weakness Types of Projects

Simple

Easy to execute

Intuitive and logical

Easy contractually

All or nothingtoorisky

Req frozen earlyMay chose outdatedhardware/tech

Disallows changes

No feedback fromusers

Encourages reqbloating

Well understoodproblems, short

duration projects,automation ofexisting manualsystems


71/73

Sofware Process 71

SummaryPrototyping


Helps req elicitation

Reduces risk

Better and morestable final system

Front heavy

Possibly higher cost

and scheduleEncourages reqbloating

Disallows laterchange

Systems with noviceusers; or areas with

req uncertainity.Heavy reportingbased systems canbenefit from UI proto


72/73

Sofware Process 72

SummaryIterative


Regular deliveries,leading to biz benefit

Can accommodatechanges naturally

Allows user feedback

Avoids req bloating

Naturally prioritizesreq

Allows reasonableexit points

Reduces risks

Overhead ofplanning each

iterationTotal cost mayincrease

System arch anddesign may suffer

Rework may increase

For businesses wheretime is imp; risk of

long projects cannotbe taken; req notknown and evolvewith time


73/73

SummaryTimeboxing


All benefits ofiterative

Planning foriterations somewhateasier

Very short deliverytimes

PM becomes morecomplex

Team size is largerComplicatedlapsescan lead to losses

Where very shortdelivery times are

very importantWhere flexibility ingrouping features

Arch is stable

2-processmodels new 6-2-12

Documents