Activity Identification approaches in Software Engineering

In software engineering, we mostly have very complex and big scale projects to deal with. These complex and big scale projects are divided into simpler, manageable, independent and small tasks which are called as activities.

There are 3 most common approaches or methods for the identification of activities in any software project:

1. Activity based approach:
   It consists of creating a list of all the activities that the project is supposed to involve in its life cycle. It can be done by using a brainstorming process which includes the complete project team and analyzing of the past projects. Work Breakdown Structure (WBS) is created for the same purpose. It involves dividing a complex and big scale project into simpler, manageable, independent and smaller tasks which can be completed in approximately few weeks by a single development team working on the project.

   The root of the project tree is labelled by the project name itself. Each node (activity) is recursively decomposed and divided into smaller sub-activities, until at the leaf level, the activities require approximately two weeks to develop and can be given to a single development team. It follows top-down approach.

2. Product based approach:
   It consists of producing a Product Breakdown Structure and a Product Flow Diagram. A product based structure is very much similar to the work breakdown structure which includes dividing a complex and big scale product into its sub set products until simple, manageable, independent and smaller products are obtained at the leaf level. The Product Breakdown Structure is constructed prior to the Work Breakdown Structure and it focuses on generating an ordered list of all the sub products required to successfully complete the project.

   This generated structure helps in the creation of the Work Breakdown Structure, which in turn helps in the identification of the activities required to produce the required sub products. There is a very less probability that a product will be left out in a product breakdown structure than that an activity might be left out of a work breakdown structure.

3. Hybrid approach:
   In this approach, an alternative work breakdown structure is constructed based on:
   • A simple list of final deliverable.
   • For each deliverable, a set of activities required to produce that product.

   
   
   The main problem with the purely activity based work breakdown structure is after identifying all the activities, the task of sequencing them in proper order is always left out. Hence, hybrid approach gives us a modified version of the Work Breakdown Structure which includes some of the important properties of the Product Breakdown Structure and as it includes the important properties of both the approaches, it overcomes the disadvantages of both of them.

IBM (International Business Machines Corporation) recommends that the following 5 levels should be used in the work breakdown structure:

• Level-1: Project:
  It includes the actual project that software development team wants to develop after completion of the complete software development life cycle. This is the main objective and output of the whole development process and hence, must be defined in a detailed manner.
• Level-2: Deliverable:
  These are the sub-products which are generated after every milestone like Software Requirement Specification (SRS), Software Design Document (SDD), etc. These also helps to analyze the project progress at every milestone achieved.
• Level-3: Components:
  These are the key items required to produce the deliverable during the project development life cycle as modules and tests to produce system software.
• Level-4: Work-packages:
  These are the major items or collection of tasks required to produce a component which in turn acts as the basis of building the deliverables afterwards.
• Level-5: Tasks:
  These are the ones which are meant to be assigned to a single person/ team for its completion and are the basic building blocks of a project.