1. CSC444F'07Lecture 31 CSC444 Software Engineering Software Releases

2. The software vendor lives and dies the endless dance of the “release cycle” CSC444F'07Lecture 32

3. CSC444F'07Lecture 33 A Release Lifecycle

4. CSC444F'07Lecture 34 A Simple Release Plan Dates: Coding phase:Jul.1—Oct.1 Beta availability: Nov.1 General availability:Dec.1 Capacity:days available Fred31 ecd Lorna33 ecd… Bill21 ecd total317 ecd Requirement:days required AR report14 ecd Dialog re-design22 ecd… Thread support87 ecd total317 ecd Status:Capacity:317 effective coder-days Requirement:317 effective coder-days Delta: 0 effective coder days

5. CSC444F'07Lecture 35 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

6. CSC444F'07Lecture 36 Resource Ratios Typical ratios I have used Adjust to taste Assumes availability throughout the (overlapping) release cycle.

7. CSC444F'07Lecture 37 Phase Length Ratios Typical ratios I have used Adjust to taste

8. CSC444F'07Lecture 38 Release Overlap Overlapping release cycles smoothes resource utilization

9. CSC444F'07Lecture 39 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,

10. CSC444F'07Lecture 310 Release Concepts & Terminology

11. CSC444F'07Lecture 311 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

12. CSC444F'07Lecture 312 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.

13. CSC444F'07Lecture 313 main maintenance R1 shipping R1.0 shipping R1.1 maintenance R2 shipping R2.1 retired maintenance R3 shipping R3.0 shipping R1.1 shipping R2.2 activeongoingactive X private big new feature shipping R2.0 R2.2.a

14. CSC444F'07Lecture 314 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.

15. CSC444F'07Lecture 315 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

16. CSC444F'07Lecture 316 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?

17. CSC444F'07Lecture 317 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

18. CSC444F'07Lecture 318 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

19. CSC444F'07Lecture 319 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...

20. CSC444F'07Lecture 320 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.

21. CSC444F'07Lecture 321 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

22. CSC444F'07Lecture 322 Versions As distinguished from “releases”. Different variants of the same software –Differ in small ways 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

23. CSC444F'07Lecture 323 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

24. CSC444F'07Lecture 324 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

25. CSC444F'07Lecture 325 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

26. CSC444F'07Lecture 326 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?