bannerb

This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C

SWE-135 - Static Analysis

1. Requirements

4.4.4 The project manager shall verify the software code by using the results from static analysis tool(s).

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 Applicability Across Classes

If Class D software is safety critical, this requirement applies to the safety-critical aspects of the software.

Class

     A      

     B      

     C      

   CSC   

     D      

   DSC   

     E      

     F      

     G      

     H      

Applicable?

   

   

   

   

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.

2. Rationale

The static analysis requirement for NASA software projects increases the quality and safety of code developed for NASA Missions. Using static analysis helps to ensure that code meets the coding standards/criteria established by the project team (SWE-061) and common coding errors are eliminated before system integration and test (SWE-066). Studies show that the cost of catching errors dramatically increases from one phase of development to the next by roughly a factor of 10 136. Eliminating errors during implementation results in cost and time savings during integration and testing, which is particularly important cost saving factor for projects using high-fidelity test beds.

3. Guidance


Modern static code analysis tools can identify a variety of issues and problems, including but not limited to dead code, non-compliances with coding standards, security vulnerabilities, race conditions, memory leaks, and redundant code. Typically, static analysis tools are used to help verify adherence with coding methods, standards, and/or criteria. While false positives are an acknowledged shortcoming of static analysis tools, users can calibrate, tune, and filter results to make effective use of these tools. Software peer reviews/inspections of code items can include reviewing the results from static code analysis tools.

Static analysis tools may not be readily available for some platforms or computing languages. If static analysis tools are determined to be unavailable, the project can document the alternate manual methods and procedures to be used to verify and validate the software code. These manual methods and procedures will be addressed or referenced in the project's compliance matrix against this requirement.

For critical code, it is essential to use sound and complete static analyzers. Sound and complete analyzers guarantee that all errors are flagged and that no false negatives (i.e., an erroneous operation being classified as safe) are generated. Such commercial analyzers are expensive but necessary for critical applications. Note that sound and complete static analyzers are now available free of charge for C and C++ software systems (see the Tools Table provided under the Resources tab).

The cost of sound and complete commercial tools can be prohibitive for projects working on non-critical software systems. However there are other static analyzers available free of charge, which can identify many common errors or deviations from standards or good coding practices. It is a best practice to use some type of static analysis in all software development efforts, but required for mission-critical software.

Introducing the routine use of static analyzers in an existing development process can be a tricky proposition. Even if the software team is convinced of the benefits such tools can bring, projects need to be careful and make the introduction of static analysis as unobtrusive as possible. Fortunately, current generation static analyzers come with interfaces similar to compilers, such as GNU (Unix-like computer operating system developed by the GNU Project) Compiler Collection (GCC), and/or Integrated Development Environments (IDEs), such as Eclipse, which helps in gaining acceptance. However, the user interface is not the only factor to consider. Here is a non-exhaustive list of potential challenges:

  • The static analyzer may not accept your code. It is not uncommon that the first problem (after installation) with a static analyzer is with its inability to process code.

Today, most commercial static analyzers rely on the same front-end code processor (e.g., the Edison Design Group (EDG) front-end for C and C++), which means that they in principle are able to process the same code. However, the algorithms used for the analysis might not handle code constructs in similar manners, and therefore, there are differences amongst tools. This problem is even more prevalent with tools that are free of charge because they may rely on different parsers, so commercial tools are recommended.

Guidance: For existing projects interested in evaluating commercial static analyzers, consider the following pointers:

    • Start with a static analyzer that comes with a free evaluation period and evaluate it on your most “tricky” code, i.e., with all the language constructs and libraries that the team commonly uses.
    • Choose a commercial analyzer based your evaluation, not on a vendor demonstration; vendors will only show what works, not the potential challenges.
    • Choose a tool that comes with extensive technical support. Your application might have quirks that do not seem like quirks to your project, but might be to others. So, readily available support can be a key factor in effectively using a static analyzer. For this reason, commercial tools are recommended. Free static analyzers will not generally provide the support the software team may need.
    • Choose a tool that relies on commonly used parsers to mitigate future issues. For example, for C and C++, it is best to choose a tool that relies on GCC for processing code. In general, GCC can process all C and C++ programs and also offers options to cover old constructs or customized extensions. 

