A GOAL-BASED FRAMEWORK FOR SOFTWARE MEASUREMENT

Slides:



Advertisements
Similar presentations
Software Quality Assurance Plan
Advertisements

Lecture # 2 : Process Models
Metrics for Process and Projects
Metrics for Process and Projects
Low Defect Potentials (< 1 per function point)
SENG 530: Software Verification and Validation
Software Quality Metrics
Soft. Eng. II, Spr. 02Dr Driss Kettani, from I. Sommerville1 CSC-3325: Chapter 6 Title : The Software Quality Reading: I. Sommerville, Chap: 24.
Software Engineering II - Topic: Software Process Metrics and Project Metrics Instructor: Dr. Jerry Gao San Jose State University
Software Metrics II Speaker: Jerry Gao Ph.D. San Jose State University URL: Sept., 2001.
1 Software metrics in general Seminar on Software Engineering Sanna Martikainen,
1 Software Engineering II Presentation Software Maintenance.
CS 325: Software Engineering March 26, 2015 Software Quality Assurance Software Metrics Defect Injection Software Quality Lifecycle Measuring Progress.
Software Process and Product Metrics
Capability Maturity Model
Quality of Information systems. Quality Quality is the degree on which a product satifies the requirements Quality management requires that : that requirements.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 27 Slide 1 Quality Management 1.
N By: Md Rezaul Huda Reza n
1 Chapter 2 The Process. 2 Process  What is it?  Who does it?  Why is it important?  What are the steps?  What is the work product?  How to ensure.
College of Engineering and Computer Science Computer Science Department CSC 131 Computer Software Engineering Fall 2006 Lecture # 1 (Ch. 1, 2, & 3)
1 Software Quality CIS 375 Bruce R. Maxim UM-Dearborn.
Software Engineering Software Process and Project Metrics.
Chapter 6 : Software Metrics
Software Quality Engineering Chapters 1-3 Overview, Software Quality and Quality Assurance.
Topic (1)Software Engineering (601321)1 Introduction Complex and large SW. SW crises Expensive HW. Custom SW. Batch execution.
Software Quality Assurance SE Software Quality Assurance What is “quality”?
Software Measurement & Metrics
This chapter is extracted from Sommerville’s slides. Text book chapter
Software Engineering Quality What is Quality? Quality software is software that satisfies a user’s requirements, whether that is explicit or implicit.
Chapter 12 Evaluating Products, Processes, and Resources.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
Question To know that quality has improved, it would be helpful to be able to measure quality. How can we measure quality?
Software Project Management Lecture # 3. Outline Chapter 22- “Metrics for Process & Projects”  Measurement  Measures  Metrics  Software Metrics Process.
Software Metrics – part 2 Mehran Rezaei. Software Metrics Objectives – Provide State-of-art measurement of software products, processes and projects Why.
SWEN 5130 Requirements Engineering 1 Dr Jim Helm SWEN 5130 Requirements Engineering Requirements Management Under the CMM.
University of Sunderland COM369 Unit 6 COM369 Project Quality Unit 6.
Introduction to Software Engineering. Why SE? Software crisis manifested itself in several ways [1]: ◦ Project running over-time. ◦ Project running over-budget.
6/6/01 1 Copyright 2001 by Ralph R. Young Effective Requirements Practices Designed to improve individual, project, and organizational effectiveness. Based.
Computing and SE II Chapter 15: Software Process Management Er-Yu Ding Software Institute, NJU.
Chapter 3: Software Project Management Metrics
Click to add text SUITE SEM Implementation Process Training.
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
Introduction to Measurement. According to Lord Kelvin “When you can measure what you are speaking about and express it in numbers, you know something.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
A Metrics Program. Advantages of Collecting Software Quality Metrics Objective assessments as to whether quality requirements are being met can be made.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Conceptual design Tells the customer what the system will do Tells the customer what the system will do Answers: Answers: Where will the data come from?
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 15a: Product Metrics for Software Software Engineering: A Practitioner’s Approach, 6/e Chapter.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Software Measurement: A Necessary Scientific Basis By Norman Fenton Presented by Siv Hilde Houmb Friday 1 November.
Software Engineering (CSI 321) Software Process: A Generic View 1.
Your Interactive Guide to the Digital World Discovering Computers 2012 Chapter 12 Exploring Information System Development.
SE513 Software Quality Assurance Lecture12: Software Reliability and Quality Management Standards.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
1 Software Engineering Muhammad Fahad Khan Software Engineering Muhammad Fahad Khan University Of Engineering.
by: Er. Manu Bansal Deptt of IT Software Quality Assurance.
PROCESS ASSESSMENT AND IMPROVEMENT. Process Assessment  A formal assessment did not seem financially feasible at the onset of the company’s process improvement.
Emilia Mendes Professora Visitante CAPES/ Associate Professor Univ. Auckland, NZ. Introdução a Métricas, Qualidade e Medição de Software.
SQA project process standards IEEE software engineering standards
Software Quality Control and Quality Assurance: Introduction
SQA project process standards IEEE software engineering standards
CIF301 Project Quality Unit 6
McCall’s Quality Factors
Software Engineering (CSI 321)
Chapter 13 Quality Management
Software Engineering I
Capability Maturity Model
Software metrics.
Capability Maturity Model
Software Verification and Validation
Presentation transcript:

A GOAL-BASED FRAMEWORK FOR SOFTWARE MEASUREMENT Presented By Marlon Edmond B r o o k l y n    C o l l e g e Department of Computer and Information Science CIS 763X: Software Methodology

Software metrics is a term that embraces many activities , all of which involve some degree of software measurement: Cost and effort and estimation Productivity measures and models Data collection Quality models and measurement Reliability models Performance Evaluation and models Structural and complexity metrics Capability-maturity assessment Management by metrics Evaluation of methods and tools

Classifying Software Measures In software there are three such classes Processes: Collection of software-related activities. Products: Artifacts, deliverables or documents that result from a process activity. Resources: Entities required by a process activity.

Internal and External Attributes An internal attribute can be measured by examining the product, process, or resource on its own, separate from its behavior. (Program size, complexity, dependencies). External attributes are those that can be measured only with respect to how the product, process or resource relates to the environment. (Ease of Navigation, Number of failures)

Internal and External Attributes Size, Effort, Cost Code Complexity Functionality Modularity Redundancy Syntactic Correctness Reuse External Usability Integrity Efficiency Testability Reusability Portability Interoperability

Importance Of Internal Attributes Many software engineering methods proposed and developed in the last 25 years provide rules, tools, and any heuristics for providing software products. It is claimed that this structure makes them easier to understand, and tests. It is assumed that good internal structure leads to a good external quality. This connection has rarely been established.

Processes We often have questions about our software-development activities and processes that measurement can help us to answer. We want to know how long it takes for a process to complete, how much it will cost, whether it is effective or efficient, and how it compares with other processes that we could’ve chosen. Example: AT&T developers wanted to know the effectiveness of their software inspections. In particular, managers needed to evacuate the cost of inspections against benefits received. To do this, they measured the average amount of effort expended per thousand lines of code reviewed. This information combined with measures of the number of faults discovered during the inspections, allowed managers to perform a cost-benefit analysis.

Products Products are not restricted to the items that management is committed to deliver to the customer. Any artifact or document produced during the software life cycle can be measured and assessed. For example developers often build prototypes for examination only, so that they can understand requirements or evaluate possible designs; these prototypes may be measured in some way. External product attributes depend on both product behavior and environment, each attribute measure should take these characteristics into account. Internal product attributes are sometimes easy to measure. We can determine the size of a product by measuring the number of pages it fills or the number of words it contains. Other internal product attributes are more difficult to measure, because opinions differ as to what they mean and how to measured them. For example the complexity of codes.

Resources The resources that we are likely to measure include any input for software production. Resources include personnel, materials, tools and methods. Resources are measured to determine their magnitude, cost and quality. Cost is often measured across all types of resources, so that managers can see how the cost of inputs affects the cost of the outputs. Resource measure combines a process measure (input) with a product measure (output).

Determining What To Measure A particular measurement is useful only if it helps you to understand the underlying process or one of its resultant products. In turn, recognizing improvement of the process and product can occur only when the project has clearly defined goals for process and products.

Goal-Question-Metric The GQM approach to process and metrics has proven to be a particular effective approach to selecting and implementing the metrics. To use GQM, You express the overall goals of your organization Ask relevant questions Measure.

Examples Of AT&T goals, questions and metrics

Measurement and Process Improvement The Software Engineering Institute has suggested that there are five levels of process maturity. These levels of are: ad hoc, repeatable, defined, managed and optimized. The SEI distinguishes one level from another in terms of key process activity going on at each level.

Overview Of Process Maturity And Measurement Ad hoc: Initial, Baseline Repeatable: Process dependent on individual. Defined: Process defined and institutionalized. Managed: Measured process. Optimizing: Improvement fed back to the process.

Software Measurement Validation Even when you know which entity and attribute you want to assess, there are many measures from which to choose. Measures or measurement systems are used to assess an existing entity by numerically characterizing one of more of its attribute. Prediction systems are used to predict some attribute of a future entity, involving a mathematical model with associated prediction procedures.

Software Measurement Validation (con’t) The formal requirement for a validating measure involves demonstrating that it characterizes the stated attribute in the sense of measurement Theory. To validate the prediction system formally you must first decide how stochastic it is, and then compare performance of the prediction system with known data points.

Bibliography Fenton, N. Pfleeger, S.L. Software Metrics. International Thompson Computer Press. 1998.

END OF PRESENTATION