Project%20Management:%20Inspections%20and%20Reviews%20Formal%20Specifications

1
Project ManagementInspections and
ReviewsFormal 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 cant 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
• 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 Arent 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

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
• Hoares CSP, Transition axioms, Lamports
  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) 626--643, 1996.