SOFTWARE DEVELOPMENT

LIFE CYCLE (SDLC)

M. Weintraub

& F.Tip

Thanks go to Andreas Zeller for allowing incorporation of his

materials

2

• noun pro·cess

a series of actions that produce

something or that lead to a particular result

http://www.merriam-webster.com/dictionary/process

PROCESS

3

Typical “Good” Qualities

Effective Actually Used

Efficient Reusable

Relevant Managed

Valid Measurable

Usable

WHAT EACH PARTY CONTROLS

Client Side Tech Side

4

Every software project has three client controls

The tech team has three controls

Cost

Functionality

Time

Process

People Technology

Software Engineering is about managing the client side and defining the tech side

while managing risk.

TEAMS

• Working with and within teams requires extra effort for

• Communication

• Documentation

• Tooling

• Hand-offs (process exchanges or role turn-over)

• Your process needs to be able to accommodate changes in team

composition

5

PROJECT INFLUENCES

• Scale

• Affects the ability to know “everything”

• Complexity becomes a critical factor, if it wasn’t already

• Legacy

• Rarely is everything from scratch

• Being able to extend others’ work is essential

6

1. Feasibility

2. Specification

3. Architecture and Design

4. Development

5. Validation

6. Evolution/Maintenance

Processes differ by the order and frequency of these elements

KEY ELEMENTS IN A PROCESS

7

PROCESS MODELS

Process Models

CODE AND FIX (1950- )

Build first version

Modify until

client is satisfied

Operate

Retirement

CODE AND FIX: ISSUES

1. No process steps – no

specs, docs, tests…

2. No separation of

concerns – no

teamwork

3. No way to deal with

complexity

10

Waterfall Model(1968)

Communicationproject initiation

requirements gathering

Planningestimatingscheduling

tracking

Modelinganalysisdesign

Constructioncodetest

Deploymentdeliverysupport

feedback

CommunicationCommunicationproject initiation

requirements gathering

Planning

Planningestimating

scheduling

tracking

Waterfall Model (1968)

Modelinganalysis

design

Waterfall Model

Constructioncode

test

Deployment

Deploymentdelivery

support

feedback

WATERFALL MODEL

1. Real projects rarely follow a sequential flow

2. Hard to state all requirements explicitly

3. No maintenance or evolution involved

4. Customer must have patience

5. Any blunder can be disastrous

18

Boehm’s First Law

19

Errors are most frequent

during requirements and design

activities and are the more expensive

the later they are removed.

WHAT THIS MEANS IN PRACTICE

20

0

75

150

225

300

Requirements Design Code Unit Test System Test Field

Co

st

Project Phase

Relative cost of an error depending on when it is discovered

NEXT IDEA:

SPLIT THE WATERFALL IN TO INCREMENTS

21

Features

Time

Increment #1

Increment #2

Increment #3

INCREMENTAL MODEL

▪ Each linear sequence produces a particular “increment” to

the software

▪ First increment typically core product; more features added

by later increments

▪ Allows flexible allocation of resources

22

EVOLUTIONARY MODELS: PROTOTYPING

23

Quick Plan

Quick Design

PrototypeConstruction

Deployment and Feedback

Communication

PROTOTYPES

A horizontal prototype tests a particular layer

(typically the GUI) of the system

A vertical prototype tests a particular functionality

across all layers

Resist pressure to turn a prototype into a final result!

24

PROTOTYPES

25

Bottom Layer

Top Layer (GUI)

Syste

m S

tack

HORIZONTAL PROTOTYPE

26

Bottom Layer

Top Layer (GUI)

PROTOTYPES

27

Bottom Layer

Top Layer (GUI)

VERTICAL PROTOTYPE

28

Bottom Layer

Top Layer (GUI)

SPIRAL MODEL (1988)

• System is developed in series of

evolutionary releases

• Milestones for each iteration of the

spiral

• Process does not end with delivery

• Reflects iterative nature of

development

29

PlanningModeling

TestDeployment + Feedback

Communication

Construction

FORMAL INTEGRATION OF ITERATIVE AND

INCREMENTAL: UNIFIED PROCESS (1999)

30

Planning

Modeling

Construction

Deployment

CommunicationSoftware

Increment

Inception

Elaboration

ConstructionTransition

Production

INCEPTION

31

PlanningCommunication

Inception

Planning

Modelling

Construction

Deployment

CommunicationSoftware

Increment

Inception

Elaboration

ConstructionTransition

Production

• Encompasses communication with user + planning

• Results in a set of use cases

• Architecture is just a tentative outline

ELABORATION

32

Planning

Modelling

Elaboration

Planning

Modelling

Construction

Deployment

CommunicationSoftware

Increment

Inception

Elaboration

ConstructionTransition

Production• Refines and expands preliminary use cases

• Provides architecture and initial design model

CONSTRUCTION

33

Modelling

Construction

Planning

Modelling

Construction

Deployment

CommunicationSoftware

Increment

Inception

Elaboration

ConstructionTransition

Production

• Builds (or acquires) software components according to

architecture

• Completes design model

• Includes implementation, unit tests, acceptance tests

TRANSITION

34

Construction

Deployment

Transition

Planning

Modelling

Construction

Deployment

CommunicationSoftware

Increment

Inception

Elaboration

ConstructionTransition

Production

• Software given to end users for beta testing

• Feedback reports defects and changes

• Support information written

PRODUCTION

35

Deployment

Software Increment

Planning

Modelling

Construction

Deployment

CommunicationSoftware

Increment

Inception

Elaboration

ConstructionTransition

Production

• Software is deployed

