Decomposition Techniques in Software Project Planning

Creating a cost and effort estimate for a software project is an example of a problem that can be handled, and most of the time the problem is too complicated to handle in one sitting. Because of this, we break down the issue and reframe it as a collection of more manageable, lesser issues. Before generating an estimate, the project planner needs to comprehend the software’s scope and determine its approximate “size.”

The decomposition approach was discussed in two different ways –

• Decomposition of the problem
• Decomposition of the process

Estimation uses one or both forms of partitioning.

Software Sizing:

A software project’s estimate’s accuracy depends on several factors:

•  how well the planner estimated the size of the product to be built;
• how well the planner translated the size estimate into human effort, calendar time, and money (a function of the availability of trustworthy software metrics from previous projects);
• how well the project plan reflected the skills of the software team; and
• how stable the product requirements and the environment supporting the software engineering effort were.

Size is the first significant obstacle a project planner must overcome because the project estimate is only as good as the estimate of the amount of work to be completed. Size in the context of project planning refers to a software project’s measurable output. It is possible to assess size in LOC if a direct approach is used. If an indirect method is selected, the size is shown as FP.

Sizing Problem:

The sizing problem can be approached in four ways:

“Fuzzy logic” sizing:

This method makes use of the approximation reasoning strategies that are the basis of fuzzy logic. To use this method, the planner must first choose the kind of application, then quantify its size using a qualitative scale, and finally fine-tune the size within the initial range. The planner should have access to a historical database of projects to compare projections to real experience, even though personal experience might be employed.

Function point sizing:

The information domain is estimated by the planner. We’ll talk about its features later in the session.

Sizing of standard components:

Software is made up of several “standard components” that are universal to a given application domain. For instance, subsystems, modules, displays, reports, interactive programs, batch programs, files, LOC, and object-level instructions are typical parts of an information system. After estimating how often each standard component will occur, the project planner analyses past project data to calculate the delivered size for each standard component. Take an information systems application as an example. The planner predicts that eighteen reports will be produced. According to historical data, each report requires 967 lines of COBOL [PUT92]. This allows the planner to project that the reports component will take 17,000 LOC. Other standard components are estimated and computed similarly, yielding an adjusted statistical combined size value.

Change sizing:

This strategy is applied when a project calls for the use of pre-existing software that needs to be changed to complete the project. The planner estimates the quantity and kind of changes that need to be made (such as adding, removing, altering, and reusing code). For every kind of change, the “effort ratio” [PUT92] can be used to estimate the change’s size.