Software process is a collection of activities,actions and tasks. Each of these reside within a framework that defines the relationship among them.
Framework activities include communication, planning, modeling, construction and deployment. Each framework activity includes set of engineering actions and each action defines a set of tasks that incorporates work products, project milestones and software quality assurance (SQA) points that are required. Umbrella activities are carried throughout the process.="">
Process flow determines how activities, actions and tasks are arranged with respect to sequence and time.
Linear process flow: executes each activity in sequence.="">
Iterative process flow: repeats one or more activities before starting next.="">
Evolutionary process flow: carry out activities in a circular way.="">
Parallel process flow: execute one or more activities in parallel with each other.="">
Defining a framework activity
Consider communication activity. For small project, this can be defined as having tasks set:
- Making phone call with stakeholder
- Discuss requirements and note it down
- Organize requirements
- Mail stakeholder for review and approval
For large projects this may have extended actions such as feasibility study, elicitation of requirements, elaboration of requirements, specification documents, validation etc.
Identifying a task set
Task set is the actual work to be done to achieve an objective of engineering action. For small project, consider elicitation action in communication activity, this may include :
- Prepare list of stakeholders of the project
- Organize a meeting for stakeholders
- Discuss requirements
- Finalize requirements list
- Make a list of issues raised
For large projects extraneous steps may be added to elicitation such as interviewing each stakeholder separately before group meeting, more techniques are applied in discussing requirements…etc.
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 with 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 sequence of framework activities and ensures each sections 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 – List of patterns related to current one is documented for further reference.
- Known uses or examples – Indicates where or how the process pattern is applicable.
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 project determined.
Problem – recognized that stakeholder have a general idea of requirements and cannot place specific requirements.
Solution – prototyping can help the stakeholder to be more specific about requirements and hence prototype can be evolved.
Resulting context – a prototype fulfilling basic requirements is approved by stakeholder and the prototype may be evolved or thrown for making a new one which will become the finished product.
Related patterns – customer communication , iterative design , requirement extraction.
Known uses/examples – unclear requirements problem can be solved through prototyping.