• Problems are monitored

RE-ITERATION

36

Deployment

Communication Planning

Modelling

Construction

Deployment

CommunicationSoftware

Increment

Inception

Elaboration

ConstructionTransition

Production

• Feedback results in new iteration for next release

UNIFIED PROCESS

37

Planning

Modelling

Construction

Deployment

CommunicationSoftware

Increment

Inception

Elaboration

ConstructionTransition

Production

• Draws on best features of conventional process models

• Emphasizes software architecture and design

• Integrates with UML modeling techniques (more on this later)

TRADITIONAL VS. AGILE PROCESSES

AGILE SOFTWARE DEVELOPMENT

• Individuals and activities over processes and tools.

• Working software over comprehensive documentation.

• Customer collaboration over contract negotiation.

• Responding to change over following a plan.

39

Manifesto for Agile Software Development (2001)

WHAT IS AGILE DEVELOPMENT?

• Fast development? Hacking? Prototyping?

Uncontrolled fun? Programmer heaven?

• Agility = ability to react to changing situations quickly,

appropriately, and effectively.

1. Notice changes early

2. Initiate action promptly

3. Create a feasible and effective alternative plan quickly

4. Reorient work and resources quickly and effectively

40

AGILE?

41

Communicationproject initiation

requirements gathering

Planningestimatingscheduling

tracking

Modelinganalysisdesign

Constructioncodetest

Deploymentdeliverysupport

feedback

INCREMENTAL MODEL

42

Features

Time

Increment #1

Increment #2

Increment #3

AGILE PROCESSES

43

Time

Scope

Analyze

Design

Implement

Test

Waterfall Iterative Agile Processes

Credits: Prof. Bodik

AGILE VS. PLAN-DRIVEN

• Low criticality

• Senior developers

• Requirements change very

often

• Small number of

developers

• Culture that thrives on

chaos

44

• High criticality

• Junior developers

• Requirements don't

change too often

• Large number of

developers

• Culture that demands

order

Agile Plan-Driven

EXTREME PROGRAMMING (1999–)

45

Design

CodingTest

Planning

Software

Increment

Design

CodingTest

Planning

Software Increment

PLANNING

• In XP, planning takes place

by means of stories

• Each story captures

essential behavior

46

Planning

DesignDesign

CodingTest

Planning

Software Increment 47

EXTREME PROGRAMMING

• Design is made on the fly, using the KISS (keep it simple) principle

• Virtually no notation besides CRC cards (object sketches) and

spike solutions (prototypes)

Coding

Design

CodingTest

Planning

Software Increment

• Each story becomes a unit

test that serves as

specification

• The program is

continuously refactored to

have the design match the

stories

48

CODING

Coding

Design

CodingTest

Planning

Software Increment

CODING

To ensure continuous

review, XP mandates

pair programming

49

Test

Design

CodingTest

Planning

Software Increment

TESTING

Unit tests

• Detect errors

• Find missing

functionality

• Measure progress

50

Test

Planning

Software Increment

Design

CodingTest

Planning

Software Increment

EXTREME PROGRAMMING

The resulting

prototypes result in

new stories 51

Design

CodingTest

Planning

Software Increment

Design

CodingTest

Planning

Software Increment

EXTREME PROGRAMMING

52

SPOT THE DIFFERENCE

53

SCRUM

54

SCRUM

• An iterative and incremental agile software

development method for managing software

projects and product or application development.

• Small working teams to maximize communication,

minimize overhead and maximize knowledge

sharing.

• Adaptable to technical and business changes.

• Yields frequent software increments that can be

inspected.

55

SCRUM

• Development work and the people who perform it

are partitioned into clean, low coupling partitions.

• Constant testing and documentation is performed.

• Ability to declare project “done” whenever required.

56

SCRUM

Demos: Demonstrate software increment to the

customer for evaluation.

SCRUM

A prioritized list project requirements or

features that provide business value.Backlog:

Sprints: Consists of work units that are required to

achieve a defined backlog into a

predefined time-box (usually 14-28 days).

Scrums: Short (~15 mins.) daily meetings of the

scrum team. The Scrum master usually

leads the meeting.

• Puts test specification as the critical

design activity

• Understands that deployment comes

when the system passes testing

• Clearly defines what success means

• No more guesswork as to what

“complete” means

• The act of defining tests requires one

to understand how the solution works

TEST-FIRST DESIGN

59

Tests

Design

SpecificationDefines

(non)function

objectives

Defines

acceptance

objectives

System

under testDevelopment

Informs designs

Defines

system

Deployment

Verified

system

• What is the net tolerance for finding errors

in deployment?

• How fast is the market moving?

• Are the teams experienced with a

particular process?

• Is the contract fixed and firm?

• When do the clients expect to see

something?

KEY CONCERNS IN SELECTING A PROCESS

60

Adapted from

http://www.agilemodeling.com/essays/costOfChange.htm

Copyright © 2003 Scott W. Ambler

Typical view of

waterfall

Typical view of

iterative

EVEN WITH ADVANCES IN PROCESS, PROJECT

SUCCESS REMAINS RISKY

Pessimist View Optimist View

61

0 23 45 68 90 113

All projects

Success Challenged Failed

0% 25% 50% 75% 100%

Lean

Iterative

Agile

Ad-Hoc

Traditional

Successful Challenged Failed

Dr. Dobb’s Journal 2013 IT Project Success Survey posted at

www.ambysoft.com/surveys/Standish Group (UK), Chaos Study, 1995

http://geekandpoke.typepad.com/geekandpoke/2012/05/development-cycle.html