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:
- 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.
- 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.
- 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.
Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.
- Software Engineering | Debugging Approaches
- Software Engineering | Introduction to Software Engineering
- Prototyping Approaches in Software Process
- Short Note on Activity and Swimlane Diagram
- Software Engineering | Requirements Engineering Process
- Software Engineering | Re-engineering
- Software Engineering | Reverse Engineering
- Difference between Software Engineering process and Conventional Engineering Processs
- Various Approaches of Partitioning
- Various Approaches to Functional Testing
- Types of RCM Approaches
- Difference between Forward Engineering and Reverse Engineering
- Software Engineering | Halstead’s Software Metrics
- Software Engineering | Classification of Software Requirements
- Software Engineering | Classification of Software
- Software Engineering | Software Project Management Complexities
- Software Engineering | Role and Responsibilities of a software Project Manager
- Software Engineering | Seven Principles of software testing
- Software Engineering | Agile Software Development
- Software Engineering | Software Maintenance
If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to firstname.lastname@example.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.
Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.