|Ive 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:||
Frequently Asked Question What are Process Patterns?
My definition for a pattern, and there are many out there so dont get your knickers in a knot if it isnt 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 interested in.
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.
Frequently Asked Question What Books Are Available?
Frequently Asked Question 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 Copliens 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.
Frequently Asked Question What Types of Process Patterns Exist?
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 discussed below.
Frequently Asked Question What are Organizational Patterns?
There is a growing body of patterns called organizational patterns, the key resource page for which is Jim Copliens 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 Publishing Company.
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. Youll 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, Process Patterns can and should be used as a reference manual) but it wouldnt have flowed as nicely and it wouldnt 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.