What are your burning software development issues?

[email protected]

Copyright © James W. Grenning All Rights Reserved

Embedded Systems Conference Boston October 2008 -- ESC 206

Agile Embedded Software Developmenta Renaissance

Embedded Systems Conference

Boston October 2008 -- ESC 206

James W. Grenning

Renaissance Software Consulting Company

www.RenaissanceSoftware.net

1

[email protected]



What are your burning software development issues?

2

[email protected]



Software Development is Easy!

• Just like this Black Diamond

3

[email protected]



We never have any problems like

• Late Delivery

• Poor Quality

• Burnout

• Missed Customer Expectations

4

Software Development is Easy!

[email protected]



Like this Cliff!

5

[email protected]



We Make Our Problems

Vague Requirements

MissedCustomer

ExpectationsLate Project

Unrealistic Plan

Unplanned Activities

Unpredictable Activities

Poor Quality6

[email protected]



Positive Feedback Unstable System

Unrealistic Plan

Late ProjectMissed

Customer Expectations

Schedule Pressure

Long Hours

Bugs Poor Quality

Misunderstood Requirements

Vague Requirements

Unplanned Activities

Unpredictable Activities 7

[email protected]



Can Projects be Managed Better?

Figure out everything, then

do what you figured

From Winston Royce’s original paper on Waterfall

8

[email protected]



Waterfall -- The Experience

Requirements

Code

Design

Test

Time

NovemberSeptemberJulyMayMarch

Test and Fix

Test and FixTest and Fix

Test and Fix


Test and Fix

Test and Fix

Test and Fix


Test and Fix

Test and Fix

Test and Fix


Test and Fix

9

Test

[email protected]



Figure it All Out, Then Do It

10

[email protected]



11

[email protected]



Why Consider Agile?

• Manage with data

• Improve Predictability

• Improve Quality

• Improve Productivity

12

[email protected]



VelocityCompleted work per Iteration

13

0

5

10

15

20

25

30

35

40

45

50

1 2 3 4 5 6 7 8

[email protected]



Product Burn Down ChartWork to be Completed

14

0

75

150

225

300

1 2 3 4 5 6 7 8 9 10

[email protected]



Change Becomes Visible

15

0

75

150

225

300

1 2 3 4 5 6 7 8 9 10

New features added and nothing

removed

[email protected]



But Change is Hard!

16

Pe

rfo

rma

nce

Time

1. Late Status Quo

2. Resistance

3. Chaos

4. Integration

5. New Status Quo

ForeignElement

Transforming Idea

[email protected]



Organizational Change

Virginia Satir Change Model 17

[email protected]



What is Agile?

18

[email protected]



What is Agile?

• Agile software development is a conceptual framework for undertaking software engineering projects. -- wikipedia

• a.k.a. Extreme Programming, Scrum, Feature Driven Development, DSDM, Crystal Clear, Agile Unified Process

19

[email protected]



www.agilemanifesto.org

20

[email protected]



Individuals and Interactions over Processes and Tools

21

[email protected]



Working Software over Comprehensive Documentation

• Each team has different needs

• Less formal documentation might work.

• Prefer executable Documentation

22

[email protected]



Customer Collaboration over Contract Negotiation

23

[email protected]



Responding to Change over following a plan

24

[email protected]



Agile Practices Support the Iterative Model

• Iterative and Incremental Development

• Concurrent Engineering

• Teamwork

• Continuous Planning/Tracking

• Fine-Grain Scope Control

• Evolutionary Design

• Automated and Continuous Testing

Feedback25

[email protected]



Iterative and Incremental Development

Projects end, products don’t (hopefully)

Requirements analysis is never done

Design is never done

26

[email protected]



Iterative and Incremental Development

Requirements

Design

Code

Test

27

Parallel instead of Serial

Working software delivered each iteration.

[email protected]



Track Projects Based on Functionality Built and Tested

Requirements

Design

Code

Test

28

Com

ple

te S

tori

es

