260 likes | 588 Vues
Personal Software Process Software Estimation. CIS 376 Bruce R. Maxim UM-Dearborn. Product Size Measures. Must be: Precise – gives an exact value for product size and is defined by the product content Specific – based on defined product properties.
E N D
Personal Software ProcessSoftware Estimation CIS 376 Bruce R. Maxim UM-Dearborn
Product Size Measures Must be: • Precise – gives an exact value for product size and is defined by the product content • Specific – based on defined product properties. • Countable – automated counting is far less tedious than manual counting and more accurate
Establishing Satandards • Database Projects • fields, tables • GUI elements, queries, code lines • GUI Creation • buttons, boxes, labels • Programming • LOC, FP
Expert Guessing A = The most pessimistic estimate. B = The most likely estimate. C = The most optimistic estimate. Ê = (A + 4B + C) 6 (Weighted average; where Ê = estimate).
Parameter Simple + Average + Complex = Fi Distinct input items 3( ) + 4( ) + 6( ) = ? Output screens/reports 4( ) + 5( ) + 7( ) = ? Types of user queries 3( ) + 4( ) + 6( ) = ? Number of files 7( ) + 10( ) + 15( ) = ? External interface 5( ) + 7( ) + 10( ) = ? Total = ? Function Points
Function Point Equation F.P.’s = T * (0.65 + 0.01 * Q) T = unadjusted table total Q = score from questionnaire (14 items with values 0 to 5) • Cost of producing one function point? May be organization specific.
Backup. Data communication. Distributed processes. Optimal performance. Heavily used operating system. On-line data security. Multiple screens. On-line master file update. Complex inputs, queries, outputs. Complex internal processing. Reusable code. Conversion or installation. Multiple user sites. Ease of use. Function Point Questionnaire
BASIC INTERMEDIATE MODE a b a b Organic 2.4 1.05 3.2 1.05 Semidetached 3.0 1.12 3.0 1.12 Embedded 3.6 1.20 2.8 1.20 COCOMO - I • Model E = a Sb * m(x)
Basic COCOMO • Computes software development effort (and cost) as a function of program size, expressed in estimated lines of code. • m(x) = 1
Intermediate COCOMO • Computes software development effort as a function of program size and a set of "cost drivers" that include subjective assessments of product, hardware, personnel, and project attributes. • m(x) = m(xi)
Detailed COCOMO • Includes all characteristics of the intermediate version with an assessment of the cost driver’s impact on each step (analysis, design, ect.) of the software engineering process • m(x) based on similar questionnaire
Size Accounting • Base – initial unmodified original program • Added – new lines not in base always increases LOC in base count • Modified – lines changed in base, does not increase LOC (includes adapted reused code) • Deleted – lines removed from base always decreases LOC • Reused – unmodified existing code increases LOC • Total – net sum of changes in base LOC
Example • Base code 500 LOC • Added 60 LOC • Deleted 40 LOC • Modified 30 LOC • Reused 50 LOC • Total = 500 + 60 – 40 + 0 + 50 = 570
Using Size Data • Planning and tracking • historical size and time data are necessary to estimate future project • Assessing program quality • useful in computing defect density and service costs • Assessing personal work • reused, added, deleted, modified code
Productivity • Computed in terms of units produced divided by the time units required to create it Total/time = 570 LOC / 50 hours = 11.2 LOC/hours
Size Counters • Manual counting works for small programs not large programs • Physical LOC Counters • count all text lines except counters • Logical LOC Counters • only count logical program lines defined by program control structures • Counting Program Elements • measure sizes of procedures or classes in large programs
Proxy-Based Estimation • Estimates made by comparing new project to previously completed project • Requires that you have saved historical data from previous projects • May have to do estimation based on similar pieces from multiple projects
Proxy Selection Criteria • Proxy size measure closely related to required development effort • Proxy content or product should be automatically countable • Proxy should be easy to visualize at project beginning • Proxy customizable to needs of each project and developer • Proxy sensitive to implementation variations affecting development cost or effort
Possible Proxies • Function points • Classes • Database elements • Forms • Scripts • Document chapters
Estimation Considerations - 1 • Improving Estimation Accuracy • break up product in to several parts and compute average of several independent estimates for each • Estimating Bias • use historical data techniques to minimize impact of subjective judgment • Incomplete Knowledge Bias • reestimate product size several times during development
Estimation Considerations - 2 • Overcompensation • caused by making too small an estimate after being too large or the reverse • Selecting Abstraction Level • get the right grain size • Large Systems • divide in to separately estimated subsystems • Unprecedented Systems • build prototypes and extrapolate
PROBE Estimation Method - 1 • Step 1: Conceptual Design • identify parts of product after conceptual design is finished • Step 2: Estimate Parts Size • use relative size table to get estimate for each part based on expected size (VS, S, M, L, VL) • Step 3: Estimate Sizes of Reused Parts and Base Additions • estimate sizes of any additional parts needed
PROBE Estimation Method - 2 • Step 4: Size Estimating Procedure • select which PROBE method to use (A, B, C, D, E) the default is A • Step 5: Time Estimating Procedure • check your data to see whether or not you can use method A • Step 6: Prediction Interval • determine prediction interval surrounding the size or time estimate
PROBE Use - 1 • Estimating practice • once regression parameters stabilize they do not need to be recomputed for every new program • Estimating judgment • poor proxy estimates will ruin PROBE estimate • Outliers • discard obvious outliers from regression data
PROBE Use - 2 • Using limited data • you need at least 3 historical data points for regression to work (30 is better) • Overcompensation and Undercompensation • only make changes when you change processes or discover ineffective practices (normal statistical fluctuations are common)