, Fraunhofer Center for Experimental Software Engineering, Maryland
, Fraunhofer Center for Experimental Software Engineering, Maryland
Pages: pp. 14-18
A "one size fits all" approach doesn't work in software development. Processes work or are appropriate only under certain conditions. Does NASA follow the same software development process as a startup e-commerce company? The answer is obvious. Processes differ greatly throughout the industry, and this special issue looks at some aspects of this diversity.
First of all, what is a process? Asking this might seem trivial, but by reading the many excellent submissions for this issue, we realized this question has a far from trivial answer. According to the Merriam-Webster's Collegiate Dictionary, you can define a process as "a series of actions or operations conducing to an end." This definition seems to fit peoples' general ideas about process, but clearly, numerous differing definitions of process exist. Is process the way a company operates—from marketing to human resources, to actual development—or the way a developer produces design or code, or tests the software? Does the process refer to management, engineering, or both? Does process imply a lot of formalism and expanding effort for writing and reading documents, instead of product development?
Some people would answer yes to these questions, others no. Maybe the correct answer is that it depends on the situation.
We also noted that when you ask people to write about software process, they tend to use the Capability Maturity Model (CMM) as the basis for their reasoning.
Returning to the dictionary definition, the end—in this case, the ultimate goal—shapes the process in terms of scope (namely, the phases or activities covered) and organizational level. Depending on the perspective, we can talk about processes for entire organizations, teams, or the individual. The process also depends on the perspective of the person using the term, having a different meaning for the CIO than for the process engineer or the hiring manager. In any case, the process should help by guiding people on what to do—on how to divide and coordinate the work—and by ensuring effective communication. Coordination and communication, for example, form the main problems in large projects involving many people—especially in distributed projects where people cannot communicate face to face.
For a given organizational level, the process varies with the project's goals and available resources. At a high level, the company's business strategy determines the business approach. The main goals of time to market, minimum cost, or—although people often say "and"—higher quality and customer satisfaction (see Stan Rifkin's article referenced in the " Process Diversity Resources" sidebar) set the priorities. The company's size; the number, knowledge, and experience of people (both engineers and support personnel); and hardware resources determine how to achieve the goal. The application domain and the corresponding software and system requirements together with other constraints form another main factor. The space shuttle or nuclear plant control software embedded in a complex system have different safety and reliability constraints than a word processor running on a PC; software for a car has different time response constraints than a payroll system.
These factors get translated into more detailed goals when the process scales down to the project, team, and individual levels. For example, a project's objective can be to improve prediction and estimation, avoid risk, and make people happy (wishful thinking!)—such that they don't leave in the middle of the project. The team-level objective can be to increase communication, while the personal objective can be to better plan individual work.
Whenever someone (be it an individual or a company) wants to reach a desired end, they must perform a series of actions or operations. They must consider the order of these actions, their dependencies, who will perform them, what they require and what they will generate, how long it will take to complete them, and what tools they will employ. Thus, they do follow a process, be it predefined or ad hoc (see Bob Glass's Loyal Opposition column in this issue about ad hoc processes). Because all these process components (activities, products, agents, tools) and their interactions (information flow, artifacts flow, control, communication, timing, dependencies, concurrency) can vary, processes will differ—even if they have the same level, scope, and goal.
Absolutely! We plan for a trip; how can we not plan for developing software? We periodically check on our car or bank account; how can we not check on our project's status? We buy the best golf clubs on the market; how can we not care what tools and techniques to use for design, coding, and testing? For a successful dinner we debate whether to order in or cook. Should we develop software or buy and integrate? We could go on with examples, but you get the point.
So why should people care about processes? To understand, evaluate, control, learn, communicate, improve, predict, and certify their work. What could people do with processes? They could document, define, measure, analyze, assess, compare, and change them.
Now this is the most difficult question. We hope that reading the articles in this issue will help answer this question. The authors present how and why different companies use different processes, referring to different software development levels and scope. The authors show whether or not (and why) processes worked, and generously share the lessons learned from their experience (as engineers, managers, consultants, and researchers). They cover a large spectrum of development types, including new product development, reuse, commercial off the shelf (COTS), maintenance, services, and product line—from the company level, down to the project, team, and individual. This selection of high-quality articles address both managerial and engineering aspects, either focusing on the whole life cycle or just a subset of the phases; developers are either onsite or work in a distributed environment.
"Strengthening the Case for Pair Programming," by Laurie Williams, Robert R. Kessler, Ward Cunningham, and Ron Jeffries addresses software process in the small—namely, at the individual developer level. The article proposes a new way for developers to work on software engineering, which is to work in pairs, side-by-side, collaborating on the design, coding, or testing.
In dynamic domains such as telecommunications where change is overwhelming, product requirements can be unstable or even unknown as a project begins. Delivery time is short while the release date is fixed and firm. The question is, how do we deal with chaos when traditional processes do not work for nontraditional product development requirements? Based on their experience at AG Communication Systems, Linda Rising and Norman S. Janoff in "The Scrum Software Development Process for Small Teams" advise developers to identify and use process patterns that work. The article reports the successful implementations of their Scrum development process for three teams at AGCS.
In "The Role of Process in a Software Start-up," Stanley M. Sutton Jr., asks the questions "Does process matter to start-ups?" and "How is process different for a new and dynamic company—which aims to shorten time to market—targeting the commercial marketplace?" Adherence to process improvement frameworks such as the CMM is claimed to be problematic for these young companies. The author argues for a defined yet flexible process that can adapt quickly as the development parameters change.
For different reasons (usually for obtaining contracts), companies might need to show their capability in business. One way is by getting certified or assessed according to process frameworks such as the CMM and ISO. In "Applying CMM Project Planning Practices to Diverse Environments," Donna L. Johnson and Judith G. Brodman acknowledge that because companies and projects differ greatly, they do not implement processes the same way. They show that it is possible for most organizations—no matter how unique—to take their existing practices and package them to satisfy CMM goals.
Using COTS products, as opposed to developing software from scratch, is becoming increasingly popular. The process of acquiring and integrating third-party products, possibly from different vendors, however, differs from traditional software development. In their article "Developing New Processes for COTS-Based Systems," Lisa Brownsword, Tricia Oberndorf, and Carol A. Sledge identify these differences and define a process framework for the creation and maintenance of COTS-based systems.
Maurizio Morisio, Colin Tully, and Michel Ezran, in "Diversity in Reuse Processes," discuss the key factors in different approaches for successfully implementing reuse. The article is based on studies of four very different companies that successfully implemented reuse programs. The authors identify a shared set of key factors across the four companies that seem to lead to successful reuse programs.
In "Selecting A Project's Methodology," Alistair Cockburn argues that different projects require different methodologies, mainly defined by three factors: project size, the criticality of the system being created, and the project's priorities. The methodology should also support quality work assuring an end product with no fatal defects and should help track and manage the project according to its budget and time constraints. The author concludes by describing a project, whose characteristics changed over time and in which the methodology changed accordingly.
The bottom line for process diversity in software development is that you must know yourself (as a company, team, or individual) and the diversity of existing processes out there, and adopt and adapt what's best for you.
We've compiled an annotated list of important resources for process diversity in software development.