Lecture 6 Estimation Estimate size, then Estimate effort, schedule and cost from size Bound estimates CS 540 – Quantitative Software Engineering

Proposed System Check Status Create Order Shipment Notice Inventory Assign Inventory to Order Inventory Assigned New Inventory for Held Orders Assign Order to Truck Truckload Report Shipping Invoices Order Update Order Display Problem Resolution Dispatch Accounting Management Reports Customer Check Credit & Completion Users Catalog Orders Order Creation Credit Check Inventory Assignment Held Order Processing Completion Dispatch Support Problem Resolution Management Reporting OA&M

Project Metrics l Cost and schedule estimation l Measure progress l Calibrate models for future estimating l Metric/Scope Manager Product Number of projects x number of metrics = 15-20

Approaches to Cost Estimation By expert By analogies Decomposition Parkinson’s Law; work expands to fill time available Price to win/ customer willingness-to -pay Lines of Code Function Points Mathematical Models: Function Points & COCOMO

Time Staff-month T theoretical 75% * T theoretical Impossible design Linear increase Boehm: “A project can not be done in less than 75% of theoretical time” T theoretical = 2.5 * 3 √staff-months But, how can I estimate staff months?

Sizing Software Projects l Effort = (productivity) -1 (size) c productivity ≡ staff-months/kloc size ≡ kloc Staff months Lines of Code or Function Points 500

Understanding the equations Consider a transaction project of 38,000 lines of code, what is the shortest time it will take to develop? Module development is about 400 SLOC/staff month Effort = (productivity) -1 (size) c = (1/.400 KSLOC/SM) (38 KSLOC) 1.02 = 2.5 (38) 1.02 ≈ 100 SM Min time =.75 T= (.75)(2.5)(SM) 1/3 ≈ 1.875(100) 1/3 ≈ x 4.63 ≈ 9 months

Function Points Bell Laboratories data Capers Jones data Productivity (Function points / staff month) Productivity= f(size)

Lines of Code l LOC ≡ Line of Code l KLOC ≡ Thousands of LOC l KSLOC ≡ Thousands of Source LOC l NCSLOC ≡ New or Changed KSLOC

Productivity per staff-month: »50 NCSLOC for OS code (or real-time system) » NCSLOC for intermediary applications (high risk, on-line) » NCSLOC for normal applications (low risk, on- line) »10,000 – 20,000 NCSLOC for reused code Reuse note: Sometimes, reusing code that does not provide the exact functionality needed can be achieved by reformatting input/output. This decreases performance but dramatically shortens development time. Bernstein’s rule of thumb

Productivity: Measured in 2000 Classical rates130 – 195 NCSLOC Evolutionary approaches244 – 325 NCSLOC New embedded flight software 17 – 105 NCSLOC

QSE Lambda Protocol l Prospectus l Measurable Operational Value l Prototyping or Modeling l sQFD l Schedule, Staffing, Quality Estimates l ICED-T l Trade-off Analysis

Heuristics for requirements engineering l Move some of the desired functionality into version 2 l Deliver product in stages 0.2, 0.4… l Eliminate features l Simplify Features l Reduce Gold Plating l Relax the specific feature specifications

Function Point (FP) Analysis l Useful during requirement phase l Substantial data supports the methodology l Software skills and project characteristics are accounted for in the Adjusted Function Points l FP is technology and project process dependent so that technology changes require recalibration of project models. l Converting Unadjusted FPs (UFP) to LOC for a specific language (technology) and then use a model such as COCOMO.

Function Point Calculations l Unadjusted Function Points UFP= 4I + 5O + 4E + 10L + 7F, Where I ≡ Count of input types that are user inputs and change data structures. O ≡ Count of output types E ≡ Count of inquiry types or inputs controlling execution.  [think menu selections] L ≡ Count of logical internal files, internal data used by system  [think index files; they are group of logically related data entirely within the applications boundary and maintained by external inputs. ] F ≡ Count of interfaces data output or shared with another application Note that the constants in the nominal equation can be calibrated to a specific software product line.

External Inputs – One updates two files External Inputs (EI) - when data crosses the boundary from outside to inside. This data may come from a data input screen or another application.

