Software Metrics

by [email protected] (Patti Beadles)

The software engineering community has been placing a great deal of
emphasis lately on metrics and their use in software development.  The
following metrics are probably among the most valuable for a software
project:

The Pizza Metric
----------------

        How:    Count the number of pizza boxes in the lab.
        What:   Measures the amount of schedule under-estimation.
                If people are spending enough after-hours time
                working on the project that they need to have
                meals delivered to the office, then there has
                obviously been a mis-estimation somewhere.

The Aspirin Metric
------------------

        How:    Maintain a centrally-located aspirin bottle for use
                by the team.  At the beginning and end of each month,
                count the number of aspirin remaining aspirin in the
                bottle.
        What:   Measures stress suffered by the team during the project.
                This most likely indicates poor project design in the
                early phases, which causes over-expenditure of effort
                later on.  In the early phases, high aspirin-usage
                probably indicates that the product's goals or other
                parameters were poorly defined.

The Beer Metric
---------------

        How:    Invite the team to a beer bash each Friday.  Record the
                total bar bill.
        What:   Closely related to the Aspirin Metric, the Beer Metric
                measures the frustration level of the team.  Among
                other things, this may indicate that the technical
                challenge is more difficult than anticipated.

The Creeping Feature Metric
---------------------------

        How:    Count the number of features added to the project after
                the design has been signed off, but that were not requested
                by any requirements definition.
        What:   This measures schedule slack.  If the team has time to add
                features that are not necessary, then there was too much
                time allocated to a schedule task.

The "Duck!" Metric
----------------------------

        How:    This one is tricky, but a likely metric would be to
                count the number of engineers that leave the room when
                a marketing person enters.  This is only valid after a
                requirements document has been finalized.
        What:   Measures the completeness of the initial requirements.
                If too many requirements changes are made after the product
                has been designed, then the engineering team will be wary
                of marketing, for fear of receiving yet another change to
                a design which met all initial specifications.

The Status Report Metric
------------------------

        How:    Count the total number of words dedicated to the project
                in each engineer's status report.
        What:   This is a simple way to estimate the smoothness with which
                the project is running.  If things are going well, an item
                will likely read, "I talked to Fred; the widgets are on
                schedule."  If things are not going as well, it will say,
                "I finally got in touch with Fred after talking to his
                phone mail for nine days straight.  It appears that the
                widgets will be delayed due to snow in the Ozarks, which
                will cause the whoozits schedule to be put on hold until
                widgets arrive.  If the whoozits schedule slips by
                three weeks, then the entire project is in danger of
                missing the July deadline."

Try a Free Evaluation Copy of our Product: LinkScan