1. Project Management: Inspections and Reviews Formal Specifications
5 February

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

3. Reviews and Inspections

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

5. 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, …

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

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

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

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

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

11. Will you review or inspect? What? How?

12. Formal Specifications

13. 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)

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

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

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

17. 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!

18. 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): , 1996.