Class Points
Based on the design document, the quantification can be effectively done using a class diagram in objectoriented development. The class hierarchy and structural functionality will be contained in the specified target system. These are referred as logical blocks for the developed system. The development of the technique class point was done in 1998 (ISBSG). This class point approach is related to the function point method. By means of counting the internal attributes, the system will be denoted.
To find the measurement of a target system three main steps have been followed. These steps are illustrated in Figure 2.2. Some sort of activity must be performed in every step in order to collect the data that quantified in various classes.
The classes must be identified, and divide onto four types of system in the initial step. The different types of system are as follows:
 (1) Task Management Type (TMT).
 (2) Human Interaction Type (HIT).
 (3) Data Management Type (DMT).
 (4) Problem Domain Type (PDT).
Every type represents features of the target system.
A complex system can be easily differentiated with the help of this classification and the contrast between them can be analyzed easily. Once the finding and classification of class is completed, the level of complexity existing in each class will be determined by class points. Further, the number of attributes, the number of services requested, the number of external methods, etc., were also determined. Through using the technical complexity present in the target system, the evaluation of class points will be done. In the previous section the determination of the technical complexity factor is explained briefly. For this class point, the detailed explanation based on equation and protocol.
FIGURE 2.2 Class Point computation procedure.
The technique is not well suited for general software projects. The gathering of quantification information is not effectively achieved in the class point technique. Only the number of attributes, the number of services requested, and the number of external methods was calculated. Additionally, the estimating of effort in software systems is affected by the number of classes, number of parameters, and number of inheritance relationships. The professional decision methods such as Technical Complexity Factor (TCF), Total Degree of Influence (TDI), complexity level, and component type were utilized by UCP. For every factor the obtained value will be related to an expert’s decision and variance will be created based on final outcome.
The modified class point was developed to overcome these kinds of issues. The developed technique possesses similar sorts of advantages, like use case points which is given in the preceding section. The developed technique will depend only on the diagram and independent of subjective factors like expert decision. The system’s architectural complexity can be easily solved by this modified class point. For various factors the equation and definition is explained below.
In order to determine the structural complexity, basic information must be collected from the class diagrams represented in Table 2.7, and to find the structural complexity the relative information must be collected from the class represented in Table 2.6 from equations 7 to 13. By summing the value of the class points the CP will be obtained.
In the target system, architectural complexity can be learned effectively by the developer and project manager using this class points and use case points created on the basis of UML. Within UML the concept of size measurement may be utilized for estimating effort in the project. Through summation of class points and use case points, UML points can be obtained.
Example:
Consider the project with following parameters:
Class Type 
Number of Classes 
NEM 
NSR 
NOA 
PDT 
3 
5 
3 
10 
4 
5 
8 

9 
12 
7 

HIT 
5 
6 
8 
9 
7 
12 
10 

6 
9 
6 

5 
7 
2 

5 
6 
3 

DMT 
2 
2 
4 
0 
1 
0 
0 

TMT 
2 
4 
3 
0 
6 
10 
1 
Assume all the technical factors have average influence. Estimate the effort using CP1 and CP2.
SOLUTION
The values of CP1 and CP2 are taken from Appendix A for the corresponding NEM (Number of External Methods), NSR (Number of Services Requested), and NOA (Number of attributes) given in the problem.
Class Type 
Number of Classes 
NEM 
NSR 
NOA 
Complexity (CP1) 
Complexity (CP2) 
Weight (W1) 
Weight (W2) 
PDT 
3 
5 
3 
10 
Average 
High 
6 
10 
4 
5 
8 
Average 
Average 
6 
6 

9 
12 
7 
Very high 
High 
15 
10 

HIT 
5 
6 
8 
9 
High 
High 
12 
12 
7 
12 
10 
High 
High 
12 
12 

6 
9 
6 
High 
Average 
12 
7 

5 
7 
2 
High 
Low 
12 
4 

