March 2001
Volume 3 • Number 2

Contents

SOFTWARE PROCESSES
Variability in Software Development Process Families

by Ramkumar Ramaswamy, Software Concept Laboratory, Infosys Technologies Ltd.

An important feature of an organizationwide software process is its tailorability. The variability in process families is analogous to the phenomenon of variability that occurs in product families. Most variability that arises in practice falls into one of two broad categories: variability at the level of an individual process step, and variability at the level of an iteration philosophy. The author analyzes four sources of variability in the first category and two sources of variability in the second. He suggests simple but effective, practical tactics for accommodating such variability while specifying and documenting a process. Many of these tactics are motivated through analogies with variability in a product family.

Key words: process architecture, process documentation, process specification, tailorability

INTRODUCTION

The importance of formal, well-documented processes in software development cannot be overemphasized. Many organizations, particularly those at higher levels of the Software Engineering Institute’s Software Capability Maturity Model (CMM) (Paulk et al. 1993), strive to collate best practices and lessons learned into an organizationwide process that individual project teams can tailor to suit their needs. This is indeed a challenging task; few organizations are able to find one process that fits all teams. (This article does not make any special distinction between “process” and “methodology” though the two are not entirely synonymous.) In the context of the CMM, there are two levels of tailoring (Ginsberg and Quinn 1994). One is the tailoring of the CMM for the definition and development of the organization’s standard software processes (OSSP), and the second is the tailoring of the OSSP for the definition and development of the project’s software processes. The first case is addressed by several authors, especially in the context of small organizations. As an example of recent CMM-focused discussion, readers may see (Paulk 1999) and the references therein. An interesting complement is a paper by (Cockburn 2000), which presents a high-level framework along the axes of team size, criticality, and priority for selecting a software development methodology. In this article the author focuses on some aspects of tailoring the activities of an OSSP for specific projects, where there are few published shop-usable prescriptions.

Tailoring needs can be driven by different players in the project team, such as programmers, designers, analysts, and, of course, the project manager. Following is a sample of the more common real-world forces that drive the need for multiple versions of a process:

• Time constraints. The customer’s application may be faced with a window of opportunity that cannot miss. The popular phrase “Internet time” captures this phenomenon in the context of Web application development, in which time-to-market is crucial. Development must then be consciously accelerated, and the process must avoid steps that may be an overhead in such a context.
• Deviation from greenfield. An organizationwide development process usually has more of a greenfield development (new development) flavor. Greenfield development and “pure porting,” however, are but two ends of a long scale called “reengineering”; along the middle of the scale there are scenarios involving varying amounts of redesign, reimplementation, and enhancement. A project may occur at any place on this scale and needs a corresponding amount of customization. For example, one scenario the author encountered involved moving an application from Smalltalk to PowerBuilder with a few enhancements, and could be termed “almost pure porting.” Another scenario the author encountered was typical of “nearly greenfield development”: a large legacy credit-card transaction processing system implemented using COBOL on an IBM mainframe had to be redesigned with object-oriented techniques and reimplemented using C++ on UNIX.
• Varied choice of tools and techniques. Most projects use the latest CASE tool at the outset of the project (often at the customer’s request). Many analysts (the author included), however, find it quicker to use paper and pencil to draw class diagrams early in requirements modeling, and enter the final model into a CASE tool only when the models are nearly finalized and detailed design is ready to begin.
• Varying skill levels. One project team may already be familiar and comfortable with the development environment it uses, while another may find itself doing a lot of learning on the job because of new technology, inexperienced developers, or both. At Infosys, for example, an e-commerce development team of 20 people typically has about five to seven people with prior experience in e-commerce technology.

As pointed out by several authors, such as (Humphrey 1992), the problem of building software development process models is much like that of building software systems; consequently, an architectural framework is needed to define the basic elements, how they relate, and how they are decomposed into greater detail. Useful insights can be had by carrying this analogy one step further to a product family, which is a set of related systems whose designs can be viewed as variants of the design of a single underlying product, at a suitable level of abstraction (Parnas 1976).

The author believes this analogy is extremely useful since many of the intellectual approaches and lessons learned in the context of software architecture for product families can be put to good use in the context of process architecture. (As an example, Infosys has lessons learned from its banking software applications, represented by an established product family called Finacle.) Customized product “incarnations” are created by embellishing the core design in multiple ways–by instantiating the abstract elements of this design, and by incorporating additions or modifications in a controlled way.

Similarly, the set of actual processes in use by project teams may be called a “process family”: a set of processes that can be viewed as variants of an underlying organizationwide process, at a suitable level of abstraction. Usually one may not actually look for a single process but rather a set of a small number of processes. This allows one to selectively leverage the advantages of customization as well as organizationwide institutionalization. Infosys, for example, has two distinct development process specifications–one for structured development and one for object-oriented development. For the sake of simplicity, however, the author writes in terms of one organizationwide process.