Introduction to The Personal Software Process and The Team Software Process

1. Introduction toThe Personal Software ProcessandThe Team Software Process Dr. Kaan Kurtel

2. Measuring Software Size

3. 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

4. Imprecise and inaccurate Precise and inaccurate x x x x x x x xx x x x x x Imprecise and accurate Precise and accurate x x x x x x x x x x x x x x Precision and Accuracy

5. The PSP Measurements • The basic PSP data are • program size • time spent by phase • defects found and injected by phase • Measures derived from these data • support planning • characterize process quality

6. PSP Size Measures • The goals of the PSP size measures are to • define a consistent size measure • establish a basis for normalizing time and defect data • help make better size estimates • Some of the questions these data can help to answer are • What size program did I plan to develop? • How good was my size estimate? • What was the completed size of the finished program?

7. PSP Time Measures • The goals of the PSP time measures are to • determine how much time you spend in each PSP phase • help you to make better time estimates • Typical questions these data can help answer are • How much time did I spend by PSP phase? • How much time did I plan to spend by PSP phase?

8. PSP Defect Measures • The goals of the PSP defect measures are to • provide a historical baseline of defect data • understand the numbers and types of defects injected • understand the relative costs of removing defects in each PSP phase • Some questions these data can help answer are • How many defects did I make in each phase? • How many defects did I remove in each phase? • How much time did it take to find and fix each defect?

9. PSP Derived Measures • Some PSP derived measures are • To Date and To Date % • Product size developed or reviewed per hour • CPI (continuousprocessimprovement) • % Reuse and % New Reusable • A/FR (appraisal to failure ratio) • PQI (process quality index) • You will learn about these measures in the rest of the PSP course.

10. Size Measurement Criteria • The size measure should be sensitive to language, design, and development practice • Size measurements must be • related to development effort • precise • machine countable • suitable for early planning

11. Establishing a Database Counting Standards • Database Projects • fields, tables • queries, GUI elements, code lines • GUI Creation • buttons, boxes, labels • Programming • LOC, FP • pages, screens, scripts, reports

12. Line-of-Coding Standard • Useful size measure for many kind of programming. • LOC correlates well with development effort. • The first step: to establish a counting strategy.

13. C++ LOC Versus Time

14. Coding Standards

15. Simple Guideline • Count logical statements • Write every countable statement on a separate line • Count all statements except blank and comment lines • Count each language separately

16. Counting Program Size -1 • Statement specifications • executable • nonexecutable • counted statement types • Application • language and code type • origin and usage

17. Counting Program Size -2 • Logical lines • invariant to editing changes • correlate with development effort • uniquely definable • complex to count • Physical lines • are easy to count • are not invariant • must be precisely defined for each case

18. PSP’s LOC Counting Standard • Count all statements. This includes • begin, end, if, then, else, • {, }, ;, ., • declarations, directives, headers, etc. • Do not count blanks, comment lines, or automatically generated code. • Count added and modified code for measuring and estimating development productivity.

19. Size Accounting • For small products, size tracking can be done manually, but it requires care. • For larger products, size tracking requires an accounting system. • Size accounting provides an orderly and precise way of tracking size changes through multiple product versions.

20. 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

21. Example: The size accounting problem Countversion 0 = 350 LOC Countversion 1 = 450 LOC Add 125 Added and Modified LOC Version 1 LOC = 455 Version 1 LOC = 475 ???

22. Example of Size Accounting

23. New Reusable The Version 2 Size Accounting Example Version 2 New program 910 LOC Version 1 Base program 450 LOC Added & Modified 135 LOC Modified 75 LOC Added 60 LOC Deleted 200 LOC Unmodified 175 LOC Reused 600 LOC

24. Using Size Data • To use size data: • Planning • Quality management • Process analysis

25. Calculating Productivity • Productivity is generally measured as the labor hours required to do a unit of work. • Developt a 600-LOC program in 60 hours. • The productivity would be 10 LOC per hour. • The calculation is simple.

26. Variations in LOC Productivity

27. Size Counters • The sizes of small programs • relatively easy to count • manually counting can be time-consuming and error-prone. • For large programs • manual counting is impractical • making automated size counters essential

28. Physical LOC Counters • The simplest type of size counts. • Count all text lines except comments and blank lines. • A text line that has both comments and source code is count as one LOC.

29. Logical LOC Counters • Similar the physical LOC counting • Except that line-counter stepping is more complex. • Try to develop if you have plenty of time • Endless debate the best way to count LOC • The key: be precise and consistent

30. Machine Countable • Manual size counting is time-consuming and inaccurate. • Automated counters will only work for defined product characteristics. • Counters can be complex, depending on the • size definition selected • counting method used

31. Imagix 4D • www.imagix.com • With Imagix 4D, software developers are able to understand, document and improve complex, third party or legacy source code. • Automate the analysis of control flow and dependencies. • For C, C++ and Java developers

32. Other Size Measures • Expert Guessing • Function Point • COCOMO

33. Expert Guessing A = The most pessimistic estimate. B = The most likely estimate. C = The most optimistic estimate. E= (A + 4B + C) 6 (Weighted average; where E = estimate).

34. 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

35. 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.

36. Summary • To effectively plan and manage your work, you must measure product size. • For different types of work, use different size measures. • For each measure, size must correlate with development time. • If the size measure does not correlate or is not automatically countable, it will not be very useful. • Every size measure should be precisely defined and automatically countable.

37. References • Watts S. Humphrey, “PSP: A Self-Improvement Process for Software Engineers”, Addison Wesley Professional, 2005. • DAAD project “Joint Course on Software Engineering”, ww2.informatik.hu-berlin.de/swt/ intkoop/daad/herc2005/talks/PSP.ppt, 2005. • Watts S. Humphrey, “Three Dimensions of Process Improvement,” CROSSTALK, February 1998.