Project Metrics - PowerPoint PPT Presentation

Loading...

PPT – Project Metrics PowerPoint presentation | free to download - id: 3e6494-NTg3N



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Project Metrics

Description:

Project Metrics Infsy 570 Dr. R. Ocker goal of metrics to improve product quality and development-team productivity concerned with productivity and quality measures ... – PowerPoint PPT presentation

Number of Views:99
Avg rating:3.0/5.0
Slides: 52
Provided by: Rosali75
Learn more at: http://www.psu.edu
Category:
Tags: metrics | project

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Project Metrics


1
Project Metrics
  • Infsy 570
  • Dr. R. Ocker

2
goal of metrics
  • to improve product quality and development-team
    productivity
  • concerned with productivity and quality measures
  • measures of SW development output as function of
    effort and time
  • measures of usability

3
terms
  • measure
  • quantitative expression of an attribute of a
    product or process
  • measurement
  • the act of determining a measure
  • metric
  • quantitative measure of the degree to which a
    system, component or process possesses an
    attribute

4
terms
  • indicator
  • a metric that provides insight into the SW
    process or project
  • enables manager to adjust (improve) the process
    or project
  • process indicators
  • allow assessment of process in terms of what
    works and what doesnt

5
Terms
  • project indicators
  • allow manager to
  • (1) assess status of ongoing project
  • (2) track project risks
  • (3) uncover problem areas
  • (4) adjust tasks or workflow
  • (5) evaluate teams ability to control quality

6
metrics apply to
  • process - used to develop the SW
  • project - specific SW development project
  • product - SW produced
  • many of the same metrics apply to both the
    process and project domains

7
1. Process metrics and SW process improvement
  • How to improve SW quality and organizational
    performance?
  • fig 4.1 text, fig.2 Paulish Carleton
  • Factors that influence quality
  • people - skills and experience of SW people
  • technology - used in development (e.g. CASE)
  • product complexity
  • process - glue that ties it all together

8
motivation to improve process
  • results from business need, e.g. strong
    competition, need increased profitability
  • The only rational way to improve any process is
    to measure specific attributes of the process,
    develop a set of meaningful metrics based on
    these attributes, and then use the metrics to
    provide indicators that will lead to a strategy
    for improvement.
  • ... process metrics are strategic

9
Process improvement approach (fig. 3, Paulish et
al.)
  • business need
  • motivation to improve
  • assessment (of current practices and process
    maturity level)
  • improvement methods selected
  • metrics measure impact

10
Process improvement approach (fig. 3, Paulish et
al.)
  • business establishes goals to improve process
    over period of time
  • defines measures to gauge progress
  • when data indicate process problems - take
    corrective action

11
Software process improvement method
  • integrated collection of procedures, tools, and
    training for increasing product quality,
    improving development-team productivity, or
    reducing development time

12
Some outcomes of an improved SW process might
include
  • fewer defects
  • earlier identification and correction of defects
  • faster time to market
  • better predictability of project schedules and
    resources

13
Types of process metrics
  • private vs. public metrics
  • SW process improvement should begin at the
    individual level

14
some private metrics
  • defect rates by individual
  • defect rates by module
  • errors found during development

15
public metrics
  • use information from individual and team metrics
  • some public metrics
  • project-level defect rates
  • effort
  • calendar times

16
2. Project Metrics
  • project metrics are tactical
  • used by project manager to adapt project work
    flow and technical activities
  • i.e. guide adjustments to work schedule to avoid
    delays assess product quality on an ongoing
    basis

17
attention to metrics should lead to reduction in
project costs
  • as quality improves
  • errors are minimized
  • rework reduced

18
estimation
  • first application of project metrics on SW
    project
  • metrics collected from past projects used as
    basis for time and effort estimates
  • as project advances, collect production rates and
    error metrics

19
3. Software Measurement
  • direct measures vs. indirect measures

20
direct measures
  • direct measure of process
  • cost and effort
  • direct measure of product
  • lines of code (LOC)
  • execution speed
  • defects per time period

21
Indirect measures
  • indirect measures of product
  • functionality
  • quality
  • complexity
  • reliability
  • maintainability

22
Consolidation of metrics
  • individual metrics combined to develop project
    metrics
  • project metrics consolidated to create process
    metrics
  • how to combine metrics from different projects?
  • normalization - enables comparison

23
3.1 Size-oriented metrics
  • derived by normalizing quality and/or
    productivity measures
  • use size of the SW to normalize
  • size-oriented measures include
  • LOC
  • effort
  • errors
  • defects
  • people

24
normalizing
  • suppose choose LOC as normalization value
  • then can compare across projects
  • errors per KLOC
  • defects per KLOC
  • per LOC

25
estimates
  • very important to estimate the associated cost of
    development early in the development project
  • to have accurate cost predictions, need accurate
    estimates of project size

26
Software size
  • primary factor affecting SW cost is the SIZE of
    the project
  • estimating SW size is DIFFICULT
  • most frequently used metrics for measuring size
  • lines of code (LOC)
  • function points
  • some controversy regarding using LOC as key
    normalization measure

