33510320232_40376a5052_k

Test case points is only one approach to determining the size of work that needs to be tested. The other measures fall into three broad categories.  The categories are: (more…)

Advertisements

Size Matters. . .But Which Size

If size matters then you must measure.

If size matters then you must measure.

Size matters.  I will provide a moment of silence to let the jokes and requisite tittering die down.  In software development the size of the software being built or changed matters because size affects productivity, size affects risk and size affects how projects are managed.  I suggest that these reasons are just the tip of the iceberg of why size matters.  Because size is such a major determinant in how a project is run, I would suggest we can’t leave the knowledge of how big the software component of a project is to shear guess work.  We must measure software size.  Unfortunately there are numerous measures of size and each of these measures has its own strengths and weakness making selection a chore.  Finding the right measure or at least the right category is more than an academic discussion unless you want to adopt a measure that does not meet your needs.

Fortunately the landscape of software size measures can be simplified by consolidating all of the available size measures into three categories.  The first category (and oldest) is that of physical measures, second is functional measures and the third is relative measures. Each of these categories is valid in specific circumstances.  Each category contains measures that are valuable as a tool to answer specific questions.  Each category waxes and wanes in its explanatory power across portions of the development life cycle.  Lets explore each in a bit more detail in anticipation of creating a simple selection algorithm.

Relative size measures use the measurer’s perspective as a framework to assess size.  These measures are much akin to stepping off a distance and declaring it to be so many yards or feet.  The measure is relative to size of the measure’s stride (your stride and mine are probably different).  Relative measures are fine for an approximation but fail to deliver precision or comparability.   Relative measures provide their greatest explanative power when there is the least amount of information or when there is no standard measure available. One of the most common uses of relative measures has historically been in budget activities when only a small amount of information is known; analogies are the most common type of relative measure used in in the budgeting process.   In recent years story points (a relative measure) have been used by some organizations as a means to to develop an approximate size during the development of requirements.

Functional size measures evaluate software size by assessing the size based on a set of rules focusing on “user” recognizable functionality.  Most standard functional measures focus on sizing only what was requested (and later delivered).  The focus on sizing business functionality means that functional measures can be used as soon as requirements or stories are identified.  The ability to size requirements based on a common set of rules allows the transition from relative to functional measures; from perceived size to rules based size. The transition from relative measures to  functional measures is also marked by an increase in the the number of rules required to determine size (and therefore to some extent the amount of effort required to determine size) while at the same time the level level of  abstraction typically decreases (what is being measured is closer to what is being delivered).  An example of the decrease in level of abstraction is shown in the the level of detail of IFPUG Function Points.  IFPUG Function points are determined by measuring and counting five types of components (external inputs, external outputs, external inquires, internal logical files and external interface files).  Examples of functional measures include IFPUG Function Points, Cosmic Function Points and Use Case Points to name a few.

Physical measures of size count tangible “things” like lines of code, modules, objects or typical software components.  The rules for counting physical size measures tend to vary by language, technology or are tied directly to specific technologies.  Because of the variance in the rules aggregating data in non-homogeneous organizations tends to be problematic.  For example, what does comparing 10 lines of Java and 10 lines of ASP.net mean or worse yet one object, three pages of documentation and 1,000 lines of generated Java?  Physical measures reach their zenith in explanative and predictive power during the specific activities that create the physical item being counted; code during coding, test cases during testing or pages of documentation during the creative writing phase called user documentation.
Size matters for estimation and planning regardless of methodology or technique.  Whether a project uses a relative, functional or physical measure matters less than measuring work and using that measure to create information.  Which method you use depends on organizational and project culture.