Doing Inventory

Exposing rogue features and reducing bloat

on your list that you really can't identify, be sure to ask other members of the development team. Unidentified items will prove troublesome to further analyze. If nobody is able to identify what the item is, then you know you are dealing with a suspect asset.

Step 3: Determine if they are needed
Once you've identified each of the items, you then need to determine if they are actually needed by the product. A large part of this step is already completed simply by knowing the identified purpose of the items. It is nonetheless an important and longer step, with a distinct purpose from the previous one. This is when you determine the concrete use for each item on your list, determining when, where, and how each is used.

You want to know where each dialog appears in the program. Images may be used in the default interface, or perhaps they are selectable by means of a user-selectable skin. Check each shared library to see whether it is needed, or whether it is a remnant from a previous version. Review each configuration setting in the registry, or configuration files, to ensure that it is applicable to the product (configuration bloat can be just as much of a problem as file bloat). Be watchful of items that look like they might be used but simply aren't (for example an extra JPG in the directory which is actually never referenced).

The information you collect needs to be enough to determine when, where, and how the item is used. "When" ensures that you've considered all the variables that may impact the use of the item. It is quite possible that certain items, such as language resources or device drivers, are used only in certain configurations. "Where" and "how" will give you the insight you need to test the item. They can also further identify those cases where an item is used, but only in another component that is not used (perhaps an icon that is displayed only in a dialog that is no longer referenced).

Beyond merely determining that the item is used by the program, you need to determine if it is supposed to be used by the program. You should be able to state which requirement describes, or requires, each of the items on your list. Often, requirements are quite strict in what they state, other times they are open. Sometimes a directory filled with selectable images will have no specifics, but other times the requirement may specifically state only three skins that can be chosen. Your work here may be of interest to the requirements management team as they strive to improve their system: don't leave them out of the loop!

At this point, there are three situations that will result in change requests for the product. First, if an item is both not used by the product and not described by the requirements, you will likely want to create a deletion request for this item. Second, if an item is used by the program but not included in the requirements, you will need to speak with the team to determine whether the item should be added to the requirements, or removed from the program. Third, if an item is described by the requirements but not used by the program, in this case you need to determine whether the program is to be adjusted to use the item, or whether the item and the requirement for the item both need to be dropped.

Step 4: Ensure they are tested
This last step seems obvious at first, but it plays an

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.