The Process Patterns Resource Page
I've built this page so that all of us may
have a shared resource which provides key information about, and
links to, process patterns and software development process resources. Contents:
My definition for a pattern, and there are many
out there so don't get your knickers in a knot if it
isn't the one that you felt was the "official"
one, 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: James Coplien's definition and
The Software Patterns Criteria).
Software development patterns come in many flavors, 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 would argue that
process patterns and organizational
patterns go hand in hand, and that
there are at least three types of process patterns that we are
Just as there are process patterns, there are
also process antipatterns. An antipattern 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
antipattern describes an approach and/or series of actions for
developing software that is proven to be ineffective and often
detrimental to your organization.
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.
A general history of patterns.
As I indicate in my books,
Process Patterns and
More Process Patterns, I
believe that there are at least three types of process patterns.
In order of increasing scale they are:
Taxonomies for organizational patterns are
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.
Kaul proposes to use the three
dimensions - Structure, Process, and Behavior -
presented in Gamma (1995) as a taxonomy for organizational
patterns. Kaul believes that structural organizational patterns
would cover established patterns of interacting and coordinating
technological and human structure of an organization, covering
much of the same ground as does organization structure and some
management patterns. Process organization patterns would be
patterns relating to information flow, communication, and
decision making within organizations, covering the same ground as
my process patterns and some management patterns once again.
Finally, behavioral organizational patterns deal with delegation
within organizations, covering the same ground as role and some
Cusik also proposes a taxonomy
for organizational patterns, specifying (but not defining it
seems) three types: process, project risk, and organization. His
process type appears to map reasonably well to mine, project risk
seems to be a subset of my management type, and his organization
type seems to encompass my organizational structure type, role
type, and part of my management type.
Why is a taxonomy important? I suspect that
different types of patterns will require different approaches to
documenting them. For example, I believe that when you are
documenting a phase or stage process pattern that it is valid to
indicate potential metrics that may be collected when performing
that process, as well as potential risks that may need to be
mitigated. Would this be true of role patterns? Probably not.
Different types of patterns, different (but consistent) ways to
References for this section:
Gamma, E., Helm, R., Johnson, R., Vlissides, J.
(1995). Design Patterns - Elements of Reusable
Object-Oriented Software. Reading, MA: Addison-Wesley
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
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
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
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 (yes,
Patterns can and should be used as
a 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.