Presentation on theme: "Metrics for Process and Projects"— Presentation transcript:
1Metrics for Process and Projects Chapter 15 & 22Metrics for Process and ProjectsSoftware Engineering: A Practitioner’s Approach6th EditionRoger S. Pressman
2Measurement Provides a mechanism for objective evaluation Assists in EstimationQuality controlProductivity assessmentProject ControlTactical decision-makingActs as management tool
3Measures, Metrics and Indicators A measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or process.E.g., Number of errorsThe IEEE glossary defines a metric as “a quantitative measure of the degree to which a system, component, or process possesses a given attribute.”E.g., Number of errors found per person hours expendedAn indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself.
4Motivation for Metrics Estimate the cost & schedule of future projectsEvaluate the productivity impacts of new tools and techniquesEstablish productivity trends over timeImprove software qualityForecast future staffing needsAnticipate and reduce future maintenance needs
5A Good Manager Measures processprocess metricsproject metricsmeasurementproduct metricsproductWhat do weuse as abasis?• size?• function?
6Metrics in the Process and Project Domains Process metrics are collected across all projects and over long periods of timeProject metrics enable a software project manager toAssess the status of an ongoing projectTrack potential risksUncover problem areas before they go “critical”Adjust work flow or tasksEvaluate the project team’s ability to control quality of software work products
7Process Metrics and Software Process Improvement (1) ProductCustomer characteristicsBusiness conditionsProcessPeopleTechnologyDevelopment environmentFig.-22.1: Determinants for s/w quality and organizational effectiveness
8Process Metrics and Software Process Improvement (2) We measure the efficacy of a s/w process indirectly, based on outcomesProbable outcomes areMeasures of errors uncovered before release of the s/wDefects delivered to and reported by end-usersWork products delivered (productivity)Human effort expendedCalendar time expendedSchedule conformance, etc.
9Process Metrics and Software Process Improvement (3) Software metrics etiquette [GRA92]Use common sense and organizational sensitivity when interpreting metrics dataProvide regular feedback to the individuals and teams who collect measures and metricsDon’t use metrics to appraise individuals
10Process Metrics and Software Process Improvement (4) Software metrics etiquette [GRA92] (contd.)Work with practitioners and teams to set clear goals and metrics that will be used to achieve themNever use metrics to threaten individuals or teamsMetrics data that indicate a problem area should not be considered “negative”. These data are merely an indicator for process improvementDon’t obsess on a single metric to the exclusion of other important metrics
11Process Metrics and Software Process Improvement (5) ErrorSome flaw in a s/w engineering work product that is uncovered before the s/w is delivered to the end-userDefectA flaw that is uncovered after delivery to the end-user
12Project Metrics Used during estimation Used to monitor and control progressThe intent is twofoldMinimize the development scheduleAssess product quality on an ongoing basisLeads to a reduction in overall project cost
13Typical Project Metrics Effort/time per software engineering taskErrors uncovered per review hourScheduled vs. actual milestone datesChanges (number) and their characteristicsDistribution of effort on software engineering tasks
14Software Measurement S/W measurement can be categorized in two ways: Direct measures of the s/w process (e.g., cost and effort applied) and product (e.g., lines of code (LOC) produced, etc.)Indirect measures of the product (e.g., functionality, quality, complexity, etc.)Requires normalization of both size- and function-oriented metrics
15Size-Oriented Metrics (1) Lines of Code (LOC) can be chosen as the normalization valueExample of simple size-oriented metricsErrors per KLOC (thousand lines of code)Defects per KLOC$ per KLOCPages of documentation per KLOC
17Size-Oriented Metrics (3) Controversy regarding use of LOC as a key measureAccording to the proponentsLOC is an “artifact” of all s/w development projectsMany existing s/w estimation models use LOC or KLOC as a key inputAccording to the opponentsLOC measures are programming language dependentThey penalize well-designed but shorter programsCannot easily accommodate nonprocedural languagesDifficult to predict during estimation
18Function-Oriented Metrics The most widely used function-oriented metric is the function point (FP)Computation of the FP is based on characteristics of the software’s information domain and complexity
19Information DomainNumber of external inputs – from user or another applicationNumber of external outputsNumber of external inquiries – request from user that generates an on-line outputNumber of internal logical files (maintained by system)Number of external interface files (provides data but not maintained by system)19
21Analyzing the Information Domain 123525284401792[ × ∑(Fi)]count-total × [ ×∑(Fi)]
22Taking Complexity into Account Factors(Fi) are rated on a scale of 0 (not important)to 5 (essential)The following are some examples of these factors:Is high performance critical?Is the internal processing complex?Is the system to be used in multiple sites and/or by multiple organizations?Is the code designed to be reusable?Is the processing to be distributed?and so forth . . .
23Computing Function Points 123525284401792[ × ∑(Fi)]1.0798.44count-total × [ ×∑(Fi)]
24Uses of Function Points(FP) But how long will the project take and howmuch will it cost?If programmers in an organization produce average 16 function points per month. Thus . . .98.44 FP divided by 16 = 6 man-monthsIf the average programmer is paid $5,200 per month (including benefits), then the [labor] cost of the project will be . . .6 man-months X $5,200 = $31,200
25Pros & Cons of FP Controversy regarding use of FP as a key measure According to the proponentsIt is programming language independentCan be predicted before coding is startedAccording to the opponentsBased on subjective rather than objective dataHas no direct physical meaning – it’s just a number