keybd INPUT yes screen OUTPUT lf swiss11 off ~\n 1 nolist fmt \n\N yes 1 yes fixed 5 degrees off 5.00000 -5.00000 5.00000 -5.00000 5 5 home,home Bugfix Rule 6: Each software review, inspection, or test step will find and remove 30 percent of the bugs that are present. 0.30 BugsLeft Uses Rule 6 &Bugfix to estimate the number of defects that will be shipped assuming &TestRun test cycles. 50.53071 Creep Rule 3: Creeping user requirements will grow at an average rate of 1 percent per month over the entire development schedule. Enter assumed monthly creep rate in the value field. 0.01 Critical_Creep This cell computes the monthly creep rate (fractional change in requirements) for which the growth in requirements over the build time for the project equals the size of the original specification. 0.06513 Defect Rule 5: Raising the number of function points to the 1.25 (1.27) power predicts the approximate defect potential for new (enhancement) software projects. 1788.85438 Effort Rule 10: Multiply software development schedules by number of personnel to predict the approximate number of months of staff effort. Commonly define a staff month as 22 working days with six productive hours each day, or 132 work hours per month 29.29495 fp Number of Function Points in the project. 400.00000 Growth Percentage Growth in Requirements by delivery for &Creep rate 11.55086 home Software Estimating Rules of Thumb. This web generates a number of estimates for sizing software projects based on the function point model. These are very rough estimates to be used with CAUTION. To use either: a) enter the number of thousands of lines of delivered source code &KDSI; or b) set KDSI to 0 and enter the number of function points &FP. Then return to this home cell and execute. For more refined estimates consider varying the conversion from source lines to function points &LOC_to_fpoint. Or explore the creep rate parameter &Creep. To investigate the number of Quality Control steps required vary the &TestRun parameter. Kevin J. Northover Refs: Capers Jones, IEEE Computer, March 1996, 116-118. Ted Lewis, IEEE Computer, August 1996, 13-15. KDSI Enter the estimated number of thousands of lines of delivered noncommentary logical source code statements in the value field of this cell. 40 Lifetime Rule 9b: Raising the function points total to the 0.25 power yields the approximate number of years the application will stay in use. 4.47214 LOC_to_fpoint Rule 1: One function point = 100 logical source code statements. This ratio can vary from >300 for assembler to <20 for object oriented languages and program generators. For procedural languages such as COBOL, C, Fortran, etc. 100 is a rough conversion factor. Enter the conversion factor to use in the value field. 100 Maintenance Rule 9: Dividing the number of function points by 500 predicts the approximate number of maintenance personnel required to keep the application updated. 0.80000 Paper Rule 2: Raising the number of function points to the 1.15 power predicts approximate page counts for paper documents associated with software projects. 982.58242 Schedule Rule 7: Raising the number of function points to the 0.4 power predicts the approximate development schedule in calendar months. 10.98561 Staffing Rule 8: Dividing the number of function points by 150 predicts the approximate number of personnel required for the application. 2.66667 Test Rule 4: Raising the number of function points to the 1.2 power predicts the approximate number of test cases created. 1325.78161 TestRun Number of Test Cycles in development of system. Includes Major Design Reviews, code inspections and various testing levels. 10