Software Project Planning Part II

Troutman's Postulates Profanity is the one language understood by all programmers. Not until a program has been in production for at least six months will the most harmful error be discovered. If the input editor has been designed to reject all bad input, an ingenious idiot will discover a method to get bad data past it. If a test installation functions perfectly, all subsequent systems will malfunction.

Software Cost Estimation Software cost estimation is used to determine how many resources are needed to complete a project. There are two main approaches: 1.Lines of Code (LOC) estimation (old) 2.Counting function points in the project description (new)

Lines of Code (LOC) Estimation LOC is a Software Size measure It can be obtained only after the project has been completed Estimations are used instead

Lines of Code (LOC) Estimation One estimation method is to estimate:  Max = maximum possible lines of code  Min = minimum possible lines of code  Best = Best guess for the possible lines of code  Estimate = (Max + Min + 4*Best)/6

Lines of Code (LOC) Estimation PartMin SizeBest GuessMax Size Total  Estimate = ( * ) = 1086/6 = 181  We also need an estimate of standard deviation.  Why? Software Company XYZ project “Q”

Lines of Code (LOC) Estimation PartMin SizeBest GuessMax Size Total The standard deviation for each part can be estimated as: (Max – Min)/6 Why can you use (Max – Min)/6 as an estimate for StdDev for each part? StdDev (total) = SQRT( 4.17^ ^ ^ ^ ^2) = 8.70 PartMin SizeBest GuessMax SizeStdDev (55-30)/6 = (40-20)/6 = (35-15)/6 = (60-35)/6= (51-25)/6=4.33 Total

LOC-Based Cost Estimation A software company can determine future costs based on historical data You can “curve fit” data into a polynomial equation.

LOC-Based Cost Estimation The equation your book uses is: a * KLOC ^ b + c KLOC = Thousands of lines of code a = marginal cost per KLOC = added cost per thousand lines of code b = non-linearity of relationship c = fixed cost of doing any project

LOC-Based Cost Estimation a * KLOC ^ b + c –b<1 economy of scale –b=1 linear relationship –b > 1 diseconomy of scale To see how this function behaves:

LOC-Based Cost Estimation a * KLOC ^ b + c Proj IDSize (KLOC)Effort (PM) XYZ Software Company historical data

LOC-Based Cost Estimation KLOC PM XYZ has a linear cost function What are a,b, and c in a*KLOC^b + c?

Constructive Cost Model (COCOMO) Created by Barry Boehm in the 1970’s Uses thousands of delivered source instructions (KDSI) instead of KLOC (Same thing) Unit of effort is programmer-months (PM’s)

Constructive Cost Model (COCOMO) Historical project data is divided into three types: 1.Applications 2.Utility programs 3.System programs

Constructive Cost Model (COCOMO Applications - allow users to do things like creating text documents, playing games, listening to music or surfing the web. Utility programs - focuses on how the computer infrastructure (including the computer hardware, operating system, application software and data storage) operates. More technical than applications. Systems programs – at the register level. Requires intimate knowledge of the system (device drivers, etc.)

Constructive Cost Model (COCOMO) Boehm developed the following formula’s from data: o Applications programs: PM = 2.4 * (KDSI)^1.05 o Utility programs: PM = 3.0*(KDSI)^1.12 o System programs: PM = 3.6*(KDSI)^1.20

Constructive Cost Model (COCOMO) Boehm also determined that there was a standard development time (TDEV) based on the type of project and the cost of effort: o Applications programs: TDEV = 2.5*(PM)^0.38 o Utility programs: TDEV = 2.5*(PM)^0.35 o Systems programs: TDEV = 2.5*(PM)^0.32

Constructive Cost Model (COCOMO) This model seems a little outdated There is no longer a clear breakdown between applications, utilities, and systems programs. There are many more “virtual levels” of programming than the three in his model

COCOMO-II Provides more support for modern software development COCOMO was developed during the mainframe/batch era. COCOMO-II was developed during the desktop/applications era. We need a COCOMO-III for the mobile device/ mobile apps era.

COCOMO-II COCOMO II can be used for the following major decision situations: –Making investment or other financial decisions involving a software development effort –Setting project budgets and schedules as a basis for planning and control –Deciding on or negotiating tradeoffs among software cost, schedule, functionality, performance or quality factors –Making software cost and schedule risk management decisions –Deciding which parts of a software system to develop, reuse, lease, or purchase –Making legacy software inventory decisions: what parts to modify, phase out, outsource, etc –Setting mixed investment strategies to improve organization's software capability, via reuse, tools, process maturity, outsourcing, etc –Deciding how to implement a process improvement strategy COCOMO-II Calculator

Function Point Analysis Function point analysis involves identifying and quantifying the functionality requirements for a project. You identify “function points” which are units of functionality. Each function point has an associated “cost” depending on how hard it is to implement the function point. The is no standard for counting function points. Specific rules are not as important as is consistency within the organization.

Function Point Analysis The classic items to count are: –Inputs –Outputs –Inquiries –Internal files –External interfaces

Function Point Analysis Inquiries – request/response pairs that do not change internal data (e.g. – requesting the address of an employee) Inputs – a logical unit of data supplied to the program (e.g. records - individual fields are not counted as 1 input) Outputs – displays of application data (e.g. a report, a screen display, an error message) Internal files – logical files maintained by the system External interfaces – data shared with other programs

Function points are very often weighted as to whether or not they are simple, average, or complex. Function Point Analysis SimpleAverageComplex Outputs457 Inquiries346 Inputs346 Files71015 Interfaces5710 Sample weighting for XYZ software company

Function Point Analysis The function points are multiplied by their corresponding weights and the values are totaled. The total is called the unadjusted function points

Function Point Analysis For example, suppose a table showing the number of each function point category was determined Find the unadjusted function points SimpleAverageComplex Outputs410 Inquiries350 Inputs103 Files215 Interfaces100 XYZ Software Company project “Q”

Productivity Productivity = Total size of project Total effort of all programmers = Total LOC Total PD LOC = Lines Of CodePD = Programmer Days

Productivity PhasePD’s Requirements20 Design10 Implementation10 Testing15 Documentation10 Total PD = = 65 Suppose there were 950 LOC produced Then the Productivity = 950/65 = 14.6 LOC/PD XYZ Software Company project “Q”

Evaluating Estimations Methods have been developed to help determine if your estimates are correct or not. To do this, Tom DeMarco (Bell Labs) developed the estimate quality factor (EQF)

Estimate Quality Factor To determine EQF, you must revise your estimates as the project continues. For example, consider the following estimates: V = |2.3—3.5|*1.5 + | |*4 + | |*2.5 + | |*3.5 = 4.75 EQF = 11.5*3.5/ V = 40.25/4.75 = 8.7 The higher the EQF, the better were the series of estimates Time of estimate0 months1.5 months5.5 months8 months11.5 Months (done) Estimate2.3 million3.1 million3.9 million3.4 million3.5 million