This entry is about the relationship between patterns and the PersonalSoftwareProcess defined by WattsHumphrey.

Are processes an example of WhenToUsePatternForm?

It seems to me that if I am going to do some job more than twice, then  the RuleOfThree applies.

To do any non-trivial job, I must accomplish a set of tasks, so the job is a process.

----

'''Pattern Name'''

Process Definition Template?

'''Problem'''

What problem does this process address?

'''Agent'''

Who is the agent responsible for doing the process?

'''Context'''

When does this process need to be done?
What inputs are required to do this process?
	* Input 1
	* Input 2
	* ...

'''Forces'''
	* Qualities 
	* Attributes
	* Issues
	* Priorities

'''Solution'''

How do I balance or resolve the forces?

'''Rule'''

Specifically how?  What method and tasks must I perform?
	* Task 1
	* Task 2
	* ...

'''Reason'''

Why should I use this process?

'''Resulting Context'''

What have I produced as result of this process?
	* Output 1
	* Output 2
	* ...

'''Examples'''

See scripts in ADisciplineForSoftwareEngineering by WattsSHumphrey

'''Related Patterns'''
	* Is it part of a larger process?
	* Is there a next phase?
	* Was there a previous phase?
	* Is it an instance of a meta-process, e.g. DefinedProcess ?

'''Author(s)'''
KentSchnaith

'''Date(s)'''
11-Feb-97

----

Another log for the fire...

Can process be separated from methodology?
What aspects of Shlaer-Mellor, Booch, OMT, or Fusion can be abstracted up to a higher level? - KentSchnaith

----
I believe that processes are rarely amenable to pattern
form.  Empirical research has demonstrated that for
effective construction of large, complex processes,
repeatable processes are a myth.
The few places where repeatable processes seem to work
are in organizations with very high cost and low
productivity, those these are sometimes necessary to
achieve ultra-high safety or reliability.

The patterns of most effective
organizations lie not in process,
but in structure.
See Cain and Coplien, "A Role-Based Empirical Process
Modeling Environment," Proceedings of ICSP/2, 125-133,
February, 1993, IEEE Computer Press.
We still sometimes call them ProcessPatterns,
though they're not about process.

-- JimCoplien
----

See DefinedProcess -- KentSchnaith
----
Seems better to describe the reason why after the solution.  

-- KentSchnaith