1. objectives:
 In this session, you will learn to:
 Measure the process-components of a software development process
 Measuring a project by using the function point technique
 Measure the complexity of UML artifacts

2.  To measure a software development process, you need to measure all its process-components.
 To measure the process-components, you need to measure its dimensions.
 Like the quality process, the process-component consists of the following dimensions:
 Technology: Refers to the output of a process-component.
 Methodology: Refers to activities and tasks related to a process-component.
 Sociology: Refers to roles in a process-component.

3.  To measure all the process-components of a software development process, you need to calculate the total number of
roles, activities, output, and tasks.
 The total number of roles, activities, output, and tasks is also called total unit value.
 You may need to refine the total unit value in context of a specific environment because the same software can be
implemented in various environments.

4.  To refine the total unit value, you need to determine:
 The number of instances of each dimension of the
process-components required in the software development process.
 The weighing factors for each dimension of the
process-components.
 The weighing factor for each dimension of
process-components depends upon the following:
 The environment of the software project.
 The importance of each dimension in the software project.

5.  To obtain the strength of the process-component dimensions, you need to multiply the number of instances of the
dimensions to their weighing factor.
 Estimating the number of dimensions of the
process-components for each iteration is known as the planned productivity.
 The actual productivity is determined at the completion of the iteration.
 To analyze the total expected delay in the project:
 Calculate the adjustment factor.
 Calculate revised time required to complete the successive iterations using the adjustment factor.

6.  Adjustment factor can be calculated as:
Adjustment Factor = Actual productivity / Planned productivity
 To calculate the revised time required to complete a successive iteration, you need to divide the planned duration by
the adjustment factor.

7.  The Function Point (FP) estimation technique is the most popular technique used to estimate the size of a project.
 This technique breaks systems into smaller components, so they can be better understood and analyzed.
 FPs are a unit measure for software much like an hour is to measuring time, miles are to measuring distance, or Celsius
is to measuring temperature.

8.  The FP technique was invented by Albercht of IBM in 1979 and has evolved over the years.
 The key to identifying the FPs of a software, is to identify the different components that make up a software system.
 Using the FP technique, the estimation of the total work can be done by counting the total number of:
 Files
 Interfaces
 Inputs
 Outputs
 Enquiries

9.  Calculating FPs for a project involves the following steps:
1. Determine the type of FP count
2. Identify the scope and application boundary
3. Determine Unadjusted Function Point (UFP)
4. Determine the Value Adjustment Factor (VAF)
5. Calculate the Adjusted Function Point (AFP)

10.  Determining the Type of FP Count:
 The three basic categories of function points based on the type of project are:
 Development Project FP Count
 Enhancement Project FP Count
 Application FP Count
 Identifying the Scope and Application Boundary:
 This helps in identifying the components of the proposed system and the system’s references to
external components.

11.  Determining the UFP:
1. Identify the following two types of information:
 Data at rest: Comprises of stored data that is required for processing.
 Data in motion: Comprises of transactions that result in movement of data in and out of an application.
2. Based on this information, calculate:
 Data FPs: Calculated by measuring the Internal Logical Files (ILFs) and External Interface Files (EIFs) –
Together called File Types referenced (FTRs). For each FTR, the following values are measured:
 Data Element Types (DETs)
 Record Element Types (RETs)
 Transaction FPs: These are calculated by measuring the following:
 External Input (EI)
 External Enquiry (EQ)
 External Output (EO)

12.  Determining the VAF:
 VAF is based on General System Characteristics (GSCs).
 There are 14 GSCs:
 Data Communication
 Distributed Processing
 Performance Objectives
 Heavily Used Configuration
 Transaction Rule
 On-line Update
 Complex Processing
 Reusability
 Installation Ease
 Operational Ease
 Multiple Site Use
 Facility Change

