Software Process

1
Software Process

• Process Models and Improvement - 4 lectures
• Formal Methods - 1 lecture and exercise
• Future Topics
• Clean Room - 1 lecture
• Empirical basis of Software Engineering - 2
  lectures
• Final review of topics - 1 lecture

2
Formal Methods in Practice - Review and Myths
Examined

• Final chapter of Potter, Sinclair and Till
• Hall's Seven Myths of Formal Specification

3
From theory to practice -Application of Formal
Specification to SoftwareDevelopment in Practice

• Formalisms such as Z are helpful at both the
  requirements analysis phase as well as during the
  specification phase.
• Through refinement, especially operation
  decomposition, progress from the formal
  specification to the actual program code is
  possible. In this respect, formal methods can
  extend into the detailed design and
  implementation phases.
• In addition, formal specification can be used to
  direct the testing process during development.

4
Practical problems of introducing Z

• Typically Z will be introduced where other
  perhaps less formal methods are already in use.
  Therefore, it is important to choose an
  appropriate starting point for introducing a new
  method - perhaps at the time of a major
  re-development, or alternatively, a piece-meal
  approach of introducing the new method gradually
  for maintenance work.
• The need for training must be given adequate
  consideration. Particularly the need for
  dispelling fears about the difficulty of the
  mathematics of formal specification -
  particularly those held by non-technical
  managers. (IBM's readers and writers training
  could help.)
• Potter, Sinclair and Till suggest that small
  pilot projects may provide the best route of
  introduction.

5
Other considerations

• As well as training, introduction of any new
  method requires support throughout the process of
  usage.
• Extra time may be needed during the early phases
  of development as formal specification may
  uncover more errors earlier on in the SLC.
• Two benefits of formal methods may be considered
  as counter balancing this extra time
• the review process may be aided by use of a
  mathematical notation in place of natural
  language and
• extra time spent in specification may be saved
  during the later phases of development.

6
Three stages to introducing Z

• 1 - Notation and method taught to developers and
  they apply it to existing problems and in small
  pilot projects.
• 2 - Once confidence in using the notation is
  established, simple proofs (e.g. calculation of
  pre-conditions) may be attempted.
• 3 - Proof skills are applied in rigorour
  development of program code from formal
  specifications.
• Because the cost of proof may be high, two cases
  can be made for its application.
• 1 - For critical systems, those on which human
  life depends, formal methods may be mandated to
  ensure absolute conformance of the implementation
  to the specification. Cost may not be an issue
  here. Also where the cost of replacing faulty
  systems is greater than the cost of ensuring
  correctness, e.g. some embedded systems.
• 2 - Cost may be justified on the basis of
  improved productivity with an anticipated
  reduction in time and effort needed for
  development. Here verification is not so
  important as the clarity of communications which
  formal methods support.

7
Relationship to other methods
Formal Methods
Process Algebras CSP
Algebraic techniques OBJ
State based technques Z, VDM
can be used in complementary fashion with CSP
describing intercomputer communications
pre-prototyping and as the basis of prototyping
Sets of equations to capture behaviour directly "m
ore abstract descriptions"
Structured Analysis methods may be used to
structure the specification while Z is used
to specify components or Z specification may be
followed by DFD for system structure
8
Industrial Applications I

• The Customer Information and Control System
  (CICS) Product
• Work at IBM Hursley Lab.
• CICS is a development tool for producing
  interactive commercial and financial systems.
• .5 M lines of code
• gt 200 IBM staff trained as readers or writers of
  Z
• Work since 1981 has resulted in 50 K lines of
  code for the new version of CICS having been
  specified in Z with a 9 cost saving in
  development.
• Proof is used to simplify pre-conditions.
  Refinement is done informally with review groups.
• Primary benefits in documentation, communication
  and thinking.

9
Industrial Applications II

• The Inmos T800 Floating Point Transputer
• Main steps in approach
• Formal specification of the IEEE Floating Point
  Standard in Z
• Decomposition into small specification units
• Occam programs developed to satisfy the
  decomposed specification
• Occam code used to generate the microcode
• Main lesson learnt
• As most errors found were due to human
  transcription errors, the need for tool support
  was identified.

10
Seven Myths of Formal Methods

• Background
• Praxis Systems is a software engineering company
  using formal methods on real projects. Hall's
  paper draws on his company's experience in using
  formal methods to challenge seven common myths
  about formal methods.

11
The Myths

• 1 - Formal methods can guarantee that software is
  perfect.
• 2 - They work by proving that programs are
  correct.
• 3 - Only highly critical systems benefit from
  their use.
• 4 - They involve complex mathematics.
• 5 - They increase the cost of development.
• 6 - They are incomprehensive to clients.
• 7 - Nobody uses them for real projects.

12
Myth 1

• Formal methods can guarantee that software is
  perfect.
• Counter fact
• Formal methods are very helpful at finding errors
  early on and can nearly eliminate certain classes
  of error.
• Fallibility of formal methods arises from two
  facts
• limits on proofs, and mistakes made in doing
  proofs.
• A proof is simply a demonstration that one formal
  statement follows from another. The real world is
  not a formal statement. All engineering is
  concerned with making models of the real world
  and using these models to design artifacts.
• There are limits on modelling techniques. Models
  only cover some aspects of a program's behaviour.
  The correspondence between the formal description
  and the real world is limited. We do not have
  good models for nonfunctional properties such as
  performance, reliability, maintainablity and
  availibility.

13
Demonstrations of Correctness

• Despite these limitations
• Some properties can be established only by formal
  reasoning, e.g. universal statements like "the
  program will always log user actions".
• The relationship between the specification and
  its implementation is formal and be proved to be
  correct.

