009

YEAR

20 7

32

Software Tools Software Development Processes

CO

MP

SC

I Software Development Processes

eala

nd Part II - Lecture 2

klan

d | N

ew Z

eve

rsity

of A

uck

The

Uni

v

1

Today’s Outline009

y

YEAR

20 7

32

• Introduction to Software Development ProcessesXt P i (XP)

CO

MP

SC

I • eXtreme Programming (XP)• Rational Unified Process (RUP)

eala

ndkl

and

| New

Ze

vers

ity o

f Auc

kTh

e U

niv

2

009

YEAR

20 7

32C

OM

PS

CI

Software Development P

eala

nd

Processes

klan

d | N

ew Z

e

He who fails to plan,

vers

ity o

f Auc

k pplans to fail(Proverb)

The

Uni

v

3

Software Development Pr c ss

009

ProcessGeneric plan for a software project

YEAR

20 7

32

p p j

1. What has to be done? (-> tasks/activities/steps)

CO

MP

SC

I 2. Why do a task? (-> outcomes, produced artifacts)3. When should it be done? (-> schedule)4 Wh d i ( l l ibili i )

eala

nd

4. Who does it? (-> people, roles, responsibilities)5. How should it be done? (-> methods, standards, tools)

klan

d | N

ew Z

e

• Many different processes exist• No single process suitable for every project

vers

ity o

f Auc

k • No single process suitable for every project (no “one size fits all”)

• Using a process can improve the quality of the product

The

Uni

v

4

s ng a proc ss can mpro th qua ty of th pro uct

Adaptive vs. Predictive Processes

009

Processes Adaptive Predictive

YEAR

20 7

32

• Lightweight, ‘agile’• Control by feedback

• Heavyweight, ‘traditional’ • Control by planning

Adaptive Predictive

CO

MP

SC

I Control by feedback• Many short iterations (weeks)• Small scale (<10 developers)• Face-to-face communication

Control by planning • Few long iterations (months)• Large scale (>30 developers)• Written documents

eala

nd

Face to face communication• Code- & people-centric• Egalitarian

Written documents• Rule-centric• Authoritarian

klan

d | N

ew Z

e

• Problems:– Long-term results hardly

predictableN d d j

• Problems:– Inflexible with changing

requirementsHi h i i d i

vers

ity o

f Auc

k – Needs good project foundation

– Cowboy-coding chaos

– High integration and testing effort

– ‘Control freak’ bureaucracy

The

Uni

v

5• E.g. XP • E.g. waterfall, RUP

Agile Software Development009

g p

• Evolved in mid 1990s as part of a reaction against YEAR

20 7

32

p gheavyweight methods

• Many short iterations (weeks), ‘prototyping’:

CO

MP

SC

I

Analysis Design Implementation Testing PrototypeIteration#1

eala

nd

Analysis Design Implementation Testing Prototype

Analysis Design Implementation Testing Prototype

#1

#2

klan

d | N

ew Z

e

Analysis Design Implementation Testing Prototype#3

vers

ity o

f Auc

k

• Control by feedback: reevaluation & revision of …

The

Uni

v

6

ontro y f ac r a uat on & r s on of project after each iteration

009

YEAR

20 7

32C

OM

PS

CI

eXtreme Programming (XP)

eala

nd

eXtreme Programming (XP)

klan

d | N

ew Z

eve

rsity

of A

uck

The

Uni

v

7

XP Overview009 „Instead of cowboy coders we have software

YEAR

20 7

32

ysheriffs; working together as a team, quick on the draw, armed with a few rules and practices that are li ht i d ff ti “

CO

MP

SC

I light, concise, and effective.“ (James D. Wells, extremeprogramming.org)

eala

nd • XP=eXtreme Programming:Nomen est omen a code centered approach

klan

d | N

ew Z

e Nomen est omen, a code-centered approach• XP culture: not just about getting work done• Set of day to day best practices for developers and

vers

ity o

f Auc

k • Set of day-to-day best practices for developers and managers that encourage and embody certain values

• 5 values 12 practices/rules

The

Uni

v

8

5 values, 12 practices/rules

The 5 XP Values009

1. Communication– Teamwork: consistent shared view of the system

O ffi i d l YEAR

20 7

32

– Open office environment: developers, managers, customers– Verbal, informal, face-to-face conversation

2. Feedback Cost of

CO

MP

SC

I – Find required changes ASAP to avoid cost– From the customer, through early

