Agenda: Proposing Bricked Estimation Method

Problem: There are plenty of estimation model available in Software industry. Many times we dont have clarity on estimation because of complexity and we end up using assumption based estimation, which does not work always. We need a road map to follow.

Solution: Simple and easy to understand, using combination of vast techniques to cover Software Development and Testing estimations.

Software Development and Testing Estimation based on Bricked Estimation Method. By: Ananda Pramanik, Bangalore, India

Introduction: Management is an art likewise Estimation is also an intelligent art frilled with mathematics. Estimation is done on Time and Cost. Often we start estimation without knowing the requirement specially in case of bidding phase and we land up with either wrong budget or effort. Very essential element of estimation is to correctly understand primary requirements before you intend to bid. Then work on estimation factors to arrive to a direction map. There are many estimation models available in IT industry even some for software development or some specific to software testing. This paper is focusing on Bricked Estimation Method thats scale the project/service or work package. As with any other estimating exercise, there is no "correct" answer. The sample solution presents Bricked Estimate Method based on one interpretation of the requirements and some reasonable estimating assumptions. It is pre-requisite to have some understanding of (WBS) Work Breakdown Structure, (FPA) Functional Point Analysis and SDLC (Software Development Life Cycle) before implementing below method. Proposed method stands on WBS, FPA and use of weighting factors, this drives through first development estimation then sets testing estimation. Dont worry; I have used small examples to explain my points. Proposed estimation drives through Development and testing estimation using simple example as explained below. Once the requirement is received in bundle, try to break those requirements in related individual components or module wise structure by identifying the major functional deliverables and further subdividing those deliverables into smaller functions. For Example: We need to provide estimation of effort on below project: There is an electric billing system available where residents can add or modify their address details. Residents can also add and modify meter details but not meter reading details. Electric Supply Company can search and view those records in their billing system. Here we need to work on first Modules Biller Sub level 1 Resident details Company Table: 1 Search Sub level 2 add details modify details Search function

Functional Requirements was the original objective behind the development of function points. It has been successfully used to evaluate size which can be derived from Function Points. Each Functional Point can fall in any one or more of parameter - Input types, Output types, Query types, Logical File types and External interface types. Then segregating function points as adjustable and non adjustable parameters. I have used below weighting factors:
Simple Input Output Query No. of logical files External interfaces 3 4 3 5 5 Average 4 5 4 8 7 Complex 6 7 6 10 9

Table: 2 Unadjustable functional points

Sub level 1 from WBS Residential Details Functional Point Analysis for Development Simple Average Input 2 1 Output 0 2 Query 3 0 No. of logical files 1 0 External interfaces 0 0 Simple Input Output Query No. of logical files External interfaces Sum of above Input Output Query No. of logical files External interfaces Sum Total 3 2 1 1 0 Simple 15 8 12 10 0 45 Average 0 0 1 0 0 Average 4 10 4 0 0 18

Complex 0 0 1 0 0 Complex 0 0 0 0 0 Complex 0 0 6 0 0 6

Search

69 Unadjustable functional points

Table: 3 Adjustable functional points

Complex internal processing Code reusability High performance Multiple sites Distributed process Total

3 1 1 2 0 7

Table: 4 Adjustable FP = Unadjustable FP * [0.65 + Adjustable FP * 0.01] = 69 * [0.65 + 7 * 0.01] = 69 * [0.72] = 49.68 = 49.7(round off) functional points

Assumption: 21 FPs can be handled by a developer in a month. i.e. 49.7 / 21 = 2.36 = 2.4 man months required to handle 49.7 functional points.

Interpretation: From above example typically one resource can work on design, code, review, unit test and execute in 2.4 months. 2.4 months equals 48 days so if more resources are involved then in short time frame the above work can be delivered. E.g. 3 resources can complete above task in 16 working days. In respect of dependent or non dependent task in parallel can minimize the number of days. Now, we will work on Testing Estimation. Below values for simple, average and complex are based on number of possible probability of test can be drawn, review and execute in 3 to 5 days of fashion for each functional point. Sometime 2 FPs can take less time and sometime 1FP can take more time but on an average table: 5 values will satisfy and fit most of the conditions. Hence we will treat below table as weighting factor for testing estimation. So we will multiple below mentioned values in table: 5 for each function point under respective category. I have continued above example to illustrate my views.
Simple 3 Average 4 Complex 5

Table: 5

Therefore, after calculating functional points from Table: 3 and multiplying values from table: 5
Sum of all FPs Input Output Query No. of logical files External interfaces Simple 15 6 12 6 0 Average 4 8 4 0 0 Complex 0 0 5 0 0

Sum Total

39

16

60 Unadjustable functional points

Table: 6 Unadjustable functional points for testing are 60. Adjustable functional points for testing
Complex Test Data Setup Generic test cases Dynamic Test Multiple Environments Total 2 1 1 2 6

Table: 7 Adjustable FP = Unadjustable FP * [0.65 + Adjustable FP * 0.01] = 60 * [0.65 + 6 * 0.01] = 60 * [0.71] = 42.6
Assumption: 23 FPs can be handled by a tester in a month. i.e. 42.6 / 23 = 1.85 = 1.9 man months required to handle 42.6 functional points.

Interpretation: From above example typically one resource can work on test design/test case writing, review, execution with 3 rounds of retesting cycles and delivered in 1.9 months. 1.9 months equals 38 days so if more resources get involved then in short time frame the above work can be delivered. E.g. 2 resources can complete above task in 19 working days. In respect of dependent or non dependent task in parallel can minimize the number of days. Apart from estimating through above method, it is also advisable to keep 25% more from above estimation for studying, planning and releasing activities and 20% extra as contingency. Overall method will provide only effort estimation which is just one element of the other few elements of complete estimation for bidding.