csc444f'07lecture 31 csc444 software engineering software releases
TRANSCRIPT
CSC444F'07 Lecture 3 1
CSC444Software Engineering
Software Releases
Software Releases
• The software vendor lives and dies the endless dance of the “release cycle”
CSC444F'07 Lecture 3 2
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
CSC444F'07 Lecture 3 3
A Release Lifecycle
CSC444F'07 Lecture 3 4
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
CSC444F'07 Lecture 3 5
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
CSC444F'07 Lecture 3 6
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.
CSC444F'07 Lecture 3 7
Phase Length Ratios
• Typical ratios I have used
• Adjust to taste
specification & design
alpha test
code & unit test
beta test
3 2 2 1
CSC444F'07 Lecture 3 8
Release Overlap
• Overlapping release cycles smoothes resource utilization
specification & design
alpha test
code & unit test
beta test
specification & design
code & unit test
R1.2
R1.3 requirements gather
maintenance
CSC444F'07 Lecture 3 9
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
CSC444F'07 Lecture 3 10
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
CSC444F'07 Lecture 3 11
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
CSC444F'07 Lecture 3 12
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.
CSC444F'07 Lecture 3 13
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
CSC444F'07 Lecture 3 14
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.
CSC444F'07 Lecture 3 15
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
CSC444F'07 Lecture 3 16
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?
CSC444F'07 Lecture 3 17
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
CSC444F'07 Lecture 3 18
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
CSC444F'07 Lecture 3 19
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...
CSC444F'07 Lecture 3 20
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.
CSC444F'07 Lecture 3 21
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
CSC444F'07 Lecture 3 22
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
CSC444F'07 Lecture 3 23
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
CSC444F'07 Lecture 3 24
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
CSC444F'07 Lecture 3 25
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
CSC444F'07 Lecture 3 26
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