Software Size Measurement Methodology Selection:
Care should be taken while selecting a methodology to use for the Functional Size Measurement. The methodology should be such that it measures all the major, relevant functionality on which the effort is required to be spent on development; otherwise – in case of measurement of only a small part of the software functionality – the significance of measurement is lost. The methodology should be simple and easy to use as well. Hence, there is a need of an integral software size measurement methodology which is presented in the FSSM book.
The following are some important facts that should be considered regarding the Functional Size Measurement, and methodologies to measure the functional size:
- Software Components:
Software is composed of several distinct components which are inter-related but do not have any obligatory fixed size proportion relationship with respect to one another in any software application. That means, if there are four components: c1, c2, c3 and c4, their size may have any proportion according to the functional requirements concerning these components in different applications. So the magnitude of c1 may be much greater (measured by any method, e.g., counts, units) than c2 in one software application but it may be the opposite in another application. Similarly, the size proportion of c1 to other components in one application may be entirely different than in another application. - Software Components' Features:
Each component has several features. For example, component c1 may have two features: c1f1, c1f2; component c2 may have three features: c2f1, c2f2, c2f3; component c3 may have four features: c3f1, c3f2, c3f3, c3f4; and component c4 may have one feature: c4f1. The size of different features varies according to the application. For most of the features, there is no fixed size relationship of different features of a component amongst themselves and with the features of other components. For example, in one application, the size of one feature c1f1 may be about 10 times bigger (measured by any method, e.g., counts, units) than the size of c2f3, but in another application, it may be of approximately the same size or even of opposite proportion. - Application Sub-programs (Modules):
If an application is made of several sub-programs or modules, the sub-programs have different proportions of different features of the components and may not have any similar size proportionate relationship with respect to one another or with respect to the whole software. - Size and Complexity:
Size and complexity of a software component are interrelated
What is meant by the complexity of the software components here is the level and degree of effort and time required for understanding, analyzing, designing, coding, testing, and maintaining the components.
The more the effort and time are required for these activities, the more complex the component is. For example, regarding data component, 1 table with 10 columns in a database application, or 1 data record with 10 fields in a program is quite simple, but 20 tables with 15–20 columns each, or 20 data records with 15–20 fields each, respectively, are more complex, and 80 tables with 20 columns each, or 80 data records with 20 fields each, respectively, are highly complex as far as the effort and time required for their understanding, analyzing, designing, coding, testing, and maintaining are concerned. The same is true for other components – functionality execution, user interfaces, and message communication.
As a general rule, the bigger the size of the component, the more the effort and time required to understand, analyze, design, code, test, and maintain it; and the more the effort and time required to understand, analyze, design, test, and maintain it, the more complex the component is. - Effort for Software Development:
Effort for software life cycle activities – development (analysis, design, coding, and testing), maintenance, documentation, etc. – is spent on all the features of all the components. Of course, not all the minute details of all the functionality can be taken into account for measurement, but it is important that the most relevant, major components and all their important features should be considered for size determination, effort estimation, and performance indication. If an accurate estimation of the total software size is needed for correct project planning, the size of all the measurable features for all the components should be computed. Hence, no major and relevant component and at the same time, no major and relevant feature should be ignored for measurement and estimation. - Size Relationships of Software Components, Features in Applications:
If we consider various application programs in different domains and see the magnitude of the presence of different features of the constituent components, it will vary from one application to the other. Not only that, the magnitude will vary in different sub-programs or modules of these applications programs with respect to one another.
The relationship of size between the components and their features depends on only the functionality required and it varies from one application to the other, and from one sub-program (module) to the other of any particular application.
For example, in the signaling part of the application of telecom call handling (call handling would normally consist of signaling, call control, number analysis, routing, charging, subscriber data, etc.), there will be much more amount of
input/output operations from the input/output devices and much more message communication to/from other modules than the disk memory read/write operations. On the other hand, subscriber data will have more disk memory read operations to access the subscriber data, and message communication to/from call control module than computational/logical and decision operations. Routing may have more proportion of decision operations to decide about the routing.
In the radar application which will normally consist of input/output for image data, image extraction, filtering, etc., there will be high amount of input/output operations, high amount of computational operations, and medium amount of disk memory read/write operations in the complete application.
In a data warehouse report preparation application, there will be high amount of disk memory read/write operations and high amount of computational operations. - Partial Measurements of the Components and of their Features:
If only a few features of one component or of a few components are measured (by any method, e.g., counts, units) and based on that the complete software size is calculated by using various multiplication factors, it may give unreliable results because there is no fixed proportional relationship of the size of one feature to the other feature(s) of the same component or of the other components for the majority of features as explained before. For example,
Example 1 In one application, there may be 50 data tables for which there may be one memory data read and write operation each from/to disk for each table, so the count for memory data read/write operations will be 100. In another application, there may be 2 data tables of which there may be 25 memory data read and write operations each from/to disk for each table, so the count for memory data read/write operations will be 100. In both the applications, the number of memory data read/write operations is the same but the data complexity and effort required
from the point of view of development is much more in the former application. If we do the measurement of only memory data read and write operation, we would not know how big and complex the data part is, and whether database expertise is required for the development.
Example 2 In an application, there may be 2 user screens, one for input data and the other for output data, being used for input/output data 50 times each, so there will be 100 input/output operations. In another application, there may be 50 user screens for input data being used for 1 input operation each and 50 user screens for output data being used for 1 output operation each, so the total number of input/output operations will be 100. In both the applications, the number of input/output operations is the same but the user interface design in the latter application is more effort consuming than the former. Only the size of input/output operations does not give a right indication about the input/output interface size and complexity, and thus the effort required for designing the screens, that is, screen structures, cannot be estimated based on the size of the input/output operations.
Moreover, in the aforementioned examples, the size of memory data read/write and input/output operations, respectively, does not indicate the magnitude of other operations in the program, for example, computational, logical, decision, repeat, execution flow control, and message exchange operations, and thus the effort required for these operations cannot be estimated. - Partial Measurement in the Existing Methodologies:
The existing methodologies of software size measurements measure only a few features of a few components and try to estimate the total software size with the help of some multipliers based on type/field of applications and past experience with similar projects. Effort estimation done in this manner may be inaccurate in most of the cases. - Skills and Expertise for Software Development:
Different skills and expertise may be needed for different activities of the software life cycle; for example, for an application which uses huge amount of data deploying databases, database skills would be required. Hence, it is necessary/desirable to know the size and complexity of different components of the software which can
help in project planning activities from the point of view of human expertise and skills required. - Effort Calculations:
Real effort depends on many factors such as expertise, experience, knowledge, productivity, and efficiency of the project team members but the average effort which has, more or less, approximate fixed proportionate relationships with the type of components to be developed, tested, and maintained can be calculated taking into consideration the average productivity, efficiency, and knowledge. - Static and Dynamic Characteristics of Software:
Static and dynamic (run-time) characteristics of any software application may be different. For example, in a program, there may be one disk memory read operation which is in a loop of one thousand times. While counting the Function Points for the memory read operation, it will be counted as one Function Point which is correct from the point of view of software development because it will lead to the effort for writing the statement(s) for one such operation, but at run-time, it will create high disk memory read traffic. If it is desired to assess the run-time characteristics based on the Function Points, careful selection of the right kind of parameters (Function Points) will be required. - Dynamic (Run-time) Characteristics of Software:
Real run-time performance characteristics can best be obtained by capturing data at real run-time and analyzing that to find out what type of operations are being performed because the analysis based on static structure of data may not indicate the true performance due to the presence of decision operations. For example, if in a program there is one decision statement which leads to many:
a. memory data write operations if it is evaluated true;
b. data output operations for data display if it is evaluated false;
and if, at the execution time, the possibility of its being true is about 75%, the result will be high memory write traffic in about 75% of the cases and high output traffic for data display in the other 25% of the cases whenever the program is run. Based on the static structure analysis only, we will assess the program to have high memory as well as high output traffic which is also correct from the point of view of design because care will have to be taken to provide suitable design for both high memory traffic as well as high output traffic since both the situations can occur.