External Interface Table For example, EIs that reference or update 2 File Types Referenced (FTR’s) and has 7 data elements would be assigned a ranking of average and associated rating of 4. File Type References (FTR’s) are the sum of Internal Logical Files referenced or updated and External Interface Files referenced.

External Output from 2 Internal Files External Outputs (EO) – when data passes across the boundary from inside to outside.

External Inquiry drawing from 2 ILFs External Inquiry (EQ) - an elementary process with both input and output components that result in data retrieval from one or more internal logical files and external interface files. The input process does not update Internal Logical File, and there is no derived data.

EO and EQ Table mapped to Values

Adjusted Function Points l Accounting for Physical System Characteristics l Characteristic Rated by System User 0-5 based on “degree of influence” 3 is average Unadjusted Function Points (UFP) Unadjusted Function Points (UFP) General System Characteristics (GSC) General System Characteristics (GSC) X = Adjusted Function Points (AFP) Adjusted Function Points (AFP) AFP = UFP ( *GSC), note GSC = VAF= TDI 1. Data Communications 2. Distributed Data/Processing 3. Performance Objectives 4. Heavily Used Configuration 5. Transaction Rate 6. On-Line Data Entry 7. End-User Efficiency 8. On-Line Update 9. Complex Processing 10. Reusability 11. Conversion/Installation Ease 12. Operational Ease 13. Multiple Site Use 14. Facilitate Change

Complexity Table TYPE:SIMPLEAVERAGECOMPLEX INPUT (I)346 OUTPUT(O)457 INQUIRY(E)346 LOG INT (L)71015 INTERFACES (F) 5710

Complexity Factors 1. Problem Domain___ 2. Architecture Complexity ___ 3. Logic Design -Data ___ 4. Logic Design- Code___ Total ___ Complexity = Total/4 = _________

Problem Domain Measure of Complexity (1 is simple and 5 is complex) 1. All algorithms and calculations are simple. 2. Most algorithms and calculations are simple. 3.Most algorithms and calculations are moderately complex. 4.Some algorithms and calculations are difficult. 5.Many algorithms and calculations are difficult. Score ____

Architecture Complexity Measure of Complexity (1 is simple and 5 is complex) 1. Code ported from one known environment to another. Application does not change more than 5%. 2. Architecture follows an existing pattern. Process design is straightforward. No complex hardware/software interfaces. 3. Architecture created from scratch. Process design is straightforward. No complex hardware/software interfaces. 4. Architecture created from scratch. Process design is complex. Complex hardware/software interfaces exist but they are well defined and unchanging. 5. Architecture created from scratch. Process design is complex. Complex hardware/software interfaces are ill defined and changing. Score ____

Logic Design -Data 1.Simple well defined and unchanging data structures. Shallow inheritance in class structures. No object classes have inheritance greater than 3. 2.Several data element types with straightforward relationships. No object classes have inheritance greater than 3.Multiple data files, complex data relationships, many libraries, large object library. No more than ten percent of the object classes have inheritance greater than three. The number of object classes is less than 1% of the function points 4.Complex data elements, parameter passing module-to-module, complex data relationships and many object classes has inheritance greater than three. A large but stable number of object classes. 5.Complex data elements, parameter passing module-to-module, complex data relationships and many object classes has inheritance greater than three. A large and growing number of object classes. No attempt to normalize data between modules Score ____

Logic Design- Code 1.Nonprocedural code (4GL, generated code, screen skeletons). High cohesion. Programs inspected. Module size constrained between 50 and 500 Source Lines of Code (SLOCs). 2.Program skeletons or patterns used. ). High cohesion. Programs inspected. Module size constrained between 50 and 500 SLOCs. Reused modules. Commercial object libraries relied on. High cohesion. 3.Well-structured, small modules with low coupling. Object class methods well focused and generalized. Modules with single entry and exit points. Programs reviewed. 4.Complex but known structure randomly sized modules. Some complex object classes. Error paths unknown. High coupling. 5.Code structure unknown, randomly sized modules, complex object classes and error paths unknown. High coupling. Score __

Complexity Factors 1. Problem Domain___ 2. Architecture Complexity ___ 3. Logic Design -Data ___ 4. Logic Design- Code___ Total ___ Complexity = Total/4 = _________

Computing Function Points See unctionpoints.htm

