Software Engineering - PowerPoint PPT Presentation

1 / 15
About This Presentation
Title:

Software Engineering

Description:

As part of knowing about the quality of the project (and its status) ... Important to clearly define metrics. Often need to tailor metrics to specific products ... – PowerPoint PPT presentation

Number of Views:40
Avg rating:3.0/5.0
Slides: 16
Provided by: SteveC1
Category:

less

Transcript and Presenter's Notes

Title: Software Engineering


1
Software Engineering
  • Metrics - I
  • Lecture 15

2
Metrics -- Overview
  • As part of knowing about the quality of the
    project (and its status), we would like
    quantitative measurements
  • We typically measure
  • Evaluation of analysis and design
  • Code complexity
  • Testability

3
Metrics Overview 2
  • Important to set the objectives of measurement
    before collecting the data
  • Important to clearly define metrics
  • Often need to tailor metrics to specific products
  • Hard to find data to try-out various metrics

4
Why we dont measure
  • Unclear as to the benefits
  • Software processes are often poorly organized/not
    sufficiently mature to take advantage of
    measurement
  • No standards for measurement limited support
    for data collection/analysis
  • Often hard/impossible to measure maintainability,
    complexity, and understandability
  • Hard to analyze data

5
Metric classification
  • Objective vs. subjective
  • Absolute vs. relative
  • Explicit vs. derived
  • Dynamic vs. static
  • Predictive vs. explanatory

6
Problems of measurement
  • Effect on people
  • Peoples effect on measurements
  • Difficulty of data comparisons

7
Analysis metrics
  • Predicting size
  • Function point metrics
  • Bang metrics

8
Design metrics
  • Design is often not measured!
  • Architecture estimating coding/testing effort
  • Card and Glass
  • System complexity Structural complexity data
    complexity
  • s(i) fout2(i) v(i)/(fout(i) 1)
  • Henry and Kafura
  • Complexity length(i) (fin(i) fout(i))2

9
Design metrics
  • Architecture (continued) estimating
    coding/testing efforts
  • Fenton (USAFC) Structure quality index
  • Factors include modules in architecture, other
    control modules, db items, modules with single
    entry/exit, program structure, module
    independence, modules not dependent on prior
    processing, db size and compartmentalization,
    module entry/exit characteristics

10
Design metrics
  • Component level design
  • Cohesion
  • Bierman and Ott
  • Coupling
  • Dhama
  • Complexity
  • McCabe

11
Design metrics
  • Interface design

12
Code metrics
  • Code complexity and thus required testing
    effort
  • Halstead complexity metrics
  • Live variable metrics
  • Understandability (affecting the ease of the
    tester to understand the code) style metrics

13
Test metrics
  • Generally focus on process of testing rather than
    the technical characteristics of testing itself
  • Function/bang metrics
  • High level design/Architecture
  • Cyclomatic complexity
  • Halstead complexity/ KLOC count
  • Understandability

14
Quality metrics
  • Analysis of data as part of
  • Post mortems
  • Defect prevention
  • Looking for
  • Symptoms, severity, where found, when found, how
    found, where caused, when caused, how caused,
    where fixed, when fixed, how fixed

15
Maintenance metrics
  • Aim is to determine when the product becomes
    stable
  • Stability metrics
  • Reliability metrics
  • Defects per KLOC
  • Jelinski and Moranda
  • Okomuto
  • Musa
  • Littelwood and Verall
Write a Comment
User Comments (0)
About PowerShow.com