Heavy vs Light Methodologies: Bulimic or Anorexic?...Rational Unified Process (RUP) Some history …...

1

Heavy vs Light

Methodologies:

Bulimic or Anorexic?

Fernando Brito e Abreu ([email protected])

Universidade Nova de Lisboa (http://www.unl.pt)

QUASAR Research Group (http://ctp.di.fct.unl.pt/QUASAR)

© Fernando Brito e Abreu 202-12-2008

Abstract Anorexia versus Bulimia

Overview of heavy-weight methodologies

Origins of light-weight methodologies

The “Agile Manifesto”

Agility example: XP

The dark side of the light

Planned (RUP) vs Agile (XP)

When to be agile?

2


Anorexia versus Bulimia

Anorexic (thin) project / Light-weight / Agile Project run unconstrained

Total freedom for artists

Unpredictable deliverables

Bulimic (fat) project / Heavy-weight / Planned Highly constrained project

e.g. following DoD Mil. Std 2167A

High organizing overheads

Very well defined deliverables


Examples …

Plan-driven

methodologies

Agile software development

Heavy-weight

methodologies

Light-weight methodologies

CMM, ISO9000-3,

ISO12207, PSP, TSP,

ISO15504 (SPICE),

RUP, CMMi, …

Extreme Programming (XP),

Scrum, Feature-Driven

Development (FDD), Adaptive

Software Process, Crystal Light

Methodologies, Dynamic Systems

Development Method (DSDM),

Lean Development

Fat? Bulimic? Thin? Anorexic?

3


Overview of heavy-weight

methodologies

Processes and tools

Comprehensive

documentation

Contract negotiation

Following a plan

“On projects with more than 250

people, methodology will have

almost no impact on success or

failure – politics will dominate.”

Jim Highsmith


CMM - Capability Maturity Model

Quality management Process measurement and analysis

Initial (1)

Repeatable (2)Software configuration management

Software quality assurance Software subcontract management

Software project tracking and oversight Software project planning

Requirements management

Defined (3) Peer reviews

Intergroup coordination Software product engineering

Integrated software management Training program

Organization process definition Organization process focus

Managed (4)

Process change management Technology change management

Defect prevention

Optimizing (5)

Software quality management Quantitative process management

See details on this

slides collection!

See details on this

model on another

slides collection!

4


CMMI - CMM Integrated

to Perform

Maturity Levels

Generic Practices

Generic Goals

Process Area 2

Common Features

Process Area 1 Process Area n

Ability

Implementation

Verifying

to Perform

Commitment Directing

Implementation

Specific Goals

Implementation

Specific Practices

to Perform

Maturity Levels

Generic Practices

Generic Goals

Process Area 2

Common Features

Process Area 1 Process Area n

Ability

Implementation

Verifying

to Perform

Commitment Directing

Implementation

Specific Goals

Implementation

Specific Practices

See details on this model on See details on this model on

another slides collection!


ISO/IEC 15504

Measurement

Framework•Capability Levels

•Process Attributes

•Rating Scale

Process Entities (process areas) +

Indicators per Process Entity

ISO15504-5

Process

Assessment

Model

ENG.1 CUS.2 ORG.3 .. n

Capability

Dimension

Process Dimension

Capability

Scale

5

4

3

2

1

0

See details on this

slides collection!

See details on this

model on another

slides collection!

http://images.google.com.br/imgres?imgurl=http://www.totalbanco.com.br/imagens/cmmi.png&imgrefurl=http://www.totalbanco.com.br/framework.shtml&h=317&w=500&sz=28&hl=pt-BR&start=6&um=1&tbnid=KJEY9sEg2XErNM:&tbnh=82&tbnw=130&prev=/images%3Fq%3DCMMI%26svnum%3D10%26um%3D1%26hl%3Dpt-BR%26sa%3DN

5


Rational Unified Process (RUP)Some history …

Rational Approach Objectory Process 3.81995

IBM - Rational Unified

Process v20032003

Rational Objectory

Process 4.01996 OMT approach

UML 0.5

OOSE

Rational Unified

Process 5.01998

Performance Testing

Business Engineering

Data Engineering

Objectory UI Design

Change & Configuration

Management

UML 1.2

Rational Objectory

Process 4.11997 Requirements

College

SQA Process

UML 1.0


Analysis Model

Specified by

Deployment Model

Distributed by

Design Model

Realized by

Implementation Model

Implemented by

X

OKX

OK

X

OK

Test Model

Verified by

Use-Case Model

Rational Unified Process (RUP)Model-based development

6


(What)

(Who) (How)

Rational Unified Process (RUP)Who, What, How, When

(When)

Workflow



Project Start

Final Result

Planned Result

7



Agility The ability to both create and respond to change in

order to profit in a turbulent business environment Companies need to determine the amount of agility they need

to be competitive

Chaordic (ex: agile view) Exhibiting properties of both chaos and order

The blend of chaos and order inherent in the external environment and in people themselves, argues against the prevailing wisdom about predictability and planning

Things get done because people adapt, not because they slavishly follow processes

An agile view is a chaordic view


The Agile Manifesto subscribersAlistair CockburnAndrew HuntArie van BennekumBrian MarickDave Thomas James GrenningJeff SutherlandJim Highsmith

Jon Kern Ken SchwaberKent Beck Martin FowlerMike Beedle Robert C. Martin Ron JeffriesSteve MellorWard Cunningham

8


The Agile Manifesto

“We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is, while there is value on the items on the right,we value the items on the left more.”

[Feb 2001]


Individuals and interactionsover processes and tools

Promote teambuilding and mutual trust

Build projects around motivated individuals

Give team members the environment and support they need, and trust them to get the job done

Adopt a barely sufficient methodology “the conventions we agree to”

Processes are described in manuals; practices are what happen in reality

9


Working softwareover comprehensive documentation

Our highest priority is to satisfy the customer through early and frequent delivery of valuable software

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter time scale

Working software/product is the primary measure of progress


Customer collaborationover contract negotiation

Set an open tone with the customer(s)

organization(s)

Adopt collaborative values and principles

Business people and developers work together daily throughout the project

10


Responding to changeover following a plan

Being agile means accepting that outcomes are not predictable and that processes are not repeatable

Welcome changing requirements, even late in development

Agile processes harness change for the customer’s competitive advantage

Agility is about adaptability rather than predictability

Case Study:

Extreme Programming (XP)

11


XP principles and planning

Basic principles

Very short cycles

Intense feedback

Networked

communication

Planning practices

User stories

Release planning

Iteration planning

On site customer


XP – Schedule …

12


XP product build philosophy

Principles Build the complete product, all the time

One button builds everything, including Product executables

Installation materials

Test harness and test components

Generated documentation

Benefits Easy to manage

Easy to add new team members

Integrates well with testing environment


Agility example: XP

13


XP programming practices

Pair programming

Test-first design

Refactoring

Continuous integration

Collective ownership

Coding standard

40 hour week


Pair programming

Method:Two programmers sit at one workstation

Each programmer take turns “driving”

Short lived pairs to avoid “vices”

Benefits:Avoids loosing focus and drifting away

Transmits knowledge to the team

Trains newbies

14


Pair programming research findings

Pairs use no more man-hours than singles

Pairs create fewer defects

Pairs create fewer lines of code

Pairs enjoy their work more

Source: Laurie Williams

http://collaboration.csc.ncsu.edu/laurie/



Pair programming

Test-first design

Refactoring



Coding standard

40 hour week

http://www.objectmentor.com/whatwedo/training.html

15


Test-first designaka Test-Driven Development (TDD)

Principles

All code must have tests, with the test created first

Unit tests are executed during the automated build

When a bug is found, new tests are created

All unit tests must pass before code can be released

Benefits

Provides constant visibility into areas of the system at risk

The result is rapid progress and a system that always

works better than it did the previous version

We end up with a rich suite of regression tests!


Test first design

Progress in tiny (5 min) cycles

Write a test case

Write the code that passes it

Repeat until program does what you want

Use a unit testing framework

e.g. Junit (www.junit.org) uses a green bar sign

to mean that the code has passed all tests

http://www.junit.org/

16


Example1st step: Write the tests

public void testCreateFuelingStationVisit() {Date date = new Date();double fuel = 2.0; // 2 gallons.double cost = 1.87*2; // Price = $1.87 per gallonint mileage = 1000; // odometer reading.double delta = 0.0001; //fp tolerance

FuelingStationVisit v = new FuelingStationVisit(date, fuel, cost, mileage);

assertEquals(date, v.getDate());assertEquals(1.87*2, v.getCost(), delta);assertEquals(2, v.getFuel(), delta);assertEquals(1000, v.getMileage());assertEquals(1.87, v.getPrice(), delta);

}


public class FuelingStationVisit { public FuelingStationVisit(Date date, double fuel,

double cost, int mileage){itsDate = date;itsFuel = fuel;itsCost = cost;itsMileage = mileage;

}

public Date getDate() {return itsDate;}public double getFuel() {return itsFuel;}public double getCost() {return itsCost;}public double getPrice() {return itsCost/itsFuel;}public int getMileage() {return itsMileage;}

}

3rd step: Run the tests!

Example2nd step: Write the code

17



Pair programming

Test-first design

Refactoring



Coding standard

40 hour week


Refactoring

After getting something to work we refactor

Refactoring mustprogress incrementally in tiny steps

improve internal code structure, namely by reducing its complexity

not alter the external behavior of the software components (this is guaranteed by running all the tests

18


Refactoring techniques Generalize where possible

Redistribute classes, variables and methods in order to facilitate future adaptations and extensions

Remove all duplications

Make the code as expressive as possible (e.g. forcing naming conventions)

Make the code as simple as possible (complexity metrics can be used to detect “bad smells”)



Pair programming

Test-first design

Refactoring



Coding standard

40 hour week

19



Daily builds are for wimps

Build, end to end, at every check in

Check in frequently

Build and test time must be very fast

Put resources on speeding build time

Put resources on speeding test time

Wimp: A person who

lacks confidence, is

irresolute



Pair programming

Test-first design

Refactoring



Coding standard

40 hour week

20



Anyone can improve any part of the code at

any time

No one acts as the gatekeeper for any part of the

code

This includes schemas …

and libraries …

and everything else that’s different

What about models? And requirements specs?



Pair programming

Test-first design

Refactoring



Coding standard

40 hour week

21


Coding standard

Group of conventions that everyone agrees to

Emerges over time

Continuously evolves

The team rules



Pair programming

Test-first design

Refactoring



Coding standard

40 hour week

22


40 hour week

You can’t do your best when you are tired

When you don’t do your best, you make

messes

Messes slow everyone down

So you must be rested

Occasionally, you may work one week of

moderate overtime


23


The dark side of the light ...

“XP Considered Harmful ... for Reliable SW

Development”

[Gerold Keefer, 2002]

The embrace change value ...

The practice of refactoring ...

The simplicity value ...

The practice of pair programming ......



Business Modeling

Req. Management

Analysis & Design

Implementation

Test

Deployment

CCM

Project Management

Environment

Coding

Testing

Listening

Designing

RUPRUP XP

24


Configuration Mgmt

Management

Environment

Business Modeling

Requirements

Analysis and Design

Implementation

Test

Deployment

Preliminary Iteration(s)

Iter.#1

PhasesProcess Disciplines

Iterations

Supporting Disciplines

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Elaboration TransitionInception Construction

XP-Window



When to be agile?

Problems characterized by change, speed, and

turbulence are best solved by agility.

Accelerated time schedule combined with significant risk

and uncertainty that generate constant change during the

project

Is your project more like drilling for oil or like

managing a production line?

Oil exploration projects need agile processes

Production-line projects are often well-served by rigorous

methodologies

25


When to be agile?Important questions

How close are the views and values expressed in

the Agile Manifesto to:

your customer’s views and values?

your project’s views and values?

your organization’s views and values?

your personal views and values?

If the answer if not positive for all of this questions,

then there is a high failure probability for agility


References[Acton2002] Agile Software Development, Dottie Acton, Lockheed Martin Mission Systems

[Ambler????] Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, Scott Ambler

[Beck2000] Extreme Programming Explained: Embrace Change, Kent Beck, Addison Wesley

[Charette????] Foundations of Lean Development: The Lean Development Manager’s Guide, Vol 2, Robert Charette

[Cockburn2002]Agile Software Development, Alistair Cockburn, Pearson Education, Inc, Boston, MA

[Fowler2000] Refactoring: Improving the Design of Existing Code, Martin Fowler et al., Addison-Wesley

[Highsmith2000] Adaptive Software Development: a Collaborative Approach to Managing Complex Systems, Jim Highsmith, Dorset House Publishing, New York

[Highsmith2002] Agile Software Development Ecosystems, Jim Highsmith

[Jeffries????] Extreme Programming Installed, Ron Jeffries & Ann Anderson, Addison-Wesley

[Kruchten2000] The Rational Unified Process: an Introduction, 2nd Edition, Philippe Kruchten, Addison-Wesley

[McCabe2003] Agile Development, Rich McCabe

[Palmer????] A Practical Guide to Feature-Driven Development, Stephen Palmer & John Felsing

[Rising2000] The Scrum Software Development Process for Small Teams, Rising, L. & N. S. Janoff, IEEE Software

[Schwaber2002] Agile Software Development with Scrum, Ken Schwaber & Mike Beedle, Prentice-Hall

Heavy vs Light Methodologies: Bulimic or Anorexic?...Rational Unified Process (RUP) Some history …...

Documents

Transcript of Heavy vs Light Methodologies: Bulimic or Anorexic?...Rational Unified Process (RUP) Some history …...