1. Formal Methods in Software Engineering
Adding Formal Methods to a Project
Lecture 32

2. Adding Formal Methods to a Project
Remember using formal methods is not an all or nothing process
The level of rigor used should be tailored to fit the specific project with respect to
system criticality level
budget
schedule
technical environments

3. Best Use of Formal Methods
New system components
adaptive or corrective maintenance
Poorly understood requirements
perfective maintenance
Highly critical system components
preventative maintenance

4. Management Considerations - part 1
Project staff expertise
Formal Methods Expert (seeks to match applications with appropriate methods, tools, and techniques)
Project Domain Expert (evaluates candidate application and identifies the best to experiment with)
Project scale
best to only try applying formal methods on 1 or 2 components the first time out
can be viewed as a training exercise
demonstrate value of formal methods with low risk

5. Management Considerations - part 2
Project training
use existing staff with formal methods expertise
provide in-house, hands-on training with formal methods languages and support tools
outside experts provide training and advice in early project stages
Process integration strategy
few changes needed if requirements analysis procedure are well-defined
formal methods can complement existing process steps

6. Management Considerations - part 3
Project guidelines and standards
writing formal specifications requires guidelines similar to those found in existing
configuration management procedures
coding style guidelines
documentation standards
Guidelines will have the greatest impact on the project if they are in place before the project or training begins

7. Technical Considerations - part 1
Type of application
applications with greater complexity will benefit more from formal methods use than simple applications
logic and discrete math applications benefit more than numerical applications
Size of application
optimal code size is between 4K LOC and 25 KLOC
Type of formal methods used
project objectives (better documentation or early defect detection)

8. Types of Analysis/Formal Methods
The preferred type of analysis and method is strongly influenced by the project objectives
Modest
Low Level
of Rigor
(e.g. formal
specifications for
documentation)
Project Objectives
for the Use of
Formal Methods
To optimize the chances for a positive FM experience, it is important to match the project objectives for the use of FM and the type of FM chosen.
We have emphasized from the start the spectrum of rigor available in FM tools and techniques. Of course, the higher the rigor the more effort required to use a given FM. Hence the level of rigor should be only high enough to insure the objective desired in the use of FM. In short, choose the method (and tool) appropriate for the outcome -- don’t apply overkill.
Moderate
Moderate Level
of Rigor
(e.g. early defect
detection)
Ambitious
High Level
of Rigor
(e.g. assure
correctness of critical
properties or algorithms)
L 4

9. Technical Considerations - part 2
Level of rigor for formal methods
usually determined by the methods dependence on automate tool support (higher rigor = more dependent)
Scope of formal methods use affected by
number of system components
degree of system functionality
number of life cycle phases

10. Level of Rigor for Formal Methods
Increasing rigor is usually associated with increasing dependence on automated support tools
require formal methods tools
Levels of Rigor
high
medium
This slide follows up the issues raised on the previous slide and expands the discussion of the role of the level of rigor in the FM chosen.
It can be pointed out that some formal methods can even be applied without tool support. These methods will be appropriate for some projects and project objectives. On the other hand, to gain significant benefits in a complex problem domain will require a larger ante, and this means FM with tool support.
low
informal
manual
reviews,
inspections
modeling
using logic
and discrete
mathematics
formal
specification
language
with type
and syntax
checking
fully formal
specification
language
with rigorous
semantics and
proof checking
L 4

11. Scope of Formal Methods Use
Three dimensions of scope of formal method use
Number of System
Components
all components
The graph is intended to represent the most important of the parameters to be considered when deciding the scope of FM involvement on a project. A project manager could choose to limit the use of FM in any or all of the three dimensions pictured, thus tailoring the use of FM to a particular project’s environment, structure, and staff expertise. Only teams experienced in FM would be able to handle a configuration with high choices in all or even several of these dimensions.
most important
function(s)
selected
component(s)
single
phase
all functions
Degree of
System Functionality
Number of Phases
in Life Cycle
all phases
L 4

12. Technical Considerations - part 3
Type of formal methods tools used
must take project objectives, level or rigor, and scope into account when selecting a formal methods tool
other important factors
available training
history of use
ease of learning and ease of use
effective support
match with problem domain

13. Plan for Introducing Formal Methods on a Project - part 1
Identify formal methods and domain expertise
expertise in both needed
Define scale of formal methods involvement
trial, partial, or full project?
Choose an application
Select suitable formal methods to be use

14. Plan for Introducing Formal Methods on a Project - part 2
Select formal methods tools to use
consider application and available resources
Implement formal methods training
Develop project guidelines
analogous to those for conventional software engineering processes
Track and document process changes
update and revise process using measurement-based project feedback

15. Cost Considerations
The act of formalizing specifications can be considered to be cost-effective if you consider the cost associated with fixing defects later in the software life cycle
Proof checking may be less cost-effective, so choose the problem domain wisely
The highest level of rigor should be reserved for mission critical and highly complex system components

16. Limitations of Formal Methods
Formal methods are not a magic solution to all software development problems
Need to use formal methods in suitable project environments if benefits are to exceed their costs
Formal methods and domain expertise must be fully integrated to achieve positive results

17. Benefits of Formal Methods
Formal methods can help detect defects earlier in the software life cycle
Formal methods can be applied with various levels of resource investment
They can be integrated into existing process models with minimal disruption
They can improve software quality

18. Prerequisites to Using Formal Methods
Need a reasonably mature, disciplined development environment
Environment should emphasize quality (in fact quality ceilings may have been reached using traditional methods)
Project staff must have adequate expertise, training, and support