Matching a static analyzer with the development team’s compiler will eliminate many challenges. Even if the tool has a good parser, make sure to give the tool access to the right libraries. Remember that a static analyzer is essentially a fancy compiler that does not produce executable code. Getting the compiling and linking environment right can be challenging if the chosen tool does not use the same parser as the team’s compiler. 


  • The static analyzer may take an extensive amount of time to finish the analysis. In cases where the analysis is in-depth and code is “complex”, a static analyzer can take an inordinate amount of time to come back with results. Using a static analyzer includes making configuration decisions regarding precision, scalability, and language construct coverage. The most precise analyzers use sophisticated algorithms and usually have large memory requirements. These factors may result in slow analysis times and in running out of memory (which causes swapping with “slow” storage mechanisms, e.g., hard disks).

Guidance: Select and configure a static analyzer to operate within a diurnal development cycle and consider two analysis steps. As a rule of thumb, don’t set up a static analysis session to take more than eight hours. This will ensure that you can run overnight and offer new results every morning.  Note that the most precise static analyzers come with different levels of analysis, which can be configured to fit time requirements and later to run a precise analysis of the project at select points in the development process.  Fast but imprecise analyzers can be added to produce quick results, but will produce more warnings. Care must be taken to filter results, remove irrelevant findings, and also to configure the tool without suppressing useful, if noisy, code checks. 

With static analysis, there is often a trade between precision and scalability. You can expect to spend time upfront configuring the static analyzer to the particular needs of the project. For example, a quick, but crude, static analyzer will produce quick feedback within a normal work cycle, and, a slow, but precise, analyzer can be run before a major release. Note that there are some precise commercial tools that are customizable for rapid analysis.


  • The static analyzer comes back with too many warnings. Fortunately, there are now many mechanisms (filtering, analysis tuning, increased precisions) to deal with this problem. This challenge also stems from the need to trade precision for scalability. For example, you may configure an analyzer to be complete, which means that it needs to flag every possible error. In doing so, it relies on approximations (called abstractions in the literature), which lead the analysis to consider execution paths that may not be realizable.  Therefore the analyzer may not distinguish between a real error and a possible error (warnings). The question is: “What can be done when faced with an overwhelming number of warnings?”

Guidance: First, make sure you are familiar with the static analyzer. Static analyzers that look for errors fall into two categories: debuggers and certifiers. Debuggers try to find bugs quickly, and in doing so, they cut many corners; thus they usually generate many warnings. Certifiers are slower but they try to characterize every operation as safe, unsafe, potentially unsafe, or dead. Depending on your need, pick one or the other, or use one or the other at the proper place in your process. Note that certifiers are recommended for safety critical code.

Second, make sure that your static analyzer has a filtering capability. Most come with a means of filtering by types of errors. However, if possible, pick a tool that can rank warnings so that you can focus on the most likely bugs. Some tools will do that automatically and present only a percentage of all the warnings. Lastly, it may be necessary to write a customized script to filter results.

When triaging warnings or errors, it is recommended to first process errors that appear early in the execution and re-run the static analyzer to avoid a lot of unnecessary work. As with compiler errors, fixing an early error might lead to the elimination of many later errors/warnings. This dependency between warnings is why it is recommended to run analysis during the development process; the results are addressed and cascading side effects less likely to accumulate.  