14
Error Detection

• Despite mistakes made by human specifiers, formal
  methods do work because they offer qualitatively
  different and better guarantees than any other
  methods. They offer specifications that can be
  refuted.
• Further the ability to expose errors is one of
  strengths of formal methods. like IBM, Praxis
  found inspections of formal specifications
  uncovered more errors than found in inspection of
  informal specifications.

15
Myth 2

• Formal methods are all about program proving.
• Counter fact
• They work largely by making you think very hard
  about the system you propose to build.
• Formal methods are primarily about specification.
  The specification can act as a contract between
  specifiers and implementers.
• 4 steps in applying Formal Methods
• 1 - develop the specification
• 2 - prove properties of the specification
• 3 - develop program by refinement of the
  specification
• 4 - verify that program is a correct
  implementation of the specification
• N.B. many projects stop at Step 1. In any case,
  specification is central to the remaining steps.

16
Praxis Experience

• Praxis found that formal methods used in
  specification on the CASE project helped in the
  following ways
• clarifying the requirements,
• discovering latent errors,
• making decisions about functionality at the right
  stages.
• Hall argues that "thinking hard" about proving
  properties may give more benefits than proofs of
  implementation, as correcting specification
  errors is more costly than correcting
  implementation errors.

17
Myth 3

• Formal methods are only useful for
  safety-critical systems.
• Counter fact
• They are useful for almost any application.
• Formal methods should be used wherever the cost
  of system failure is high. Systems in the
  following categories can benefit from formal
  methods
• critical systems ( safety critical, but also
  essentical to operation)
• replicated systems
• embedded systems
• commercial sensitive systems
• N.B. almost all software qualifies under one or
  more of these categories.

18
Further Considerations

• Formal methods can also benefit in other areas
• fitness for purpose
• maintainability
• ease of construction
• better visibility
• The rigor used in applying formal methods can be
  dependent on the application.
• Many benefits come simply from the formal
  specification stage.

19
Myth 4

• Formal methods require highly trained
  mathematicians.
• Counter fact
• They are based on mathematical specifications,
  which are much easier to understand than
  programs.
• The mathematics for formal specification is easy
  set theory and logic.
• With training, the specifications are easier to
  understand than the corresponding programs.
• Getting the right level of abstraction is the
  most difficult part - specifiers need to get away
  from programming language details.
• Training is essential - in discrete mathematics,
  in the formal notation and through tutoring and
  consultation in real projects.
• It is unrealistic to expect the majority of
  software engineers to be able to do proofs easily.

20
Myth 5

• Formal methods increase the cost of development.
• Counter fact
• They can decrease the cost of development.
• Evidence suggests that use of formal methods
  results in lower development costs.
• This is comes from experiences recorded by
  Praxis, IBM and Rolls-Royce.
• Using formal methods typically increases the time
  spent on specification, but shortens the time
  spent on down stream phases of development.
• Over the lifetime of the specification, its size
  can increase during production and decrease
  during subsequent simplification.

21
Future Investments

• Because of the investment in specification, in
  preliminary training and its development, its
  maintenance for future use is important.
• So when errors are found in the later phases of
  development, it is important to feed these back
  in correcting the specification.
• This was found to impose a very small overhead
  during the later phases.
• It makes the specification more value especially
  for guiding maintenance in the future as well as
  reuse in other developments.
• Also it is important to record design decisions
  made and alternatives considered during
  specification for subsequent users of the
  specification.

22
Myth 6

• Formal methods are unacceptable to users.
• Counter fact
• They can help clients understand what they are
  buying.
• The specification captures what the customer
  wants before it is built.
• Thus it has a valuable role and can be the basis
  of a contract between the developers and their
  customer.
• However, care must be taken to make the
  specification comprehensible to the user via
  various means
• natural language paraphrasing
• demonstration of consequences
• animation of the specification via prototyping

23
Myth 7

• Formal methods are not used on real, large-scale
  software.
• Counter fact
• They are being used successfully on practical
  projects in industry.
• Examples cited by Hall
• 1 - IBM's work on CICS
• 2 - Inmos' work on the Floating point unit for
  the transputer
• 3 - Plessey's Secure Multiprocessing of
  Information by Type Environment - secure computer
  architecture
• 4 - Tektronix's specification of oscilloscope
  families
• 5 - Danish Datamatik Center's formally specified
  compilers
• 6 - Praxis work on the Computer Aided Software
  Engineering project and on specifying the
  Portable Common Tool Environment
• 7 - Rolls-Royce's work on formally specifying
  nuclear-reactor control software

24
Conclusion
Only highly critical systems benefit from their
use.
Nobody uses them for real projects.
Formal methods can guarantee that software is
perfect.
They are incomprehensible to clients.
They work by proving that programs are correct.
They involve complex mathematics.
They increase the cost of development.
They can help clients understand what they are
buying.
Formal methods are very helpful at finding errors
early on and can nearly eliminate certain classes
of error.
They are useful for almost any application.
They can decrease the cost of development.

• They are based on mathematical specifications,
  which are much easier to understand than
  programs.

They work largely by making you think very hard
about the system you propose to build.
They are being used successfully on practical
projects in industry.
25
Reading assignment and exercise

• Read Tony Hoares slides on Assertions -
  http//research.microsoft.com/thoare/Assertions2
  0prog20prosp_files/v3_document.htm and Jon
  Pincus slides on Process Improvement at
  Microsoft - from his talk Analysis is Necessary,
  But Far from Sufficient Experiences Building and
  Deploying Successful Tools for Developers and
  Testers
• Write an essay (max. 1.5k words) on the topic
• Practical Process Improvement through the
  introduction of new methods and tools