X hits on this document

PDF document

A FLEXIBLE SIZING APPROACH - page 4 / 7

19 views

0 shares

0 downloads

0 comments

4 / 7

THE BASIC WORK UNIT

QSM calls this common denominator the Basic Work Unit. In the past, SLOC was a nearly universal measure of work for software projects spanning different technologies, languages, and development paradigms. But the advent of modern diagramming tools, GUI languages, and programming environments make lines of code less useful as a measure of work performed. Developers who use diagramming tools may find that a combination of GUI actions better represents the work needed to translate a given set of requirements into software. Those who spend their time configuring database tables may wish to identify the smallest unit of work applicable to database construction and build from there.

It doesn’t matter what the Basic Work Unit is called. What matters is that the estimator identify the high level programming tasks (or steps) to be performed, then decompose each step until it carries approximately the same amount of time and effort as writing an executable line of code. This is an idea nearly all developers understand intuitively, since even in GUI environments some code must still be written by hand. The goal is to preserve a common frame of reference while allowing users the flexibility to choose the sizing method that most accurately reflects the actual work being performed: translating abstract requirements into a concrete, functioning software system.

DERIVING GEARING FACTORS FROM COMPLETED PROJECTS

One of the best ways to derive gearing factors is from completed software project data. Gearing factors can be calculated at the end of a project and the resulting factors used to estimate new projects. Gearing factors can also be estimated or sampled during the sizing process.

For completed projects, the gearing factor is best determined by running an automated code counter on the software product and dividing the LOC count by the number of function units in the final product. For Objects, if your basic work unit is SLOC, the gearing factor is the average number of lines of code per Object. This figure is obtained by dividing the effective (new_LOC + modified_ LOC) count from a few comparable completed projects by the object count from each project.

For a single language project sized in function points, the calculation would be similarly straightforward. The calculation for a 100,000 line of code project with a final function point count of 2500 would look like this:

Final effective SLOC count/ Final effective function point count = 100,000/2500 = 40 SLOC/FP

For mixed language projects this process is a bit more complex. When calculating gearing factors to be used for future estimates, care should be taken to use only projects written solely or primarily (85% or more) in the language of interest. For obvious reasons, calculating a function point language gearing factor for Java from a project that is only 5% Java will not result in an accurate gearing factor for that language. For mixed language

3

© Copyright 2011 Quantitative Software Management. Inc. All Rights Reserved.

Document info
Document views19
Page views19
Page last viewedSun Dec 04 12:59:07 UTC 2016
Pages7
Paragraphs91
Words2542

Comments