KEMBAR78
Process and Project Metrics-1 | PPTX
Process and Project
Metrics
Final 5-1
Syed Saqib Raza Rizvi
Reconciling LOC and FP Metrics
• The relationship between lines of code and function points depends
upon the programming language that is used to implement the
software and the quality of the design.
• Function points and LOC-based metrics have been found to be
relatively accurate predictors of software development effort and
cost
• Using LOC and FP for estimation a historical baseline of information
must be established
Object-Oriented Metrics
• Number of scenario scripts (NSS)
• Number of key classes (NKC)
• Number of support classes (e.g. UI classes, database access classes,
computations classes, etc.)
• Average number of support classes per key class
• Number of subsystems (NSUB)
Use Case-Oriented Metrics
• Describe (indirectly) user-visible functions and features in language
independent manner
• Number of use case is directly proportional to LOC size of application
and number of test cases needed
• However use cases do not come in standard sizes and use as a
normalization measure is suspect
• Use case points have been suggested as a mechanism for estimating
effort
Web App Project Metrics
• Number of static Web pages (Nsp)
• Number of dynamic Web pages (Ndp)
• Customization index: C = Nsp / (Ndp + Nsp)
• Number of internal page links
• Number of external systems interfaced
• Number of static content objects
• Number of dynamic content objects
• Number of executable functions
Software Quality Metrics
• Factors assessing software quality come from three distinct points of view
(product operation, product revision, product modification).
• Software quality factors requiring measures include
correctness (defects per KLOC)
maintainability (mean time to change)
integrity (threat and security)
usability (easy to learn, easy to use, productivity increase, user attitude)
• Defect removal efficiency (DRE) is a measure of the filtering ability of the quality
assurance and control activities as they are applied through out the process
framework
DRE = E / (E + D)
E = number of errors found before delivery of work product
D = number of defects found after work product delivery
Integrating Metrics with Software
Process
• Many software developers do not collect measures.
• Without measurement it is impossible to determine whether a
process is improving or not.
• Baseline metrics data should be collected from a large,
representative sampling of past software projects.
• Getting this historic project data is very difficult, if the previous
developers did not collect data in an on-going manner
Arguments for Software Metrics
• If you don’t measure you have no way of determining any
improvement
• By requesting and evaluating productivity and quality measures
software teams can establish meaningful goals for process
improvement
• Software project managers are concerned with developing project
estimates, producing high quality systems, and delivering product on
time
• Using measurement to establish a project baseline helps to make
project’s tasks possible
Baselines
• Establishing a metrics baseline can benefit portions of the process,
project, and product levels
• Baseline data must often be collected by historical investigation of
past project (better to collect while projects are on-going)
• To be effective the baseline data needs to have the following
attributes:
data must be reasonably accurate, not guesstimates
data should be collected for as many projects as possible
measures must be consistent
applications should be similar to work that is to be estimated
Metrics for Small Organizations
• Most software organizations have fewer than 20 software engineers.
• Best advice is to choose simple metrics that provide value to the
organization and don’t require a lot of effort to collect.
• Even small groups can expect a significant return on the investment
required to collect metrics, if this activity leads to process
improvement.
Establishing a Software Metrics
1. Identify business goal
2. Identify what you want to know
3. Identify sub goals
4. Identify sub goal entities and attributes
5. Formalize measurement goals
6. Identify quantifiable questions and indicators related to goals
7. Define measures to be used and create operational definitions for
them
8. Identify actions needed to implement the measures
9. Prepare a plan to implement the measures
•Thank You

Process and Project Metrics-1

  • 1.
    Process and Project Metrics Final5-1 Syed Saqib Raza Rizvi
  • 2.
    Reconciling LOC andFP Metrics • The relationship between lines of code and function points depends upon the programming language that is used to implement the software and the quality of the design. • Function points and LOC-based metrics have been found to be relatively accurate predictors of software development effort and cost • Using LOC and FP for estimation a historical baseline of information must be established
  • 3.
    Object-Oriented Metrics • Numberof scenario scripts (NSS) • Number of key classes (NKC) • Number of support classes (e.g. UI classes, database access classes, computations classes, etc.) • Average number of support classes per key class • Number of subsystems (NSUB)
  • 4.
    Use Case-Oriented Metrics •Describe (indirectly) user-visible functions and features in language independent manner • Number of use case is directly proportional to LOC size of application and number of test cases needed • However use cases do not come in standard sizes and use as a normalization measure is suspect • Use case points have been suggested as a mechanism for estimating effort
  • 5.
    Web App ProjectMetrics • Number of static Web pages (Nsp) • Number of dynamic Web pages (Ndp) • Customization index: C = Nsp / (Ndp + Nsp) • Number of internal page links • Number of external systems interfaced • Number of static content objects • Number of dynamic content objects • Number of executable functions
  • 6.
    Software Quality Metrics •Factors assessing software quality come from three distinct points of view (product operation, product revision, product modification). • Software quality factors requiring measures include correctness (defects per KLOC) maintainability (mean time to change) integrity (threat and security) usability (easy to learn, easy to use, productivity increase, user attitude) • Defect removal efficiency (DRE) is a measure of the filtering ability of the quality assurance and control activities as they are applied through out the process framework DRE = E / (E + D) E = number of errors found before delivery of work product D = number of defects found after work product delivery
  • 7.
    Integrating Metrics withSoftware Process • Many software developers do not collect measures. • Without measurement it is impossible to determine whether a process is improving or not. • Baseline metrics data should be collected from a large, representative sampling of past software projects. • Getting this historic project data is very difficult, if the previous developers did not collect data in an on-going manner
  • 8.
    Arguments for SoftwareMetrics • If you don’t measure you have no way of determining any improvement • By requesting and evaluating productivity and quality measures software teams can establish meaningful goals for process improvement • Software project managers are concerned with developing project estimates, producing high quality systems, and delivering product on time • Using measurement to establish a project baseline helps to make project’s tasks possible
  • 9.
    Baselines • Establishing ametrics baseline can benefit portions of the process, project, and product levels • Baseline data must often be collected by historical investigation of past project (better to collect while projects are on-going) • To be effective the baseline data needs to have the following attributes: data must be reasonably accurate, not guesstimates data should be collected for as many projects as possible measures must be consistent applications should be similar to work that is to be estimated
  • 10.
    Metrics for SmallOrganizations • Most software organizations have fewer than 20 software engineers. • Best advice is to choose simple metrics that provide value to the organization and don’t require a lot of effort to collect. • Even small groups can expect a significant return on the investment required to collect metrics, if this activity leads to process improvement.
  • 11.
    Establishing a SoftwareMetrics 1. Identify business goal 2. Identify what you want to know 3. Identify sub goals 4. Identify sub goal entities and attributes 5. Formalize measurement goals 6. Identify quantifiable questions and indicators related to goals 7. Define measures to be used and create operational definitions for them 8. Identify actions needed to implement the measures 9. Prepare a plan to implement the measures
  • 12.