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

Size: px

Start display at page:

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

Gwenda Daniel
8 years ago
Views:

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

work always. We need a road map to follow.

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

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.

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 Output Query No. of logical files External interfaces Table: 2 Unadjustable functional points Sub level 1 from WBS Functional Point Analysis for Development Residential Details Simple Average Complex Input Output Query No. of logical files Search Simple Average Complex Input Output Query No. of logical files Sum of above Simple Average Complex Input Output Query No. of logical files Sum Total Table: 3 69 Unadjustable functional points Adjustable functional points

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.

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 * [ Adjustable FP * 0.01] = 69 * [ * 0.01] = 69 * [0.72] = = 49.7(round off) functional points Assumption: 21 FPs can be handled by a developer in a month. i.e / 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 Table: 5 Therefore, after calculating functional points from Table: 3 and multiplying values from table: 5 Sum of all FPs Simple Average Complex Input Output Query No. of logical files 6 0 0

7 functional points. Interpretation: From above example typically one resource can work on design, code, review, unit test and execute in 2.

5 Sum Total Table: 6 60 Unadjustable functional points 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 * [ Adjustable FP * 0.01] = 60 * [ * 0.01] = 60 * [0.71] = 42.6 Assumption: 23 FPs can be handled by a tester in a month. i.e / 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.

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.

Software Estimation Techniques - Common Test Estimation Techniques used in SDLC

Software Estimation Techniques - Common Test Estimation Techniques used in SDLC In order to successful software project & proper execution of task, the Estimation Techniques plays vital role in software