1. Informatics 43 – June 2, 2015

2. Some Announcements Discussion on Friday – review. Bring questions. 0.5% extra credit for submitting the EEE Course Evaluation. Final Exam on Thursday, June 11, 8:00am- 10:00am.

3. Verification and Validation Verification: “doing the product right” – Software conforms to specifications – Every phase is consistent with the previous phase Validation: “doing the right product” – Software meets users’ needs

4. From www.easterbrook.ca/steve/2010/11/the-difference-between-verification-and-validation/

5. Quality Assurance (from week 7) What software qualities do we want to assure? Correctness How? Testing Inspections and reviews Proofs, formal methods Static analysis

6. Inspections and Reviews Humans read documents and look for defects. Surprisingly effective, especially for assuring qualities other than correctness. Many different approaches and levels of details (despite textbook, p. 220, section 10.5)

7. Formal Methods Mathematically oriented proofs of correctness. Emphasis on reliability. Note: verification only. Usually done with formal specifications. Often used for hardware verification. Leslie Lamport: http://channel9.msdn.com/Events/Build/2014/3-642 http://channel9.msdn.com/Events/Build/2014/3-642 – 00:00 – 07:00 and 44:15 – 46:05

8. Static Analysis A computer program analyzes source code and finds defects (without running the code). Lint, a tool from way back when: Pylint - http://doughellmann.com/2008/03/01/static-code-analizers-for-python.html Static analysis of Unreal Engine 4: http://www.viva64.com/en/b/0249/ if (a > b); a = 0;

9. Static Analysis John Carmack (co-founder of Id, super- programmer): The most important thing I have done as a programmer in recent years is to aggressively pursue static code analysis. Even more valuable than the hundreds of serious bugs I have prevented with it is the change in mindset about the way I view software reliability and code quality. http://www.gamasutra.com/view/news/128836/InDepth_Static_Code_Analysis.php

10. Project Effort Estimation

11. Estimating a project’s size Approach 1: Naïve estimation – Take your best guess Approach 2: Estimation by parts – Bottom-up or top-down, depending on where you start Approach 3: Re-estimation – As more time is spent on a project, uncertainty decreases

12. Estimate uncertainty © 2000 Ian Sommerville

13. What to estimate Effort (person-months) Duration (calendar months) Cost (dollars) KLOC (thousands of lines of code)

14. Longhorn Project (2003) – 16 MLOC, 5000 people, 3 years – 1067 LOC/person/year Grady and Caswell at HP (1987) – ~1100 LOC/person/year Brooks (1975) IBM OS/360 – 600-800 instructions/person/year in control group Productivity Rates

15. Factors Affecting Productivity Rates Application domain experience Process quality Project size – Negative relationship Technology support Working environment

16. A general estimation formula Textbook, p. 275 (13.3.1): Units of effort = a + b(size) c + ACCUM(factors) a base cost b scales the size variable c non-linearity ACCUM a function, sum or product or ? factors other influences on the effort

17. Comparison of Formulas HalsteadBoehmWalston-Felix KLOCE=0.7 KLOC 1.50 E=2.4 KLOC 1.05 E=5.2 KLOC 0.91 1 10 50 100 1000 0.7 22.1 247.5 700.0 22,135.9 2.4 26.9 145.9 302.1 3,390.1 5.2 42.3 182.8 343.6 2,792.6 Coefficients derived using actual project data – Variability in project characteristics?

18. What to measure Lines of code – e.g. delivered lines of executable source code Function points – count inputs, outputs, files Feature points – similar to function points, also count algorithms Object points – count screens, reports, and 3-GL components

19. Function points Analyze specifications and high-level design for – External inputs – External outputs – External inquiries – Internal logical files (e.g. classes, data structures) – External interface files The result is a number of Function Points. Maybe: person-months = 0.20 * FP 1.5