Checking coding standards/criteria through the use of a static analysis tool complements manual code reviews (SWE-087), and results in safer software systems. Coding standards/criteria (see also SWE-061) ensures code consistency across a project, and facilitates not only reviews but also software system integration. Software components that do not comply with coding standards can result in incorrect assumptions about the component, which can result in errors at later development stages. Debugging can also be hampered by deviations from coding standards/criteria since they can result in misleading assumptions. Enforcement of coding standard yields benefits that can continue into the later software life-cycle phases, reducing software maintenance complexity and fostering code reuse.

Static analysis is applicable to a wide range of software systems, with exceptions when tools are not available for a particular platform or programming language. Note that there are many available tools for widely used languages such as Ada, C, C++ and Java (see the Tools Table referenced under the Resources tab).

The NASA IV&V Program maintains access to an extensive set of static code analyzers to support the evaluation of a diverse set of coding languages including C, C++, Ada, Java, and Fortran.  IV&V has established a robust infrastructure to support the independent, meaning outside of the developers software development environment (SDE), execution of these tools as well as a mature capability for the prioritization and evaluation of the analyzer results.  The IV&V Program regularly utilizes these analyzers in the evaluation of the Agency’s safety and mission critical software and can provide fee for service support for projects not currently receiving IV&V from the NASA IV&V Program.  For more information please contact the IV&V Program business representatives via the IV&V Program website 464.

4. Small Projects

Small projects can benefit from inserting static analysis in their development process. As mentioned above, there are many static analyzers available free of charge. So, using these does not impose an additional cost for a small project with constrained resources. However, it might have an impact on development time, since it takes time to get used to a new tool and free tools tend to generate a lot of false positives.

The time spent getting used to a tool is negligible. Most tools use the same interfaces as compilers and are not difficult to use. There might be differences due to the language parser used by the tool. To ensure smooth integration of the tool in the development process, pick a tool that relies on parsers from common compilers (e.g., GCC). This helps to ensure that the tool can be easily integrated in existing make-files or other compiling mechanisms.

Generation of many false positives can be a problem since it might overwhelm the users. In some sense, it is similar to the problem of choosing an adequate warning level for a compiler: generating too many warnings causes them to be ignored. Choose a static analyzer that has the capability of filtering results or that can be adjusted to generate less warnings. In general, it is a good habit to start using a static analyzer at the level that generates fewer warnings and to slowly increase the levels until too many warnings are being generated.

5. Resources

5.1 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

Tool nameTypeOwner/SourceLinkDescriptionUser

Rational Suite for Technical Developers

COTS

IBM Rational

http://www-03.ibm.com/software/products/en/developer ...

Rational Suite for Technical Developers provides complete cross-functional support through product integrations and workflow to optimize real-time and embedded development.

IV&V, GSFC

Wireshark

Open Source

Wireshark Foundation

https://www.wireshark.org ...

Wireshark is the world's foremost network protocol analyzer. It lets you see what's happening on your network at a microscopic level.

LaRC, KSC, IV&V

Windchill FTA (formerly RELEX)

COTS

PTC

https://www.ptc.com/en/products/plm/plm-products/windchill ...

By helping you construct a graphical representation of the critical issue and its contributing events, Windchill FTA (formerly Relex Fault Tree) provides the analysis tools required to help mitigate its occurrence or impact. The powerful analytical capabilities of Windchill FTA quantify system risk and reliability, helping you make targeted decisions about design, maintenance, and controls to reduce the probability of failures.

IV&V, KSC

Vault

Academic

MicroSoft

http://research.microsoft.com/en-us/people/maf/ ...

An experimental system, in development at MicroSoft by Rob DeLine and Manuel Fahndrich. It is based on formal annotations placed in the code. (Link needs to be updated.)

TBD,

Valgrind Memory Analyzer

Open Source

Valgrind

http://valgrind.org/ ...

Valgrind is an instrumentation framework for building dynamic analysis tools. There are Valgrind tools that can automatically detect many memory management and threading bugs, and profile your programs in detail. You can also use Valgrind to build new tools.

LaRC, JPL, KSC

UNO

By Request - Contact User for a copy of this tool.

