1 / 26

Metrics for Process and Projects

Metrics for Process and Projects. Course Instructor: Aisha Azeem. A Good Manager Measures. process. process metrics. project metrics. measurement. product metrics. product. What do we. use as a. basis?. • size?. • function?. Why Do We Measure?.

Download Presentation

Metrics for Process and Projects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Metrics for Process and Projects Course Instructor: Aisha Azeem

  2. A Good Manager Measures process process metrics project metrics measurement product metrics product What do we use as a basis? • size? • function?

  3. Why Do We Measure? • 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 of software work products.

  4. Process Measurement • We measure the efficacy of a software process indirectly. • That is, we derive a set of metrics based on the outcomes that can be derived from the process. • Outcomes include • measures of errors uncovered before release of the software • defects delivered to and reported by end-users • work products delivered (productivity) • human effort expended • calendar time expended • schedule conformance • We also derive process metrics by measuring the characteristics of specific software engineering tasks.

  5. Cont . . . • Provides a mechanism for objective evaluation • Assists in • Estimation • Quality control • Productivity assessment • Project Control • Tactical decision-making • Acts as management tool

  6. Process Metrics • Quality-related • focus on quality of work products and deliverables • Productivity-related • Production of work-products related to effort expended • Statistical SQA data • error categorization & analysis • Defect removal efficiency • propagation of errors from process activity to activity • Reuse data • The number of components produced and their degree of reusability

  7. Project Metrics • used to minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks • used to assess product quality on an ongoing basis and, when necessary, modify the technical approach to improve quality. • every project should measure: • inputs—measures of the resources (e.g., people, tools) 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.

  8. Typical Project Metrics • Effort/time per software engineering task • Errors uncovered per review hour • Scheduled vs. actual milestone dates • Changes (number) and their characteristics • Distribution of effort on software engineering tasks

  9. Metrics in the Process and Project Domains • Process metrics are collected across all projects and over long periods of time • Project metrics enable 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 of software work products

  10. Process Metrics and Software Process Improvement Product Businessconditions Customercharacteristics Process People Technology Developmentenvironment Fig: Determinants for s/w quality and organizational effectiveness

  11. Process Metrics and Software Process Improvement • There are “private and public” uses for different types of process data • Software metrics etiquette • Use common sense and organizational sensitivity when interpreting metrics data • Provide regular feedback to the individuals and teams who collect measures and metrics • Don’t use metrics to appraise individuals

  12. Cont. . . • Software metrics etiquette (contd.) • Work with practitioners and teams to set clear goals and metrics that will be used to achieve them • Never use metrics to threaten individuals or teams • Metrics data that indicate a problem area should not be considered “negative”. These data are merely an indicator for process improvement • Don’t obsess on a single metric to the exclusion of other important metrics

  13. Cont . . . • Statistical Software Process Improvement (SSPI) • Error • Some flaw in a s/w engineering work product that is uncovered before the s/w is delivered to the end-user • Defect • A flaw that is uncovered after delivery to the end-user

  14. Software 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

  15. Size-Oriented Metrics • Lines of Code (LOC) can be chosen as the normalization value • Example of simple size-oriented metrics • Errors per KLOC (thousand lines of code) • Defects per KLOC • $ per KLOC • Pages of documentation per KLOC

  16. Cont . . . • Controversy regarding use of LOC as a key measure • According to the proponents • LOC is an “artifact” of all s/w development projects • Many existing s/w estimation models use LOC or KLOC as a key input • According to the opponents • LOC measures are programming language dependent • They penalize well-designed but shorter programs • Cannot easily accommodate nonprocedural languages • Difficult to predict during estimation

  17. Function-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

  18. Cont. . . • Controversy regarding use of FP as a key measure • According to the proponents • It is programming language independent • Can be predicted before coding is started • According to the opponents • Based on subjective rather than objective data • Has no direct physical meaning – it’s just a number

  19. Object-Oriented Metrics • Number of Scenario scripts • Number of key classes • Number of support classes • Average number of support classes per key class • Number of subsystems

  20. Use-Case Oriented Metrics • The use-case is independent of programming language • The no. of use-cases is directly proportional to the size of the application in LOC and to the no. of test cases • There is no standard size for a use-case • Its application as a normalizing measure is suspect

  21. Web Engineering Project Metrics • Number of static Web pages • Number of dynamic Web pages • Number of internal page links • Number of persistent data objects • Number of external systems interfaced • Number of static content objects • Number of dynamic content objects • Number of executable functions

  22. Web Engineering Project Metrics (2) • Let, • Nsp = number of static Web pages • Ndp = number of dynamic Web pages • Then, • Customization index, C = Ndp/(Ndp+ Nsp) • The value of C ranges from 0 to 1

  23. Metrics for Software Quality • Goals of s/w engineering • Produce high-quality systems • Meet deadlines • Satisfy market need • The primary thrust at the project level is to measure errors and defects

  24. Measuring Quality • Correctness • Defects per KLOC • Maintainability • Mean-time-to-change (MTTC) • Integrity • Threat and security • integrity =  [1 – (threat  (1 - security))] • Usability

  25. Defect Removal Efficiency (DRE) • Can be used at both the project and process level • DRE = E / (E + D), [E = Error, D = Defect] • Or, DREi = Ei / (Ei + Ei+1), [for ith activity] • Try to achieve DREi that approaches 1

  26. Integrating Metrics within the Software Process Softwareengineeringprocess Softwareproject Measures e.g. LOC, FP, Defects, Errors Datacollection Metrics e.g. No. of FP, Size, Error/KLOC, DRE Softwareproduct Metricscomputation Metricsevaluation Indicators e.g. Process efficiency, Product complexity, relative overhead Fig: - Software metrics collection process

More Related