The better you understand how PP works, the better you can use it.
Component Types
The first thing PP does is brush away the murky haze surrounding processes by clearly defining processes. A process is a collection of best (or at least better) practices that are used to achieve repeatable project excellence. These practices are the components used to form a process by "prescribing" what a particular project needs.
PP takes the concept of "practice" and organizes it into 6 types of components:
- Activities
- Forms
- Policies
- Roles
- Standards
- Tools
Component types make assembling the components needed for a process instance much easier and allow deeper understanding. They're not magic, but make process assembly more engineering and less art. Gone is the over-simplicity of "best practices". Instead we now view process as a set of activities that are done following certain policies, by people playing certain roles, using certain forms, standards and tools. This provides most of the crystal clear perspective needed to use formal processes well, but we also need components to have Unification Correctness.
Unification
Any system with many parts needs unification to organize the parts into an interactive whole, according to the intentions of the architect. If this is done well, the crucial Gestalt effect is achieved because the whole is greater than the sum of the parts. Thus unification artifacts are mandatory for complex systems. Any complex system without them is doomed to some level of incomprehensibility and sub-optimization.
For example in The Mythical Man Month, Fred Books says,
"Even though they have not taken centuries to build, most programming systems reflect conceptual disunity far worse than that of cathedrals. Usually this arises not from a serial succession of master designers, but from the separation of design into many tasks done by many men.
"I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas."
(Note - Brooks has the word "the" in italics. We have highlighted that word and bolded the key sentence.)
This famous dictum has guided countless designers since it was written in 1975. It guides us today into making room in PP for both expressing and enforcing system conceptual integrity.
So, unification gives a system component interaction and conceptual integrity gives a system the original intentions of its architects. Conceptual integrity is correctness of unification. Thus if conceptual integrity is the most important consideration in system design, then unification correctness is the key process constituent. PP encourages correct unification by these mechanisms:
Diagrams - Visual aids that describe component interactions. They generally achieve human comprehensibility much faster and better than text or speech, by an order of magnitude. "A picture is worth a thousand words." The most process diagrams are flowcharts. Architecture is also best expressed with a diagram, supplemented by text if needed.
Procedures - Text that describes how to use system components to accomplish a task. Please note we didn't say, "Text that describes how to accomplish a task." :-)
Diagrams and procedures revolve around the components chosen for a process. Thus each unique process needs unique Unification Correctness artifacts. These are hard to build, which is one reason we see so many standard processes. Avoid quickie approaches here, or worse yet, no written procedures or diagrams. Also avoid the sin of too much. A good lightweight solution is to lavish lots of time on your diagrams, which can be assimilated very quickly. Then you can spend the bare minimum on procedures, because much of system procedural behavior is captured in the flowcharts.
Remember, the goal of process management is unification correctness.
Standardization
Components vary across differrent popular processes. In most cases two similar components are the same. For example XP calls Uses Cases "User Stories", and calls Architecture a "Metaphor".
As we assemble the Component Inventory we use standard name, definitions and such. This frequently means that a name you're used to, because it was in a popular process, has been replaced by a new unfamiliar name. Sorry about this, but we prefer to use standard names rather than confusing synonyms.
Standardization enhances component reuse, whether the component is text in a standard file format, a Java class, structured data in XML or guess what, a process component. :-)
Component Inventory
Component type and standardization allow us to march through existing processes to build the initial Component Inventory. We are also adding components based on personal experience and PP user experiences.
This is long, tedious work. For example taking XP apart and putting it back together (translating it) turned the 12 main practices and others into, so far, 36 components. Just identifying them took several days, and there must be a doze more and I'm sure I made errors. Then each component needs documentation and use in an example.
What's in the inventory is not something physical. It's pure knowledge, with the minor exceptions of forms and tools. Knowledge cannot be applied without knowing how to use it, so we get into the next subject:
Educational Materials
These allow a multiplier effect. The more one knows about how to use something, the better the results. In the case of using "pure knowledge" training is paramont.
We have barely started Education Materials. There's lots of work ahead.... :-)
Architecture
Now that you've read the above you can more easily comprehend this model. Pardon the wide image. The model was the 5th document in a VKSL series using the Mini Process 2.
This shows not only the usual partions and relations, but also the long term architectural goals of PP. The three feedback loops will increase the quality of the source material. The Prescriptive partition will take considerable effort to perfect, but will be well worth it. The Descriptive partition should develop rapidly since we're not breaking nearly as much new ground. The Process Instance partion is somewhat of a unique way to look at process, and allows the other partions much leverage. Note the number 3 falls within Ivar Jacobson's recommended 2 to 4 architectural partitions.
There's lots more we could say, but we let the diagram speak for itself.
(More later. It's been exhausting just getting this far. My writing is beginning to be less than fluid. - JH. :-)