Sprints or Iterations (2-4 weeks)

[email protected]



Teamwork

29

[email protected]



Teamwork

• Shared workspace (lab)

• Collaborative development

– Pair programming

• Accessible customer

– Usually an internal customer

• Shared code ownership

• Continuous Integration

30

[email protected]



Concurrent Engineering

31

[email protected]




RequirementsEngineering

SoftwareEngineering

HardwareEngineering

Sequential EngineeringRequirementsSoftware Hardware

32

[email protected]




Req. Detail & Tests

Req. Detail & Tests

Req. Detail & Tests

Req. Detail & Tests

RequirementsEngineering

Features 1st w/ Arch

Features 1stw/ Arch



SoftwareEngineering

Hw Design &Prototyping




HardwareEngineering

Vision, Goals, Priorities

Requirements List

Architectural Vision

Initial HW Architecture

33

[email protected]



Fine Grained Scope Control

34

[email protected]



Fine-Grain Scope Control

• Story

– Something the system must do

– Like a use case, part of a use case, or scenario

• Stories

– Provide value

– Demonstrate progress

– Reduce risk

– Can be estimate

– Can be tested

– Many fit into an iteration

35

[email protected]



Stories and Acceptance Tests

• Stories lack detail

• Details are provided in automated acceptance tests

• The test are like executable use cases

• Test either pass or fail

36

[email protected]



Getting Technical

37

[email protected]



Evolutionary Design

• All designs evolve

• Change is a fact of life

• Team works towards an Architectural Vision

• Details are worked out JIT in code

• Good designers needed hands-on

• Designs evolve using Refactoring techniques

• Bigger teams need more formality

38

[email protected]



Automated Testing

• Key to evolutionary design is keeping the cost of retest low

• 25% of defects are introduced while changing existing code

• Automated tests keep that cost low

• Test are run with every change

39

[email protected]



Where is the Time Going?

• 50% to Debug is commonly claimed

• 25% of all defects are introduced while changing and fixing code [R.B Grady, Software Process

Improvement]

• One messed up project…

– 5 months in requirements

– 3 months development

– 6 one month test and fix cycles

40

Add a Test

Add the Code

to Eliminate

the Link Error

Add the Code to

Eliminate the

Compilation error

Compilation error

Run All Test

Link Error

Compile and Link OK

Add Needed Code

New Test Fails

Refactor as

Needed

All Tests Pass

All Tests Pass, More to do

All Tests Pass

No More to do

[email protected]



TDD Unit Testing State Machine

41

Bug discoveryBug injection

Bug found Bug fixed

Td Tfind T fix

Time

[email protected]



The Physics of Debug Later Programming (DLP)

• As Td increases, Tfind increases dramatically

• Tfix is usually short, but can increase with Td

42

Bug discovery

Bug injection

Bug found

Bug fixed

T d Tfind T fix

Time

[email protected]



The Physics of Test Driven Development

• When Td is short Tfind is short

• It is so short that it is not even considered a bug

43

[email protected]



Example Automated Test - sprintf()

44

TEST(sprintf, formatString)

{

char buffer[20];

memset(buffer, 0xaa, sizeof(buffer));

LONGS_EQUAL(12, sprintf(buffer, "%s\n", "Hello World"));

STRCMP_EQUAL("Hello World\n", buffer);

BYTES_EQUAL(0xaa, buffer[13]);

}

TEST(sprintf, formatInt)

{

char buffer[20];

memset(buffer, 0xaa, sizeof(buffer));

LONGS_EQUAL(12, sprintf(buffer, "i=%i\n", 10));

STRCMP_EQUAL("i=10\n", buffer);

BYTES_EQUAL(0xaa, buffer[7]);

}

[email protected]



Program to Interfaces

45

<<interface>>

Time Service

+ getDay()

+ getTimeOfDay()

+ setPeriodicAlarm()

Admin

Console

Light

Scheduler

+addSchedule()

+removeSchedule()

+wakeUp()

<<interface>>

Light Controller