Adjusted Function Points l Now account for 14 characteristics on a 6 point scale (0-5) l Total Degree of Influence (DI) is sum of scores. l DI is converted to a technical complexity factor (TCF) TCF = DI l Adjusted Function Point is computed by FP = UFP X TCF l For any language there is a direct mapping from Function Points to LOC Beware function point counting is hard and needs special skills

Function Points Qualifiers l Based on counting data structures l Focus is on-line data base systems l Less accurate for WEB applications l Even less accurate for Games, finite state machine and algorithm software l Not useful for extended machine software and compliers An alternative to NCKSLOC because estimates can be based on requirements and design data.

Initial Conversion LanguageMedian SLOC/function point C104 C++53 HTML42 JAVA59 Perl60 J2EE50 Visual Basic42

SLOC l Function Points = UFP x TCF = 78 *.96 = ~ 52 function points l 78 UFP * 53 (C++) SLOC / UFP = 4,134 SLOC ≈ 4.2 KSLOC. (Reference for SLOC per function point: )

Understanding the equations For 4,200 lines of code, what is the shortest time it will take to develop? Module development is about 400 SLOC/staff month From COCOMO: Effort = 2.4 (size) c By Barry Boehm

What is ‘2.4?’ Effort = 2.4 (size) c = 1/(.416) (size) c Effort = (productivity) -1 (size) c where productivity = 400 KSLOC/SM from the statement of the problem = (1/.400 KSLOC/SM)(4.2 KSLOC) 1.16 = 2.5 (4.2) 1.16 ≈ 13 SM

Minimum Time Theoretical time = 2.5 * 3√staff-months Min time =.75 Theorectical time = (.75)(2.5)(SM) 1/3 ≈ 1.875(13) 1/3 ≈ x 2.4 ≈ 4.5 months

How many software engineers? l 1 full time staff week = 40 hours, if 1 student week = 10 hours. l Therefore, the estimate of 13 staff months is actually 52 student months. l The period of coding is December 2004 through April 2005; a period of 5 months. l 52 staff months/5 months = 10 student software engineers Design Simplification to cut FP in half is a must, as there are only five student software engineers onboard

Function Point pros and cons l Pros: Language independent Understandable by client Simple modeling Hard to fudge Visible feature creep l Cons: Labor intensive Extensive training Inexperience results in inconsistent results Weighted to file manipulation and transactions Systematic error introduced by single person, multiple raters advised

Specification for Development Plan l Project l Feature List l Development Process l Size Estimates l Staff Estimates l Schedule Estimates l Organization l Gantt Chart

Wide Band Delphi l Convene a group of expert l Coordinator provides each expert with spec l Experts make private estimate in interval format: most likely value and an upper and lower bound l Coordinator prepares summary report indicating group and individual estimates l Experts discuss and defend estimates l Group iterates until consensus is reached

Heuristics to do Better Estimates l Decompose Work Breakdown Structure to lowest possible level and type of software. l Review assumptions with all stakeholders l Do your homework - past organizational experience l Retain contact with developers l Update estimates and track new projections (and warn) l Use multiple methods l Reuse makes it easier (and more difficult) l Use ‘current estimate’ scheme

Heuristics to Cope with Estimates l Add and train developers early l Use gurus for tough tasks l Provide manufacturing and admin support l Sharpen tools l Eliminate unrelated work and red tape (50% issue) l Devote full time end user to project l Increase level of exec sponsorship to break new ground (new tools, techniques, training) l Set a schedule goal date but commit only after detailed design l Use broad estimation ranges rather than single point estimates

Easy? l “When performance does not meet the estimate, there are two possible causes: poor performance or poor estimates. In the software world, we have ample evidence that our estimates stink, but virtually no evidence that people in general don’t work hard enough or intelligently enough.” -- Tom DeMarco

Capers Jones Expansion Table

Bernstein’s Trends in Software Expansion Small Scale Reuse 1990 Subsec Time Sharing 1995 Object Oriented Programming 1960 Machine Instructions 1965 Macro Assembler 1970 High Level Language 1975 Database Manager 1980 On-line 1985 Prototyping 2000 Large Scale Reuse Regression Testing 4GL Order of Magnitude Every Twenty Years Expansion Factor Technology Change