prototypes & communication

Cost ofchange

eala

nd

– Testing, code review, team estimates3. Simplicity

– Build the simplest thing that works for today

Point of timewithin project

klan

d | N

ew Z

e p g f y– No work that might become unnecessary tomorrow– Simple design easier to communicate

4 Courage

vers

ity o

f Auc

k 4. Courage– To change and to scrap, “embrace change”– Better change now (cheaper)

Never ever give up!

The

Uni

v

9

– Never ever give up!5. Respect your teammates and your work

The 12 XP Practices009 Fine scale feedback

YEAR

20 7

32

1. Pair ProgrammingProgramming in teams of two: driver and navigator

2 Planning Game: method for project planning with the customer

CO

MP

SC

I 2. Planning Game: method for project planning with the customer3. Test Driven Development

– First write test cases, then program codeF h d f i d

eala

nd

– For each defect, introduce new test case4. Whole Team: teamwork of customer, developer/manager

klan

d | N

ew Z

e

Shared understanding5. Use an agreed Coding Standard6 C ll ti C d O hi

vers

ity o

f Auc

k 6. Collective Code OwnershipEverybody is responsible for and can change all code

7. Simple Design

The

Uni

v

108. System Metaphor

Consistent, intuitive naming of program parts

The 12 XP Practices009 Continuous process

YEAR

20 7

32

p9. Continuous Integration

– Work with latest version

CO

MP

SC

I – Integrate local changes ASAP10. Refactoring

d i h ibl

eala

nd

– Improve design whenever possible– Remove clutter & unnecessary complexity

11 S ll R l s s

klan

d | N

ew Z

e 11. Small Releases

Programmer welfare

vers

ity o

f Auc

k Programmer welfare12. Sustainable Pace

No Overtime – change timing or scope instead

The

Uni

v

11

No O rt m chang t m ng or scop nst a

Some XP Terminology009

gy

• User storyYEAR

20 7

32

y– Things the system needs to do for the users– Written on a card in a few sentences

Should take 1 3 weeks to implement

CO

MP

SC

I – Should take 1-3 weeks to implement• Release: running system that implements important user stories• Spike

eala

nd

– Small proof-of-concept prototype– Explores the feasibility of an implementation approach

• Iteration

klan

d | N

ew Z

e Iteration– Phase of implementation, 1-3 weeks long– Consists of tasks, each of which is 1-3 days long

vers

ity o

f Auc

k

• Project velocity: used to estimate progress– Either #stories / time (time)– Or time / #stories (scope)

The

Uni

v

12

Or time / #stories (scope)

XP Workflow Overview009

UYEAR

20 7

32

UserStories

DefectsProject velocity

CO

MP

SC

I

ReleasePlanning TestsIteration

eala

nd

N tN

klan

d | N

ew Z

e

SmallRelease

NextIteration

NewUser Story

vers

ity o

f Auc

k

UncertainEstimates

ConfidentEstimates = is followed by

The

Uni

v

13Spike = result goes into

XP Criticism009 • Relies on on-site customer

YEAR

20 7

32

– Single point-of-failure (-> source of stress, lack of technical expertise)

– May not be representative for all users ( > user conflicts)

CO

MP

SC

I – May not be representative for all users (-> user conflicts)• Unstable Requirements because of informal change requests

instead of formal change management (-> rework, scope creep)

eala

nd

• Lack of documentation, e.g. tests instead of requirements documents

• Incremental design on the fly ( > more redesign effort)

klan

d | N

ew Z

e • Incremental design on-the-fly (-> more redesign effort)• Pair-programming required• Interdependency of practices requires drastic organizational

vers

ity o

f Auc

k p y p q gchanges

• Scalability? Distributed development?

The

Uni

v

14

009

YEAR

20 7

32C

OM

PS

CI

The Rational Unified

eala

nd

Process (RUP)

klan

d | N

ew Z

eve

rsity

of A

uck

The

Uni

v

15

RUP Overview009 • Extensible, customizable process framework

YEAR

20 7

32

, p• Created by the Rational Software Corporation in the

1980s and 1990s, which was sold to IBM in 2003

CO

MP

SC

I

• Now software process product of IBM• IBM sells RUP tools, e.g. Rational Method Composer

eala

nd

g pfor authoring, configuring and publishing processes

• Business-driven development

klan

d | N

ew Z

e

• Tied to UML• Heavyweight, i.e. of considerable size, but recent

