Applications maintain data. An order entry system would obviously have a file with orders in it. This order file would be functional. It would be related to the data that was used and maintained by the system. However, there are other types of files that are found in an application. These are technical. They often make up 50% of the physical files in an application. They are referred to as code tables. They usually have two columns: code and description. An example of this might be a file of airport abbreviations. Many travel related applications have a file or table with airport names and their abbreviations. When a user enters an airport name, that entry must be one of the abbreviations in that table. This makes practical sense. If a user wanted to enter Newark Liberty International Airport, EWR must be used. Otherwise, some users would enter Newark Airport while others entered Liberty International Airport and still others might enter any other combination of these words. The code table is not adding any functionality; it is improving other data entry processes. Occasionally, a code table will have additional columns for auditing purposes. For example, an entry might have the name of the employee who added it as well as the date it was entered.
There are three types of code tables: substitution, static or constant and valid values. The airport abbreviation table described above is an example of a substitution type. Instead of Newark Liberty International Airport, the user can enter EWR. This is a basically a concept. In all probability, the user would have to enter the abbreviation. This would keep the airport names consistent. Allowing the user to enter the actual airport name would result in variations in the names of the same airport. Static or constant code tables often have a single entry in them. A typical example is when a company logo is stored as a file. Sometimes several static pieces of information are maintained in the same code table. Default values are also kept in this type of code tables. For example, the default WordPress role when entering a new user might be Subscriber. This could be placed in a code table to facilitate changes. Valid values would show what values were acceptable for a certain variable. For example, WordPress roles might be Super Admin, Administrator, Editor, Author, Contributor and Subscriber. Check numbers for an application might be from 1000 to 9999.
Code tables are technical in nature. Business files are associated with the problem the application is being developed to solve. For example, WordPress would have a logical file associated with the users that would be involved with a blog. Users have different roles. The roles might be placed in a code table. The need for a user table would be identified from the very beginning of the project. It would be mentioned in the initial user stories. From there, someone would have identified the user file. The different roles might not become apparent until developers started to design files and screens associated with the users. The roles themselves might have been called out in the initial user stories, but the decision to place the roles in a file would probably have been made during development. As long as the roles table conforms to one of the structures discussed above, it is considered a code table. Code tables are sometimes maintained using system utilities like text editors or SQL. Other times, code tables are maintained by screens that were developed for that purpose. In either case, they are still code tables.
Code tables are not counted when counting function points. They should not be. No one knows what code tables may be necessary early in the life cycle. For decades, we have been generating reasonable estimates for new software development using function points as the primary driver of software size. If some of the code tables are identified early, they should still not be counted. The most important reason to identify code tables is to remember not to count them. In addition, if there are maintenance transactions like screens that update the code tables, they are not counted either. This makes sense. Transactions that update code tables are not labor intensive. Even when they are coded, they are the types of transactions that are usually clones from other code table update transactions. Care must be taken to make sure the that none of the code tables have been misclassified. Use the airport code table as an example. If there is an abbreviation and description then it is a code table. If a field is added with the number of runways, then this would indicate that the file had business related information in it. It would stop being a code table and be considered as a logical file.
Code tables are considered when counting Software Non-functional Assessment Process (SNAP) points. These come into play when changes are being made to existing functionality. This is almost always the case with development iterations after the first. The creation of code data is counted like a change to the elementary process that utilizes it. This is unlike the addition of a new logical file (ILF or EIF) which is considered an addition to the functionality of the application. Changes to code data are often counted in a similar manner. Other times code data is considered part of the data that data that is delivering added value to users by data configuration. However, in all cases, code data carries less weight than business data. For most changes, there impact of changing one or more code tables is exactly the same. In addition, no matter how many code tables are involved in a elementary business process, they all count as a single file type referenced (FTR).