This scholarly paper makes several important contributions to the software engineering problem of how to size a system. Remember that size is the principal factor when determining the cost of system development. The authors provide models for sizing certain types of applications. They also indicate how to improve productivity. Their approach is reasonable, a good read, and dovetails with my own sizing experience. I especially like the way the authors carefully qualify their results.

The authors make the wonderful observation that “the number of attributes in classes does not affect the complexity as much as the number of classes and relationship types.” This insight suggests how software engineers can constrain software design in order to minimize size. They clearly define the nature of the sizing problem.

Section 3.1 restricts their findings to information systems. An information system is defined as “a database application that supports business processes and functions through maintaining a database using a standard database management system (DBMS).” In an entity-relationship model, information systems have the following properties: a graphical user interface (GUI); business logic embedded in the database; report generators; the ability to update data structures to reflect business processes; simple data functions; and error correction programs.

The researchers confess that without careful data controls, their results were inconsistent. Then, they explain how to get valid data. Their results are based on a good set of data with Java code.

Although the authors fail to define a physical line of code, I think they count the number of carriage returns, subtracting comment lines and blank lines. They do not indicate whether the lines of code include data definition statements. They use Code Counter Pro 1.21, which implicitly defines a line of code.

Their model contains a set of equations computing KLOC, the metric of 1,000 lines of code, as a linear function of the number of classes, the number of relational types, and the average number of attributes per class. Each equation deals with a carefully defined subset of information systems. They do not study nonfeature code needed to satisfy architectural constraints such as reliability, performance, recovery, operability, scalability, and maintainability. Also, when function points are used for sizing, the authors report that reuse level, security, GUI, and external reports and inquiry need to be added to adjustment factors.

There is a small but important error in Section 5.1.2: the conversion factor of 53 is not prescribed; it is an industry approximation and needs to be calibrated individually for each software shop.

Overall, this paper presents a thoughtful approach to software sizing. If your application fits within the authors’ constraints, you can profitably use their approach. (Heed their warning and do not apply their model carelessly.) I look forward to future papers on these continuing research efforts and insights.