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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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