Process Patterns in Software Engineering
As the software team moves through the software process they encounter problems. It would be very useful if solutions to these problems were readily available so that problems can be resolved quickly. Process-related problems which are encountered during software engineering work, it identifies the encountered problem and in which environment it is found, then it will suggest proven solutions to problem, they all are described by process pattern. By solving problems a software team can construct a process that best meets needs of a project.
Uses of the process pattern:
At any level of abstraction, patterns can be defined. They can be used to describe a problem and solution associated with framework activity in some situations. While in other situations patterns can be used to describe a problem and solution associated with a complete process model.
- Pattern Name – Meaningful name must be given to a pattern within context of software process (e.g. Technical Reviews).
- Forces – The issues that make problem visible and may affect its solution also environment in which pattern is encountered.
It is of three types :
- Stage pattern – Problems associated with a framework activity for process are described by stage pattern. Establishing Communication might be an example of a staged pattern. This pattern would incorporate task pattern Requirements Gathering and others.
- Task-pattern – Problems associated with a software engineering action or work task and relevant to successful software engineering practice (e.g., Requirements Gathering is a task pattern) are defined by task-pattern.
- Phase pattern – Even when the overall flow of activities is iterative in nature, it defines sequence of framework activities that occurs within process. Spiral Model or Prototyping might be an example of a phase pattern.
Initial Context: Conditions under which the pattern applies are described by initial context. Prior to the initiation of the pattern :
- What organizational or term-related activities have already occurred?
- Entry state for the process?
- Software engineering information or project information already exists?
For example, the Planning pattern requires that :
- Collaborative communication has been established between customers and software engineers.
- Successful completion of a number of task patterns for the communication pattern has occurred.
- The project constraints, basic requirements, and the project scope are known.
Problem: Any specific problem is to be solved by pattern.
Solution: Describes how to implement pattern successfully. This section describes how initial state of process is modified as a consequence of initiation of pattern.
Resulting Context: Once the pattern has been successfully implemented, it describes conditions. Upon completion of pattern :
- Organizational or term-related activities must have occurred?
- What should be the exit state for the process?
- What software engineering information has been developed?
Related pattern: Provide a list of all process patterns that are directly related to this one. It can be represented n a hierarchy or in some other diagrammatic form.
Known uses and Examples: In which the pattern is applicable, it indicates the specific instances. For example, communication is mandatory at the beginning of every software project, is recommended throughout the software project, and is mandatory once the deployment activity is underway.
Example of Process Pattern:
Let’s see an example of a process pattern to understand it more clearly.
Pattern Name: Prototyping Model Design
Intent: Requirements are not clear. So aim is to make an model iteratively to solidify the exact requirements.
Type: Phase Pattern
Initial Context: Before going to the prototyping these basic conditions should be made
1. Stakeholder has some idea about their requirements i.e. what they exactly want
2. Communication medium should be established between stakeholder and software development team to ensure proper understanding about the requirements and future product
3. Initial understanding about other factors of project like scope of project, duration of project, budget of project etc.
Problem: Identifying and Solidifying the hazy and nonexistent requirements.
Solution: A description of the prototyping should be presented.
Resulting Context: A prototype model which can give a clear idea about the actual product and that needs to be agreed by stakeholder.
Related Patterns: Requirement extraction, Iterative design, customer communication, Iterative development, Customer assessment etc.
Known Uses & Examples: When stakeholder requirements are unclear and uncertain, prototyping is recommended.