Code tables are a type of configuration table for an application. An example is the table of airport abbreviations that most travel related applications use. It facilitates data input because Newark International Airport can be abbreviated as EWR. This saves key strokes but also insures consistency. Otherwise, one person might enter Newark Airport and another might input Newark International Airport. However, there is more involved than consistency and saving keystrokes. This code table limits the airports that will be accommodated by the application. To recognize a new airport, an abbreviation must be assigned and the abbreviation-airport name pair must be added to the table. Adding that pair might be done with a text editor, SQL, another utility or transactions built into the system. If there are screens that maintain a code table, then an administrator might use it to update a code table.
The other extreme of configuration is a complete system dedicated to configuration. In the seventies, Digital Equipment Corporation was selling its line of PDP minicomputers. When someone bought a minicomputer, the DEC salesperson would have to configure it for them. Peripherals would be selected, usually by the client. However, the salesperson would have to know what type of cables and device drivers to sell with it. The client might end up buying equipment that was missing a component that was needed to have a workable system. Some of the items purchased might be incompatible. DEC decided they needed a system to insure that complete and workable systems were being delivered. They decided to build an expert system, called XCON, to achieve this.
There are cases between these in complexity. An example would be part of an order entry that applied promotions to the orders. The system allowed communications services to be ordered. Promotions would apply discounts to certain combinations of products. For example, if someone ordered voice mail and caller id, then they would be given a certain discount. They could receive this discount even if they already received a senior citizens discount. However, they could not receive both a senior citizen discount and an active military discount. There were many complications like this. The team built this into a table, but the table was complicated. It sometimes required symbols to be defined to keep track of certain situations. There were conditional structures built into the table. For all practical purposes it required someone with some programming ability to enter the promotions. Promotions were set up for each geographic market. Different geographic markets only supported a subset of the company’s products. When the company entered a new market, it had to enter dozens of new promotions for that market. Despite the fact that there were no changes to the computer language statements that made up the application, there was significant effort in constructing new entries into the Promotion table.
Code tables are usually not identified in the initial user stories. The need for these tables often becomes apparent after development has begun. Thus these tables are not counted when they are initially added. Neither are the transactions that are used to maintain the code table itself. Usually, it is not necessary to estimate any changes to the content of a code table. Adding, changing or deleting an entry in a code table is usually trivial and can be done by either an end user or a developer. There is an exception.
Occasionally, an application will have some business logic associated with the code table built into the application. Suppose that somewhere in the application there was logic that prevented booking a flight from EWR to LGA. Then, when there were changes to the code table, there would need to be testing of any transaction that utilized the code table. For example, a Book Flight process would have to be tested. If there were 10 or less changes to the code table, then there would be 12 SNAP points counted. This would have been 6 * 2 attributes (the abbreviation and the full name). Even in this case, in the unlikely event that there are changes to the transactions that maintain the code table themselves, no Function or SNAP points are counted.
The XCON application is not really an example of using configuration files. The configuration logic was built into the application itself. XCON was written in OPS5. This was an expert system shell that is no longer widely used. It had a language level between 5 and 6. OPS5 programs are made up of production rules. These rules held the configuration information. Changes are sized by using the other techniques discussed in other posts. This is the case for most applications. Code tables are usually only used to enforce data consistency. Reference tables are usually maintained by end users who are entering various rates like currency exchange rates, not by development personnel who are using them embed business rules into the tables. In these cases, there are no user data configuration files to consider.
In the other example above, the Promotion file is definitely a reference ILF. It may have been designed so that end users could extend there own application by adding new promotions. It this works out, then the Promotion file is not user data configuration file since it does not require a developer to add more promotions. When promotions are added, they are added by end users and the time required is not estimated using any of the guidelines in this methodology. Promotions involve business analysis and design activities that are unrelated to software construction. For example, they may require the use of focus groups to decide whether the promotions will be effective.
Sometimes, an application is designed to be extendable by end users, but it is found that the configuration information is too complicated for the end users to enter. Other times, the application is designed to use configuration files that will be maintained by developers. Again, in these cases the configuration files are ILFs, unless they are code tables. The screens or transactions that maintain them are elementary processes. Changes to any of these things are counted as explained elsewhere. However, when content of these files is changed it requires time and effort from the development staff. This is when sizing the changes to the user data configuration files becomes important. For example, suppose that the Promotion configuration file had 10 attributes. If 50 new entries had to be added to the file in order to enter a new market, then this would e 120 SNAP points. Because there are over 30 new records, the size is equal to 12 * 10 (number of attributes).