JPL

http://spinroot.com/uno ...

JPL  Static code analysis (C language)

JPL

Simulink

COTS

MathWorks

http://www.mathworks.com/products/simulink/ ...

Simulink® is an environment for multidomain simulation and Model-Based Design for dynamic and embedded systems. It provides an interactive graphical environment and a customizable set of block libraries that let you design, simulate, implement, and test a variety of time-varying systems, including communications, controls, signal processing, video processing, and image processing.

IV&V, Stennis, GSFC, ARC, GRC, JPL, MSFC, KSC, JSC

Saturn

Academic

Alex Aiken-Stanford University

http://saturn.stanford.edu/index.html ...

The goal of the Saturn project is to statically and automatically verify properties of large (meaning multi-million line) software systems. The focus of the work is simultaneously achieving scalability, precision, and a straightforward way of expressing analyses that is easy to reason about. Version 1.2.

TBD

RCAT

NASA Owned

NASA NSC

http://nsc.nasa.gov/RCAT/ ...

The NASA Root Cause Analysis Tool (RCAT) is designed to facilitate the analysis of anomalies, close calls, and accidents and the identification of appropriate corrective actions to prevent recurrence. The RCAT software provides a quick, easy, accurate, and repeatable method to perform and document root cause analysis, identify corrective actions, perform trending, and generate data usable in precursor analysis and probabilistic risk assessment.

IV&V

Rational Clearquest

COTS

IBM Rational

http://www-01.ibm.com/software/awdtools/clearquest/ ...

Change management software that helps improve developer productivity while accommodating the methodologies, processes and tools that best fit the project and the people on the team. This software provides tools and processes that allow you to maintain control of changes while catering to the diverse needs of the developer.

IV&V, JSC

Rational Clearcase

COTS

IBM Rational

http://www-01.ibm.com/software/awdtools/clearcase/ ...

Provides controlled access to software assets, including code, requirements, design documents, models, test plans and test results. It features parallel development support, automated workspace management, baseline management, secure version management, reliable build auditing, and flexible access virtually anytime, anywhere.

IV&V, JSC

QAC

COTS

Phaedrus Systems

http://www.phaedsys.org/principals/programmingresearch/index.html ...

Proprietary language parsing engines to statically analyze your source code. They identify problems caused by language usage that's dangerous, overly complex, non-portable, or difficult to maintain. Plus, they include the basic building blocks for coding standard enforcement.

JPL

PurifyPlus

COTS

UNICOM Systems, Inc.

https://teamblue.unicomsi.com/products/purifyplus/?cmmcuid=17201434002914876099162cmmcsid50200000=14 ...

Run-Time Analysis Tools for Application Reliability and Performance

LaRC,JPL

PolySpace

COTS

MathWorks

https://www.mathworks.com/products/polyspace.html ...

Polyspace® static code analysis products use formal methods to prove the absence of critical run-time errors under all possible control flows and data flows. They include checkers for coding rules, security vulnerabilities, code metrics, and hundreds of additional classes of bugs.

ARC, IV&V

PMD

Open Source

PMD

http://sourceforge.net/projects/pmd/ ...

PMD is a source code analyzer. It finds common programming flaws like unused variables, empty catch blocks, unnecessary object creation, and so forth. It supports Salesforce.com Apex, Java, JavaScript, XML, XSL.

KSC

Semmle

COTS

Semmle

https://semmle.com/case-studies/semmle-nasa-landing-curiosity-safely-mars ...

NASA JPL are using Semmle QL throughout the organization to enforce NASA’s coding standards, to find and eradicate critical software problems and their variants, as well as Semmle LGTM to effectively share best practices and knowledge across the team of NASA JPL’s flight software developers and to prevent variants of known problems from ever being introduced into mission software.

JPL

mygcc

Academic

Nick Volanski

http://mygcc.free.fr/ ...

