1 / 58

SOFTWARE ESTIMATION LECTURE NOTES 4

SOFTWARE ESTIMATION LECTURE NOTES 4. SOFTWARE ESTIMATION. Software Project Management begins with a set of activities that are collectively called Project Planning. Software Project Planning encompasses Five major activities : 1. Project Estimation 2. Project Scheduling

aspen
Télécharger la présentation

SOFTWARE ESTIMATION LECTURE NOTES 4

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SOFTWARE ESTIMATIONLECTURE NOTES 4

  2. SOFTWARE ESTIMATION Software Project Management begins with a set of activities that are collectively called Project Planning. Software Project Planning encompasses Five major activities: 1. Project Estimation 2. Project Scheduling 3. Risk Analysis 4. Quality management Planning 5. Change Management Planning ESTIMATION Software Project Management begins with a set of activities that are collectively called Project Planning. Before a Project begins Project Manager must Estimate - The Work to be done - The Resources that will be required. - The Time that will be “elapsed” from start to finish.

  3. SOFTWARE ESTIMATION The Software Team must establish a Project Schedule that defines :- a) Software Engineering tasksb) Milestones, c) Responsible for conducting each task, d) Inter-task dependencies. . Estimation lays a foundation for all other Project Planning activities and that Project Planning provides the “ROAD MAP” for successful Software Engineering.

  4. SOFTWARE ESTIMATION Estimation is as much ‘’Art’’ as it is Science. However this important activity need not be conducted in a haphazard manner. Software Estimation begins with a description of the “SCOPE OF SOFTWARE PRODUCT”. Until the Scope is “Bounded” it is not possible to develop a meaningful Project Estimate. The ‘’PROBLEM’’ is then decomposed into a set of smaller Problems and each of these is Estimated using historical data (Metrics) and/or previous experience as a guide. The Problem Complexity and Risk are then considered before final Estimate is made.

  5. SOFTWARE ESTIMATION Estimation of Recourses, Cost and Schedule for a Software Engineering Effort requires:- - Experience, - Access to good historical information (Project Metrics) - Courage to commit to Quantitative predictions (when Quantitative information is all that exists).Estimation carries inherent “RISK”, and this Risk leads to uncertainty.The availability of Historical Information (Project Metrics) has a strong influence on Estimation Risk. Estimation Risk is measured by the degree of uncertainty in the Quantitative Estimates establish for Recourses, Cost and Project Schedule. Estimation Risk becomes dangerously high when Project Scope is poorly understood or Project Requirements are subject to changes.

  6. SOFTWARE ESTIMATION SOFTWARE SCOPE AND FEASIBILITY Software Scope Describes: - The function and features that are to be delivered to end-users. - The data that are input and output. - The “Content” that is presented to user as a consequence of using the software. - Performance, constraints, reliability and interfaces that bounds the system. Software Scope is defined using one of the following techniques: - A narrative description of software scope is developed after communication with all stakeholders. - A set of Use-Cases are developed by end-users.

  7. SOFTWARE ESTIMATION SCOPE CONSIDERATIONFunctions described in the “Statement of Scope” or within the Use-Cases are evaluated and in some cases refined to provide more detail point to the beginning of Estimation. Because both Cost and Schedule Estimates are functionally oriented, some degree of functional decomposition is useful. Performance considerations encompass Processing and Response Time requirements. Constraints identify limits placed on the software by hardware, available memory size on other existing system.

  8. SOFTWARE ESTIMATION SCOPE CONSIDERATIONOnce the Project Scope has been identified it is reasonable to ask yourself:- - Can we build the Software to meet this scope? - Is the Project feasible? Often Software Engineers rush past these questions only to become mired (become stuck) in a Project that is doomed from the onset. Since not everything in real life is feasible, the Software Feasibility is emphasized in Estimation. Software Feasibility has four solid dimensions: - Technology - Finance - Time - Resources

  9. SOFTWARE ESTIMATION SOFTWARE SCOPE AND FEASIBILITYOnce the Software Scope and Feasibility have been identified the second task is Estimation of the “RESOURCES” required to accomplish the Software Development Effort. RESOURCES The three major categories of Software Engineering Resources: - People - Reusable software components. - Development environment (H/W, S/W Tools) Each Resources is specified with four Characteristics: - Description of the resource. - A statement of availability. - Time when resources will be required. - Duration of the time that resource will be applied. NOTE: The last two characteristics can be viewed as a “Time Window”. Availability of the Resource for a specified window must be established at the earliest practical time.

  10. 1.HUMAN RESOURCES - The Project Planner begins by evaluating Software Scope and selecting the ‘’skills’’ required to complete development. Both Organizational position (e.g. Manager, Senior Software Engineer etc and the specialty (e.g Database Telecommunication, client/server etc) and the Location of each human resource is specified. - The Number of People required for a Software Project can be determined only after an Estimate of Development Effort (e.g. Person-months) is made. SOFTWARE ESTIMATION

  11. 2. REUSABLE SOFTWARE RESOURCES • The Reusable Software Resource categories:-1. OFF-THE-SHELF COMPONENTS • 2. FULL-EXPERIENCE COMPONENTS 3. PARTIAL-EXPERINECE COMPONENTS 4. NEW COMPONENTS: • Guidelines for Planning Reusable Resource Components :- • 1. If Off-the-Shelf Components meet Project requirement acquire them. The cost of the off-the-shelf components will almost always be less than the cost to develop equivalent software. Also risk is low. • If full-experience components are available, the risk associated with modification and integration are generally acceptable. • If Partial-Experience Components are available, the use of them for current Project must be carefully analyzed. - If extensive modification is required proceed carefully since the cost to modification can sometimes be greater than the cost to develop newcomponents also Risk is high. SOFTWARE ESTIMATION

  12. 3. ENVIRONMENTAL RESOURCES The Software Engineering Environment (SEE) corporate Hardware and Software / NetWare. H/W provides a platform that support the tools required to produce Work Products that are outcome of good Software Engineering practice.When a System is to be engineered the Software team may require access to H/W elements being developed by other Engineering teams. Software Project Planner must specify each Hardware element and the Time window for HW / SW and verify that these resources will be available. SOFTWARE ESTIMATION

  13. SOFTWARE PROJECT ESTIMATION Software is the most expensive element of virtually all Computer-Based System.For complex, custom System, a large Cost Estimation error can make the difference between profit and loss. Cost overrun can be disastrous. Software Cost and Effort Estimation will never be an exact science. Because too many Variables Factors can affect the ultimate Cost of Software and Effort applied to develop it. Variable Project Factors: - Human Factor - Technical Variable Factors - Environmental Factors - Political Factors SOFTWARE ESTIMATION

  14. OPTIONS FOR RELIABLE ESTIMATESa) Delay Estimation until late in the Project (obviously we can achieve 100% accurate Estimates after the Project is complete!) b) Base Estimates on similar Projects that have already been completed. c) Use one or more Empirical Models for Software cost and Effort Estimation. d) Use relatively simple Decomposition Techniques to generate Project Cost and Effort Estimates.Each of the viable Software Cost Estimation options are only as good as the Historical data used to seed the estimation. If no Historical data (metrics) exist, costing rest on a very shaky foundations. SOFTWARE ESTIMATION

  15. DECOMPOSITION TECHNIQUES Software Project Estimation is a form of Problem solving, and in most cases, the Problem to be solved is too complex in one piece. For this reason, we Decompose the problem, re-characterizing it as a set of smaller problems.Estimation uses one or both form of the two different partitioning point of views:- - Decomposition of the Problem - Decomposition of the Process Before an Estimate can be made , the Project Planner must understand the Scope of the Software to be built and generate an Estimate according to the ‘’Size of Software’’. SOFTWARE ESTIMATION

  16. SOFTWARE PROJECT SIZING: • Accuracy of a Software Project Estimate is predicted on a number of things: • 1. The degree to which the Planner has properly Estimated the Size of the Product to be built.2. The ability to translate the Size Estimate into Human-effort (Calendar Time and Money)3. The degree to which the Project Plan reflects the abilities of Software team.4. The stability of Product requirement s and the environment that supports the Software Engineering effort. • Sizing represents the Project Planner’s first major challenge since a Project Estimate is only as good as the Estimate of the Size of the work to be accomplished • Size refers to a Quantifiable outcome of the Software Project. • - If a Direct approach to Sizing is taken size can be measured in (LOC) • - If an Indirect approach is taken that the sizing approach is represented as FP SOFTWARE ESTIMATION

  17. SOFTWARE PROJECT SIZING: • There are Four Different Sizing Approaches: • 1. Fuzzy Logic Sizing • 2. Function Point Sizing • 3. Standard Component Sizing • 4. Change Sizing • The result of each Sizing approaches must be combined statistically to createExpected-Value Estimate.” This is accomplished by determining the following values for- • - Optimistic (Sopt) (Lowest estimation value) • - Most Likely (Sm) (Moderate estimation value) • - Pessimistic (Spess) (High estimation value) • Combine the Value Sizes using the following Equation to determine the Expected Value EstimationS =[(Sopt + (4 * Sm) + Spess)] / 6 -Once the Expected Value for the Estimation variable has been determined, Historical (LOC) or (FP) Productivity data are applied. SOFTWARE ESTIMATION

  18. PROBLEM – BASED ESTIMATION TECHNIQUES • LOC and FP data are used in two ways during Software Estimation. • As an Estimation variable to “Size” each element of Software. • As a Baseline Metrics collected from past project and used in conjunction with estimation variable to develop cost and effort projections. • LOC and FP Estimations are different Estimation techniques. Yet both have number of characteristics in common. SOFTWARE ESTIMATION

  19. PROBLEM – BASED ESTIMATION TECHNIQUES • The Project Planner begins with a bounded Statement of Software Scope and from this Statement attempts to Decompose Software problem Functions that can be Estimated individually. - (LOC) or (FP) is then estimated for each Function. • - Baseline Productively Metrics are then applied to the appropriate Estimation Variable and Cost or Effort for the Function is derived. Function Estimates are combined to produce an overall • Estimate for the entire Project. SOFTWARE ESTIMATION

  20. PROBLEM – BASED ESTIMATION TECHNIQUES The (LOC) and (FP) Estimation Techniques differ in the level of detail required for Decomposition and the target of partitioning. When (LOC) is used as the Estimation variable Decomposition is absolutely essential and often taken to considerable levels of detail. For (FP) Estimation, Decomposition works differently. Besides focusing on each Function’s Information Domain characteristics it also takes into consideration the Complexity Adjustment Factor values. - SOFTWARE ESTIMATION

  21. PROBLEM – BASED ESTIMATION TECHNIQUES Regardless of Estimation variable that is used the Project Planner begins by Estimating a range of Values for each Function or Information domain value. Using Historical data or intuition, the Planner Estimates ‘’Expected Value’’ considering the following variables: Optimistic Value, Most Likely Value Pessimistic Value Once the Expected Value has been determined, Historical (LOC) and (FP) Productivity data are applied. SOFTWARE ESTIMATION S = [Opt value + (4 * Most Likely) + Pess value] / 6

  22. PROBLEM – BASED ESTIMATION TECHNIQUESAN EXAMPLE OF (LOC) BASED ESTIMATION FUNCTIONSESTIMATED LOC - User Interface and Control Facilities (UICF) 2,300 - Two Dimensional Analysis (2DGA) 5.300 - 3D Geometric Analysis Function (3DGA) 6,800 *** - Database Management (DBM) 3,350 - Computer Graphic Display facility (CGDF) 4,950 - Peripheral Control Function (PCF) 2,100 - Design Analysis Modules DAM) 8.400 __________________________________________________________________ TOTAL ESTIMATED LOC ( ∑ LOC ) 33.200========================================================== SOFTWARE ESTIMATION For Example:- Using the Expected Value Equation we can calculate the Estimated Value for (3DGA) Function as follows:- Optimistic Estimation = 5,000 LOC Most Likely Estimation = 6,700 LOC Pessimistic Estimation = 9.000 LOC S = [Opt value + (4 * Most Likely) + Pess value] / 6 S = [5000 + ( 4 * 6,700) + 9,000] / 6  6,800

  23. AN EXAMPLE OF (LOC) BASED ESTIMATION • Historical data obtained from the Metrics indicates the following Organizational Averages: • Average Productivity is 620 LOC / Pm (Lines of Code Per Month) • Average Labor Cost is $8,000 Per month. • Cost for a Line of Code can be calculated as follows (COST / LOC) • COST / LOC = (8000 / 620) = $13 Total Estimated Project Cost and Project Effort can be calculated as: follows- • Considering that the Total LOC ( ∑ LOC) for the System is 33,200 :- • Total Estimated Project Cost = (33200 * 13 ) = $431,600 • Total Estimated Project Effort = (33200 / 620) =~ 54 Man Months SOFTWARE ESTIMATION

  24. AN EXAMPLE OF FUNCTION POINT (FP-BASED) ESTIMATION • For this example we assume Average Complexity Weighting Factor. • Each of the Complexity Weighting Factor is estimated and the Complexity Adjustment Factor is computed using the Complexity Factor Table as shown on the next page • Expected Value is calculated for each Information Domain using :- • S = [Opt value + (4 * Most Likely) + Pess value] / 6 SOFTWARE ESTIMATION

  25. AN EXAMPLE OF FUNCTION POINT (FP-BASED) ESTIMATION • COMPLEXITY FACTOR ASSUMPTIONS (Based on the Answers for 14 Questions) • FACTORVALUE (Fi) ------------------------------------------------------------------ • 1. Back-up and Recovery ? 4 • 2. Data Communication ? 2 • 3. Distributed Processing ? 0 • 4. Performance Critical ? 4 • 5. Existing Operational Environment ? 3 • 6. On-line Data Entry ? 4 • 7. Input transactions over multiple Screens? 5 • 8. Online Updates ? 3 • 9. Information Domain Values Complex ? 5 • 10. Internal Processing Complex? 5 • 11 Code Designed for reuse? 4 • 12. Conversion / installation in Design? 3 • 13. Multiple Installations? 5 • 14. Application Designed for change ? 5 • =========================================== • ∑ (Fi) 52Estimated Number of Adjusted FP is derived using the following Formula:-FP ESTIMATED=(FP COUNT TOTAL * [COMPLEXITY ADJUSTMENT FACTOR] • Complexity Adjustment Factor is [0.65+ (0.01*∑(Fi))] • Complexity Adjustment Factor= [0.65 + (0.01 * 52)] = 1.17 • ESTIMATED FP COUNT = (320 * 1.17) = 375 SOFTWARE ESTIMATION

  26. AN EXAMPLE OF (FP) BASED ESTIMATION • Historical data obtained from the Metrics indicates the following Organizational Averages:- • - Average Productivity for this type of Application is 6.5 FP / Per Month - Average Labor Cost is $8,000 Per Month. • Cost for a Function Point (COST / FP ) is calculated as followsCost / FP = (8000 / 6.5) = $1230 (Cost for 1 FP) • Total Estimated Project Cost and Project Effort can be calculated as:- • Considering that the Total Adjusted FP ( ∑ FP) is 375 FP :- • Total Estimated Project Cost =(375 * 1230) = $461,000 • Total Estimated Project Effort =(375 / 6.5) =~ 58 Man Months SOFTWARE ESTIMATION

  27. AN EXAMPLE OF PROCESS-BASED ESTIMATION • Notes: CC = Customer Communication CE = Customer Evaluation • Based on Average Labor cost of $8,000 Per month - Total Estimated Project Effort = 46 Person - Month • - Total Estimated Project Cost = (8,000 * 46) = $368,000 SOFTWARE ESTIMATION

  28. ESTIMATION WITH USE-CASES • Developing an Estimation approach with Use-Casesis problematic for the • following reasons:- • Use-cases are described using many differentformats and styles;there isno standard form. • Use-cases represent an external view (User’s view)of the Software and are written at different levelsof abstracttion. • Use-cases do not address the complexity of the functions andfeatures that are described. • Use-cases do not describe complex behavior (e.g interactions)that involves many functions and features. However, Use-cases can be used for Estimation, but only if they are considered within the context of the ‘’Structured Hierarch’’ that the Use- cases are described. SOFTWARE ESTIMATION

  29. ESTIMATION WITH USE-CASES It is argued that any level of Use-case Structural Hierarchy :- a) Can be described by no more than 10 Use-cases. b) EachUse-case would contain no more than 30 distinct Scenarios. (obviously more Scenarios require considerably more developmentefforts.) Before Use-cases can be used for Estimation:-a) The Level within the Structural Hierarchy is established, b) The Average Length (in pages) of each Use-case is determined, c) Type of Software is defined (eg. Real time, Business, Engineering /Scientific, etc)d) Rough architecture for the System is considered Once these characteristics are established, Emperical Data may be used to establish the Estimated number of LOC or FP per Use-case (for each level of hierarchy). The Structured Hierarchical data then used to compute the Effort required to develop the System. SOFTWARE ESTIMATION

  30. ESTIMATION WITH USE-CASES LOC estimates = N * LOCavg + [(Sa / Sh - 1) + (Pa / Ph - 1)] * LOCadjust Where: N = Actual number of Use-cases LOC avg = Historical Average LOC / Use-case for this type Subsystem LOC adjust = Adjustment based on ‘n %’ of LOCavg n = Defined locally and represents the difference between thisProject and the ‘Average’ Project Sa = Actual Scenarios per Use-case Sh = Average Scenarios per Use-case for this type Subsystem Pa = Actual Pages per Use-case Ph = Average Pages per Use-case for this type of Subsystem The above expression is used to develop a rough Estimation of the Number of LOC, based on the Actual number of Use-cases Adjusted by the number of Scenarios and Page length of the Use-cases. The Adjustment represents up to ‘n %’ of the Historical Average LOC per Use-case. SOFTWARE ESTIMATION

  31. AN EXAMPLE OF USE-CASE BASED ESTIMATION • Consider the CAD Software example again for Use-case • Estimation purpose. • CAD Software is composed of three Subsystem groups:- • User Interface Subsystem includes (UICF) • Engineering Subsystem group includes the (2DGA) (3DGA) and (DAM) Subsystems. • Infrastructure Subsystem group includes (CGDF) andPCF Subsystems) SOFTWARE ESTIMATION

  32. AN EXAMPLE OF USE-CASE BASED ESTIMATION • User Interface Subsystem (UICF). • - Described with 6 Use-cases - Each Use-case is described by no more than 10 Scenarios • - Each Use-case has an average of 6 Pages • Engineering Subsystem (2DG, 3DG, DAM) • - Described with 10 Use-cases • - Each Use-case has no more than 20 Scenarios • - Each use case has an average of 8 Pages • Infrastructure Subsystem group (CGDF, PCF) • - Described with 5 Use-cases • - Each use-case has an average of 6 Scenarios- Each Use-case has an average of 5 Pages SOFTWARE ESTIMATION

  33. Based on n = 30% Difference the following tabe is created for USE-CASE Based Estimation SOFTWARE ESTIMATION

  34. USE CASE BASED ESTIMATION • Let us consider the calculations for User Interface Subsystem based on 30% difference between • this project and Actual Project (n = 30%) • Historical data obtained from Metrics indicates that User Interface Software requires:- • An Average (LOC avg)of 800 LOC per Use-case when the Use-case has no morethan12 Scenarios and described in less than 5 Pages. - LOC avg = 800 • When considering 30% Differences between this Project and Average Projects • LOC Adj = (800 * 0.30) = 560 Using the formulae below we can calculate LOC Estimates for each Subsystem group • LOC Estimates = N * LOC avg + [(Sa / Sh - 1) + (Pa / Ph - 1)] * LOC adjust • Historical data from Metrics indicates the following Averages- Average Productivity rate 620 LOC / Month • - Average Salary of $8000 Per month, • Total Project Cost and Total Development Effort can be calculated as follows: • - Cost / LOC = (8000 / 620) =$13 (Cost for 1 LOC) • - Total Project Estimates = (42,568 * 13) = $552,000 • - Total Development effort = (42,568 / 620 ) =68 Person- Months SOFTWARE ESTIMATION

  35. RECONCILING ESTIMATES • The Problem Based Estimation Techniques dicussed so far each gave different • Cost and Effort Estimate results which must be reconciled to produce a single • Estimate of Effort, Project Durationor Cost. • Examination of the four different Problem-Based Estimation techniques • indicate different Total Estimated Efforts for the CAD Software range from : • 46 Person-monthsto a high of 68 Person-months • The Average Estimate Of Efforts is 56 Person-months. • The variation from Average estimate is approximately 18% on the low side and 21% on the high side. SOFTWARE ESTIMATION

  36. RECONCILING ESTIMATES What Happens When Agreement Between Estimates is poor? The answer to this question requires a re-evoluation of information used tomake the Estimates. Wedely divergent Estimate can often be traced to one of the two causes. 1. The Scope of the Project is not adequately understood or has been misinterpreted by the Project planner. 2. Productivity data used for Problem-Base Estimation Techniques is inappropriate for the Application. Productivity Data is either obsolute (no longer accuratelyreflects theSoftware Engineering Organization) ,or has been misapplied. The Project Planner must determine the cause of divergence and then reconcile the Estimates. SOFTWARE ESTIMATION

  37. EMPIRICAL ESTIMATION MODELS • An Estimation model for Computer Software uses Empirically derivedformulas to • predict Effort as a Function of LOC or FP. • Values for LOC and FP are estimated using LOC based Estimations and FP Based • Estimations. • The resultant Values out of these Estimation are plugged into the Estimation Model. • The Empirical data that support most Estimation Models are derived from a • limited sample of Projects. For this reason, no Estimation Model is appropriate for all • Classes of Software and in all Development Environments. • Therefore, the resultsobtained from such Models must be used judiciously. • An Estimation Model should be calibrated to reflect local conditions. • The Estimation Model should be tested by applying data collected from completed • projects, plugging the data into model, and then comparing Actual to Predicted results. • If aggrement is poor the Estimation Model must be tuned and reflected before it can be used. SOFTWARE ESTIMATION

  38. THE STRUCTURE OF ESTIMATION MODEL A typical Estimation Model is derived using Regression Analysis on data collected from past Software Projects. The overall structure of such Model takes the from of :c E = A + B * (ev) Where: A, B and c are Emperically derived constant. E is Effort in Person-Months(ev) is the Estimation Variable either LOC or FP) In addition the relationship noted in the above equation , the majority of Estimation Models have some from of Project Adjustment Components that enables Effort in Person Months (E) to be Adjusted by other Projects Characteristic such as Problem Complexity, Staff experience, and Development environment). SOFTWARE ESTIMATION

  39. PROPOSEDLOC-ORIENTED ESTIMATION MODELS0.91 WALSTON-FELIX MODEL E=5.2*(KLOC) 1.16 BAILEY-BASILI MODEL E=5.5+0.73(KLOC) 1.05 BOEHM SIMPLE MODEL E=3.2*(KLOC) 1.047 DOTY MODEL FOR E=5.288*(KLOC) ---------------------------------------------------------------------------------------------------------- PROPOSED FP MODELS ALBRECHT AND GAFFNEY ModelE=-91.4+0.0355FP KEMERER MODELE=-37+0.96FP SMALL PROJECT REGRESSION MODELE= -12.88 + 0.405 FP Each of these Models indicates that eachwill yield a different result for the same value of LOC or FP. The implication is clear- Estimation Models mustbe calibrated for local needs. SOFTWARE ESTIMATION

  40. THE COCOMO II MODEL(COnstructive COst MOdel) COCOMO is most widely used and discussed Software Cost Estimation Model in the Software Industry. The latest COCOMO Model II is a Hıerarch of Estımatıon Models that address the following areas:. 1. APPLICATION COMPOSITION MODEL Used during the early stages of Software Engineering when: - Prototyping of UserInterfaces, - Consideration of Software and System Intraction, - Assesment ofPerformance and Evaluating of Technology maturity are paramount. 2.EARLY DESIGN STAGE MODEL Used once Requirement have been stabilized and basic Software Arcchitecture has been established. 3.POST-ARCHITECTURAL STAGE MODEL Used during the Construction of the Software. SOFTWARE ESTIMATION

  41. THE COCOMO II MODEL(Constructive Cost Model) • Like all other Estimation ModelCOCOMO II Model requires Sizing • Information. • Three different Sizing Options are audilable as part of the COCOMO Model Hierarchy: • LINES OF SOURCE CODES (LOC) • FUNCTION POINT (FP) • OBJECT POINTS (OP) • The COCOMO II Application Composition Model uses Object Points (OP) - an Indirect Software measure that is computed using Counts of of : 1.No. of User Interface Screen 2. No. of Reports • 3.No. of Reusable Components to be required to build the Application • Each Object instance is classified into one of threee complexity levels • (Simple , Mediumand Difficult) using criteria suggested by Boehm. • NOTE : COCOMO II is also available in FP and LOC as sophisticated Estimation Model. SOFTWARE ESTIMATION

  42. COMPLEXITY WEIGHTING FOR OBJECT TYPES TABLE In essece Complexity is a Function of the Number of Source of the Clientand Server Data tables that are required to generate the Screen or Reportand the number of Views or Sections presented as part of the Screen orReport. Once Complexity is determined, the number of Screens, Reports and Reusable Components are weighted according to Boehm’s Complexity weighly of object table (as above). The Object Point Count is them determined by multiplying the Original number of Objects instances by the Weighting Factor in the figure and then summing to obtain a Total Object Point Count.

  43. When Component-based development or General Software Reuseis to beapplied • the percent of Reuse (%Reuse) is estimated and Object Point Count is adjusted: • NOP=(OBJECT POINTS)*[(100 - % REUSE)/100] *** Where: NOP is defined as New Object Points • To derive and Estimate of Effort on the computed NOP value, “Productivity Rate” must be derived by considering the different Levels of Developer Experiences and Development Environment Maturity as shown on the Productivity Rate for Object Points table below • Once the Productivity Rate has been determine an Estimate of Project Effort can be derived as: • ESTIMATED EFFORT = (NOP / PROD) SOFTWARE ESTIMATION

  44. THE SOFTWARE EQUATION The Software Equation is a multivariable Model that assumes a specific distribution of Effort over the life of a Software Development Project. The Model has been derived from Productivity Data collected for over 400 contemporary Software Projects. Based on this data an Estimation Model of the form:- 0.333 3 4 E = [LOC * B / P] *(1 / t ) Where E = Effort in Person Month or Year t = Project Duration Month/Year B = Special Skills Factor (For Small Programs (KLOC = 5 to 15)B = 0.16 ) (For Programs where (KLOC > 70)  B = 0.39) P = Productivity Parametersthat reflects - Overall Process Maturity and manupulate practices to theextentto which good SE practices are used - The level of Programming Languages used - The State of Software Environmen - The Skills and Exprience of team - The Complexity of the Application. SOFTWARE ESTIMATION

  45. THE SOFTWARE EQUATION • Typicalal values of P (Productivity Parameter) might be:- • P = 2,000 for the development of Real-time embeded Software • P = 10,000 for Telecominication and System Software • P = 12,000 for Scientific Software • P= 28,000 for Business System Applications.The Productivity Parameters can be derived for local conditions using Historical Data collected from past Development Efforts. • It is important to note that the Software Equation has two independent Parameters: • An Estimate of Size in LOC • An Indication of Project Duration in Calendar Months or Years SOFTWARE ESTIMATION

  46. THE SOFTWARE EQUATION • To simplify the Estimation process Putnam and Myers suggested a set of equations derived from the Software Equation. • Minimum Development Time is defined as:0,43 • tmin = 8.14 (LOC / P) in Calendar months for tmin > 6 Calendar months • 3 • E = 180 Bt in Person-month for E > or equal to 20 Person-months Using Equation with P = 12,000 tmin = 8.14 (33200 / 12000) = 12.6 Calendar Months 3 E = 180 * 0.28 * (1.05) = 58 Person-months The results of Software Equation corresponds favourable with the Estimates developed with COCOMOS Model SOFTWARE ESTIMATION

  47. ESTIMATION FOR OBJECT-ORIENTED PROJECTS • It is worth to supplement Conventional Software Cost Estimation Methods with an approach • that has been designed explicity for O-O Software. • LORENY AND KIDD SUGGEST THE FOLLOWING APPROACH: • Develop Estimates using effort decomposition, FP Analysis and any other Method that is applicable for conventional applications. • Using O-O Analysis modeling, develop Use-case and determine a count Recognizethat the number of Use-cases may change as the project progresses. • From the Analysis model, determine the number of Key Classes. • Catagorize the type of Interface for the application and develop a Multiplier for SupportClass. • INTERFACE TYPEMULTIPLIER(FOR SUPPORT CLASS) • NO GUI (Without Graphical User interface) 2.00 • TEXT BASED USER INTERFACE 2.25 • GUI 2.50 • COMPLEX GUI3.00 • ============================================================= • Multiply No. of Key Classes with Multiplier to obtain an Estimation for No. of Support Class. SOFTWARE ESTIMATION

  48. ESTIMATION FOR OBJECT-ORIENTED PROJECTS (Cont’d) • 5. Multiply the Total Number of Classes (Key + Support) by the AverageN number • of Work-Unit per Class (Suggestion 15-20 Person-day per Class). • Cross-check the Class-Based Estimate by Multiplying the Average Number of • Work-Unit Per Use-case • . =============================================================== • The previously mentioned Estimation Techniques can be used for any • Software Projects. • However, when a Software Team encounters an extremlyShort Project • Duration (weeks rather than months) that is likely to have acontinuing • stream of changes, Project Planning in General and Estimation in particular • should be abbreviated. SOFTWARE ESTIMATION

  49. SOFTWARE ESTIMATIONESTIMATION FOR AGILE DEVELOPMENTBcause the Requirements for an Agile Project are defined as a Set of User Scenarios it is Possible to develop an Estimation approach that is informal, yet reasonably disciplined and meaningfull within the context of Project Planning for each Software Increment.Agile Projects Estimation uses a Decomposition Approach that encompasses following Steps1.Each User Scenario is considered seperatly for Estimation purpose:-2. The Scenario is decomposed into the set of Functions and the Software Engineering Tasks that will be required to develop them.3a) Each Tasks is estimated Seperatly ( Note:- Based on Historical data and Emperical Model, or experience)3b) Alternatively the Volume (Size) of the Scenarious can be Estimated in LOC, FP on Object Points.4 a) Estimation for eachTask are summed to create an Estimate for the Scenario.4 b) Alternatively the Volume Estimate for Scenario is translated into Effort using historical data5. The Effort Estimation for all Scenarios that are to be implemented for a given Software Increment are summed to develop the Effort Estimate for thr Increment.

  50. ESTIMATION FOR AGILE DEVELOPMENT Since the Project Development Duration required for the development of a Software Increment is quite short (typically 3 to 6 weeks for each version); - The Estimation for Agile Development Approach serves two purposes:. 1. To ensure that the Number of scenarious to be included in the Increment, conforms to the available Resources. 2. To establish a basis for allocating Effort as the Increment is developed.

More Related