Estimating Code Complexity in LabVIEW

One of the principal tasks of project planning is estimating how long the project will take to complete, how many developers will be needed and how much money the project will cost. Accurate estimating reduces the chances of the project falling behind schedule, exceeding budget, and not meeting the requirements specified by the end user. Accurate estimates are often difficult due to the amount of uncertainty that exists early in a project. To estimate more accurately, software metrics known as code complexity metrics are frequently used to help express the size of the project and calculate how long it will take to complete.

If you need a code complexity metric simply to help you improve your ability to deliver your LabVIEW projects on time and within budget, you can use LabVIEW node count as your software metric. For more information on node count and how it can be used to estimate code complexity, see the sections below entitled Code Complexity Metrics in LabVIEW and Improving Your LabVIEW Estimating.

If you are attempting to integrate LabVIEW development into a project estimation process that requires a more traditional code complexity metric, National Instruments has found a roughly one-to-one relationship between LabVIEW nodes and source lines of code (SLOC). For more information on SLOC and how NI derived this relationship, see the sections below entitled Traditional Sized-Based Code Complexity Metrics and Converting LabVIEW Nodes to SLOC.

The VI Metrics tool, included in the LabVIEW Professional Development System (PDS), provides measurements for LabVIEW code. The VI Metrics tool can count the number of LabVIEW nodes used within any VI or hierarchy of VIs. A node is almost any object on the block diagram, including functions, VIs, and structures, such as loops and sequences, but excluding labels and graphics. Nodes are similar to statements, operators, functions and subroutines in text-based languages. Like many traditional software metrics applied to text-based programming languages, node count is a size-based metric that can be used to estimate software complexity.

In LabVIEW PDS, the VI Metrics tool can be launched by clicking Tools»Advanced»VI Metrics.... The VI Metrics tool also provides other information, such as the number of global and local reads and writes and the number of diagrams. Figure 1 below shows a VI Metrics window for a VI named Memory Monitor. In this example, VI Metrics displays the total number of nodes in the entire hierarchy of VIs, as well as the number of nodes in each individual VI.

Figure 1. The VI Metrics window shows several statistics, including use of nodes.

If you are interested in improving the accuracy and reliability of your estimates of the length and requirements needed for your LabVIEW projects, but are not concerned with converting your complexity metrics to a text-based equivalent, you simply need to choose a representative LabVIEW metric. The LabVIEW node is the software metric recommended by National Instruments.

However, choosing a LabVIEW metric is only the first step towards improving your estimating on LabVIEW projects. For this approach to work, you must build up a repository of information on current and prior projects. Using this historical information, you can compute how long it took to develop individual components of your existing systems and correlate that information with the number of nodes in that component. However, before you can estimate the number of nodes required for a new project, there are several things you should first do.

With text-based programming languages, one popular code complexity metric is known as Source Lines of Code (SLOC). SLOC is used to describe the size of the code, which can be used to calculate how long the project will take to complete and how much the project will cost, as well as measure productivity once the software has been finished. One reason for the popularity of SLOC is that it is relatively easy to compute; in C, a SLOC is typically defined as any line of code that terminates with a semicolon (i.e. a human-written line of code that is not a comment or blank). Many vendors sell tools that calculate SLOC for any given source file. Because programming practices are usually standardized within an organization, companies using SLOC typically build up a database of information on projects to improve their estimations.

Graphical programming obviously presents a challenge to project estimators familiar with SLOC. A comparable LabVIEW code complexity metric, such as node count, must be translated into SLOC for LabVIEW development to be integrated into the project estimation practices found in many companies.

Two recent National Instruments software development projects involved creating equivalent software in LabVIEW and C. The first project was the development of the NI DAQmx APIs for LabVIEW and LabWindows/CVI, the National Instruments ANSI-C development environment. In the second project, National Instruments re-architected the LabVIEW and LabWindows/CVI operator interfaces for the test management software NI TestStand. Upon completion of the two projects, National Instruments compared the number of LabVIEW nodes used to the equivalent C SLOC and found there was roughly a one-to-one relationship between LabVIEW nodes and SLOC.

However, be aware that any conversion of a LabVIEW metric to SLOC will be inexact due to the fact that size-based code complexity metrics are dependent on the programming language being used. For example, statements in a higher language programming language such as C can provide more functionality than those in a lower-level language like assembly language. LabVIEW developers also have varying experience levels and coding styles that can impact the development of an application, and LabVIEW is typically more productive than other development environments, making any correlation between LabVIEW nodes and SLOC an approximation.

If you are concerned that the project estimators in your company will not understand the concept of LabVIEW nodes, there is another method that some LabVIEW developers have used to translate LabVIEW code complexity metric to equivalent SLOC. In this alternative approach, developers compared the size of LabVIEW code on disk to the footprint of an equivalent C object file. Provided you know the SLOC used to create the C object file, you can convert LabVIEW code to SLOC. In LabVIEW, you can view the memory usage of a VI by going to File»VI Properties»Memory Usage, as shown in Figure 2.

Figure 2. The Memory Usage category of VI Properties shows the size of this code on disk, which is 10.0K.

Note: The Memory Usage feature shows not only the size of the LabVIEW code on disk, but also the memory used by the front panel and block diagram objects and the data stored in the VI. When using this method to convert LabVIEW complexity to equivalent SLOC, only include the memory associated with the code.

Note: National Instruments has not uses this SLOC conversion method during software development and cannot offer guidance at this time on a conversion factor from LabVIEW code size to equivalent SLOC.

Although LabVIEW is a graphical development environment, you can still use a code complexity metric like LabVIEW node count to evaluate the amount of time and effort required to complete past projects and help you guide your future development. While the relationship between a single LabVIEW node and a text-based source line of code is not perfectly correlated, National Instruments has found the ratio of one LabVIEW node to one SLOC through internal studies of projects involving equivalent LabVIEW and C code. To improve your project estimation results, you should track your LabVIEW metric over multiple projects, breaking those projects down into smaller components and including important factors such as individual developer programming experience and the type of code in development.