Generic process model – framework activity, task set, process patterns

Software Process

The software process comprises activities performed to create a software product. It deals with the technical and management aspects of software development.

Software process includes :

  • Tasks – focus on a small, specific objective.
  • Action – set of tasks that produce a major work product.
  • Activities – group of related tasks and actions for a major objective.
generic process model 6 2

A process framework for software engineering defines five framework activities. Framework activities include communication, planning, modelling, construction and deployment. Each framework activity includes a 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 Framework Activities

  • Communication – Communicate with stakeholders and customers to obtain objectives of the system and requirements for the software.
  • Planning – Software project plan has details of resources needed, tasks and risk factors likely to occur, schedule.
  • Modelling – Architectural models and design to better understand the problem and for work towards the best solution.
  • Construction – Generation of code and testing of the system to rectify errors and ensuring all specified requirements are met.
  • Deployment – Entire software product or partially completed product is delivered to the customer for evaluation and feedback.

Umbrella activities

Activities that occur throughout a software process for better management and tracking of the project.

  • Software project tracking and control – Compare the progress of the project with the plan and take steps to maintain a planned schedule.
  • Risk management – Evaluate risks that can affect the outcome and quality of the software product.
  • Software quality assurance (SQA) – Conduct activities to ensure the quality of the product.
  • Technical reviews – Assessment of errors and correction done at each stage of activity.
  • Measurement – All the measurements of the project and product features.
  • Software configuration management (SCM) – Controlling and tracking changes in the software.
  • Reusability management – Back up work products for reuse and apply the mechanism to achieve reusable software components.
  • Work product preparation and production – Project planning and other activities used to create work product are documented.

Process flow

Process flow determines how activities, actions and tasks are arranged with respect to sequence and time.

Linear process flow

Linear process flow executes each activity in sequence.

linear process flow

Iterative process flow

Iterative process flow repeats one or more activities before starting next.

iterative process flow

Evolutionary process flow

Evolutionary process flow carry out activities in a circular way.

evolutionary process model

Parallel process flow

Parallel process flow execute one or more activities in parallel with each other.

parallel process flow

Defining a framework activity

Consider communication activity. For small project, this can be defined as having tasks set:

  • Making a phone call with stakeholder.
  • Discuss requirements and note them 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 a 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 the group meeting, more techniques are applied in discussing requirements…etc.

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.
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.

Advertisements
Advertisements
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments