610 likes | 1.04k Views
Chapter 3: Software Project Management Metrics. What is a Metric. A metric enables you to measure the quality of a factor. E.g., prototype, the metrics could be the number of defects reported for the prototype.
E N D
What is a Metric • A metric enables you to measure the quality of a factor. E.g., prototype, the metrics could be the number of defects reported for the prototype. • The analysis of metrics enables you to make important decisions related to project management. E.g., the data for defects recorded for the prototype enables you to identify the causes of the defects.
Types of defects • Severe – critically affect the functionality of a product. • Major – logically affect the functionality of a product. • Minor – a slight defect but does not disturb the functionality of the application.
Characteristics of a Metric • Goal-oriented approach • Measurable • Analyzable • Programming Language-independent • Timely
Goal-oriented Approach The goal of a metric: • to reduce the time spent on it. • is used to define a baseline value.
Measurable • Measurability, metric can be used to measure a software entity to a high degree of accuracy. • Measurability of a metric ensures consistent results for all processes in a project. • E.g., measuring the reusability of a piece of code.
Analyzable • Another important characteristic of a metric is analysis. • If a metric is not suitable for analysis, it is futile to monitor it for improvement in a project. • E.g., an organization uses a metric to measure client satisfaction.
Programming-language independent • Metric is independent of the programming language used to develop software. • E.g., Software project is divided into three main modules. For each modules are programmed in different languages, the metrics that can measure the size, complexity, or the effort spent.
Timely • A good metric is timely. • The data to produce results using the metric should always be available when it is needed.
How Many Steps to Create a Metric? There are four steps to create a metric: • Define the goal of the metric • Identify the requirements of the metric • Identify the organizational baseline value for the metric • Review the metric for its usability
Define the Goal of a Metric • The definition of a goal is important because the metric is designed based on goal. • The goal should be as clear, measurable and as explicit as possible. • E.g., a metric can have a goal to measure the number of defects reported by clients.
Identify the Requirements of the Metric • After defining the goal of the metric, the next step is to identify its requirements. • The requirement include: human resource, data collection techniques, and methodologies used to process the data.
Identify the Organizational Baseline Value for the Metric • A baseline value is an average value, which is identified based on prior experience. • A metric is designed so as to achieve the baseline value.
Review the Metric for its Usability • It is the final step. • Process experts can be asked to test and provide feedback on the metric. • The feedback can be used to enhance the functionality and the user-friendliness of the metric.
Types of Software Metrics The types of metrics commonly used by organizations include: • Design metrics • Project metrics • Product metrics • Maintenance metrics
Design Metrics • Design metrics enable you to see the deviation from user requirements. • Lesser the deviation, fewer the defects. • Complexity is a characteristic measured during design phase. E.g., structure, data components and interface design. • Design metrics are difficult to implement. • Architecture design metric is the one of the varieties of design metrics.
Architecture Design Metrics • measures the complexities by referring to the design of the software program. • is crucial for predicting the features and functionalities of the final product. • addresses three types of complexities of a software program.
Architecture Design Metrics Types • Structural complexity – the number of fan-out modules. • Data complexity – the internal interface. • System complexity – combining the values of structural complexity and data complexity.
Example of Fan-out of a Module Check for Valid User Names Fan-out 1 Chk-Name String Not More Than 12 Fan-out 2 Fan-out 3 Check for Invalid Numeric & Alphanumeric Strings
Project Metrics • is a set of metrics related to all SDLC phases. • can help to avoid project delays, avoid and mitigate project risk. • also used to assess the quality of a finished product. • E.g., project metrics are the metrics that measure the size, complexity or the time and effort spent on a project.
Phases of Applying Project Metrics • Effort • Productivity FP • Cost • Size • Defects • Testing
Effort Metrics • to determine the amount of effort required to complete a project. • Generally, effort is estimated close to accuracy in all the phases of SDLC. • A man-month is the amount of effort required to complete work in a month.
Productivity Metric • Measurement human effort according to the number of hours spent on an FP of work. • The effort in performing an FP of work in an hour is called productivity. • To calculate productivity: • Determine the total amount of FP; • Distribute the total FP among the phases in the SDLC.
Cost Metric • measures the planned versus actual expense incurred on a project. • An important component of cost metric are resource and material resource. • Cost is the most difficult metric to control. • The reasons of cost overrun can be: price of the required resources, change, or shift in project objectives, or increase in the requirement of resources.
Size Metric • Size metric is calculated the number of FP for an entire project. • The size metric directly affects the effort, testing, and productivity metrics of a project. • Frequency changes mean that the design specifications are not clearly defined.
Defects Metric • Defects are errors that occur in a work product. • The number of defects defines the quality of a project. • Defects can occur during any phase of the SDLC. • To facilitate calculation and categorization of defects, many organizations use automated tools and techniques.
Testing Metric • Testing metric is used to measure the number of test cases required to test software. • Test case is a specification that needs to be executed to test a particular module. • There are separate test cases for: • Integration testing refers to the overall black box testing. • unit testing refers to testing individual modules.
Product Metrics • can provide an insight into the quality of work done by the development teams. • Product metrics trace and measure the quality of a deliverable in different phases.
Example of Product Metrics Effectiveness of a deliverable is measured in terms of the quantity of the deliverable completed and the number of quality goals achieved. Effectiveness = Quantity in % * Quality in % / 100
Maintenance Metrics • are used for maintenance projects. • Maintenance projects require enhancements based on client feedback or changes in the market, technology, and user preferences.
Measurement Types of Maintenance Project • Extent of change required. The modification (remaining, added, modified, deleted) modules are counted. • Type of maintenance requested by client. There are two types: • Corrective – addresses the software-related defects reported by the client. • Upgrades – enhancements on software to incorporate additional functionality.
Key Points • Metrics facilitate project planning, scheduling, and improving the SDLC process and product quality. • The four main types of metrics used widely during the SDLC of a project are design, project, product, and maintenance. • Design metrics help measure the design and architecture of a software project.
Key Points • Project metrics comprise effort, productivity, cost, defects, and size. • Project metrics measure the effectiveness of the important factors for a project. • Maintenance metrics are used to measure the cost, effort, productivity, and defects associated with a maintenance project.
Literatures • en.wikipedia.org • Basics of Software Project Management – 2004. • Ian Sommerville“Software Engineering 6th Edition” – 2000. • Roger S. Pressman “Software Engineering: a practitioner’s approach 5th Edition” – 2001.