5 
6 
3 
High 
Low 
12 
4 

DMT 
2 
2 
4 
0 
Average 
Low 
8 
5 
1 
0 
0 
Low 
Low 
5 
5 

TMT 
2 
4 
3 
0 
Low 
Low 
4 
4 
6 
10 
1 
High 
Low 
9 
4 
FOR CP1 FOR CP2
TABLE 2.7
Mathematical Equations of Different Factors
s. No. 
Factors 
Definition 
Equation 
1. 
Number of Classes (NOC) 
The correlation exists between the effort estimation and quantity of classes utilized for developing the target system and then the architectural complexity of the software system will be determined. 

2. 
Number of Realized Relationships (NORR) 
One of the correlation attributes existing among classes will be shown by this definition, then quantity of realized relationships utilized for developing the target system must be mentioned. 

3. 
Number of Methods (NOM) 
Total number of methods utilized for developing the target system. The correlation exists between the effort estimation and quantity of classes utilized for developing the target system and then the architectural complexity of the software system will be determined. 

4. 
Number of Class Attributes (NOCA) 
Total number of class attributes required for developing the target system. 

5. 
Number of Associations (NOASSOC) 
Number of associations utilized for developing target system. 

6. 
Number of Use Relationships (NOUR) 
One of the correlation attributes existing among classes will be shown by this definition, then quantity of use relationships utilized for developing the target system must be mentioned. 

7. 
Average Number of Class Attributes per Class (ANCA_CLS) 
The average number of class attributes per class within the document meant for designing. 

8. 
Average Number of Parameters per Class (ANP_CLS) 
The average number of parameters per class within the target system. 

9. 
Number of Inheritance Relationships (NOIR) 
One of the correlation attributes existing among classes will be shown in this definition, then quantity of inheritance relationships utilized for developing the target system must be mentioned. 

10. 
Average Number of Associations per Class (ANASSOC_CLS) 
The average number of associations per class within target software system. 
(Continued)
TABLE 2.7 (CONTINUED)
Mathematical Equations of Different Factors
s. No. 
Factors 
Definition 
Equation 
11. 
Class Points (CP) 
The class points present in target system. 

12. 
Average Number of Relationships per Class (ANREL_CLS) 
The average number of relationships per class within the target system. 

13. 
Average Number of Methods per Class (ANM_CLS) 
The proportion of number of methods to class existing within target system. 

14. 
Number Of Parameters (NOP) 
The parameters that are utilized in the specified method will be shown in this definition. The correlation exists between the effort estimation and quantity of classes utilized for developing the target system and then the architectural complexity of the software system will be determined. 
Given that all the technical factors have average influence. Thus, Thus,
The Constructive Cost Model (COCOMO)
In his book, which is based on software economics, Boehm explained a model for estimating the cost referred as COCOMO. Generally, three stages of application will be offered by this model which includes advanced, intermediate, and basic. On the basis of factors contained in the model the advanced application will be rendered. On the basis of complexity, the application is then classified onto three modes, such as detached, semidetached, and organic. The environment is developed using this approach. Jones (1996), explained a general effort model that is suited for every level of mode and application.
Where,
E = effort estimation, expressed in manmonths.
EDSI = estimate of distributed source instruction.
The determination of the parameters a and b will be done through the mode of development and the value for these parameters is found to be constant. In cases of complexity of the application the parameter is also increased. For the basic model the EAF and effort adjustment factor is found to be 1. For advanced and intermediate EAF and effort adjustment factor will be equal to a product of 15 cost factor. In terms of cost, the multiplicative cost factor is found to be reflective of a predicted proportional decrease (<1) or increase (>1). For instance, the cost factor of about 1.15 can be utilized for large degrees of reliability and the entire effort estimation is increased. If the cost factor of about 0.88 is utilized for a lower degree of reliability then the entire effort estimation is decreased (Jones, 1996).