csc444f'07lecture 31 csc444 software engineering software releases

CSC444F'07 Lecture 3 1

CSC444Software Engineering

Software Releases

Software Releases

• The software vendor lives and dies the endless dance of the “release cycle”


R1.0 R1.1 R1.2 R2.0

Continuous requirements gather

Initial release Follow-on releases

R1.0.1

R1.0.2

R1.0.3 R1.0.1a

point releases


A Release Lifecycle


A Simple Release Plan

Dates: Coding phase: Jul.1—Oct.1Beta availability: Nov.1General availability: Dec.1

Capacity: days availableFred 31 ecdLorna 33 ecd… …Bill 21 ecdtotal 317 ecd

Requirement: days requiredAR report 14 ecdDialog re-design 22 ecd… …Thread support 87 ecdtotal 317 ecd

Status: Capacity: 317 effective coder-daysRequirement: 317 effective coder-daysDelta: 0 effective coder days


Non-Coding Time and Resource• I explicitly plan coding only.

– Other• types of resources:

– Testers, documenters, managers

• phases:– Specification, testing

– these are sized relative to the coding phase and the coding resource

• Why?– Debugged code is the ultimate target

• Can’t be 90% done on that and still ship intended feature set

– How much time to devote to documentation?– How much time to devote to testing?– When is enough, enough?

• How?– Establish ratios– Measure what works for ratios for a given product– Adjust next time around– Converges rapidly– Initial guess is usually pretty good


Resource Ratios

1 CODERS

1:3 TESTERS

1:4 DOCS

• Typical ratios I have used• Adjust to taste• Assumes availability throughout the (overlapping)

release cycle.


Phase Length Ratios

• Typical ratios I have used

• Adjust to taste

specification & design

alpha test

code & unit test

beta test

3 2 2 1


Release Overlap

• Overlapping release cycles smoothes resource utilization


alpha test

code & unit test

beta test


code & unit test

R1.2

R1.3 requirements gather

maintenance


Shipping The Release

• After dcut, proactive management is gone.

• Can only watch defect arrivals and hope for the best.– If your ratios are off: forgetaboutit,

alpha test

beta test

GA release

first point release second

point release

third point release

defect arrival rate

shipping threshold


Release Concepts & Terminology

R3.2 (feature release)

R3.2.0 (initial release)

R3.2.1a (patch release)

R3.2.1

R3.2.2

R3.2.3

R3.2.4

R3.2.5

(point releases)

(beta release) R3.2B1


Cost of Feature Releases

• Considerable overhead associated with a feature release:– System testing– Marketing collateral– Launch events– Customer/partner briefings– New training courses and materials– New training internally– New CD’s to burn– ...

• Largest cost of them all– Increased maintenance burden from supporting an extra release in the field

• Reproduce bug in each codeline

• Decide what/when to fix

• Re-test

• Re-release

• Maintenance releases are much less costly– Regression tests will do it


Supporting Simultaneous Releases

• Generally must support at least 2 feature release maintenance streams.

• Usually must support 3.• MUST try to hold the line at 3.• Else all the maintenance will erode the company’s ability to respond

in a timely fashion to changing market conditions.

• Opportunity cost of developers– A trained developer is scarce resource

– New features or maintenance

– Opportunity cost of maintenance is the revenue the feature they might have coded could have brought in.


main

maintenanceR1

shippingR1.0

shippingR1.1

maintenanceR2

shippingR2.1

retired

maintenanceR3

shippingR3.0

shippingR1.1

shippingR2.2

activeongoing active

X

privatebig new feature

shippingR2.0

R2.2.a


Time Between Releases

• Feature releases are costly:– Therefore increase the time between feature releases.

• But, customers want more features– Therefore decrease the time between feature releases

• But, they also want stability in their own IT environment– Therefore increase the time between feature releases.– Sometimes customers get very sticky on old releases– Need to make the new release compelling to end-users

• What if one customer or prospect wants a new feature?– New feature release?– Probably not

• What if the market condition changes rapidly?– Cut short current release to rush it out?– Go back to last release, extend it, and put that out?– Costly: because of short release cycle will need to support >3 releases

in the field.


Pushing Back

• A successful development manager will need to distinguish between people asking for things that can be pushed off, and truly urgent things.– Everything is presented as the latter

• Track the request back to its source personally.– Will learn the true nature of thee request.

– Can deal with 80% of “urgent” requests in this manner


Features in Maintenance Releases

• Tried pushing back• Cannot justify a new feature release• Customer/prospect still wants/needs features earlier than the next

scheduled feature release• What now?

• Slip new features into a maintenance release.• In theory, maintenance releases should change no externally visible

program behavior (other than to correct it if faulty).• What the heck, do it anyways.• Does not have the cost of a new feature release.• Why not?


