Recently in Build Metrics Category

Metrics Overview

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:

I’m writing this post using data and charts directly made by the the new “Metrics” menu of Understand 2.0.  It provides metrics browsing and charts directly inside of Understand 2.0.    How does this differ from our upcoming Measure tool?  Primarily in scope and flexibility. With Measure you can custom design charts and comparisons and automatically report them, plus a few zillion other things.  But the new “Metrics” menu provides quite a bit of useful information with pretty much zero learning curve.

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:

Welcome to my first post using our own toolset to publish build metrics about our most recent weekly build.

 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:

Earlier, I showed you the Functional Decomposition architecture and used it and an about to be alpha tested tool called “Measure” to present measurements of the various parts of our source tree.  This was as a pre-cursor to doing weekly build size, complexity and change metrics reporting.

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:

We believe that if we use our own tools they will be better.

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: