Your SlideShare is downloading. ×
White Paper- Bricked Estimation Method
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

White Paper- Bricked Estimation Method

362
views

Published on

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 …

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

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
362
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Agenda: Proposing Bricked Estimation MethodProblem: There are plenty of estimation model available in Softwareindustry. Many times we don’t have clarity on estimation because ofcomplexity and we end up using assumption based estimation, whichdoes not work always. We need a road map to follow.Solution: Simple and easy to understand, using combination of vasttechniques to cover Software Development and Testing estimations.Software Development and Testing Estimation based on BrickedEstimation 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 therequirement specially in case of bidding phase and we land up with either wrong budget oreffort. Very essential element of estimation is to correctly understand primary requirementsbefore 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 softwaredevelopment or some specific to software testing. This paper is focusing on Bricked EstimationMethod 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 onone 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) beforeimplementing below method. Proposed method stands on WBS, FPA and use of weightingfactors, this drives through first development estimation then sets testing estimation. Don’tworry; I have used small examples to explain my points. Proposed estimation drives throughDevelopment and testing estimation using simple example as explained below. Once the requirement is received in bundle, try to break those requirements in relatedindividual components or module wise structure by identifying the major functionaldeliverables 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. EachFunctional Point can fall in any one or more of parameter - Input types, Output types, Querytypes, Logical File types and External interface types. Then segregating function points asadjustable 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 testand execute in 2.4 months. 2.4 months equals 48 days so if more resources are involved then in shorttime frame the above work can be delivered. E.g. 3 resources can complete above task in 16 workingdays. 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 onnumber of possible probability of test can be drawn, review and execute in 3 to 5 days of fashion foreach functional point. Sometime 2 FPs can take less time and sometime 1FP can take more time but onan average table: 5 values will satisfy and fit most of the conditions. Hence we will treat below table asweighting factor for testing estimation. So we will multiple below mentioned values in table: 5 for eachfunction 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 38days so if more resources get involved then in short time frame the above work can be delivered. E.g. 2resources can complete above task in 19 working days. In respect of dependent or non dependent taskin parallel can minimize the number of days.Apart from estimating through above method, it is also advisable to keep 25% more from aboveestimation for studying, planning and releasing activities and 20% extra as contingency. Overall methodwill provide only effort estimation which is just one element of the other few elements of completeestimation for bidding.

×