Software Metrics. Outline

Size: px

Start display at page:

Download "Software Metrics. Outline"

Gabriel Cameron
6 years ago
Views:

1 Outline These slides will be covered during TWO lectures. Motivation COnstr uctive COst MOdel Basic COCOMO Inter mediate COCOMO Function Point Analysis Other Metrics Uses of Metrics Conclusions

2 Motivation Why Software Metrics? Prediction Project Planning Cost Estimation Evaluation Project Tracking Verification & Validation You cannot control what you cannot measure. You get what you measure. Copyr ight , E Robertson 2

3 Motivation Dimensions of Software Metrics Product Quality Process (Technical) Size- lines of test work or iented code coverage effor t Functionor iented Humanor iented failure rate usability! metr ic is not used in its mathematical sense Copyr ight , E Robertson 3

4 Motivation Character istics of Measures & Measurements Measure: Measurement: e.g. yardstick e.g. 6.5 inches Quantitative execution time time of completion of tasks always numer ic, may be continuous or fit regular intervals ifatrue zero value exists, then ratios make sense accuracy considerations are meaningful Qualitative completeness of documentation por tability tool adequacy may be nominal ( yes - no or other discrete values) may be ordered ( better than ) Direct Indirect Copyr ight , E Robertson 4

5 Motivation How is Software Measured? measurement itself involves products and processes. a software metrics project should itself be evaluated and directed. software metrics are environment dependent metr ics must be done over along time as part of a coherent project Copyr ight , E Robertson 5

6 Motivation How is Software Measured? requires substantial knowledge of statistics difference between fitting and predicting data accuracy improves with knowledge knowledge (time) confidence envelope Copyr ight , E Robertson 6

7 Motivation Establishing a Measure How is Software Measured? distinguish quantitative and qualitative define measurement methodology direct or indirect establish scale not a metr ic in mathematical sense Develop a Model analytic or exper imental descr iptive and mathematical linear model additive measure evaluation by pieces better reliability Copyr ight , E Robertson 7

8 COnstr uctive COst MOdel Estimation Most common & sophisticated estimation model: COnstr uctive COst MOdel Barr y Boehm, Software Engineering Economics, Prentice-Hall, 1971; summarized in IEEE Trans. on Software Engineering, Jan Also, web link to additional COCOMO course notes at stotts/comp145/cocomo.html COCOMO evaluation based on: size estimation based on specifications and design sketch product specific environment infor mation type of project, exper ience of staff, organization specific Hence, cost estimation requires: exper ience specifications or preliminary design Copyr ight , E Robertson 8

9 COnstr uctive COst MOdel Process for COCOMO Estimation preliminar y design environment character istics estimate & sum sizes size estimate estimate effor t obser ve &look-up work-months effor t-modifier factors work-months effor t-modifier adjusted effor t &schedule Copyr ight , E Robertson 9

10 COnstr uctive COst MOdel COCOMO Project Classification Boehm gives many aids for deciding how a project fits within his var ious classifications. Major development modes: organic stand-alone application semi-detached utility or application in larger system embedded tight hardware connection, high-concurrency e.g. O.S., ignition control in automobile Other considerations: organizational understanding of project objectives tightness of specification confor mance requirements concurrent development of hardware or operational environment need for innovation Copyr ight , E Robertson 10

11 Basic COCOMO Basic COCOMO Input var iables: KDSI mode Output var iables: WM T dev Kilo Delivered Source Instr uctions deter mines constants c i Wor k Months minimum calendar Time for development Basic model: WM = c 1 KDSI c 2 T dev =2.5 WM c 3 #programmers = WM / T dev Copyr ight , E Robertson 11

12 Basic COCOMO Basic COCOMO Effor t and Schedule Equations: mode effor t schedule WM = T dev = organic 2.4 KDSI WM 0.38 semidetached 3.0 KDSI WM 0.35 embedded 3.6 KDSI WM 0.32 Copyr ight , E Robertson 12

13 Inter mediate COCOMO Effor t Multipliers An effor t multiplier is a numer ic value associated with an observable character istic of aproject e.g. character istic may be either product or process value is 1 for nominal state of character istic also called cost driver Program Control Operations rating description value very low straight-line code, non-nested conditionals 0.7 low straightforward nesting 0.85 nominal mostly simple nesting; some inter module control 1.0 high highly nested; complex 1.10 predicates; considerable inter module control very high reentrant code; interrupts 1.20 extra high dynamic scheduling with multiple resources 1.35 Copyr ight , E Robertson 13

14 Inter mediate COCOMO Inter mediate COCOMO Input var iables/obser vations: KDSI mode character istics Kilo Delivered Source Instr uctions deter mines constants c i deter mine effor t multipliers em i Output parameters: WM T dev Wor k Months minimum calendar Time for development Inter mediate model: WM = c 1 KDSI c 2 Π em i T dev =2.5 WM c 3 #programmers = WM / T dev Copyr ight , E Robertson 14

15 Inter mediate COCOMO Inter mediate COCOMO Same development modes: organic semi-detached embedded Effor t multipliers based on character istics of: product environment (development & operational) personnel project (resource/management) Π product of all effor t multipliers Effor t and Schedule Equations: mode effor t schedule WM = T dev = organic 3.2 KDSI 1.05 Π 2.5 WM 0.38 semidetached 3.0 KDSI 1.12 Π 2.5 WM 0.35 embedded 2.8 KDSI 1.20 Π 2.5 WM 0.32 Copyr ight , E Robertson 15

