6.1Product ModelsThe are a variety of software products, requirements documents, specification documents, designdocuments, source code, object code, test plans, user documentation, etc. For each such product, thereare a variety of models that characterize some aspect of the product. These models offer visibility andinsights into the product from a variety of perspectives. Product models can be broken down intoseveral categories. Two major categories are static and dynamic models. Static models are based uponthe static properties or structure of the product while dynamic models are based upon the executionbehavior of the product. Static models include size and structural complexity. Dynamic models includereliability, performance and test coverage. Each of the models provides an insight into some property ofthe product.Product models and metrics can be used to evaluate the process and product, estimate the cost andquality of the product, and as a feedback mechanism during software development and evolution as amonitor of the stability and quality of the product.They provide a quantitative view of the software development process and product, can be used torefine and engineer techniques and tools, can help with technology transfer, and can be used to providequality assurance probes into the product to provide visibility to anyone who needs it. In there mostrefined form they can be used in contracts for award, acceptance, and budget incentives.In the next sections we will cover models and metrics for size, control and data structure complexity,reliability, and test coverage.Size ModelsAlthough size is the most common metric, it is the most difficult to articulate. That is because it dependsupon so many different factors, e.g., the notation, the formatting style of the notation, what aspects ofthe product are considered part of its size (for example are comments extraneous information oressential parts of the size of a product), etc. For example, if we are interested in the size of arequirements document, a great deal depends upon whether the document is written in English or someformal notation and how we distinguish and enumerate requirements. Of the requirements are written inEnglish and we are unable to distinguish or enumerate independent requirements then how do we modelsize? We could count pages of the document, which has been done, but now we are concerned abouttype font, spacing, etc.The problems associated with models of size fall into two categories. The first is what do we count, i.e.what models for size do we use. These problems are partly addressed by the GQM in that theappropriate models to choose depend upon our goals. Deciding what we want to count, i.e.enumerated requirements, pages, etc. fall into this category. The second problem is associated withwhether or not there are reasonable measures that can be associated with the model. Being able todistinguish requirements, i.e., having a mechanism for enumerating requirements falls into this category.6.2This problem is dependent upon our ability to formalize the notation of the product in such a way thatthe measure makes sense.Since size metrics depend upon the product and its model, let us give some examples of size metrics andthe products they can be used on.S1. number of pages of the documentS2. number of requirementsS3. number of functions in the specificationS4. number of subsystemsS5. number of modulesS6. number of function pointsS7. number of procedures, functions or packagesS8. number of lines of codeS9. number of tokensNone of these measures are good or bad in their own right. It depends upon how we use them,whether they satisfy the concept we are trying to analyze.The number of pages of documentation can be associated with any document. It is a very gross measureand highly dependent upon the notation and page format. However, if one is interested in comparingproducts of similar notations and format is serves as a simple gross measure of size.The number of requirements is an excellent measure of any document representing the function of thesystem, e.g., the requirements document, the specification, the design, and code. It provides a measureof the functionality that the system represents and can be used to compare documents of similar sizefunctionality. For example two systems that have the same number of requirements (and are of a similarnature) that have dramatically different fault rates or lines of code associated with them provide someinsight into the development process used to produce the code. The problems associated with thismeasure are the ability to distinguish requirements, account for their interdependence, and choose thelevel at which to count.For example, in a compiler, enumerating requirements as the number of declarations and statements thatneed to be translated is one mechanism for enumerating requirements. However, the definition of thestatements and their interdependence in terms of the effect on the run-time environment, clearly changesthe concept of ôsizeö if we are comparing the size of compilers for two languages that have verydifferent run-time environments. Clearly a great deal depends upon how we are using the size measure.If we are using it to show that languages with a similar number of requirements have very differentdesigns and implementations based upon the sizes of the implementation, then the measure of number ofstatements is a reasonable measure of number of requirements. If we are using it to justify that thecompiler should both be the same size, then we are misusing the measure.6.3The number of functions in the specification is similar to the number of requirements except it is viewingfunctionality from the point of view of the designer, rather than the point of view of the user or customer.The number of subsystems is primarily a measure of the design, as is the number of modules. However,both these definitions require careful definitions of the terms. As we have seen in the literature, modulecan be used to mean everything from a FORTRAN subroutine to an information hiding subsystem.The number of function points is a derived measure associated with the amount of data beingprocessed.The number of procedures, functions or packages is a macro measure of code size or a micro measureof design. It can be used for estimation of effort since one can categorize these units by application ortype and associate a data base of effort a a detailed level of