Đo dự án phần mềm docx

Measuring Software Projects Chapter 12 To ensure the quality of software products, it is important to measure the effectiveness of the software development process at various stages. For this, you need to measure the effectiveness of the process components. In addition, you need to determine the complexity of the design created by using UML artifacts. This chapter explains how to measure the effectiveness of a software development process. In addition, it explains how to measure the complexity of the software design created by using UML artifacts. In this chapter, you will learn to:  Measure the process-components of the software development process  Measuring a project by using the function point technique  Measure the complexity of UML artifacts Objectives ¤NIIT Measuring Software Projects 12.3 N ote 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 dimensions of quality process, a process-component also consists of the following dimensions:  Technology: Refers to the output of a process-component. For example, the output of system designing process-component is a design document containing various diagrams.  Methodology: Refers to activities and tasks related to a process-component. For example, the system designing process-component can have several activities, such as analyzing SRS and creating UML diagrams. To perform the activity of creating UML diagrams, you require several tasks, such as identifying use cases, and actors, creating use case diagrams, and creating class diagrams.  Sociology: Refers to roles in a process-component. For example, the system designing process-component can have various roles, such as software engineer, system designer, and system architect. You calculate the total number of roles, activities, output, and tasks to measure all the process-components of a software development process. Consider the example of GoodWill Technologies, which is developing library management software for a city library. The project manager of GoodWill Technologies has identified the following process-components of the software development process:  Requirements modeling  System designing  Coding  Integration and testing The process-components identified for a software development process depend upon the context of the project. The process-components need not be the same as the phases of software development life cycle. Measuring Software Development Process Measuring Process-Components 12.4 Measuring Software Projects ¤NIIT The project manager has also identified the following dimensions of the process-components:  Output, such as SRS document, design documents, code, and test cases.  Activities, such as gathering and analyzing requirements, creating software system design, and coding the software system.  Tasks, such as identifying use cases, actors, and classes.  Roles, such as project manager, developer, and quality analyst. The following table lists the number of roles, activities, tasks and output of all the process-components in the library management software development process. Dimensions of Process-Component Number of Dimensions of Process-Component Output 4 Activities 7 Tasks 20 Roles 6 Total Unit Value 37 Dimensions of Process-Component In the preceding table, note the value contained in the last row. This value is the total unit value that you can use to estimate a software development process. You can also use the total unit value to compare different software development processes. You may need to refine the total unit value in context of a specific environment. This is because the same software can be implemented in various environments. For example, the library management software can be implemented in various environments, such as in schools, universities, and city libraries. The number of instances of each role required to implement the library management software in different environments will be different. The library management software for a school will be less complex as compared to the software for a city library or university. Therefore, to implement the library management software for a school, you require less number of people in the development team as compared to the people required for implementing the software in a city library or university. 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. For example, you need to determine the number of developers, testers, and quality analysts required to develop the library management software for the city library. ¤NIIT Measuring Software Projects 12.5 N ote In addition, you need to determine the weighing factors for each dimension of the process-components to refine the total unit value. For example, in context of the quality of the library management software that will be obtained at the end of the project, the role of a quality manager is more significant as compared to the role of a developer in the software development process. Therefore, the weighing factor of quality manager should be more than that of the developer. Therefore, 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. You need to multiply the number of instances of the dimensions to their weighing factor to obtain the strength of the process-component dimensions. The following table lists the number of instances, weighing factors, and strengths associated with each dimension of the process-components in the library management software development process. Dimensions of Process-Component Number of Instances Weighing Factor Strength Project Manager 1 100 100 Senior Software Engineer 2 80 160 Developer 5 50 250 Configuration Manager 1 80 80 Quality Manager 1 80 80 User 500 20 10000 Deliverable 1 600 600 Activities 18 30 540 Tasks 50 50 2500 Total Value 14310 Instances and Weighing Factors of the Dimensions of Process-components The values taken in the preceding table are only examples and may vary depending upon the software system that you are developing. 12.6 Measuring Software Projects ¤NIIT Calculating Adjustment Factor You implement the dimensions of process-components in different iterations of the software development process. Therefore, you need to specify the number of dimensions of process-components for each iteration of the software development process. 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. The actual productivity might deviate from the planned productivity. Therefore, you need to determine the adjustment factor that enables you to determine the schedule slippage of the software project. In the example of library management software, 14310 process-components need to be implemented. The project manager of GoodWill Technologies decides to implement 6000 process-components in the first iteration, which is of three months duration. The project manager decides to implement the remaining 8310 dimensions in the second iteration, which is of six months duration. Therefore, the planned productivity for the first iteration is implementing 6000 process-components in three months. In other words, 2000 process components need to be implemented per month. Similarly, the planned productivity for the second iteration is implementing 8310 process-components in six months. In other words, 1385 components need to be implemented per month. After the completion of the first iteration, the project manager identifies that 6000 process-components have been implemented in four months. In other words, only 1500 process-components have been implemented per month. Therefore, the actual productivity is 1500 process-components per month and the first iteration of the software project is delayed by one month. Based on these figures, the project manager realizes that the project will be further delayed in successive iterations and the project would not be completed in the scheduled time. To analyze the total expected delay in the project, you need to perform the following steps: 1. Calculate the adjustment factor. 2. Calculate revised time required to complete the successive iterations using the adjustment factor. The adjustment factor can be calculated as follows: Adjustment Factor = Actual productivity/ Planned productivity In the example of library management software, the adjustment factor is as follows: Adjustment Factor = 1500/2000 = 0.75 To calculate the revised time required to complete a successive iteration, you need to divide the planned duration by the adjustment factor. For example, in the library management software, the planned duration for the second iteration is six months. ¤NIIT Measuring Software Projects 12.7 Therefore, the estimated revised duration required for completion of the second iteration is: Revised Time Estimate = (6/0.75) months = 8 months According to the revised time estimate, the second iteration will be delayed by two months. The first iteration was delayed by one month and the planned duration for the project was nine months. Therefore, the library management software project will require a total of twelve months to complete. The project manager should take appropriate steps to prevent such delay. 12.8 Measuring Software Projects ¤NIIT 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. Invented by Albercht of IBM in 1979, this technique has evolved over the years. The International Function Point Users Group (IFPUG) has been promoting and encouraging effective management of software development and maintenance activities by using the FP technique. The key to identifying the FPs of a software, is to identify the different components that make up a software system. For this, you need to analyze the proposed system to identify the files required to store information and the interfaces to other systems. In addition to creating the files and interfaces, you will spend time in building input screens (Inputs), enquiry screens (Enquiries), and reports (Outputs). Therefore, the estimation of the total work can be done by counting the total number of:  Files  Interfaces  Inputs  Outputs  Enquiries 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). Measuring a Project by Using the Function Point Technique Evolution of FP Calculating FPs ¤NIIT Measuring Software Projects 12.9 Determining the Type of FP Count The FP count for different types of projects is different. The three basic categories of function points based on the type of project are:  Development Project FP Count: Evaluates the functions provided to the users with the first version of the software. This type of count is associated with new development work. The count will include all functions that are part of the first delivery of the software application. FP can be calculated at phases of a development project to track scope creep.  Enhancement Project FP Count: Measures enhancements to existing applications. It is common to enhance software after it has been placed into production. Tracking the enhancement size and the associated cost helps you understand how a development project has changed over time. It also helps you create a historical database for your organization.  Application FP Count: Measures the FP count for the installed version of the software. This count provides a measure of the current functions that the software provides to the user. Initially, this count equals the development FP count. However, as enhancements are made to the software, the application FP count is updated. Identifying the Scope and Application Boundary A computer system interacts with other computer systems and humans. Therefore, a boundary must be drawn around the system. This helps in identifying the components of the proposed system and the system’s references to external components. Determining the UFP To determine UFP, you need to 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. Based on this information, you need to calculate the following two types of FPs:  Data FPs  Transaction FPs 12.10 Measuring Software Projects ¤NIIT Data FPs Data FPs must consider the internal and external data requirements of an application. Consequently, data FPs are calculated by measuring the:  Internal Logical Files (ILFs): It is a group of logically related data or control information maintained within the boundary of the software application being developed. The primary intent of an ILF is to hold data maintained through one or more elementary processes of the application being developed. An elementary process is the smallest unit of activity that is meaningful to the users.  External Interface Files (EIFs): It is a group of logically related data or control information referenced by the software application, but maintained within the boundary of another application. The primary intent of an EIF is to hold data referenced through one or more elementary processes within the boundary of the application being developed. ILFs and EIFs are together called File Types Referenced (FTRs). An EIF counted for one application must be an ILF for another application. Once FTRs are identified, you need to determine the following two values for each FTR:  Data Element Types (DETs): Unique, user recognizable, non-repeated field maintained in or retrieved from the ILF or EIF through the execution of an elementary process. The DETs are counted by applying the following rules: z Count one DET for each unique field executed through an elementary process. For example, the account number of a customer is counted as one DET. z Two separate applications may look at the same data function and yet have separate DET counts. For example, components of customer address might be viewed as many DETs or one DET as per the logic of a process.  Record Element Types (RETs): User recognizable subgroup of data elements within an ILF or EIF. For example, consider a customer file that stores the details of the customer such as Name, Address, and Phone. The same file may store the details of the credit cards of the customers. For each customer, there may be multiple occurrences of credit cards. In this case, there are two subgroups of data elements within the file. One of the following rules applies when counting RETs: z Count a RET for each optional or mandatory subgroup of the ILF or EIF. z If there are no subgroups, count the ILF or EIF as one RET. Once the number of DETs and RETs for each FTR are determined, the complexity and corresponding score of each FTR can be determined by using the IFPUG reference matrix for ILFs and EIFs.