![26
Function Point Computation
1) Identify/collect the information domain values
2) Complete the table shown below to get the count total
• Associate a weighting factor (i.e., complexity value) with each count based on criteria established by the
software development organization
3) Evaluate and sum up the adjustment factors (see the next two slides)
• “Fi” refers to 14 value adjustment factors, with each ranging in value from 0 (not important) to 5 (absolutely
essential)
4) Compute the number of function points (FP)
FP = count total * [0.65 + 0.01 * sum(Fi)]
Information Weighting Factor
Domain Value Count Simple Average Complex
External Inputs _____ x 3 4 6 = _____
External Outputs _____ x 4 5 7 = _____
External Inquiries _____ x 3 4 6 = _____
Internal Logical Files _____ x 7 10 15 = _____
External Interface Files _____ x 5 7 10 = _____
Count total ________](https://image.slidesharecdn.com/unit8softwarequalityandmatrices-151107043311-lva1-app6892/85/Unit-8-software-quality-and-matrices-26-320.jpg)
![Function Point Example
• FP = count total * [0.65 + 0.01 * sum(Fi)]
• FP = 50 * [0.65 + (0.01 * 46)]
• FP = 55.5 (rounded up to 56)
Information Weighting Factor
Domain Value Count Simple Average Complex
External Inputs 3 x 3 4 6 = 9
External Outputs 2 x 4 5 7 = 8
External Inquiries 2 x 3 4 6 = 6
Internal Logical Files 1 x 7 10 15 = 7
External Interface Files 4 x 5 7 10 = 20
Count total 50](https://image.slidesharecdn.com/unit8softwarequalityandmatrices-151107043311-lva1-app6892/85/Unit-8-software-quality-and-matrices-27-320.jpg)
![Hierarchical Architecture Metrics
• Fan out: the number of modules immediately subordinate to the module i, that is, the number of modules directly
invoked by module i
• Structural complexity
– S(i) = f2
out(i), where fout(i) is the “fan out” of module i
• Data complexity
– D(i) = v(i)/[fout(i) + 1], where v(i) is the number of input and output variables that are passed to and from module i
• System complexity
– C(i) = S(i) + D(i)
• As each of these complexity values increases, the overall architectural complexity of the system also increases
• This leads to greater likelihood that the integration and testing effort will also increase
• Shape complexity
– size = n + a, where n is the number of nodes and a is the number of arcs
– Allows different program software architectures to be compared in a straightforward manner
• Connectivity density (i.e., the arc-to-node ratio)
– r = a/n
– May provide a simple indication of the coupling in the software architecture](https://image.slidesharecdn.com/unit8softwarequalityandmatrices-151107043311-lva1-app6892/85/Unit-8-software-quality-and-matrices-30-320.jpg)
Unit 8 software quality and matrices
- 1. Unit 8 Software Quality and Matrices Preeti Mishra Course Instructor
- 3. Software Quality Defined • Definition: Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software • Three important points in this definition – Explicit software requirements are the foundation from which quality is measured. Lack of conformance to requirements is lack of quality – Specific standards define a set of development criteria that guide the manner in which software is engineered. If the criteria are not followed, lack of quality will most surely result – There is a set of implicit requirements that often goes unmentioned (e.g., ease of use). If software conforms to its explicit requirements but fails to meet implicit requirements, software quality is suspect
- 4. ISO 9126 Software Quality Factors • Functionality – The degree to which the software satisfies stated needs • Reliability – The amount of time that the software is available for use • Usability – The degree to which the software is easy to use • Efficiency – The degree to which the software makes optimal use of system resources • Maintainability – The ease with which repair and enhancement may be made to the software • Portability – The ease with which the software can be transposed from one environment to another
- 5. 5 Five Views of Software Quality • Transcendental view • User view • Manufacturing view • Product view • Value-based view
- 6. 6 Five Views of Software Quality • Transcendental view – Quality is something that can be recognized through experience, but not defined in some tractable form. – A good quality object stands out, and it is easily recognized. • User view – Quality concerns the extent to which a product meets user needs and expectations. – Is a product fit for use? – This view is highly personalized. • A product is of good quality if it satisfies a large number of users. • It is useful to identify the product attributes which the users consider to be important. – This view may encompass many subject elements, such as usability, reliability, and efficiency.
- 7. 7 Five Views of Software Quality • Manufacturing view – This view has its genesis in the manufacturing industry – auto and electronics. – Key idea: Does a product satisfy the requirements? • Any deviation from the requirements is seen as reducing the quality of the product. • Product view – Hypothesis: If a product is manufactured with good internal properties, then it will have good external properties. – One can explore the causal relationship between internal properties and external qualities. – Example: Modularity enables testability. • Value-based view – This represents the merger of two concepts: excellence and worth. – Quality is a measure of excellence, and value is a measure of worth. – Central idea • How much a customer is willing to pay for a certain level of quality. • Quality is meaningless if a product does not make economic sense. • The value-based view makes a trade-off between cost and quality.
- 8. • Process Measure the efficacy of processes. What works, what doesn't. • Project Assess the status of projects. Track risk. Identify problem areas. Adjust work flow. • Product Measure predefined product attributes (generally related to ISO9126 Software Characteristics) What to measure
- 9. Three kinds of Software Quality Metrics ◦ Product Metrics - describe the characteristics of product size, complexity, design features, performance, and quality level ◦ Process Metrics - used for improving software development/maintenance process effectiveness of defect removal, pattern of testing defect arrival, and response time of fixes ◦ Project Metrics - describe the project characteristics and execution number of developers, cost, schedule, productivity, etc. fairly straight forward Software Quality Metrics
- 10. Desired attributes of Metrics (Ejiogu, 1991) – Simple and computable – Empirical and intuitively persuasive – Consistent and objective – Consistent in the use of units and dimensions – Independent of programming language, so directed at models (analysis, design, test, etc.) or structure of program – Effective mechanism for quality feedback Software Quality Metrics
- 11. Classification of software requirements into software quality factors • The classic model of software quality factors suggest by : – McCall (consist of 11 factors, 1977) – Deutsch and Willis (consist of 12 to 15, factors,1988) – Evans and Marciniak (1987)
- 12. McCall’s Factor Model • Classifies all software requirement into 11software quality factors, grouped into three categories : 1. Product operation factors : Correctness, Reliability, Efficiency, Integrity,usability. 2. Product revision factors : Maintainability, Flexibility, Testability. 3. Product transition factors : Portability, Reusability, Interoperability.
- 14. Why have Software Product Metrics? • 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
- 15. A Framework for Product Metrics
- 16. Measures, Metrics, and Indicators • These three terms are often used interchangeably, but they can have subtle differences • Measure – Provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or process • Measurement – The act of determining a measure • 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
- 17. Purpose of Product Metrics • Aid in the evaluation of analysis and design models • Provide an indication of the complexity of procedural designs and source code • Facilitate the design of more effective testing techniques • Assess the stability of a fielded software product
- 18. Activities of a Measurement Process • 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
- 19. Characterizing and Validating Metrics • A metric should have desirable mathematical properties – It should have a meaningful range (e.g., zero to ten) – It should not be set on a rational scale if it is composed of components measured on an ordinal scale • If a metric represents a software characteristic that increases when positive traits occur or decreases when undesirable traits are encountered, the value of the metric should increase or decrease in the same manner • Each metric should be validated empirically in a wide variety of contexts before being published or used to make decisions – It should measure the factor of interest independently of other factors – It should scale up to large systems – It should work in a variety of programming languages and system domains
- 20. Collection and Analysis Guidelines • Whenever possible, data collection and analysis should be automated • Valid statistical techniques should be applied to establish relationships between internal product attributes and external quality characteristics • Interpretative guidelines and recommendations should be established for each metric
- 21. A Product Metrics Taxonomy
- 22. Metrics for various software development activities Analysis Model • Design Model Source Code • Testing • Functionality delivered • Provides an indirect measure of the functionality that is packaged within the software • System size • Measures the overall size of the system defined in terms of information available as part of the analysis model • Specification quality • Provides an indication of the specificity and completeness of a requirements specification • Architectural metrics • Provide an indication of the quality of the architectural design • Component-level metrics • Measure the complexity of software components and other characteristics that have a bearing on quality • Interface design metrics • Focus primarily on usability • Specialized object-oriented design metrics • Measure characteristics of classes and their communication and collaboration characteristics • Complexity metrics • Measure the logical complexity of source code (can also be applied to component- level design) • Length metrics • Provide an indication of the size of the software • Statement and branch coverage metrics • Lead to the design of test cases that provide program coverage • Defect-related metrics • Focus on defects (i.e., bugs) found, rather than on the tests themselves • Testing effectiveness metrics • Provide a real-time indication of the effectiveness of tests that have been conducted • In-process metrics • Process related metrics that can be determined as testing is conducted
- 23. Function Based Matrices Function Points
- 24. Introduction to Function Points • First proposed by Albrecht in 1979; • Can be used effectively as a means for measuring the functionality delivered by a system • Using historical data, function points can be used to – Estimate the cost or effort required to design, code, and test the software – Predict the number of errors that will be encountered during testing – Forecast the number of components and/or the number of projected source code lines in the implemented system • Derived using an empirical relationship based on 1) Countable (direct) measures of the software’s information domain 2) Assessments of the software’s complexity
- 25. Information Domain Values • Number of external inputs – Each external input originates from a user or is transmitted from another application – They provide distinct application-oriented data or control information – They are often used to update internal logical files – They are not inquiries (those are counted under another category) • Number of external outputs – Each external output is derived within the application and provides information to the user – This refers to reports, screens, error messages, etc. – Individual data items within a report or screen are not counted separately • Number of external inquiries – An external inquiry is defined as an online input that results in the generation of some immediate software response – The response is in the form of an on-line output • Number of internal logical files – Each internal logical file is a logical grouping of data that resides within the application’s boundary and is maintained via external inputs • Number of external interface files – Each external interface file is a logical grouping of data that resides external to the application but provides data that may be of use to the application
- 26. 26 Function Point Computation 1) Identify/collect the information domain values 2) Complete the table shown below to get the count total • Associate a weighting factor (i.e., complexity value) with each count based on criteria established by the software development organization 3) Evaluate and sum up the adjustment factors (see the next two slides) • “Fi” refers to 14 value adjustment factors, with each ranging in value from 0 (not important) to 5 (absolutely essential) 4) Compute the number of function points (FP) FP = count total * [0.65 + 0.01 * sum(Fi)] Information Weighting Factor Domain Value Count Simple Average Complex External Inputs _____ x 3 4 6 = _____ External Outputs _____ x 4 5 7 = _____ External Inquiries _____ x 3 4 6 = _____ Internal Logical Files _____ x 7 10 15 = _____ External Interface Files _____ x 5 7 10 = _____ Count total ________
- 27. Function Point Example • FP = count total * [0.65 + 0.01 * sum(Fi)] • FP = 50 * [0.65 + (0.01 * 46)] • FP = 55.5 (rounded up to 56) Information Weighting Factor Domain Value Count Simple Average Complex External Inputs 3 x 3 4 6 = 9 External Outputs 2 x 4 5 7 = 8 External Inquiries 2 x 3 4 6 = 6 Internal Logical Files 1 x 7 10 15 = 7 External Interface Files 4 x 5 7 10 = 20 Count total 50
- 29. Architectural Design Metrics • These metrics place emphasis on the architectural structure and effectiveness of modules or components within the architecture • They are “black box” in that they do not require any knowledge of the inner workings of a particular software component
- 30. Hierarchical Architecture Metrics • Fan out: the number of modules immediately subordinate to the module i, that is, the number of modules directly invoked by module i • Structural complexity – S(i) = f2 out(i), where fout(i) is the “fan out” of module i • Data complexity – D(i) = v(i)/[fout(i) + 1], where v(i) is the number of input and output variables that are passed to and from module i • System complexity – C(i) = S(i) + D(i) • As each of these complexity values increases, the overall architectural complexity of the system also increases • This leads to greater likelihood that the integration and testing effort will also increase • Shape complexity – size = n + a, where n is the number of nodes and a is the number of arcs – Allows different program software architectures to be compared in a straightforward manner • Connectivity density (i.e., the arc-to-node ratio) – r = a/n – May provide a simple indication of the coupling in the software architecture
- 31. Process and Project Based Matrices
- 32. Process and Project Indicators Process indicators enable software project managers to: – assess project status – track potential risks – detect problem areas early – adjust workflow or tasks – evaluate team ability to control product quality
- 33. Process metrics • Private process metrics – (e.g. defect rates by individual or module) are known only to the individual or team concerned. • Public process metrics – enable organizations to make strategic changes to improve the software process. • Metrics should not be used to evaluate the performance of individuals. • Statistical software process improvement helps an organization to discover its strengths and weaknesses.
- 34. Project Metrics • Software project metrics are used by the software team to adapt project workflow and technical activities. • Project metrics are used to avoid development schedule delays, to mitigate potential risks, and to assess product quality on an on-going basis. • Every project should measure its inputs (resources), outputs (deliverables), and results (effectiveness of deliverables).
- 36. Size-Oriented Metrics • Derived by normalizing (dividing) any direct measure (e.g. defects or human effort) associated with the product or project by LOC. • Size oriented metrics are widely used but their validity and applicability is widely debated.
- 37. Software Quality Assurance ( SQA)
- 38. In respective stages of software development • The degree to which a system, component, or process meets specified requirements. • The degree to which a system, component or process meets customer or user needs or expectations. What is SQA?
- 39. SQA encompasses the entire software development process • software requirements • software design • coding • source code control • code reviews • change management • configuration management • release management SQA
- 40. • 1. Purpose • 2. Reference documents • 3. Management • 4. Documentation • 5. Standards, practices, convention, and metrics • 6. Software Reviews • 7. Tests • 8. Problem reporting and corrective actions • 9. Tools, techniques, and methodologies • 10. Media control • 11. Supplier control • 12. Records collection, maintenance, and retention • 13. Training • 14. Risk management • 15. Glossary • 16. SQAP change procedure and history 1) Underlined sections will be included in our project’s SQAP Content of SQAP - Software Quality Assurance Plan1)