Why Use Software Verification?

Software development often proves far more expensive than expected. Evidence indicates that the earlier a defect is discovered in development, the less impact it has on both the timescales and cost. Bugs discovered late in the development cycle send costs soaring and risk the integrity and safety of a system, especially if the software has been deployed.

02/01/2009


Software development often proves far more expensive than expected. Evidence indicates that the earlier a defect is discovered in development, the less impact it has on both the timescales and cost. Bugs discovered late

The typical software development life-cycle follows the familiar waterfall process.

The typical software development life-cycle follows the familiar waterfall process.

in the development cycle send costs soaring and risk the integrity and safety of a system, especially if the software has been deployed. Obviously, careful planning, organization, and a team with the correct skills all help.

Since its inception in the early 1970s, the sequential waterfall model has served as a framework for software development alternatives. In this model, each phase cascades to the next, which only starts when the defined goals for the previous phase are achieved.

In practice, earlier phases often need to be revisited as developers work iteratively and requirements come together as users test prototype versions of the system. Because of this iterative approach, it is even more important to apply suitable verification and validation (V&V) techniques at each stage and within each iteration.

Requirements

The first step or level in the waterfall model is developing system requirements. This step involves close collaboration between the ultimate user and the development team. There is much to gain by ensuring requirements are captured in full, are well understood, and are specified completely and unambiguously. Formal methods of tracking requirements are based on a mathematical approach to specification, development, and verification of software and hardware systems.

The derived class, IOFile, inherits attributes from both InputFile and OutputFile, which both inherit from File.

The derived class, IOFile, inherits attributes from both InputFile and OutputFile, which both inherit from File.

These formal methods can vary from using commonly accepted notation to the full formality of theorem proving or automated deduction—a method of proving mathematical theorems by a computer program. Although the cost of using formal methods often limits them to applications where a high level of software integrity is required, some degree of formal specification provides benefits for any software application.

Design

Traditionally, the design of large systems follows a top-down, functional decomposition approach. The system is broken down into subsystems, which pass data and control across defined interfaces. Subsystems normally comprise a number of program modules or units, and each module has a number of routines which perform distinct tasks.

With the advent of model-based design strategies, much verification can now be automated. Unit testing, previously applied only to code, can be conducted in simulations. Given a particular precondition and series of inputs, the outputs and post-conditions may be checked. The model can even be instrumented such that intermediate conditions can also be checked to ensure the correctness of different paths through the design. It is quite possible to achieve the correct results for the wrong reasons through coincidental correctness.

Implementation

Source code generally brings the first opportunity to apply sophisticated tools to verify and test an application, and it is also the point at which many of the defects are introduced. Poor programming practices and informal testing contribute to software that both fails to perform correctly and is difficult to understand and maintain. While many organizations use style guides to promote conformity and encourage greater care, it is only a small step towards the compliance striven for by developers of safety-critical systems.

Typically a programming standard contains a large number of rules and guidelines. However, a relatively new coding standard, titled “The Power of 10: Rules for Developing Safety-Critical Code,” has been devised by the Jet Propulsion Laboratory (JPL) and is restricted to only 10 verifiable coding rules. The theory is that a small, carefully selected rule set is more likely to be enforced and will still detect many of the causes leading to software defects.

The perceived quality of software under analysis classifies programming rules/guidelines by:

  • Portability: These rules highlight programming constructs that vary across different compilers.

  • Dependability: These rules expose unsafe code likely to impact performance or reliability.

  • Testability: These rules detect features that cause the testing to be more difficult.

  • Maintainability: These rules detect features difficult to understand that would impact updates or revisions such as redundancy and reuse of identifier names.

  • Complexity: These rules highlight complex code so that it can be simplified or greater caution should be exercised when modifying.

  • Style: These rules ensure that code follows the same style and adheres to recognized good programming practices.

Acceptance Testing

At the end of the implementation phase, software units are integrated and tested as sub-systems and as part of the full system. Once integration testing is complete and the product is ready for delivery to the customer, the final phase is acceptance testing.

Acceptance testing is a formal testing process conducted under the direction of the software users to determine if the operational software system meets their needs as defined by the requirements. Each acceptance test attempts to test the functionality as required by the user. These tests are different from unit tests in that unit tests are modeled and written by the developer of each module, while the acceptance test is modeled and possibly even written with or by the customer.


Author Information

Paul Humphreys is a software engineer with LDRA Ltd. responsible for the ongoing enhancement of the LDRA static analyzer. Contact him at paul.humphreys@ldra.com .




No comments
The Top Plant program honors outstanding manufacturing facilities in North America. View the 2013 Top Plant.
The Product of the Year program recognizes products newly released in the manufacturing industries.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
The true cost of lubrication: Three keys to consider when evaluating oils; Plant Engineering Lubrication Guide; 11 ways to protect bearing assets; Is lubrication part of your KPIs?
Contract maintenance: 5 ways to keep things humming while keeping an eye on costs; Pneumatic systems; Energy monitoring; The sixth 'S' is safety
Transport your data: Supply chain information critical to operational excellence; High-voltage faults; Portable cooling; Safety automation isn't automatic
Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Plant Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.

Maintaining low data center PUE; Using eco mode in UPS systems; Commissioning electrical and power systems; Exploring dc power distribution alternatives
Synchronizing industrial Ethernet networks; Selecting protocol conversion gateways; Integrating HMIs with PLCs and PACs
Why manufacturers need to see energy in a different light: Current approaches to energy management yield quick savings, but leave plant managers searching for ways of improving on those early gains.

Annual Salary Survey

Participate in the 2013 Salary Survey

In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.

Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.

2012 Salary Survey Analysis

2012 Salary Survey Results

Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
The One Voice for Manufacturing blog reports on federal public policy issues impacting the manufacturing sector. One Voice is a joint effort by the National Tooling and Machining...
The Society for Maintenance and Reliability Professionals an organization devoted...
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.