Software Construction: Static Analysis - why is it important and a possible list of candidate tools

Static analysis is an important part of software construction and you as a developer should know some of them well (and use them).

• It'll give you an extra insight on your code (as well as others code).
• Good tools will collect some measures automatically and point you to good candidates for rework / refactoring 
• Automatically collected data include can include Lines of Code / LOC per unit, cyclomatic complexity, etc. 
• Good tools will also allow you to configure the measures and KPIs you want to analyse (e.g. Allow you to configure the KPI "cyclomatic complexity <=5" which could be synonym of "good code" for this particular project)
• Kiviat charts are useful for analysing the source code modules, typically one chart per source code file
• For some markets the use of these tools is not optional. For instance, we could not be allowed to deliver code to the integration and system test phases that has a cyclomatic complexity greater than X (rational: more complex code is harder to test, namely to achieve 100% source code coverage by tests, MC-DC techniques, etc.)
• For peer reviews (be it formal code reviews or other), these tools will help you cleaning up your code as well as respecting coding standards (if you configure them properly with parts of those coding standards). Run them before submitting your code for peer review.
• The WWW will show you what measures are more used by the industry. Examples: LOC, % commentary lines, method length, cyclomatic complexity, subroutine depth, and more.
• These tools can be configured as a task in the continuous integration server (so that for each build the reports are generated automatically for later analysis, by the TM, by the developer, etc). 

Some tools:

• https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
• https://en.wikipedia.org/wiki/SonarQube - locally installable, free, as most good things in life and multi-programming-language (C, C++, Java, C#).

Static Analysis: What to Measure? And How?

In Static Analysis how and what should we measure?
It depends on what we want to analyze and / or control with this verification method.
If you want to know some reasons why it is important to be done, read here (static analysis - why).

How? 

The ideal scenario is to choose the right tool for the job you have to do (as always). This is the how. The tool ideally integrates with your favorite IDE (e.g. Checkstyle plugin for Eclipse, see more info here) so that features are readily available without tool and additional context changes.

What? 

Tools already measure things during static analysis and will allow you to do some kind of fine tuning on the KPI thresholds (e.g. minimum value for the measure, maximum value).

There are lots of papers (and standards) on what to measure to achieve, for instance, maintainability.

Examples of measures:
- LOC
- % comments
- Cyclomatic Complexity
- Max. Depth
- Average Depth
- Etc.

For each programming language there could be different recommendations for the KPIs. Also have a look on what the "community" has to say about it (and to the tool defaults for that language). i.e. Google for it.

Additional Info

Some additional ideas:

• https://en.wikipedia.org/wiki/Software_metric#Common_software_measurements
• http://www.kaner.com/pdfs/metrics2004.pdf
• What is Static Analysis (and examples of tools): http://istqbexamcertification.com/what-are-static-analysis-tools

You also have standards like AFP and AEP (from CISQ) that deal with these topics.

SW Testing: Code coverage criteria (including MC/DC)

The Short Story

Just a sum-up of coverage criteria (software testing):
Code coverage - Wikipedia

The Long Story

Besides coding, you might get asked to provide several types of coverage of your code (the evidences to provide to your contractor could be test report deliverables, besides the [automated] test scripts and the written test specs/procedures). The more safety-critical is your code the more criteria you will be mandated to execute (the QA / PA standards refer to these issues):

• Function coverage – Has each function (or subroutine) in the program been called?
• Statement coverage – Has each statement in the program been executed?
• Branch coverage – Has each branch (also called DD-path) of each control structure (such as in if and case statements) been executed? For example, given an if statement, have both the true and false branches been executed? Another way of saying this is, has every edge in the program been executed?
• Condition coverage (or predicate coverage) – Has each Boolean sub-expression evaluated both to true and false?
• MC/DC (Modified condition/decision coverage): A combination of function coverage and branch coverage is sometimes also called decision coverage. This criterion requires that every point of entry and exit in the program has been invoked at least once, and every decision in the program has taken on all possible outcomes at least once. In this context the decision is a boolean expression composed of conditions and zero or more boolean operators. This definition is not the same as branch coverage, however, some do use the term decision coverage as a synonym for branch coverage.
• (and more, see Wikipedia)
• Usage in the software industry: Code coverage is one consideration in the safety certification of avionics equipment. The guidelines by which avionics gear is certified by the Federal Aviation Administration (FAA) is documented in DO-178B and the recently released DO-178C.
• Code coverage is also a requirement in the automotive safety standard ISO 26262 Road Vehicles - Functional Safety (part 6).
• Sources: The oldie but goldie "The Art of Software Testing" with its orange cover (initial editions); Wikipedia.

From these verification activities, you might get to conclude that there are unreachable parts of code (typically to be removed) or that your code is far too complex to cover and needs simplification, i.e. refactoring. This is why cyclomatic complexity - and other KPIs/software metrics - is limited by some standards also at certain component criticality levels.

Tools: Code Reviews and Support tools

Why (NOT) Code Reviews? 

Code reviews is not the most beloved verification method for a developer (in the end of the day it makes you proof-read others code, and everyone knows that all code other than yours is not good enough - #irony). But remember that Code Reviews are one of the most cost-effective verification methods available: Fixing a bug in software while developing it is way much cheaper than fixing it after the formal testing phases begin (several studies on the subject can be found - just "google" for it).

Also, things that we should bear in mind before we start complaining about having to do code reviews are:

• There are things that are much easier to verify looking at the code directly (e.g. correct use of RDBMS transactions) than by integration / system testing.  "White box" rules here and saves us hours (as a team - because on some cases we are saving testers' time).
• For some critical parts of your code it might be a good idea to have them being checked (read: code reviewed) prior to any deployment to production, e.g., code involved in authentication, authorization, money transfers, etc..  

Code Reviews in your QMS/SDP

Your QMS/SDP might have a Verification Process defining a code review procedure on how to conduct code reviews (see "Further Reading"). And how metrics related to code reviews are to be collected (and when, and by whom). Examples are: code review speed, preferably per technology; number of defects detected, number of defects fixed, defect fix cost - e.g. in minutes, etc.

And What About Supporting Tools?

So in order to "reap the benefits" (read: improve SW Quality and save money), give the developer teams a help by supporting the procedure with tools. For instance: Crucible (a plugin to Atlassian JIRA). Or any other. Anything other than making people use printed code and / or word processor annotated documents.

Further Reading

Examples (permissions could apply; INTERNAL):

• Example of a QMS Verification Process (Supporting Processes): https://quality.critical.pt/QMS%20PT/SUP-support/SUP-03-verification/CSW-QMS-2002-PCS-0354-verification.pdf#search=crucible%20guidebook
• Example of Code Review Support Tool Guidebook: https://quality.critical.pt/QMS%20PT/SUP-support/SUP-03-verification/CSW-QMS-2002-PCS-0354-verification.pdf#search=crucible%20guidebook
• Example of a code review under Crucible: https://crucible.critical.pt/cru/ATG-5#CFR-11408