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 that’s 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. Don’t worry; I have used small examples to explain my points. Proposed estimation drives through Development and testing estimation. Thanks, Ananda Pramanik

1. Agenda: Proposing Bricked Estimation Method
Problem: There are plenty of estimation model available in Software
industry. Many times we don’t 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

2. 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 that’s 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. Don’t
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 Sub level 1 Sub level 2
Biller
Resident details add details
modify details
Company Search Search function
Table: 1

3. 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 Average Complex
Input 3 4 6
Output 4 5 7
Query 3 4 6
No. of logical files 5 8 10
External interfaces 5 7 9
Table: 2
Unadjustable functional points –
Sub level 1 from WBS Functional Point Analysis for Development
Residential Details Simple Average Complex
Input 2 1 0
Output 0 2 0
Query 3 0 1
No. of logical files 1 0 0
External interfaces 0 0 0
Search Simple Average Complex
Input 3 0 0
Output 2 0 0
Query 1 1 0
No. of logical files 1 0 0
External interfaces 0 0 0
Sum of above Simple Average Complex
Input 15 4 0
Output 8 10 0
Query 12 4 6
No. of logical files 10 0 0
External interfaces 0 0 0
Sum 45 18 6
Total 69 Unadjustable functional points
Table: 3
Adjustable functional points –

4. Complex internal processing 3
Code reusability 1
High performance 1
Multiple sites 2
Distributed process 0
Total 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 Average Complex
3 4 5
Table: 5
Therefore, after calculating functional points from Table: 3 and multiplying values from
table: 5
Sum of all FPs Simple Average Complex
Input 15 4 0
Output 6 8 0
Query 12 4 5
No. of logical files 6 0 0
External interfaces 0 0 0

5. Sum 39 16 5
Total 60 Unadjustable functional points
Table: 6
Unadjustable functional points for testing are 60.
Adjustable functional points for testing –
Complex Test Data Setup 2
Generic test cases 1
Dynamic Test 1
Multiple Environments 2
Total 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.