SLOC Defined : Single statement, not two separated by semicolon Line feed All written statements (OA&M) No Comments Count all instances of calls, subroutines, … There are no industry standards and SLOC can be fudged

Sizing Software Projects Effort = (productivity) -1 (size) c Staff months Lines of Code or Function Points

Regression Models Effort: »Watson-Felix: Effort = 5.2 KLOC 0.91 »COCOMO: Effort = 2.4 KLOC 1.05 »Halstead: Effort = 0.7 KLOC 1.50 Schedule: »Watson-Felix: Time = 2.5E 0.35 »COCOMO: Time = 2.5E 0.38 »Putnam: Time = 2.4E 0.33

COCOMO l COnstructive COst MOdel l Based on Boehm’s analysis of a database of 63 projects - models based on regression analysis of these systems l Linked to classic waterfall model l Effort is number of Source Lines of Code (SLOC) expressed in thousands of delivered source instructions (NCKSLOC) - excludes comments and unmodified software l Original model has 3 versions and considers 3 types of systems: Organic - e.g.,simple business systems Embedded -e.g., avionics Semi-detached -e.g., management inventory systems

COCOMO Model Effort in staff months =b*NCKSLOC c bc organic semi- detached embedded

COCOMO System Types SIZEINNOVATIONDEADLINECONSTRAINTS OrganicSmallLittleNot tightStable Semi- Detached Medium EmbeddedLargeGreaterTightComplex hdw/customer interfaces

Intermediate COCOMO l Adds 15 attributes of the product that has to be rated on a six point scale from Very Low to Extra High l There are 4 categories of attributes: product, computer, personnel and project. l The ratings are reflected in P of the equation Effort in staff months =(b*KDLOC c )*P

Intermediate COCOMO attributes l PRODUCT: RELY - required reliability DATA- data bytes per DSI (smaller db) CPLX - code complexity (VH= real time) l COMPUTER: TIME - execution time, % used STOR - storage requirements, % used VIRT - changes made to hdw and OS TURN- Dev turnaround time, batch vs interactive l PERSONNEL ACAP - analyst capability, skills PCAP - programmer capability AEXP- applications experience LEXP - language experience VEXP- virtual machine experience l PROJECT MODP - Modern Development Practices TOOL - use of sfw tools SCED - amount of schedule compression

Intermediate COCOMO Attributes

COCOMO II Post Architecture Model is the most detailed model. Differs from original COCOMO in set of cost drivers, and range of values to parameters. New cost drivers are: »Documentation needs »Personnel continuity »Required reusability »Multi-site development »(-) computer turnaround time »(-) use of modern programming practices

COCOMO II l Effort = a (size) c П EM(i) c = ∑SF(j); where SF(j) are 5 scale factors and EM(i) has 17 cost drivers See: We will use the original COCOMO model in CS 540.

Case Study l Light Planning l Undergraduate Project l Eight students l October 15 to May 1

Prospectus Theater group uses a CAD tool to design and set up lighting plots. Our objective is to design an easy to use, GUI based system that guides the user through the lighting design phase. It will be capable of representing the lighting design of a theatre of any size. The involved parts of the theatre include: the room that encloses the stage, the stage itself, show set, lighting bars, their wiring, and the objects that hang on them. All items in the diagram will be selected from an inventory through the use of an inventory management system. The program will also be able to print out clear, concise, lighting plots and wiring plots that conform to the industry standards for lighting. Since the theatre has several different Operating System portability is an issue. As a result, the project will be written in JAVA, with an XML backend to store the data.

MOV l Cut Time spent learning/using CAD software by 25%. l Cut Time spent by electricians by 5%,with clearer diagrams and save $ l No software licensing fee

Requirements 1. Design a lighting scheme for a show 2. Edit stage space, set space, bars, lighting plot, and instrument properties. 3. Save and load all data in XML 4. Create and maintain equipment inventory. 5. View concurrent information between different aspects of design with a GUI driven interface using 2D drawing and text. 6. Store each design in its own separate XML file. 7. Maintain multiple lighting schemes for different plays. 8. Load user defined design space; use default on startup. 9. Open one scheme at a time. 10. Use JAVA data structures while the program is running. 11. Read and write to XML file on saves, loads and timed backups and error check XML files for design types when this happens. 12. Build a print routine for workspace, inventory screen, wiring sheet, bar diagram. 13. Print workspace design aspects individually or overlapped. 14. Use English or Metric measures for integer coordinates

