CHAPTER-3.pdf

CHAPTER 3 S O FTW ARE P RO C E S S ES AND P RO J E CT ME TRI CS At the end of the chapter, the student will be able to: 1. discuss software metrics; 2. describe the measurements for computer software; and 3. identifies the categories of software measure...

CHAPTER 3 S O FTW ARE P RO C E S S ES AND P RO J E CT ME TRI CS At the end of the chapter, the student will be able to: 1. discuss software metrics; 2. describe the measurements for computer software; and 3. identifies the categories of software measurements.  CHAPTER 03: SOFTWARE PROCESS AND PROJECT METRICS 3.1 Meanings Software metrics refers to a broad range of measurements for computer software measurement can be: ▪ applied to the software process with the intent of improving it on a continuous basis ▪ used throughout a software project to assist in estimation, quality control, productivity assessment, and project control ▪ used by software engineers to help assess the quality of technical work products and to assist in tactical decision making as a project proceeds Measure provides a quantitative indication of the extent, amount, dimensions, capacity, or size of some attribute of a product or process Metric is a quantitative measure of the degree to which a system, component, or process possesses a given attribute Indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the project itself; it provides insight that enables the project manager or software engineers to adjust the process, the project, or the product to make things better. 3.2 Process and Project Indicators Process indicators It enables a software engineering organization to gain insight into the efficacy of an existing process Project indicators It enables a software project manager to: ▪ assess the status of an ongoing project, ▪ track potential risks, ▪ uncover problem areas before they go critical, ▪ adjust work flow or tasks, ▪ evaluate the project team’s ability to control quality software engineering work products 3.3 Classification of Software Metrics Figure 3.1. Determinants for Software Quality and Organizational Effectiveness Process sits at the center of a triangle connecting three factors that have a profound influence on software quality and organizational performance. The skill and motivation of people has been shown to be the single most influential factor in quality and performance. The complexity of the product can have a substantial impact on quality and team performance. The technology (i.e., the software engineering methods) that populate the process also has an impact. In addition, the process triangle exists within a circle of environmental conditions that include the development environment (e.g., CASE tools), business conditions (e.g., deadlines, business rules), and customer characteristics (e.g., ease of communication). Process Metrics These are metrics that pertain to Process Quality. They are used to measure the efficiency and effectiveness of various processes. Process Metrics describes the effectiveness and quality of the processes that produce the software product. Examples are: ▪ effort required in the process ▪ time to produce the product ▪ effectiveness of defect removal during development ▪ number of defects found during testing ▪ maturity of the process Product Metrics These are the measures of various characteristics of the software product. The two important software characteristics are: ▪ Size and complexity of software ▪ Quality and reliability of software 3.4 Project Metrics Project metrics Project metrics are the metrics used by the project manager to check the project's progress. Data from the past projects are used to collect various metrics, like time and cost; these estimates are used as a base of new software. Note that as the project proceeds, the project manager will check its progress from time-to-time and will compare the effort, cost, and time with the original effort, cost and time. Also understand that these metrics are used to decrease the development costs, time efforts and risks. The project quality can also be improved. As quality improves, the number of errors and time, as well as cost required, is also reduced. Project metrics are considered as tactical. It is used by a project manager and a software team to adapt project work flow and technical activities. Its first application on most software projects occurs during estimation. Metrics collected from past projects are used as a basis from which effort and time duration estimates are made for current software work production rates represented in terms of pages of documentation, review hours, function points, and delivered source lines are measured. Technical metrics are collected to assess design quality and to provide indicators that will influence the approach taken to code generation and module and integration testing. Twofold intent of project metrics ▪ these metrics are used to minimize the development schedule by guiding the adjustments necessary to avoid delays and mitigate potential problems and risks  ▪ project metrics are used to assess product quality on an ongoing basis and when necessary, modify the technical approach to improve quality Suggested project measures ▪ inputs — measures of the resources required to do the work ▪ outputs — measures of the deliverables or work products created during the software engineering process ▪ results — measures that indicate the effectiveness of the deliverables Direct Measures ▪ in software engineering process, it includes cost and effort applied ▪ in product, it includes lines of code (LOC) produced, execution speed, memory size, and defects reported over some set period of time Indirect Measures ▪ include functionality, quality, complexity, efficiency, reliability, maintainability, and many other “abilities” 3.5 Size-Oriented Metrics Size-oriented metrics derived by normalizing quality and/or productivity measures by considering the “size” of the software that has been produced. But it is not universally accepted as the best way to measure the process of software development. Project LOC Effort P(000) pp.doc. Errors Defects People alpha 12,100 24 168 365 134 29 3 beta 27,200 62 440 1224 321 86 5 gamma 20,200 43 314 1050 256 64 6.................... Figure 3.2. Size-Oriented Metrics 3.6 Function-Oriented Metrics This metrics use a measure of the functionality delivered by the application as a normalization value. It was first proposed by Albrecht, who suggested a measure called the function point. Figure 3.3. Function-Oriented Metrics Function Point Function Point was derived using an empirical relationship based on countable (direct) measures of software’s information domain and assessments of software complexity Information Domain Values ▪ Number of user inputs - each user input that provides distinct application- oriented data to the software is counted ▪ Number of user outputs - each user output that provides application- oriented information to the user is counted ▪ Number of user inquiries - each distinct inquiry is counted ▪ Number of files - each logical master file (i.e., a logical grouping of data that may be one part of a large database or a separate file), is counted  ▪ Number of external interfaces - all machine-readable interfaces (e.g., data files on tape or disk) that are used to transmit information to another system are counted ▪ To compute function points (FP), the following relationship is used: FP = count-total x [0.65 + 0.01 x å Fi] where count-total is the sum of all entries obtained from the figure. 3.7 Software Quality Measures Correctness ▪ the degree to which the software performs its required function ▪ can be measured in defects per KLOC, where a defect is defined as a verified lack of conformance to requirements ▪ “Does it perform to its required function?” Maintainability ▪ the ease with which a program can be corrected if an error is encountered, adapted if its environment changes, or enhanced if the customer desires a change in requirements ▪ can be measured using MTTC (mean-time-to-change) ▪ “Is it capable to be corrected?” Integrity ▪ measures a system’s ability to withstand attacks (both accidental and intentional) on its security  ▪ can be measured in terms of threat and security ▪ “How it is secured?” Usability ▪ an attempt to quantify “user friendliness” and can be measured in terms of four characteristics: 1. the physical and/or intellectual skill required to learn the system 2. the time required to become moderately efficient in the use of the system 3. the net increase in productivity measured when the system is used by someone who is moderately efficient 4. a subjective assessment of users’ attitudes toward the system ▪ “Is it user-friendly?”