Conceptual data model-based software size estimation for information systems

Reviewer: Alan Raymond Hevner

The authors propose an approach for estimating software size from conceptual data models of information systems. Three independent variables characterize the conceptual data model: C , "the total number of classes"; R , "the total number of unidirectional relationship types"; and , "the average number of attributes per class." Drawing data from actual development projects in industry and open-source repositories, the authors build multiple linear regression models for size estimation in different system environments, such as industry Visual Basic systems, open-source PHP systems, industry Java systems, and open-source Java systems. The derived regression models are validated to predict system size in terms of number of lines of code, within an acceptable range of performance. Furthermore, the paper demonstrates that the new approach for cost estimation that predicts software size is comparable to the use of function points. The key advantages of using conceptual data models for cost estimation are the parsimonious use of only three parameters and the fact that such conceptual models are "more readily available in the early stage of software development" than many of the function point parameters. Thus, this cost estimation approach should appeal to managers of information system development projects with well-defined conceptual data models. Online Computing Reviews Service

Reviewer: Larry Bernstein

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. Online Computing Reviews Service