Successfully reported this slideshow.
Upcoming SlideShare
×

of

5

Share

# Software metrics

Software metricsIntroduction
Attributes of Software Metrics
Activities of a Measurement Process
Types
Normalization of Metrics
Help software engineers to gain insight into the design and construction of the software
Activities of a Measurement Process

To answer this we need to know the size & complexity of the projects.
But if we normalize the measures, it is possible to compare the two
For normalization we have 2 ways-
Size-Oriented Metrics
Function Oriented Metrics

See all

See all

### Software metrics

1. 1. -By: Aadarsh Sharma -152409 -ME CSE (Regular)
2. 2.  Introduction  Attributes of Software Metrics  Activities of a Measurement Process  Types  Normalization of Metrics  References 2
3. 3.  Help software engineers to better understand the attributes of models and assess the quality of the software  Help software engineers to gain insight into the design and construction of the software  Focus on specific attributes of software engineering work products resulting from analysis, design, coding, and testing  Provide a systematic way to assess quality based on a set of clearly defined rules  Provide an “on-the-spot” rather than “after-the-fact” insight into the software development 3
4. 4.  Measure  Provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or process  Metric  (IEEE) A quantitative measure of the degree to which a system, component, or process possesses a given attribute  Indicator  A metric or combination of metrics that provides insight into the software process, a software project, or the product itself 4
5. 5.  To indicate the quality of the product.  To assess the productivity of the people who produce the product  To assess the benefits derived from new software engineering methods and tools  To form a baseline for estimation  To help justify requests for new tools or additional training
6. 6.  Formulation  The derivation (i.e., identification) of software measures and metrics appropriate for the representation of the software that is being considered  Collection  The mechanism used to accumulate data required to derive the formulated metrics  Analysis  The computation of metrics and the application of mathematical tools  Interpretation  The evaluation of metrics in an effort to gain insight into the quality of the representation  Feedback  Recommendations derived from the interpretation of product metrics and passed on to the software development team 6
7. 7.  Simple and computable  It should be relatively easy to learn how to derive the metric, and its computation should not demand inordinate effort or time  Empirically and intuitively persuasive  The metric should satisfy the engineer’s intuitive notions about the product attribute under consideration  Consistent and objective  The metric should always yield results that are unambiguous 7 (More on next slide)
8. 8.  Consistent in the use of units and dimensions  The mathematical computation of the metric should use measures that do not lead to bizarre combinations of units  Programming language independent  Metrics should be based on the analysis model, the design model, or the structure of the program itself  An effective mechanism for high-quality feedback  The metric should lead to a higher-quality end product 8
9. 9. 1. Process Metrics 2. Product Metrics 3. Project Metrics
10. 10.  Process metrics are measures of the software development process, such as  Overall development time  Type of methodology used  Process metrics are collected across all projects and over long periods of time.  Their intent is to provide indicators that lead to long-term software process improvement.
11. 11.  Project Metrics are the measures of Software Project and are used to monitor and control the project. They enable a software project manager to:  Minimize the development time by making the adjustments necessary to avoid delays and potential problems and risks.  Assess product quality on an ongoing basis & modify the technical approach to improve quality.
12. 12.  Product metrics are measures of the software product at any stage of its development, from requirements to installed system. Product metrics may measure:  the complexity of the software design  the size of the final program  the number of pages of documentation produced
13. 13.  Direct measures  Easy to collect  E.g. Cost, Effort, Lines of codes (LOC), Execution Speed, Memory size, Defects etc.  Indirect measures  More difficult to assess & can be measured indirectly only.  Quality, Functionality, Complexity, Reliability, Efficiency, Maintainability etc.
14. 14.  2 different project teams are working to record errors in a software process  Team A – Finds 342 errors during software process before release  Team B- Finds 184 errors Which team is more effective in finding errors?
15. 15.  To answer this we need to know the size & complexity of the projects.  But if we normalize the measures, it is possible to compare the two  For normalization we have 2 ways-  Size-Oriented Metrics  Function Oriented Metrics
16. 16. • Based on the “size” of the software produced Project Effort (person- month) Cost (\$) LOC kLOC Doc. (pgs) Error s People A 24 168,000 12100 12.1 365 29 3 B 62 440,000 27200 27.2 1224 86 5
17. 17.  Errors per KLOC  \$ per KLOC  Pages of documentation per KLOC  Errors per person-month  LOC per person-month  Advantages of Size Oriented Metrics  LOC can be easily counted  Many software estimation models use LOC or KLOC as input.  Disadvantages of Size Oriented Metrics  LOC measures are language dependent, programmer dependent  Their use in estimation requires a lot of detail which can be difficult to achieve.
18. 18.  The function point metric (FP), first proposed by Albrecht, can be used effectively as a means for measuring the functionality delivered by a system.  Functionality is measured indirectly using a measure called function point.  Function points (FP) - derived using an empirical relationship based on countable measures of software & assessments of software complexity
19. 19. 19 Information Domain Value Count simple average complex Weighting factor External Inputs ( EIs) External Outputs ( EOs) External Inquiries ( EQs) Internal Logical Files ( ILFs) External Interface Files ( EIFs) 3 4 6 4 5 7 3 4 6 7 10 15 5 7 10 = = = = = Count total 3 3 3 3 3 • Errorsper FP • Defectsper FP • \$ per FP • Pagesof documentation per FP
20. 20. 1. Count the measurement parameters. 2. Assess the complexity of the values. 3. Calculate the raw FP (see next table). 4. Rate the complexity factors to produce the complexity adjustment value (CAV) 5. Calculate the adjusted FP as follows: FP = raw FP x [0.65 + 0.01 x CAV]
21. 21. • Advantages: language independent, based on data known early in project, good for estimation • Disadvantages: calculation complexity, subjective assessments, FP has no physical meaning (just a number)
22. 22.  http://www.slideshare.net/13-software- metrics  Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman  https://en.wikipedia.org/wiki/Software_metri c  http://www.cs.kent.edu/~jmaletic/cs63901/le ctures/SoftwareMetrics.pdf 22
23. 23. Any Queries ? 23
• #### NallaVedavathi

Nov. 21, 2020
• #### neenasusan04

Feb. 28, 2017
• #### Jtoulier

Jun. 19, 2016

May. 5, 2016
• #### sharmanitesh440

May. 4, 2016

Software metricsIntroduction Attributes of Software Metrics Activities of a Measurement Process Types Normalization of Metrics Help software engineers to gain insight into the design and construction of the software Activities of a Measurement Process To answer this we need to know the size & complexity of the projects. But if we normalize the measures, it is possible to compare the two For normalization we have 2 ways- Size-Oriented Metrics Function Oriented Metrics

Total views

2,729

On Slideshare

0

From embeds

0

Number of embeds

3

136

Shares

0