vers

ity o

f Auc

k

changes influenced by lightweight, agile processes

The

Uni

v

16

6 RUP Best Practices:The RUP ABC

009

The RUP ABCAdapt the process

YEAR

20 7

32

p p– right-size the process to project needs– adapt process ceremony to lifecycle phase– continuously improve the process

CO

MP

SC

I – continuously improve the process– balance project plans and associated estimates with the

uncertainty of a project

B

eala

nd

Balance competing stakeholder priorities – understand and prioritize business and stakeholder needs

klan

d | N

ew Z

e – center development activities around stakeholder needs – balance asset reuse with stakeholder needs

C

vers

ity o

f Auc

k Collaborate across teams– motivate individuals on the team to perform at their best – encourage cross-functional collaboration

The

Uni

v

17

– encourage cross-functional collaboration – provide effective collaborative environments

The RUP ABC Cont’d009 Demonstrate value iteratively

YEAR

20 7

32

– incremental value to enable early and continuous feedback – adapt your plans– embrace and manage change

CO

MP

SC

I – embrace and manage change – drive out key risks early

El h l l f b i

eala

nd

Elevate the level of abstraction– reusing existing assets – leverage higher-level tools frameworks and languages

klan

d | N

ew Z

e leverage higher level tools, frameworks, and languages– focus on architecture

F s ti sl lit

vers

ity o

f Auc

k Focus continuously on quality– the entire team owns quality – test early and continuously

The

Uni

v

18

test early and continuously – incrementally build test automation

RUP Lifecycle009

y• 4 phases divided into a series of timeboxed iterations• Each iteration results in an increment (release)

YEAR

20 7

32

• Each iteration results in an increment (release)• Disciplines (like traditional phases) which happen with varying

emphasis in every phase

CO

MP

SC

I

1. Inception Phase– Justification or business case

eala

nd

– Project scope, use cases, key requirements– Candidate architectures

Risks preliminary project schedule cost estimate

klan

d | N

ew Z

e – Risks, preliminary project schedule, cost estimate 2. Elaboration Phase

– Requirements, risk factors

vers

ity o

f Auc

k q– System architecture (Executable Architecture Baseline)– Construction plan (including cost and schedule estimates)

3 Construction Phase: building the rest of the system (longest)

The

Uni

v

19

3. Construction Phase: building the rest of the system (longest)4. Transition Phase: deployment, feedback, user training

RUP Lifecycle009

y

YEAR

20 7

32C

OM

PS

CI

eala

ndkl

and

| New

Ze

vers

ity o

f Auc

kTh

e U

niv

202006 Giles Lewis

RUP Criticism009 • “High ceremony methodology”

Bur ucr tic: pr c ss f r v r thinYEAR

20 7

32

• Bureaucratic: process for everything• Slow: must follow process to comply• Excessive overhead:

CO

MP

SC

I • Excessive overhead:rationale, justification, documentation, reporting, meetings, permission

eala

nd

• Very customizable: can be everything and nothing

klan

d | N

ew Z

e

But:• RUP can be used in traditional waterfall style or in

agile manner

vers

ity o

f Auc

k agile manner• Example: dX process

– Fully compliant instance of RUP

The

Uni

v

21

Fully compliant instance of RUP– Identical to XP

009

YEAR

20 7

32C

OM

PS

CI

Summary

eala

nd

Summary

klan

d | N

ew Z

eve

rsity

of A

uck

The

Uni

v

22

Summary009

y

• Adaptive vs. predictive ProcessesYEAR

20 7

32

p p• eXtreme Programming (XP)

– Agile process focused on programming as a team

CO

MP

SC

I

g p f p g mm g m– Short iterations, as much feed back as possible– Best practices include collective code ownership,

eala

nd

Best practices include collective code ownership, refactoring, pair programming

• Rational Unified Process (RUP)

klan

d | N

ew Z

e ( )– Heavyweight process framework– Phases divided into iterations,

vers

ity o

f Auc

k ,several disciplines happening simultaneously

– Best practices include risk & change management,

The

Uni

v

23

p g guse of tools, models & components

Quiz009

Q

1. Describe three differences between adaptive and YEAR

20 7

32

ppredictive processes.

CO

MP

SC

I

2. Name five of the XP best practices.

eala

nd

3. What are the characteristics of the RUP lifecycle?

klan

d | N

ew Z

eve

rsity

of A

uck

The

Uni

v

24