Informatics 43 – June 2, 2015

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.

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

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

Quality Assurance (from week 7)

What software qualities do we want to assure?

Correctness

How?

• Testing• Inspections and reviews• Proofs, formal methods• Static analysis

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)

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

– 00:00 – 07:00 and 44:15 – 46:05

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;

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

Project Effort Estimation

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

Estimate uncertainty

x

2x

4x

0.5x

0.25x

Feasibility Requirements Design Code Delivery

© 2000 Ian Sommerville

What to estimate

• Effort (person-months)• Duration (calendar months)• Cost (dollars)• KLOC (thousands of lines of code)

• 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

Factors Affecting Productivity Rates

• Application domain experience• Process quality• Project size

– Negative relationship• Technology support• Working environment

A general estimation formula

• Textbook, p. 275 (13.3.1):

Units of effort = a + b(size)c + ACCUM(factors)

a base costb scales the size variablec non-linearityACCUM a function, sum or product or ?factors other influences on the effort

Comparison of FormulasHalstead Boehm Walston-Felix

KLOC E=0.7 KLOC1.50 E=2.4 KLOC1.05 E=5.2 KLOC0.91

110501001000

0.722.1

247.5700.0

22,135.9

2.426.9

145.9302.1

3,390.1

5.242.3

182.8343.6

2,792.6

• Coefficients derived using actual project data– Variability in project characteristics?

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

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 * FP1.5