Process patterns
Process patterns are patterns used to describe problems and their solutions in the
context of software process. Problems can arise at different levels such as :
Problems associated with a complete process model
Within a framework activity
Within an action in an activity
Patterns can be described using a pattern template which include :
Pattern name
Intent (describes process pattern in one or two paragraphs)
Forces and Types (environment in which problem is encountered is identified and
the type of pattern is specified)
Stage pattern – explains problems related to framework activity and it may include
multiple task patterns as well.
Example: ‘Establishing Communication’ (stage pattern) includes ‘Requirements
Gathering'(task pattern)
Task pattern – describes problems related to software engineering action or task
such as Requirements Gathering.
Phase pattern – defines a sequence of framework activities and ensures each
section in the activity is addressed correctly such as in prototyping, spiral model etc.
Initial context – Situation to which the pattern is applied. Defines work done so far
before the pattern is applied. Actions and activities that have taken place before the
pattern is introduced.
Problem – Specific problem that is to be solved by the pattern.
Solution – Implements pattern and initial context is modified to resolve the problem.
Resulting context – Situation which will result from carrying out the process pattern
solution.
Related patterns – A list of patterns related to the current one is documented for
further reference.
Known uses or examples – Indicates where or how the process pattern is
applicable.
An example:
Pattern name – requirements unclear.
Intent – an approach to build a prototype so that stakeholder can assess and
determine specific requirements.
Type – phase pattern.
Initial context – stakeholders have been identified, communication mode has been
selected, initial understanding of problem and scope of the project determined.
Problem – recognized that stakeholder has a general idea of requirements and
cannot place specific requirements.
Process patterns are patterns used to describe problems and their solutions in the
context of software process. Problems can arise at different levels such as :
Problems associated with a complete process model
Within a framework activity
Within an action in an activity
Patterns can be described using a pattern template which include :
Pattern name
Intent (describes process pattern in one or two paragraphs)
Forces and Types (environment in which problem is encountered is identified and
the type of pattern is specified)
Stage pattern – explains problems related to framework activity and it may include
multiple task patterns as well.
Example: ‘Establishing Communication’ (stage pattern) includes ‘Requirements
Gathering'(task pattern)
Task pattern – describes problems related to software engineering action or task
such as Requirements Gathering.
Phase pattern – defines a sequence of framework activities and ensures each
section in the activity is addressed correctly such as in prototyping, spiral model etc.
Initial context – Situation to which the pattern is applied. Defines work done so far
before the pattern is applied. Actions and activities that have taken place before the
pattern is introduced.
Problem – Specific problem that is to be solved by the pattern.
Solution – Implements pattern and initial context is modified to resolve the problem.
Resulting context – Situation which will result from carrying out the process pattern
solution.
Related patterns – A list of patterns related to the current one is documented for
further reference.
Known uses or examples – Indicates where or how the process pattern is
applicable.
An example:
Pattern name – requirements unclear.
Intent – an approach to build a prototype so that stakeholder can assess and
determine specific requirements.
Type – phase pattern.
Initial context – stakeholders have been identified, communication mode has been
selected, initial understanding of problem and scope of the project determined.
Problem – recognized that stakeholder has a general idea of requirements and
cannot place specific requirements.