+ on(id)

+ off(id)

Hardware RTOS

<<anonymous callback>>

Light Controller Time Service

<<implements>> <<implements>>

• Separate interface

and

implementation

as separate

entities.

• This design has

good separation

of responsibilities

50

[email protected]



Automated Test Example -Scheduler

46

TEST(LightScheduler, ScheduleWeekdayItsSunday)

{

LightScheduler_ScheduleTurnOn(3, WEEKDAY, 1200);

FakeTimeService_SetDay(SUNDAY);

FakeTimeService_SetMinute(1200);

FakeTimeService_MinuteIsUp();

LONGS_EQUAL(-1, FakeLightController_getLastId());

LONGS_EQUAL(-1, FakeLightController_getLastState());

}

TEST(LightScheduler, ScheduleWeekdayItsMonday)

{

LightScheduler_ScheduleTurnOn(3, WEEKDAY, 1200);

FakeTimeService_SetDay(MONDAY);

FakeTimeService_SetMinute(1200);

FakeTimeService_MinuteIsUp();

LONGS_EQUAL(3, FakeLightController_getLastId());

LONGS_EQUAL(1, FakeLightController_getLastState());

}

Write a TestMake it Pass

Refactor

Stage 1

Compile for TargetProcessor

Stage 2

Run Tests in the Eval Hardware

Stage 3

Run Testsin Target Hardware

Stage 4

Run ManualTests in Target

Stage 5

More Frequent Less Frequent

[email protected]



TDD Adaptation for Embedded Development

47

[email protected]

Copyright © 2008 James W. Grenning All Rights Reserved

Specific Benefits for Embedded

• Reduce risk by verifying code independent of

hardware

• Reduce long compile/link/load cycles

• Reduce debugging on target

• Isolates and models HW/SW interactions

• Improves design by isolating hardware

dependencies

• Improves portability

• Develops a test safety net

48

[email protected]

Copyright © 2008 James W. Grenning All Rights Reserved

More Embedded TDD Resources

• TDD in C Exercise – Please send me an email.

• www.renaissancesoftware.net/blog

– TDD device driver example

– Others

• Previous ESC presentations on my website

• yahoogroups.com/AgileEmbedded

49

[email protected]



Continuous Testing

• Testing starts on day one

• Tests provide the specification of what is to be developed

• QA/System Test moves upstream.

HELP!

50

[email protected]



What’s Wrong With Waterfall?

51

[email protected]



Why Change? What's Wrong with Waterfall?

• Recommended Reading

– Iterative and Incremental Development: A Brief History [LARMAN]

52

[email protected]



Waterfall Projects Fail at a High Rate

46%Never used orproject failure

20%Extensive rework

34%Other (including

worked fine)

Jarzombek99 Study - Project Success/Failure

53

[email protected]



What Happens when theRequirements are Committed

Too Early?

Never used

Sometimes used

Always used

Rarely used

Often used

7%

13%

16%

19%

45%

54

[email protected]



Long Projects Fail

0

15

30

45

60

6 9 12 18 24 36

Project Success Rate

Su

ccess R

ate

Duration (Months)

55

[email protected]



What’s Right about Iterative?

56

[email protected]



Why Iterative?

• A system's users seldom know exactly what they what and cannot articulate all they know

• … There are many details we can only discover once we are well into implementation

• … as humans we can only master only so much complexity

• … external forces lead to changes in requirements…

[LARMEN]

57

[email protected]



Iterative is Not new

58

[email protected]



Iterative is Not New

59

[email protected]



Agile is the name of the Renaissance that software

development is experiencing.

60

[email protected]



Review Questions and Comments

• Agile Practices Support the Iterative Model – Iterative and Incremental Development

– Concurrent Engineering

– Teamwork

– Continuous Planning/Tracking

– Fine-Grain Scope Control

– Evolutionary Design

– Automated and Continuous Testing

Feedback61

What are your burning software development issues?

Documents

Transcript of What are your burning software development issues?