Project Management: Inspections and Reviews Formal Specifications 5 February

Deliverables Design Document Only highest levels Details will be filled in Living document

Reviews and Inspections

Reviews and Inspections Why? Developer can’t correct unseen errors More eyes to catch problems Earlier is cheaper Integration fix typically 3-10 times the cost at design Difference in terms Review implies completed work, often reviewed by someone at a different level Inspection implies peer review of work in progress

Software Inspections Disciplined engineering practice for detecting and correcting defects Introduced at IBM by Fagan in the 1970s More formal than walkthroughs or peer reviews Roles, statistics Used for specs, code, test plans, …

Uses Early detection of errors Identification of excellence indicators Major escapes cost 2-10 times as much; minor 2-4 Identification of excellence indicators Completeness (requirements to code) Correctness (specification to code) Style (consistency) Exit criteria for life cycle phases

Additional Benefits Programmer finds errors and types of errors that he is apt to make immediately Awareness means focus on those types of errors and therefore improved skills Designers get feedback on quality of their designs Using statistical anomalies to recode

Why do inspections work? More eyes Focused activity Structure Timely Measurable criteria for passing and rework Required follow-up

Why Aren’t Inspections Used? Rigorous and formal (requires training) Time consuming 4-5 people over multiple 2 hour sessions 250-500 lines of code per hour 5-10 errors detected per session Boring, low tech Egos

References Fagan, Design and code inspections to reduce errors in program development, IBM Systems Journal (reprinted 99) Porter, Siy and Votta, A Review of Software Inspections, 1995

Will you review or inspect? What? How?

Formal Specifications

Formal Methods and Specifications Mathematically-based techniques for describing system properties Used to show completeness, consistency, unambiguity Able to be used without executing the program (inference systems)

Inference Systems Proving something about the specification not already stated Formal proofs Mechanizable Examples: theorem provers and proof checkers

Users of Specifications Requirements analysis rigor System design Decomposition, interfaces Verification Specific sections Documentation System analysis and evaluation Reference point, uncovering bugs

Properties of Specifications Unambiguous Maps to a single specificand set Consistency Maps to a non-empty specificand set Completeness Not required! Balance between underspecification and overspecification

Examples of Specification Languages Abstract data types Algebras, theories, and programs VDM (Praxis: UK Civil aviation display system CDIS), Z (Oxford and IBM: CICS), Larch (MIT) Concurrent and distributed systems State or event sequences, transitions Hoare’s CSP, Transition axioms, Lamport’s Temporal Logic Programming languages!

References J.M. Wing, A Specifier's Introduction to Formal Methods. IEEE Computer, 23(9):8-24, September 1990. Clarke et al, Formal methods: state of the art and future directions, ACM Computing Surveys, 28(4): 626--643, 1996.