13.  To calculate the VAF, you need to:
1. Determine the degree of influence (DI) of each GSC. The DI of a GSC varies from 0 to 5:
0 – Not Present, No Influence
1 – Incidental Influence
2 – Moderate Influence
3 – Average Influence
4 – Significant Influence
5 – String Influence Throughout
2. Add the DIs of the 14 GSCs to obtain the Total Degree of Influence (TDI).
3. Use the following formula to calculate VAF:
VAF = TDI .01 + 0.65

14.  Calculating the AFP:
 To calculate AFP, you can use the following formula:
AFP = (TUFP + CFP) VAF
Where, CFP is the FP count for conversion functionality.

15.  Complexity refers to the degree of interdependency among the UML artifacts in an object-oriented software system.
 The complexity of the dynamic components depends upon the complexity of static components. Therefore, you only
need to measure the complexity of following static components:
 Use case diagram
 Class diagram
 Component diagram

16.  You measure the complexity of use case diagrams by identifying the number of actors, use cases, and their
relationships used in the diagram.
 You estimate the complexity of a use case in terms of the length of description required to explain the interaction
between multiple use cases and actors.
 The following are the categories of use cases based on the length of their description:
 Simple: Refers to the use case whose set of interactions can be described in a single sheet of paper.
 Medium: Refers to the use case whose set of interactions can be described in multiple sheets of paper.
 Complex: Refers to the use case that shares the extend and include relationships with the other use cases and
require multiple sheets of paper.

17.  You measure the complexity of a class diagram by determining:
 The size of its classes.
 The number of relationships among classes.
 The visibility of attributes of the classes.
 The visibility of operations of the classes.
 Complexity of a class diagram also depends upon the number of objects and their relationship.
 To measure the complexity of a class diagram, you can use the following object-oriented metrics suites:
 Chidamber and Kemerer (CK)
 Metrics for Object-Oriented Design (MOOD)
 Lorenz and Kidd

18.  In the CK metrics suite, the following class-based design metrics have been proposed for object-oriented systems:
 Weighted Methods per Class (WMC): Measure the complexity of a class in terms of the complexity of its
operations.
 Depth of Inheritance Tree (DIT): Measures the total number of edges in the inheritance tree from its lowest
node to its root.
 Number of Children (NOC): Measures the number of derived classes associated with a base class.
 Response for a Class (RFC): Measures the number of methods in the response set.
 Lack of Cohesion in Methods (LCOM): Measures the number of operations that access the same attribute.

19.  The MOOD metrics suite consists of two metrics that quantitatively measure the characteristics of object-oriented
design:
 Method Inheritance Factor (MIF): Measures the extent to which a UML class diagram can contain inheritance
for accessing operations and attributes of a class.
 Coupling Factor (CF): Measures the coupling among classes of a class diagram.

20.  The Lorenz and Kidd metrics suite consists of three metrics:
 Class Size (CS): Measures the size of a class by measuring the total number of operations and attributes
encapsulated within the class.
 Number of Operations Overridden (NOO): Measures the total number of operations of a base class that a
derived class has overridden.
 Number of Operations Added (NOA): Measures the total number of operations and attributes that are
declared in a derived class and have private visibility.

21.  Complexity of a component diagram is measured by measuring:
 Size of the components
 Processing speed of the components
 The size of a component diagram depends on:
 The number of classes that are realized in the component.
 The number of interfaces that share dependency relationship with the component.
 The processing speed of a component depends on the number of threads supported by the component.

22.  In this session, you learned that:
 To measure all the process-components of a software development process, you need to calculate the total
number of roles, activities, output, and tasks involved in the software project.
 The adjustment factor is used to determine the delay in the software project.
 The FP estimation technique is the most popular technique used to estimate the size of a project.
 In the FP technique, the estimation of the total work can be done by counting the total number of:
 Files
 Interfaces
 Inputs
 Outputs
 Enquiries

23.  To measure the complexity of UML artifacts, you determine the size and complexity of use case, class, and
component diagrams.
 The CK, MOOD, and Lorenz and Kidd metrics suites measure the size and complexity of a class diagram.
 The complexity of component diagrams is measured by determining the size and processing speed of components.