Before covering the detailed metrics for B448 I figured a bit of an overview on Understand 2.0 metrics would be useful.

Project vs Change Metrics

There are two basic kinds of metrics that we provide in Understand 2.0.   The first is Project Metrics, which give a static view of a particular point in time.  Examples of this are CountLine and Cyclomatic. Understand 2.0 computes and presents the value of these metrics for any snapshot in the database.  

The second kind is Change Metrics. These show differences between snapshots. The differences can be static – i.e. comparing Cyclomatic from B448 to Cyclomatic in B447. Or it can be dynamic, for instance showing lines deleted (calculated by looking at diffs).

How are Snapshots Made?

You can make a snapshot in three easy ways. First, make one from the current database. Second, make one from an alternate source location where you checked out another version of your source code, and third you can make one from any point in time using TrackBack (after version B443).  All these are done from the Change->Snapshot Manager menu.

Build 448 Metrics

After making a snapshot for B448, the Snapshot Manager showed me this basic information about each recent snapshot:

Here is the entire source for the project compared to the major components. Maintain is the source for Understand 2.0

That is nice, but what “happened”. Here are some more dynamic views showing changed SLOC and classes:

Not nearly as busy as we were last build (-:   Not quite true, these numbers reflect the code checked in. Last build had a lot of code checked in because we’d held the build for two weeks waiting for the Estimate and Metrics Graphing features to be ready.

I’m a big fan of “new complexity” as an important metric. This captures the dynamic that new complexity, in the form of new logic or changed logic represents the biggest source of bugs.  Put another way, a new complexity of 10 is way more dangerous than a stable unchanged complexity of 50.  Well… unless some changes ripple through that complexity of 50… but that is for another blog posting about using Change to find risk.

Here is a view of “new complexity” for this Build

Note that the above chart was done with Excel by exporting data out of Understand 2.0.  I also sent a note to the pertinent engineers asking them to put in various “new complexity” charts into the Metrics feature of Understand 2.0  Except for this chart, all are made directly by Understand 2.0′s new Metrics graphing menu.

Timeline:

12:52 – rescan/update code in project.
12:54 – make snapshot
12:55 – update metrics database including change metrics (more time consuming)
           This gets more time consuming each time I add a snapshot becuase it compares all snapshots to all snapshots.
            For the next build I’ll likely disable past snapshots and only do comparisons between the last two.
13:05 – starting making graphs using Metrics Graph Browser
13:35 – finished posting this blog plus sent several e-mails with ideas to pertinent engineers.

B447

I made a snapshot. This told me this basic information about B447 versus B446:

1,719 classes in B447, while 1487 were in B446.  We’ve been busy (-:

Here is an Understand 2.0 generated chart of the line volume information for B447:

and for B446:

So how much changed between B446 and B447?

Here is line change information. This separately counts lines that were added, changed and removed. An important distinction for this metric is that it isn’t just looking at line counts – it is looking at the text of the lines. If it was removed, CountLineRemoved increments, if changed CountLineCHanged, so on.  This avoids the situation of a line added and a line removed adding up to 0.

Here is the class change data. Again, a Class Added is a new class. ClassRemoved is one that is no longer in the source. A ChangedClass has some non-whitespace changes done to it – like new logic, or a new member.

Finally, here are metrics by the major architectural areas.  THese architectures were built automatically by the Architect tool of Understand 2.0.

Size (in SLOC) by Major Architectural Area

Class Change by major architectural area:

Note: All of these tables and charts were generated directly from Understand 2.0. 

My timeline for doing this was:

– 1 minute – make snapshot of 447

– 5 minutes – checkout source of 446 to alternate location. I’d forgotten to make a snapshot of it.

– 4 minutes – make snapshot of 446 from the alternate location.

– 6 minutes – update Understands 2.0 metrics database for all snapshots.

– 10 minutes – make the charts and write this posting

 I’d intended to use Measure, a tool we are about to release in alpha form, for this post…. but alas I hit a problem with it that that will have to be resolved tomorrow by the engineers working on it. 

So instead, this Build Metrics post will be done using the Change tool built in to Understand 2.0.  Later, I hope tomorrow, when the issue with Measure has been resolved, I’ll update this post with charts and reports made from it.

First some procedures….. I have an Understand 2.0 project. It was synced to current source, but using fancy SVN magic I set it to April 20 for B442, then I reparsed, made a snapshot labeled B442. Then I restored the source to April 27 for B443, reparsed, and made a snapshot labeled B443.   Then I asked Change to compare B443 versus B442:

All changes checked in to form B443:

Qt Enhancements:

Core Infrastructure:

Understand 2.0:

Impact :

Measure: No Changes checked in.

TrackBack:

Today, I’ll show you the other architecure I’ll be using – Staff.  Using the Functional Decomposition architecture developed in about 45 minutes, I was able to create “Staff”, or who owns what, in about 15 minutes. This is what it looks like when seen in the Architect->Browse Architectures window:

Or if you like big pictures, visit this one:

And here is how interdependent they all are (courtesy Understand 2.0 Architect’s Dependency Grapher). I expanded the graph one level and had it clutser nodes on the parent nodes (Utah and Tele-Commuters).

This roughly matches my expectations in that we all bounce around a lot and hence our ownerships interdepend frequently. But while we all depend on each other ultimately most roads lead to Doug P., who wrote most of the core database and other libraries all the tools utilize.  In another post I’ll show you how you can use Architect’s Dependency Graph browser to see what the precise causes of any dependence relationship are.

Back to metrics…. So who is working hard and who is hardly working here at Scitools (-: Click the pic to see it bigger, by the way it was generated directly by Measure a new tool we are about to alpha test:

So as expected, Kevin G. has been slacking (-:  And Helen M. is a machine!  Actually, Kevin G. doesn’t have coding responsibilities and Helen is a machine, but her count is added by automatically generated Lex/Yacc code in some of her parsers.

Hence, in the coming weeks, using just tools we sell or are about to introduce, I will be posting build metrics about each build we release. I will give static views of the size and scope of our various development efforts and on week two I’ll start showing change metrics describing what is new, changed and removed.

Today, I’ll start that off by showing you “Functional Decomposition”,  the first Architecture I will be using to organize future reports.

First off, Understand provides automatically a Filesystem architecture that is automatically derived from the directory structure of the project.

Understand’s Assistant, also suggests three that you can do by hand that will take you a long way.  They are “Functional Decomposition”, “Staff”, and “Requirements”.   Since we don’t deal with formal requirements here at Scitools, I’ll just be doing “Functional Decomposition” today and “Staff” tomorrow.

On the left is the basic Filesystem architecture I started with, and on the right one I whipped up in about 45 minutes:

From the left one (pure directory structure) I think you can sort of deduce what is going on generally in the structure.  But, what is difflib, or how would you know that “maintain” is really the source tree for “Understand 2.0”. You wouldn’t know.  But a quick glance at the right one should show you the general structure.

Another way to view it is in this graph, in which I’ve fully expanded all the way down to base components:

So how big is Understand?  Here is what the Metrics Browser reports for the top level of Functional Decomposition:

Cool – 1.24MSLOC. And this project doesn’t contain “ALL” the source – just what I decided was going to be changing going forward.

Okay, so how big are the parts of Understand 2.0.  For that I’ll turn to Measure, a tool we are about to put out for Alpha Testing – email support@scitools.com if you want to get on the “try it early” list.

Here is Measure comparing the volume (in LOC) of the source for the major components of our source tree:

And here is the same data shown in tabular form:

A one click switch of x-axis on the top chart now shows each component in terms of blank lines, executable lines, declarative lines, and comment lines:

And finally, here is each components complexity graphed comparitively:

So there is an overview of the major parts of Understand’s source tree, their relative sizes and complexity.
Tomorrow…. I’ll add the “Staff” architecture and do similar metrics to answer the burning question…. “Who has been busy here at Scitools??”