Early March I visited the Enterprise Software Development Conference in San Mateo. This is more an intimate expo with some 25 booths. Though well visited, you still found time to discuss with the reps their products and offerings in great detail.
I must confess, I have a more academic interest there, still looking for the solution that kept me nagging when working for Mobile Information Systems (Offering real-time solutions for the time-sensitive, same-day transportation industry) — now an entity of Oracle — in year 2000. Something that I was so used to when I had worked with Unisys in the System Software development in one of my former lives…
As products evolve over time new versions are designed and developed and will become available to the market. These can be (labeled) completely new software products and customers can choose to pay for the upgrade. And new revisions or support packages are provided to the user to update their existing software to the most recent level.
Companies release new software products to provide new functionality (aka, features) to their users, to support new hardware components and devices, to improve usability, to tighten security, and — naturally — make use of the ever increasing resources in processor, memory, disk space, etc.
Using the software you may encounter incidents where the product does not do what it is supposed to do. That can be a subtlety where, say, the output is not properly aligned. Or more drastically, where the input is not processed correctly. And that can range to more serious problems of security leaks or data loss, if not the abort of the application or even the underlying operating system. Software releases are, therefore, also the vehicle to distribute a list of bug fixes or corrections to said problems.
As nature of things go — after all, computers are only human, too! 😉 —, a new release may not only be the latest and greatest thing, it can also introduce new problems. Perhaps some hardware component or software function not supported anymore. Or new bugs frustrating the user.
There are a variety of reasons a user does not want to move to a new main release and expects that recent releases still to be supported. Consequently, companies maintain several main and support releases, replicating development and addressing incidents and providing patches to the given „dot“ release. Eventually, older releases are phased out and their support will cease.
Main releases, as mentioned before, introduce new functionality and are intended to advance the company in a competitive market, increase share and revenue stream. Likewise, said company needs to ensure their products are „bug free“; even if it means to continuously provide resources and fix incidents over the life of the product.
A company will, therefore, enjoy a variety of software releases. A few main releases with various support or patch releases. A software product usually consists of a variety of individual pieces, programs, drivers, user interfaces, messages, reports, libraries, third party components, and what not. All these parts comprise — are controlled through — the release stream. And perhaps there are also special software packages with different set of features, supporting specific hardware components, etc.
And while plans are executed to phase out older releases, there are already the future releases and schedules on the drawing board: specifications are laid-out and defined for the new product to be. Functional and detail design are written, and eventual resources are planned and assigned for the development, documentation, test, etc.
Good strategy is to introduce new (major) functionality only in main releases = new products, whereas support or patch releases (branched off from the underlying main release) are more the vehicle to further stabilize the release with well-defined sets of software or product fixes. (L10N and I18N also comes to mind.)
Software Development Suites record each individual modification to the software components, Software Life-Cycle and Change Management tools help to keep overall track. The Task database on the other hand is the repository containing incidents reported and feature requests against given releases, severity and priority, detail description or specification, current task status and updates, department and engineer assigned, etc.
While certain problems can be more readily detected during the normal use of the product (the goal of the quality assurance team, naturally, should be to find said problems before the user installs the product!), others, however, may not be obvious to the end-user. Either, the problem does not occur in the specific environment of the user; or, it may be some security exploit, the user would not even notice. Whatever the nature, chances are that the incident could occur not just in one but in other releases as well.
Consequently, each software release stream is then reviewed and determination made, whether a fix will need to be replicated — or perhaps newly developed —, based on the problem at hand and the prerequisites and requirements of the given release stream.
While the software developer working on a new feature or creating a fix for a reported incident is doing the due-diligent to ensure the software change is doing what it is supposed to do (and there may also additional code reviews), based on the design or the description of the incident, it is later the software quality team’s task to put the final stamp of „passed!“.
Of course, the patches are not tested as soon they become available, rather, the defined collection of such software features and fixes are included in a formal release cut-off process and then handed over to the software quality team. The interval of such cut-off can be weekly, monthly, daily; whatever makes most sense in the current situation.
The software quality takes the handed-off release stream and deploys the product on their prepared environment, what can be a fresh install or an update. Part of the hand-off are release notes, updates of the task database linking the features and fixes to one or more changes in software and/or documentation.
A set of test runs are started (automated or manual) confirming the working of the feature or fix (Conformance testing) while assuring that no new incidents were introduced (Regression testing). The tests and the results are carefully documented following the key principles: a test shall be repeatable, the results reproducible, and the test environment reliable.
There may be situation that a patch or a series of patches need to be pulled (and updating the task database, hopefully, setting task status appropriately), perhaps due to product stability concerns. Software engineering is then addressing concerns based on the documentation provided. Once software quality puts there “QA stamp” on the given release, that release is then ready to proceed to the next phase; e.g., handing over to professional services to customer deployment, publishing on web site for download, etc.
Closing in on the scheduled release date, the software team re-evaluates the planned and prioritized features and fixes against those that are available and have passed testing. Questions to answer are: Is the release process on target? If not, what is missing and what would it take? Are the missing pieces requirement for the target release? What are the consequences if the schedule were to slip? Would it make sense to get the product out as it and publish a revision soon after?
There can be different approaches to tackle these problems (and I may elaborate further in a separate blog).
Whatever the outcome, eventually the product is signed off and ready to go. Let’s celebrate! 🙂
And the next releases are already in the making…
(to be continued)
© March 2010 Jürgen Menge, San José