An extensible version of gcc (the GNU C compiler), that can be customized by adding user-defined checks for detecting for example memory leaks, unreleased locks, or null pointer dereferences. User-defined checks are performed in addition to normal compilation, and may result in additional warning messages. Mygcc allows programmers to add their own checks that take into account syntax, control flow, and data flow information.

TBD

Matlab

COTS

Mathworks

http://www.mathworks.com/products/matlab/ ...

MATLAB® is a high-level language and interactive environment that enables you to perform computationally intensive tasks faster than with traditional programming languages such as C, C++, and Fortran.

ARC, DFRC, GRC, GSFC, IV&V, JPL, MSFC, WFF, JSC, LaRC, SSC, KSC

Lint Plus

COTS

Cleanscape

http://legacy.cleanscape.net/products/lintplus/index.html ...

From the website: "Cleanscape LintPlus is a static source code analysis tool for ANSI C that reduces your organizational exposure to risks from latent software problems by automatically identifying problems at their source -- in the C source code prior to compiling or executing programs. From its first use, this venerable C source code analysis tool can save you hundreds of hours in code debugging, greatly reducing resources required for C testing efforts."

TBD

Lint

COTS

Gimpel Software

http://www.gimpel.com/html/index.htm ...

Also PC-Lint and FlexeLint. It will thoroughly check your C/C++ source code for bugs, glitches, inconsistencies, non-portable constructs, and much more, so you can find and fix your bugs more quickly, and more economically, than with traditional debugging procedures

LaRC, ARC

LDRA

COTS

Liverpool Data Research Associates

http://www.ldra.com/ ...

Liverpool Data Research Associates (LDRA) is a provider of software analysis, test and requirements traceability tools for the Public and Private sectors and a pioneer in static and dynamic software analysis.

LaRC (CLARREO), JSC

KlocWork Insight

COTS

Rogue Wave Software

https://www.roguewave.com/products-services/klocwork ...

A proven and widely deployed development productivity solution, Klocwork Insight enables early detection of a wide range of critical coding issues. With Klocwork Insight, software developers can run powerful static analysis at their desktop, and team leads and architects can access architecture visualization as well as important build-level metrics and trending data.

KSC (Launch Control System), ARC, JPL, IV&V

IKOS

Government

NASA

https://ti.arc.nasa.gov/opensource/ikos/ ...

Inference Kernel of Open Static Analyzers. IKOS is a C++ library designed to facilitate the development of sound static analyzers based on Abstract Interpretation.

ARC

Hudson

COTS

Oracle

http://hudson-ci.org/ ...

Hudson is a continuous integration (CI) tool written in Java, which runs in a servlet container, such as Apache Tomcat or the GlassFish application server. It supports SCM tools including CVS, Subversion, Git and Clearcase and can execute Apache Ant and Apache Maven based projects. Version 3.3.3

ARC

Fortify

COTS

MicroFocus

https://software.microfocus.com/en-us/products/static-code-analysis-sast/overview ...

MicroFocus Fortify is a static code analysis tool that is used to scan software for security vulnerabilities. Fortify is used extensively through the DoD community. GSFC uses Fortify for its DOD Clients. The NASA OCIO procured an enterprise license of Fortify. Please contact the SOC for more information soc@nasa.gov.

GSFC

Flexelint

COTS

Gimpel Software

http://www.gimpel.com/html/flex.htm ...

FlexeLint are powerful static analysis tools that will check your C/C++ source code and find bugs, glitches, inconsistencies, non-portable constructs, redundant code, and much more. It looks across multiple modules, and so, enjoys a perspective your compiler does not have.

IV&V

FindBugs

Open Source

University of Maryland

http://findbugs.sourceforge.net ...

FindBugs, a program which uses static analysis to look for bugs in Java code. It is free software, distributed under the terms of the Lesser GNU Public License. The current version of FindBugs is 3.0.1, released on 13:05:33 EST, 06 March, 2015.