UFP = 4I + 5O + 4E + 10L + 7F l Number of input types, I =3 l Number of output types O=1 l Number of inquiry types E =5 l Number of logical internal files L=1 l Number of interfaces F =1 l UFP = 4(3) + 5(1) + 4(5) + 10(1) + 7(1) = 54 Unadjusted Function Points

Technical Complexity Factor (TCF) l General System Characterists Influence (GSC) Rating Data Communication = 2 Distributed Function =1 Performance = 3 Heavily Used Configuration =1 Transaction Rate= 2 Online Data Entry =0 End-User Efficiency =5 Online Update =0 Complex Processing= 3 Reusability= 4 Installation Ease =3 Operational Ease= 3 Multiple Sites =1 Facilitate Change =3 Total:31 l TCF = GSC l TCF = (31) =.96

SLOC l Function Points = UFP x TCF = 54 *.96 = ~ 52 function points l 54 UFP * 77 (C)LOC / UFP = 4,158 SLOC = 4.2 KSLOC. (Reference for SLOC per function point: )

Time Staff-month T theoretical 75% * T theoretical Impossible design Linear increase Boehm: “A project can not be done in less than 75% of theoretical time” T theoretical = 2.5 * 3 √staff-months But, how can I estimate staff months?

Sizing Software Projects l Effort = (productivity) -1 (size) c productivity ≡ staff-months/KSLOC size ≡ KSLOC Staff months Lines of Code or Function Points 500

Understanding the equations For 4,200 lines of code, what is the shortest time it will take to develop? Module development is about 400 SLOC/staff month From COCOMO: Effort = 2.4 (size) c

What is ‘2.4?’ From COCOMO: Effort = 2.4 (size) c Effort = (productivity) -1 (size) c where productivity = 400 KSLOC/SM = (1/.400 KSLOC/SM)(4.2 KSLOC) 1.16 = 2.5 (4.2) 1.16 ≈ 13 SM

Exponent l Calculate c using c = (w) where w is the sum of the weights in the following table. Precedentness =3 Development Flexibility =3 Architecture/Risk Resolution = 4 Team Cohesion =2 Process Maturity = 3; w = 15 c = (w) = = 1.16

Minimum Time Theoretical time = 2.5 * 3√staff-months Min time =.75 Theorectical time = (.75)(2.5)(SM) 1/3 ≈ 1.875(13) 1/3 ≈ x 2.4 ≈ 4.5 months

How many software engineers? l 1 full time staff week = 40 hours, 1 student week = 20 hours. l Therefore, our estimation of 13 staff months is actually 26 student months. l The period of coding is December 2004 through April 2005, which is a period of 5 months. l 26 staff months/5 months = 5 student software engineers

Proposed System Check Status Create Order Shipment Notice Inventory Assign Inventory to Order Inventory Assigned New Inventory for Held Orders Assign Order to Truck Truckload Report Shipping Invoices Order Update Order Display Problem Resolution Dispatch Accounting Management Reports Customer Check Credit & Completion Users Catalog Orders Order Creation Credit Check Inventory Assignment Held Order Processing Completion Dispatch Support Problem Resolution Management Reporting OA&M

Case Study:

GSC

Average Median Low High Consultant

Applying the equations For 418 UFP x 63 (Java) SLOC/FP = SLOC ≈ 30 KSLOC How long will it take to develop? Module development is about 330 SLOC/staff month

COCOMO Model Effort in staff months =b*NCKSLOC c bc organic semi- detached embedded

What is ‘2.4?’ From COCOMO: Effort = (productivity) -1 (size) c where productivity = 330 KSLOC/SM = (1/330 KSLOC/SM)(30 KSLOC) 1.12 = 3 (30) 1.12 ≈ 100 SM

Minimum Time Theoretical time = 2.5 * 3√staff-months = (2.5)(100) 1/3 ≈ 12 months

Software Costs by extrapolated history l Cost Development using FPA l Estimate Requirements Engineering (1/3 of implementation Design (1/5 of implementation) Testing (1/4 of implementation Documentation & Training 7.6