This blog answers several frequently asked questions about process patterns.

What are Process Patterns?

My definition for a pattern, and there are many out there, is that a pattern is a description of a general solution to a common problem or issue from which a detailed solution to a specific problem may be determined (see also: Hillside Group’s definition). Software development patterns come in many flavours, including but not limited to analysis patterns, design patterns, organizational patterns, and process patterns. A process pattern is a pattern which describes a proven, successful approach and/or series of actions for developing software. I believe that process patterns and organizational patterns go hand in hand, and that there are at least three types of process patterns that we are interested in.

Do Process Anti-Patterns Exist?

Yes. Just as there are process patterns, there are also process anti-patterns. An anti-pattern describes an approach to solving a common problem, an approach that in time proves to be wrong or highly ineffective. As you would expect, a process anti-pattern describes an approach and/or series of actions for developing software that is proven to be ineffective and often detrimental to your organization.

What is the History of Process Patterns?

The concept of process patterns, and organizational patterns in general, was first introduced at the 1994 PLoP’94 conference. Jim Coplien’s paper “A Generative Development-Process Pattern Language” presented at conference and published in Pattern Languages of Program Design (Addison Wesley Longman, Inc. 1995, eds. Coplien & Schmidt) is a key “first” paper in process patterns, as are the rest of the papers presented at that conference. Since then the organizational patterns community has grown, with further presentations at PLoP conferences as well as printed and online papers and books being written. The key goal of this web page is to present a centralized source of information about the process patterns portion of this work.

What are Organizational Patterns?

There is a growing body of patterns called organizational patterns, the key resource page for which is Jim Coplien’s Organizational Patterns site which describes proven, successful approaches for organizing and managing people involved with the software process. Organizational patterns and process patterns go hand in hand and should be used together.

How To Document A Process Pattern

I believe that there is a need to combine the existing work in process patterns, well defined (yet still evolving) within the patterns community, with that of the existing process improvement community. The implication is the need for a format/template that both communities understand and agree to. In that light, immediately below is one way that a process pattern can be documented and following that I have included links to what others have to say on the subject.

Process Pattern Format:

• Name. Provide a concise, strong name for the pattern, such as Program or Reuse First.
• Intent. Describe the process pattern in one or two paragraphs, providing if applicable a graphical description of the process pattern. Common graphical notations applied to process patterns include, but is not limited to, flow charts, process diagrams, UML activity diagrams, and data-flow diagrams.
• Type. Indicate if it is a Task, Stage, or Phase process pattern.
• Initial Context. Indicate the situation to which the pattern solution applies, and if applicable the entry conditions that must be true before the process may begin.
• Solution. Describe in detail how to perform the steps/activities of the process pattern. You may also choose, particularly for phase and stage process patterns, to describe management, quality assurance, and risk management issues, as well as indicate potential metrics to collect when working the process.
• Resulting Context. Indicate the situation/context which will result from performing the process pattern solution, including if applicable the conditions that must be true for the process to be considered complete.
• Related Patterns. Indicate the other patterns that this pattern is composed of, is a part of, or is associated to.
• Known Uses/Examples. Indicate where/how the process pattern has been applied in use. For example, the Technical Review task process pattern can be applied to the management of peer reviews, code reviews, model reviews, and management reviews.

If you are writing a single process pattern, and hopefully publishing it to share with the rest of us, then I would suggest that you follow this format to the letter. If you are strictly writing a reference book or reference web site, presumably a collection of process patterns, then I would also follow this format or one close to it. If you are writing a process improvement-oriented book, as I did, you might choose to get a little more lenient in your approach. You’ll note that in my book I followed this format, for the most part, for phase and stage process patterns, but was much less systematic for task process patterns. It was simply a matter of usability. I could just have easily written a very structured reference manual but it wouldn’t have flowed as nicely and it wouldn’t be as usable to its readers. My advice is to do what you think is best for your readership, that the format described above is merely a good suggestion.

Why Do I Care?

In the mid-1990s I wrote two books, Process Patterns and More Process Patterns, which captured a CMM level 5 compliant approach to object-oriented software development. At the time it was a great approach.