Costs of Features in Maintenance Releases

• BASIC RULE:– Cannot introduce new code without introducing new defects

• Two reasons for introducing new code:– Fix a defect

– Code a feature

• If only doing defect corrections:– Fix 2 add 1: the trend is good: -1

– Will eventually get them all (asymptotically)

– Converging quality

• If also doing new features:– Fix 2 add 1, add a new feature, add 4: the trend is poor: +3

– Diverging quality


Negative Leveraging

• The new feature is only useful to one customer.

• The defects introduced as a result can negatively impact every customer.

• Because touching code risks breaking ANYTHING, ANYWHERE

• Customers get irate if a “maintenance release” breaks previously working functionality– Danger even when just fixing defects

– Gets much worse if adding features


Release Proliferation

• If software quality is poor in general, customers will be slow to upgrade to a release they consider will be more buggy.– Can lead to supporting many releases in the field.

• EVEN WORSE: If customers come to fear maintenance releases, they may be reluctant to leave a maintenance release.– They may insist that you fix any issues as patches to their maintenance

release

– This is catastrophic release proliferation, whereby every point releases turns into a maintenance stream of its own...


Does this apply to Web App dev?• Absolutely, yes.• Seems to be easier to deploy web apps than installed apps.• Largely illusory

– Installed apps can have “update from web” feature, so is just as convenient– With web app you own all the data, so have to take extra time to not only write

the software to migrate the data, but also test the deployment.

• Must still test the whole app, which is the largest part of the overhead of a release.

• All the other considerations also apply.

• Management asks me regularly “is this something that we can do between releases?”

– My answer is almost always “no”– Of course you can technically, but my answer comes from a deeper

understanding of the issue where the correct answer for a software professional is “no” because of the loss of productivity and danger of defects escaping into the field.


Mitigating the Consequences

• If absolutely forced to, then:

• Have a very good regression testing environment

• Segregate functionality using run-time configuration switches– Code review to ensure when off, no new code touches the system


Versions

• As distinguished from “releases”.• Different variants of the same software

– Differ in small ways

R3.2.0

R3.2.1a

R3.2.1

R3.2.2

R3.2.3

R3.2.4

R3.2.5

R3.3.0

R3.3.1

R3.3.2

R3.3.3

R3.2 R3.3

Version reasons:• multiple hardware platforms• multiple os’s• multiple databases• multiple app frameworks• multiple partner software• security• functional tiers• demoware• translations

Must Support:

• stream of maintenance releases for each version

• each feature release will continue to ship that version

• ideally at the same time

Hard to Undo the decision to support a new version:

• some customer now relies on it


Cost of Versions

• Surprisingly costly to support many versions– Not the development cost: relatively cheap – just another feature

– Ongoing maintenance costs

• Technical means:– different code (linked differently or #ifdef’d)

– run-time switches (e.g., dynamically detect version of Windows and change API calls appropriately).

– different dev platform and tools

– binary-compatible: different test environments

• In any case:– testers must test all supported versions

– coders must bear in mind they are supporting multiple versions

– must track down bugs in each version and fix


Version Proliferation

• Software company will support many versions in hopes sales will increase– each version opens up a new market segment

• Danger: too hastily commit to supporting too many versions• Be aware of costs and push-back

• If in the business of supporting many versions:– architect the software well to support it

– construct a superb multi-platform automated build/test environment


Customized Software

• A different variant of the software for important customers– Static methods: require a distinct executable– Dynamic methods: same executable

• run-time switches

• alternate dll’s

• If customization required on feature release boundary– evaluate if feature’s dev opportunity costs are worth the revenue

• If customization required sooner– either:

• carefully insert changes into the point release stream

• #ifdef all code and build a unique executable for the customer

– Can we merge the changes into the next feature release?– Nothing very palatable here

• Better to build in enough configurability that customers do not require customizations

– gui-based configuration– scripting-based configuration


User Extension API

• Allows customers to implement their own features into the software• Danger:

– must support the API forever more

– even if one already exists internally:• clean it up• identify public versus private APIs• document it• train customers on it• hire programmers to provide help desk support on it

– support becomes “debug the customer’s code”

• maintain it unchanged– do not inadvertently change behavior

• market it and sell it• consult on it

– write it once

– support it forever?

» paid/unpaid?

Vendor’s Product

Vendor’s User Extension API

Vendor’s User Extension Library

User’s Extension

Program Code

Dynamic load module

dynamically loaded into

csc444f'07lecture 31 csc444 software engineering software releases

Documents

release cycle csc444f07lecture

release lifecycle slide

good slide

maintenance r2 shipping

releases feature releases

effective coder days

release overlap

extra release