GRC (EVA Sim; EVA-Informatics), ARC, JPL, KSC

Enterprise Architect

COTS

Sparx Systems, Inc.

http://www.sparxsystems.com/ ...

Enterprise Architect provides complete traceability from requirements, analysis and design models, through to implementation and deployment. ...

IV&V

Cruise Control™

Open Source

Cruise Control™

http://cruisecontrol.sourceforge.net/ ...

CruiseControl™ is both a continuous integration tool and an extensible framework for creating a custom continuous build process. Version 2.8.4

ARC

Cppcheck

Open Source

SourceForge

http://cppcheck.sourceforge.net ...

Cppcheck is a static analysis tool for C/C++ code. It provides unique code analysis to detect bugs and focuses on detecting undefined behaviour and dangerous coding constructs. The goal is to detect only real errors in the code (i.e. have very few false positives). Version 1.84

KSC

Coverity® Prevent and Extend™

COTS

Synopsys

https://www.synopsys.com/software-integrity/security-testing/static-analysis-sast.html ...

Static code analysis

JPL, IV&V

Codesurfer®

COTS

Grammatech

https://www.grammatech.com/products/codesurfer ...

A code browser that understands pointers, indirect function calls, and whole-program effects.

IV&V

CodeSonar®

COTS

Grammatech

http://www.grammatech.com/products/codesonar/overview.html ...

By analyzing both source code and binaries, CodeSonar enables teams to analyze complete applications, enabling you to take control of your software supply chain and eliminate the most costly and hard-to-find defects early in the SDLC.

IV&V, ARC (NanoSat), JPL

CodePeer

COTS

AdaCore

http://www.adacore.com/codepeer/ ...

CodePeer is an Ada source code analyzer that detects run-time and logic errors. Version 18.1

IV&V

CodeHawk C Analyzer

COTS

Kestrel Technology

https://www.tekspedite.com/technologyprofile/30 ...

CodeHawk C analyzer is a software assurance tool capable of proving the absence of all memory access vulnerabilities in C source code by leveraging KT’s abstract interpretation engine, a static analysis technology able to mathematically model program behavior.

ARC

Code to FlowChart

COTS

AthTek

http://www.athtek.com/code-to-flowchart.html ...

Code to FlowChart is an advanced source code to flowchart converter for software engineers and document writers. It can automatically generate flowchart/NS chart from source code, and helps users to understand complex program structures by visual diagrams.

LaRC

CoCoSim

Open Source

NASA Ames RSE Group

https://github.com/coco-team/cocoSim ...

CoCoSim is an automated analysis and code generation framework for Simulink and Stateflow models. Specifically, CoCoSim can be used to verify automatically user-supplied safety requirements. Moreover, CoCoSim can be used to generate C and/or Rust code. CoCoSim uses Lustre as its intermediate language. CoCoSim is currently under development.

ARC

Clang Static Analyzer

Academic

LLVM

http://clang-analyzer.llvm.org/index.html ...

A source code analysis tool that find bugs in C and Objective-C programs. Currently it can be run either as a standalone tool or within Xcode. The standalone tool is invoked from the command-line, and is intended to be run in tandem with a build of a codebase.

TBD

CheckStyle

Open Source

SourceForge

http://checkstyle.sourceforge.net/ ...

Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard. It automates the process of checking Java code to spare humans of this boring (but important) task. This makes it ideal for projects that want to enforce a coding standard.

KSC

CGS

NASA

NASA - ARC

http://ti.arc.nasa.gov/tech/rse/vandv/cgs/ ...

C Global Surveyor. An experimental tool at NASA Ames Research Center from Guillaume Brat and Arnaud Venet, based on abstract interpretation techniques, inspired by Patrick Cousot. This is obsolete and superseeded by the work on IKOS, a framework to generate of static analyzers based on abstract interpretation.

ARC, JPL

Calysto

Academic

Domagoj Babic