16 Inter mediate COCOMO Cost Driver COCOMO Effor t Multipliers Ratings ver y ver y extra low low nom high high high product attributes required reliability database size product complexity system attributes time constraint space constraint platform volatility environment friendliness personnel attributes designer capability programmer capability application experience platform experience prog. lang. experience project character istics use of good practices use of good tools schedule flexibility Copyr ight , E Robertson 16

17 Inter mediate COCOMO product 1.07 Copyr ight , E Robertson 16.1

18 Inter mediate COCOMO Example Inputs: Π =1.07 KDSI = 73 mode semi-detached Results: WM = =392 T dev = =20 # programmers = 392 / 20 = 20 Copyr ight , E Robertson 17

19 Inter mediate COCOMO COCOMO Validity Q: IsCOCOMO any more than just a lot of numbers and a few for mulas? A: COCOMO has undergone a great deal of empir ical verification. The parameters for mode-equations and effor t modifiers were derived from fitting exper imental data. Q: Is COCOMO out-of-date? A: Many of the original parameters are relevant but the general model is still valid. BUT COCOMO can only provide relative results. COCOMO still depends on design and other project knowledge. Copyr ight , E Robertson 18

20 Inter mediate COCOMO COCOMO Infor mation Model Mode 0:M 0:M is of mode estimates Metric 0:1 0:1 contains (parent) 0:M (child) 0:1 Module 0:M 0:M is similar to 0:M 0:1 has driver value is of type Effort Multiplier 0:M 0:M 0:1 has multiplier 0:M ISA 0:M Module Type characteristic applies to ISA ISA 0:1 Parameter Characteristic ISA Ownable Object 0:1 owns 0:M Person Page 1 Copyr ight , E Robertson 19

21 Inter mediate COCOMO Changes Over Time Outdated/Depreciated Environment Character istics: batch turn-around time for debugging primar y memor y constraints ratio of data volume to program size New/Appreciated Environment Character istics multi-platfor m targeting type of user interface tools - now subdivided into many categor ies: design aids application generators CCCM secur ity COCOMO II expanded character istics begin with function points web link to COCOMO II web site at Copyr ight , E Robertson 20

22 Inter mediate COCOMO Over view of Function Point Analysis Goal: a repeatable methodology for estimating size/complexity of modules based only on their specifications Function Point (from Functionality Requirements) General approach: size = c Σ( FP i w i ) where sum is over modules (at all levels) FP i is the number of FP s oftype i w i is a weight associated with type i web link to presentation on FPA by Hunt, Gottschalk, and Grobstein at Copyr ight , E Robertson 21

23 Function Point Analysis Or iginal FPA Or iented toward functional requirements Or iginal function point categories: (with modern ter minology) 1. data sources 2. reports 3. user inquir ies 4. files 5. exter nal interfaces (to other systems) Copyr ight , E Robertson 22

24 Function Point Analysis Moder n FPA Must incorporate new specification methods new tools and technologies Some potential candidates 1. entities 2. relationships 3. data flows 4. for ms subfor ms, fields, 5.??? Where do qualitative requirements fall? e.g. concurrency constraints Copyr ight , E Robertson 23

25 Other Metrics Estimations of Complexity correlate to: V&V Software Metrics Techniques related to glass box methodologies measure program complexity based on syntax should be integrated with CM tools Cyclomatic complexity based on structure of control flow graph #edges - #nodes + 2 Var iable usage Software physics still controversial size = c #operands log(#operands) Copyr ight , E Robertson 24

26 Uses of Metrics Metr ics &Quality Assurance Goals Evaluate testing related to coverage conditions Improve reliability identify weak points Improve usability find awkward places Facilitate maintenance especially corrective and adaptive track problem modules Copyr ight , E Robertson 25

27 Uses of Metrics Metr ics &Project Management Goals 1. compare various alternatives 2. evaluate risks 3. monitor Management must understand value of infor mation must be willing to invest in infor mation project exper ience database prototype simulate design for measurement Copyr ight , E Robertson 26

28 Conclusions Software Metrics Top 10 List 1. Finding and fixing a software problem is 100 times more expensive after deliver y than during requirements and early design phases. 2. A software development schedule can be compressed up to 25%, but no more. T dev =2.5 WM For every dollar spent on development, two will be spent on maintenance. 4. Software development and maintenance costs are pr imar ily a function of the number of source instr uctions. 5. Var iations between people account for the biggest differences in software productivity. Copyr ight , E Robertson 27

29 Conclusions Software Metrics Top 10 List (cont.) 6. The overall ratio of software to hardware costs has gone from 15:85 in 1955 to 85:15 in 1985 and is still growing. 7. Only 15% of software development effor t is devoted to programming. 8. Software systems and software products typically cost three times per instruction to fully develop as does an individual software program. Softwaresystems products cost nine times as much. 9. Walkthroughs catch 60% of the errors. 10. Many software phenomena follow a Pareto distr ibution: 80% of the contribution comes from 20% of the contributors. Barr y Boehm, 1987 Copyr ight , E Robertson 28

InfoSys Courses. Outline

InfoSys Courses. Outline Outline InfoSys in the CS Curriculum Goals and Objectives Schedules Getting Started InfoSys in the CS Curriculum Computer Science Core Curriculum C211 Intro. to Computers Science C212 Intro. to Software