This article presents a method of reconciling the assets in a project. The process improves product quality by eliminating wildcards and reducing bloat. It is a flexible process that can be used in limited resource environments and is easily adaptable to almost any type of software.
During testing we use requirements to guide our activities. We check to see that the program is doing what it is supposed to be doing. But how often do we stop and wonder how much more it is doing? Why does the install process take longer and longer every week? Why is build 210 three times larger than build 209? Why does issue 3197 reference a component of the product I've never even heard of?
Checking requirements doesn't answer these questions. Instead we need a way to work backwards from what we have, to what we thought we should have. This is the realm of asset management, and our part of this is asset reconciliation. Here, I provide a simple version that helps remove some of the unknown variables, or the wildcards of product quality, and also prevents unnecessary product bloat.
There is no magic in this technique--it is a simple four-step process: 1) locate all the assets, or parts, of the application package; 2) identify what each part could be used for, or what its immediate purpose is; 3) determine if this part is actually needed by the application; and finally 4) ensure these parts are being tested.
Remember, the goal is not merely to catalog assets. The goal is to track down and eliminate unneeded bloat and make sure all remaining assets have been properly tested. The accounting need only be as rigorous as your project necessitates.
Step 1: Locate the assets
Your first step is to locate all of the parts of the application. Note that you are interested primarily in the final version--what comes out of a ZIP file or an installation package. You want to identify initially all of the directories and files that the product comprises. This is a simple starting point that consists of a few "dir" commands at a shell prompt.
But don't stop there. Often, additional assets are hiding inside compressed, or archive files (some of the usual suspects end with ZIP, JAR, TAR, and CAB). You should also understand the manner in which UI resources are stored. Something as simple as a single DLL file can contain numerous dialogs, hundreds of images, strings, and other nondescript data items. Be sure to track down all the shared libraries the install program put in or the directories. And never forget about the final tidbits stored in the registry or placed in a file in the directory.
Now that you have a big list of assets you are ready to move on, but don't be afraid to come back to this list and add more items or further detail the contents of a file you later learn is an archive, such as ZIP. Also don't be afraid to move on before exploring every compressed file or configuration item. This can be treated as an iterative process: with each pass, you can further explore one area of the assets, or go one detail level deeper in the analysis.
Step 2: Identify their purpose
For each item you have in your list you need to determine what it is. Is this an image file? Is this a library component? Is this a help reference?
Focus on identifying the general purpose of the item, rather than obtaining a detailed description of its use. You are interested, at this stage, in understanding what each of the items could be used for, where it could be used, or how it could be referenced. Don't yet concern yourself with whether the item is actually necessary for the program to operate--that is the next step.
If there are some items