Informe de resultados prueba de inteligencia prueba WISC IV Nombre: NN F/N: 20/02/

Many organizations attempt to predict project cost at the requirements phase. This means that they attempt to measure the size of the system that is to be produced. One way to esti- mate the size of (and resources needed to create) a software system is to determine the size

of the system’s requirements. There are several commonly used approaches to measuring the size of a set of requirements:

• Count the number of distinct requirements. This method is probably too simplistic, since it does not consider system complexity. In addition, this metric is influenced by the separation of multiple clauses in a single requirements sentence into separate sentences, each representing an individual requirement.

• Compute the sum over all requirements of the “functionality” expressed by each requirement. This approach requires describing the functionality that is associated with each requirement. The functionality is matched to a scale with a set of weighting factors.

• Match the requirements to those of existing systems that are to be reused. In this method, only new software is counted in any measurement of the size of a system’s requirements.

• Compute the “size” of the interfaces to other software systems to which the desired software will be interoperable.

We will now discuss each of these measurement methods in turn.

Computing the number of distinct requirements is the simplest method of estimat- ing the eventual size of the system, since it requires no special analysis of the individual requirements. The number can be computed by examining the number of rows in the requirements traceability matrix.

Unfortunately, simply counting the number of requirements does not take into account the difficulty of implementing different individual requirements. Thus, this approach does not distinguish the complexity of implementing a requirement such as

The software will begin execution when the user enters the single UNIX command “go.”

Or from the complexity of implementing the requirement:

The system will be capable of processing 10,000 distinct transactions per minute, with no transaction suspended in a waiting queue for more than one second before it is processed.

In spite of the obvious imprecision, the number of requirements does provide at least a hint as to the amount of difficulty of implementing an entire software system. We can get more accurate information by examining the requirements in detail. The most common technique of estimating the functionality of a set of requirements is called “function point analysis.” The term was coined by Albrecht, who first developed the concept at IBM in 1979 (Albrecht, 1979). Jones (1993) describes the use of function points in project estimation.

The function point estimation technique is based on an assessment of the functionality needed for each requirement based on the following:

• The number and type of user interactions

• The number and type of interfaces to internal files • The number and type of interfaces to external files

• The general perception of the difficulty of programming in the project’s application domain

We will now describe a formal procedure for computing function points. All function point metrics are based on the number and types of interfaces in the program. Interfaces can be either internal or external. The total number and sizes of interfaces are used as the basis for the collection of function points. Once this total is obtained, it is modified by sev- eral weighting factors, some of which are subjective and some of which are objective. The subjective factors include an assessment of the complexity of the interfaces and the overall complexity of the system.

More precisely, weights are assigned according to the rules that are given in Table 3.9. After the weights are assigned, a complexity factor is determined in the range from 0 (rep- resenting no influence) to 5 (representing strong influence) for each of the factors given in Table 3.10.

For each software system to be analyzed, the sum of the “complexity adjustment values” fi is computed using the values determined from Table 3.10. The final result is the total

number of function points for the system according to the equation:

FP = count_total * (0.65 + sumfi/100)

As you can see, counting the number of function points in a proposed software system is somewhat subjective in the sense that there is no well-defined definition of terms such as “average,” “simple,” or “complex.” Other terms in the “complexity analysis” list clearly indicate a lack of precision in their definition. Therefore, it is highly probable that different people will produce very different estimates of the number of function points for the same software system. There are two general approaches to the ambiguity that is associated with the function point analysis process.

TABLE 3.9 Use of Weights for Function Point Analysis

Simple Average Complex

External input or files 3 4 6

External outputs or reports 4 5 7

External queries or responses 3 4 6 External interfaces to the systems 7 10 15

The first approach is to ignore minor differences, working under the assumption that many software measurements have errors and that minor differences can be ignored because they are not statistically significant. This makes it difficult to determine the cause of any variability between function point data that is gathered from several different soft- ware development projects. It might not be clear if any correlation between the number of function points and the amount of effort expended (as measured in person-months) is due to actual relationships or just to differences in counting techniques.

The second approach is to attempt to make the collection of function point data more rigorous. This is the approach taken by the various function point users’ groups.

We note that there have been several attempts at establishing standards for function point analysis (see Leach, 1998c for a detailed example). Rather than describe these stan- dards in detail, consult the electronic mailing list for the function point users group at a site hosted by the Computer Research Institute of Montreal: [email protected].

Regardless of the approach used to standardize the collection of function points, the objectively determined weights are obtained by determining if the program will be inter- active or will execute without user interaction. The effect of the program executing concur- rently with other applications is also included in these weights.

You should be aware that the function point metric is not directly associated with pro- gramming effort or system size. An organization using the function point metrics must define some of the subjective terms carefully, collect data, compare the data with other metrics that are directly computed using correlation and other methods, and then calibrate any models that use this metric. Only then can this metric be used with confidence in a particular environment.

Because of the inherent subjectivity of function point analysis, there are several distinct standards for it. Unfortunately, there is no single international standard that can be used to

TABLE 3.10 Use of Complexity Factors and Weights for Function Point Analysis

Complexity Factor Weight (0–5)

Reliable system backup and recovery Data communications

Distributed functions Performance Heavily used system Online data entry Ease of operation Online updates Complex interfaces Complex processing Reusability Ease of installation Operation at multiple sites Modifiability

determine some of the definitions needed for consistent application of the function point method. Thus, there is little reason to expect exact correlations of your organization’s expe- rience using function points for cost and schedule estimation with another organization’s use of function point data.