Parallel development is not a choice for most software projects. It is a reality dictated by the manner and time constraints in which software is developed today. Whether a software development organization is creating a commercial software application, an internal information technology (IT) application, or a web application, parallel development is inevitable when software is developed in a team environment. To create software effectively in parallel, both the technical staff and project management must understand and address the issues involved in parallel development.
Using a Release-Based Approach to Develop Software Applications
To appreciate the need for parallel development, it is important to understand the factors that drive parallel development. The primary factor that encourages parallel development is the release-based approach that is used to develop software applications.
Typically, a software application is developed in a series of releases. This is true for both internal IT applications and commercial software packages. It is also true for electronic commerce (EC) web applications.
There are good reasons why software is developed using a release-based approach. One reason is economic. As Michael Bays states in his book, Software Release Methodology (Bays, Michael E. 1999. Software Release Methodology. Prentice Hall. P. 205.)
| "Regardless of company size or organizational structure, income depends on release of product, so releases must occur." |
Clearly, the economic need for developing successive releases of a software application applies to companies that develop commercial software packages. There are non-economic reasons for developing software according to a release-based approach. These non-economic factors apply to both commercial and internally developed software.
The chief non-economic reason for developing software according to a release-based approach is functional. Each new release represents continuous improvement of the software application.
Once a newly developed software application is used, the end users identify additional features that would improve the value of the software. The new features may allow the software application to accomplish more tasks. Alternatively, the new features may allow the software application to accomplish existing tasks in a more efficient manner.
In the fast-paced world of electronic commerce web applications, the functional need is also an economic one. A company whose web application continues to provide a rich set of useful features is able to garner more business from its existing customers, as well as win new customers.
Another reason for developing software according to a release-based approached is to accommodate changing business needs and regulations. Even if new features are not required to meet an existing business need, changes to software are needed, over time, to address new business needs and government mandated regulations.
What is Parallel Development and Why is it Used?
A release-based approach to developing a software application implies that one software release is developed after another. This is an ideal situation. In reality, software development organizations often support two or more releases at the same time. The releases are developed in parallel, meaning code changes for one software release are made at the same time that code changes are made for another software release. These code changes are made to the same code base, i.e., the same set of files have the potential to be modified for each release.
An example illustrates why software releases are developed in parallel. Once a release is shipped to customers or placed in production, there may be a need to modify the current release before the next release is available. Frequently, critical bugs that are identified after a release is completed need to be corrected before the next release is delivered.
To fix the bugs in the current release while developing software for the next release usually dictates parallel development. The reason is simple. The bugs in the current release need to be corrected without introducing code under development for the next release.
Fixing bugs in the current software release while implementing new functionality for the next software release is not the only reason for parallel development. The business needs of a software application often dictate that certain features must be completed by a specific date.
When different features need to be delivered on different dates, features can be grouped by software release. The set of features needed by a given date is allocated to one release, while the set of features needed for a future date is targeted for another release.
Business reasons typically determine when certain features need to be delivered. To meet the targeted delivery date for each release, it is not always possible to wait until the software is completed for one release before starting work on the next release. Typically, coding for a future release must start before coding for the next release is completed. Hence, the ability to deliver software according to a compressed schedule, dictated by business needs, is one of the primary reasons for parallel development.
Parallel Development for Commercial Software
Parallel development for commercial software applications is driven by a software vendor’s need to remain competitive in the marketplace. To remain competitive, a software vendor needs to maintain existing customers while attracting new ones. A release-based software development model allows a commercial software vendor to maintain a revenue stream from existing customers while attracting new ones. Typically, a new release of a commercial product is completed once or twice each year. Each release provides new functionality to keep the product competitive. The features added in a release help maintain existing customers while attracting new ones.
Parallel development is used by commercial software vendors to make patches to an existing release while developing new functionality for future releases. Parallel development may also be used if the vendor needs to support multiple platforms, each requiring some code that is specific to a platform. Finally, parallel development may be used to separate development activities for different future releases.
Parallel Development for IT Projects
Typically, an IT organization develops internally used software to support evolving business needs or to comply with changing regulations. Parallel development of IT applications is driven by the need to modify the same software application to implement new features requested by the business. Specifically, an IT organization employs parallel development when it needs to modify the same software system across several software releases. The IT organization develops multiple releases in parallel because of the demands placed on it by the business. The IT organization simply cannot wait until one release is delivered to start work on the next release.
Parallel Development for Web Applications
Parallel development of electronic commerce web applications is driven by the need to provide new capabilities to customers continuously. These new capabilities permit customers to engage in commerce with the business in an efficient, cost effective manner. Common business transactions that required time from a customer service representative can be completed electronically, usually at a lower cost to the business. When freed from facilitating routine business transactions, customer service representatives can focus on those customer facing tasks that require human expertise.
Electronic commerce web applications typically involve both code and web content changes. Web content changes may need to be made frequently, possibly daily. Code change, while required frequently, typically do not occur at the same frequency as content changes.
Parallel development can be used to facilitate content changes to the current software release while new development is underway for future software releases. Specifically, a branch can be created to facilitate content changes in the current release while new code and content development for the next release can occur in the main codeline.
Strategies for Mapping Parallel Business Projects into Software Projects
As stated above, very often the business need to deliver a certain feature set, on a certain date, drives parallel development. IT organizations do not have the option to wait until the features are completed for one software release before starting work on the next release.
IT applications and electronic commerce web applications are driven by business needs. A business organization may have several business projects that involve changes to the same software (or web) application. However, the business may view each project as separate and independent even though each project involves changes to the same code base. If this is the case, the IT organization needs to manage the code changes dictated by each business project.
The IT organization needs to work closely with the business organization to map business projects into software releases. In some instances, it may make sense to map each business project into a separate software release. In other cases, many small business projects can be grouped into a single software release. It may even be possible to implement the features requested for one or more business projects across several software releases. Unfortunately, there is not a universal strategy for mapping business projects to software releases.
While the business is the customer of the IT organization, it is essential that the IT organization provide guidance to the business about the most effective way to map business projects to software development releases. The business needs to understand when each feature specified in a business project will be implemented in a software release. The business also needs to understand the impact of changes to the requirements for a feature on the IT organization’s ability to deliver that feature in a specific software release.
Although not essential for parallel development, an iterative software development approach is an effective way to deliver the desired software functionality in each release. Several short iterations should occur during the course of each software release. At the end of each iteration, the IT organization should deliver working code to the business that implements some or part of the features targeted for the software release. By following an iterative approach, the IT organization has a better chance of delivering the features that the business desires in each release. This is because the business is able to see each feature as it is implemented. The business can provide the IT organization with the feedback needed to understand the true requirements for each feature.
Strategies for Parallel Development
A software development organization that practices parallel development needs to follow an effective branching strategy. Prior to starting a parallel development effort, the software development organization should define its high-level branching strategy. The software configuration management patterns identified by Steve Berczuk and Brad Appleton in their book, Software Configuration Management Patterns: Effective Teamwork, Practical Integration, will help any organization develop an effective branching strategy. Proper use of the mainline, active development line, release line, release-prep code line, and task branch patterns (described in their book) will ensure that the development team can support parallel development.
The development team should keep in mind the point emphasized by Dewayne Perry, Harvey Siy, and Lawrence Votta in “Parallel Changes in Large-Scale Software Development: An Observational Case Study.” In their paper, they note that software features are developed in parallel both within a single release and in the context of multiple releases. (Perry, Dewayne E., Harvey Siy, and Lawrence G. Votta. “Parallel Changes in Large Scale Software Development: An Observational Case Study”. ACM Transactions on Software Engineering and Methodology, Vol. 10, No. 3, July 2001. p. 319.) This means code changes need to be integrated both within and between codelines. For an explanation of managing changes within and between codelines, see http://www.cmcrossroads.com/articles/msmay04.pdf.
Choosing an SCM tool to Support Parallel Development
When choosing an SCM tool to support parallel development, it is important to understand how the tool implements branching. The manner in which the SCM tool facilitates branching needs to support the organization’s branching strategy. To evaluate an SCM tool’s ability to support a branching strategy for parallel development, focus on the high-level approach that the SCM tool uses to support project level branching. While most SCM tools support branching at the file level, project level branching is conceptually mode powerful and is needed to facilitate parallel development.
Conclusion
Parallel software development is the new normal. It occurs because software development organizations need to develop multiple software releases at the same time. To develop software effectively in parallel, an organization needs to understand how to map business projects to software releases. The development organization also needs to develop an effective project level branching strategy to support parallel development. The software configuration management patterns, identified by Steve Berczuk and Brad Appleton, provide the necessary foundation for developing a project level branching strategy. Finally, the development organization needs to choose an SCM tool that will facilitate the branching strategy to be used for parallel development.
Michael Sayko is a software configuration management consultant based in Austin, Texas. He is experienced with the practice of software configuration management from having served as a configuration manager on large, fast-paced software projects.
You can reach Michael by email at mss@acm.org
Trackback(0)
Comments 
Write comment
 |