27
LOC pros
  • easily counted (after the fact, once you choose a
    counting method)
  • used a lot

28
LOC cons
  • lack of universally accepted definition for what
    a line of code really is (there are at least 11
    different variations for counting LOC)
  • programming language dependent
  • difficult to use to estimate project size and
    effort - dont have enough information at
    beginning of project to accurately estimate LOC

29
3.2 Function-oriented Metrics
  • use a measure of functionality as the
    normalization value
  • formula estimate
  • functionality cannot be measured directly, but
    must be derived using other (direct) measures
  • method of quantifying size and complexity of
    system in terms of functions that system delivers
    to user

30
fig. 4.5 computing function points
  • measurement parameter count simple average
    complex
  • 1. number of user inputs ??? 3 4 6 X
  • 2. number of user outputs ??? 4 5 7 X
  • 3. number of inquiries ??? 3 4 6 X
  • 4. number of files ??? 7 10 15 X
  • 5. number of external interfaces
  • ??? 5 7 10 X
  • counttotal XX

31
You must perform the count
32
1. number of user inputs
  • each unique user input that provides
    application-oriented data to the SW
  • includes input that enter directly as
    transactions from the user, and those that enter
    as transactions from other applications (e.g.
    input file of transactions)

33
2. number of user outputs
  • each user output that provides application-oriente
    d information to user (reports, screens, error
    messages, etc.)
  • include reports and messages to the user and
    reports and messages to other applications (e.g.
    files of reports and messages)

34
3. number of inquiries
  • inquiry is an on-line input that results in
    generation of an immediate SW response in form of
    an on-line output
  • each distinct inquiry is counted

35
4. number of internal files
  • include each logical file or if using a DB,
    logical grouping of data, that is generated, used
    and maintained by the application

36
5. number of external interfaces
  • files passed or shared between applications
    should be counted
  • i.e., machine-readable interfaces (e.g., data
    files on tape or disk) that are used to transmit
    information to another system are counted

37
to compute
  • 1. classify and count the five user function
    types
  • 2. adjust for processing complexity
  • determine complexity value associated with each
    count
  • can develop criteria for determining whether
    simple, average or complex
  • 3. make the function points calculation
  • FP count-total X .65.01X ? Fi
  • Fi (i1 to 14) are complexity adjustment values
  • see table 4.1

38
answer questions such as
  • answer questions such as
  • Is performance critical?
  • Are the master files updated on-line?
  • Is the code designed to be reusable?
  • Use function points to normalize measures of SW
    productivity and quality.

39
FP Pros
  • programming language independent
  • based on data more likely to be known early in
    the project (still need requirements specs. or
    design specs. see Matson et al.)

40
FP Cons
  • computation based on subjective data
  • designed to measure business-type applications
    (not good for technical or scientific
    applications)

41
4. Metrics for SW Quality
  • focus on the process, the project and the product
    (as do productivity metrics)

42
Factors that affect quality
  • product operation - using it
  • product revision - changing it
  • product transition - portability

43
Measuring quality
  • correctness
  • degree to which SW performs its required function
  • defects per KLOC - most common measure for
    correctness
  • maintainability
  • ease with which a program can be corrected,
    adapted, or enhanced

44
Measuring quality
  • MTTC - mean time to change -
  • simple metric - time it takes to analyze,
    implement change, test it, and distribute it to
    users
  • integrity
  • measures systems ability to withstand attacks on
    its security

45
Measuring quality
  • usability
  • quantify user friendliness
  • measured using 4 characteristics
  • 1. physical/intellectual skill required to learn
    the system
  • 2. time required to become moderately efficient
  • 3. net increase in productivity when system used
  • 4. users attitudes toward the system

46
5. Integrating metrics within the SW process
  • majority of SW developers do not measure
  • problem is cultural
  • measurement results in cultural change
  • resistance, often due to fear

47
barriers to implementing process improvement
methods (Paulish et al.)
  • 1. getting started
  • orgs. need to conduct an assessment (e.g.
    Capability Maturity Model)
  • 2. staff turnover
  • downsizing is difficult environment for process
    improvement
  • need champions to stick around
  • 3. dedicated resources
  • need full-time dedicated resource(s) to implement
    process improvement methods

48
barriers to implementing process improvement
methods (Paulish et al.)
  • 4. management support
  • its necessary
  • 5. time restrictions
  • youve got to make the time to institute it

49
Some preliminary recommendations (Paulish et al.)
  • 1. use capability maturity model as guide to
    improvement
  • it provides a framework showing which methods to
    use based on current maturity
  • 2. conduct an assessment at beginning
  • to identify priorities for improvement and build
    consensus within org.

50
Some preliminary recommendations (Paulish et al.)
  • 3. pick a few process improvement methods
  • implement these effectively
  • 4. pay attention to implementation of methods
  • includes good training and management
  • 5. some process improvement methods easier to
    implement than others

51
remember...cultural factors are substantial
  • have significant impact on success with adopting
    software process improvement methods
  • the collection of quality metrics enables an
    organization to tune its software engineering
    process to remove the vital few causes of
    defects that have the greatest impact on software
    development
About PowerShow.com