http://www.domagoj-babic.com/index.php/ResearchProjects/Calysto ...

Calysto is a scalable and precise static checker for general purpose code, which checks pointer properties and user provided assertions. Calysto works on the SSA form, and as such is language independent. However, interpretation of library functions (like C-lib and STL) as well as trace reporting is language-dependent (for instance, demangling C++ and Java names). Currently, trace reports are readable only for languages that do not mangle names (like C). Dr. Babic considers Calysto a bug hunting companion, rather than a formal verification tool.

TBD

C-Kit

Academic

Bell Labs

http://www.smlnj.org/doc/ckit/index.html ...

C front end written in SML that translates C source code (after preprocessing) into abstract syntax represented as a set of SML datatypes. It also provides facilities for extending the C language with additional syntactic constructs, which can be useful for implementing "C-like" domain-specific languages as well as C dialects. Ckit is currently used as the front end for a variety of tools for static analysis of C code and at least one domain-specific language. The development has stopped because the researchers involved have left Bell Labs. The latest version is 1.0, released 31 March 2000.

TBD

Bamboo®

COTS

Atlassian

http://www.atlassian.com/software/bamboo/ ...

A continuous integration server. Continuous delivery, from code to deployment. Tie automated builds, tests, and releases together in a single workflow.

ARC

Astree

COTS

AbsInt

http://www.absint.com/astree/index.htm ...

Astrée is a static code analyzer that proves the absence of run­time errors and invalid con­current behavior in safety-critical software written or gen­er­ated in C. A static program analyzer for a restricted set of C programs, (no dynamic memory allocation and recursion). It was started as a research tool by Patrick and Radhia Cousot, and their research group, and is now commercialized by AbsInt.

TBD

6. Lessons Learned

A documented lesson from the NASA Lessons Learned database notes the following:

  • Independent Verification and Validation of Embedded Software. Lesson Number: 0723: This lessons learned is based on Reliability Practice No. PD-ED-1228; from NASA Technical Memorandum 4322A, NASA Reliability Preferred Practices for Design and Test.

    "Implementation Analysis Phase: During this IV&V phase, two parallel activities are performed: (1) coding analysis and (2) testing. Coding analysis includes version comparison, textual and syntactical analysis, standards auditing, equation reconstruction, data structure analysis, flow charting, logic reconstruction, manual code inspection, traceability analysis, interface analysis, and database analysis. Software tools are employed to automate many of these program analysis techniques. They are used to help identify actual or potential errors in the developed code, and to reformat and consolidate information to facilitate manual analysis, software tools present a reliable, cost-effective means to supplement manual program analysis techniques. To maximize the visibility of software development quality, coding analysis is performed in parallel with code development. Coding analysis is achieved by analyzing the incremental code deliveries and modifications introduced in the updated program versions." 518

The Department of Defense publication Crosstalk Magazine contains the following lessons learned related to static analysis tools:

  1. Challenges in Deploying Static Analysis Tools. 300 For higher quality software and competitive products, many projects are feverishly deploying static analysis tools. Unfortunately, it turns out that many of the deployments are failures. Some have discontinued static analysis tools altogether. Some continue to use them, but find that the results are not as effective as they hoped.
    There are many challenges facing static analysis tool deployments. Although static analysis tools have some weaknesses, the main challenge stems from people. Whether the tool deployment succeeds or fails depends on the people behind it. What are the challenges facing static analysis tool deployments and how can those challenges be overcome? This paper tries to answer that question based on our own deployment of the tools, consultancies with other organizations, and others' experiences 429.
  2. Software Static Code Analysis Lessons Learned. 123 The United Kingdom Ministry of Defense has been in the forefront of the use of software static code analysis methodologies, including some of the tools and their application. This article ... discusses what is meant by static analysis, reviews some of the tools, and considers some of the lessons learned from the practical application of software static code analysis when used to evaluate military avionics software 428.


  • No labels

0 Comments