1 / 57

SOFTWARE METRICS FOR PROCESS AND PROJECTS LECTURE NOTES 3

SOFTWARE METRICS FOR PROCESS AND PROJECTS LECTURE NOTES 3. SOFTWARE METRICS FOR PROCESS AND PROJECTS.

kiral
Download Presentation

SOFTWARE METRICS FOR PROCESS AND PROJECTS LECTURE NOTES 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SOFTWARE METRICSFORPROCESS AND PROJECTSLECTURE NOTES 3

  2. SOFTWARE METRICS FOR PROCESS AND PROJECTS Software Process Metrics and Project Metrics are Quantitative Measures that enable Software Professionals to gain insight into the efficacy of Software Process and the Project that are conducted using the Process as a Framework. Quality and Productivity data are collected, analysed and compared against past averages to :- - Assess Productivity improvements. - Pinpoint Problem areas

  3. SOFTWARE METRICS FOR PROCESS AND PROJECTS WHO DOES IT ? Software Measures are often collected by Software Engineers/ Software Practitioner. Software Metrics are analyzed and assesses by Software Managers. WHY METRICS IS IMPORTANT? If you do not measure, your judgment can be based only on subjective evaluations. With Measurement:- - Trends can be spotted, - Better estimates can be made, - True improvement can be accomplished

  4. SOFTWARE METRICS FOR PROCESS AND PROJECTS WHAT ARE THE STEPS? 1. Defining a limited set of Process and Project that are easy to collect. 2. The result is analyzed and compared to ‘’Past Average’’ for similar Project performed within the organization. 3. Trends are assessed and conclusions are generated. WORK PRODUCT? A set of Software Metrics that provide insight into the Process and understanding of the Project. - Productivity Metrics - Quality Metrics

  5. SOFTWARE METRICS FOR PROCESS AND PROJECTS REASONS FOR MEASURING To Characterize To Evaluate To Predict To Improve Measurement is a Management Tool. Measurement provides a Project Manager with insight. It assists Manager and Project team in making sound decision.

  6. SOFTWARE METRICS FOR PROCESS AND PROJECTS Project Metrics are collected across all Projects and over long periods of time. Their intent is to provide a set of Process Indicators that lead to long term Software Process improvement. Project Metrics enable Project Managers to: Assess the status of an ongoing Project Track potential Risks Uncover Problem areas before they “Go critical” Adjust work flow or Tasks Evaluate the Project Team’s ability to Control Quality of Software Work Product. Measures that are collected by a Project team and converted into Metrics for use during a Project can also be transmitted to those with responsibility for Software Process improvement. For this reason, many of the same Metrics are used in both the Process and Project domain.

  7. SOFTWARE METRICS FOR PROCESS AND PROJECTS The only Rational way to improve any Process is to: a) Measure Specific attributes of the Process b) Develop a set of meaningful Metrics based on these attributes c) Use Metrics to provide Indicator that will lead to strategy for improvement However it is important to note that Process is only one of a number of ‘’Controllable Factors’’ in improving Software Quality and Organizational performance.

  8. PRODUCT CUSTOMER CHARACTERISTICS BUSINES CONDITIONS PROCESS DEVELOPMENT ENVIRONMENT TECHNOLOGY PEOPLE SOFTWARE METRICS FOR PROCESS AND PROJECTS

  9. SOFTWARE METRICS FOR PROCESS AND PROJECTS The Figure shows the Process in the centre of a triangle connecting three Factors that have profound influence on Software Quality and Organizational Performance. The Skills and the Motivation of people has been shown to be the single influential factor in Quality and Performance. The Complexity of Product can have a substantial impact on Quality and Project Team Performance. The Technology (Methods and Tools) that populates the Process has an impact. The Process Triangle exists within a circle of Environmental Conditions that include the Development Environment (CASE TOOLS, Business Conditions (Deadlines, Business rules), and Customer Characteristics (ease of communication and collaboration etc)

  10. SOFTWARE METRICS FOR PROCESS AND PROJECTS We measuring the efficacy of Software Process “indirectly”. We derive a Set of Metrics based on the Outcomes that can be derived from Process. Outcomes include Measures of:- - Errors uncovered before release of Software, - Defects delivered to and reported by end-users, - Work Products delivered (Productivity), - Human effort expanded, - Calendar time expanded, - Schedule conformance - Other measures. We also derive Process Metrics by measuring the Characteristics of specific Software Engineering Task. (E.g. we might measure the Effort and Time spent performing the Generic Software Engineering Activities.)

  11. SOFTWARE METRICS FOR PROCESS AND PROJECTS There are ‘’Private’’ and ‘’Public’’ use of Different Types of Process Data . It is natural that individual Software Engineers might be sensitive to use Metrics collected on an individual basis, these data should be Private to the individual and serve as an Indicator for the Individual only. e.g. Defect Rates by individual, Defect Rates by Software components, and error found during Development. Some Process Metrics are Private to the Software Project Team but Public to all Team members. (e.g. Defects reported for major Software functions that have been developed by a number of Engineers. Errors found during Technical Reviews, and Lines Of Code (LOC) or Function Point (FP) per Component or Function. These data are received by the Project Team to uncover Indicators that can improve Team performance. Public Metrics generally assimilate information that originally was private to an individual or a Project Team.(e.g. Project level defect rates, , Effort, Calendar Times, and Related data are collected and evaluated in an attempt to uncover Indicators that can improve Organizational Process Performance.

  12. SOFTWARE METRICS FOR PROCESS AND PROJECTS Software Process Metrics can provide significant Benefits as an Organization works to improve its overall level of Process Maturity. However like all Metrics,, these can be misused, creating more problems that they solve. SOFTWARE METRICS ETIQUETTE Suggested by Grady that is appropriate for both Managers and practitioners as they institute a Process Metrics Program. 1. Use common sense and organizational sensitivity, when interpreting Metrics. 2. Provide regular feedback to the individual and Teams who collect measures and Metrics. 3. Do not use Metrics to appraise individual. 4. Work with Practitioners and Teams to set clear goals and Metrics that will be used to achieve them 5. Never use Metrics to threaten individual or Teams. 6. Do not consider Metrics data that indicate a problem area as negative. These data are merely an indicator for process improvement Consider it as and Indicator for Process improvement. Don’t obsess on a single Metric to the exclusion of other important Metrics. As an Organization becomes more comfortable with the collection and use of Process Metrics, the derivation of simple Indicators gives way to a more rigours approach called (SSPI) “Statistical Software Process Improvement (SSPI). SSPI uses Software Failure Analysis to collect information about all errors and defects. Encountered as an Application, System, or Product is developed and used.

  13. SOFTWARE METRICS FOR PROCESS AND PROJECTS Software Project Metrics are tactical as opposed to the Software Process Metrics which are used for Strategic purposes.. Project Metrics and Indicators are used by a Project manager and a Software Team to adapt Project Workflow and technical activities. The first application of Project Metrics on most Software Projects occur during Estimation. Metrics collected from past Projects are used as a basis from which ‘’Effort’’ and ‘’Time’’ Estimates are made for current Software work. As a Project proceeds, measures of ‘’Effort’’ and ‘’Calendar Time’’ expended are compared to original Estimates. The Project Manager uses data to monitor and Control progress. As Technical work commences, other Project Metrics begin to have significance. Production Rates represented in terms of Models created, Review Hours, Function Points, and Delivered Source Code lines are measured. Errors uncovered during each Engineering tasks are tracked. As the Software evolves from Requirements into Design, Technical Metrics are collected to assess Design Quality and provide Indicators that will influence the approach taken to Software code generation and Testing.

  14. SOFTWARE METRICS FOR PROCESS AND PROJECTS THE PURPOSES OF PROJECT METRICS a) To Minimize the Project Development Schedule by making the necessary adjustments to avoid delays and mitigate potential problems and risks. To Asses Product Quality on an ongoing basis and, when necessary, modify the Technical approach to improve Quality. As Quality improves the Defects are minimized, and as the Defect counts goes down, the amount of rework required during the Project is also reduced. This leads to a reduction in overall Project Costs.

  15. SOFTWARE METRICS FOR PROCESS AND PROJECTS PROJECT METRICS APPLICATIONS- During ‘’Project Estimation Metrics collected from the past Projects are used as a basis from which ‘‘Effort and Time Estimates’’ are made for current Software work. - As Project proceeds, Measures of Effort and Calendar Time expended ( Actual Times) are compared to Planned (Original) Estimates. As Technical work commences Other Project Metrics rates begin to have significance. Such rates include:- - Production Rates - Review Hours, - Function Points - Delivered Line of Source Codes (LOC) As the Software evolves from Requirements into Design, Technical Metrics are collected to assess Design Quality and to provide indicators that influence approach taken to Code Generation & Testing.

  16. SOFTWARE METRICS FOR PROCESS AND PROJECTS Software Project Metrics are tactical as opposed to the Software Process Metrics. Project Metrics and Indicators are used by a Project manager and a Software Team to adapt Project Workflow and technical activities. The first application of Project Metrics on most Software Projects occur during Estimation. THE PURPOSES OF PROJECT METRICS a) To Minimize the Project Development Schedule by making the necessary adjustments to avoid delays and mitigate potential problems and risks. To Asses Product Quality on an ongoing basis and, when necessary modify the technical approach to improve Quality. As Quality improves the Defects are minimized and as the Defect counts goes down, the amount of rework is also reduced. This leads to a reduction in overall Project Costs.

  17. SOFTWARE METRICS FOR PROCESS AND PROJECTS SOFTWARE MEASUREMENT1. Direct Measurement 2. Indirect Measurement Direct Measurements of Software Process includes: - Cost and Effort applied. Direct Measurements of Product includes: - Lines of Code (LOC) Produced, - Execution Speed - Memory size - Defect reported over a set period of time Indirect Measurements Of Product includes - Functionality - Quality - Complexity - Efficiency - Reliability - Maintainability and many others…

  18. SOFTWARE METRICS FOR PROCESS AND PROJECTS Size Oriented Metrics are derived by normalizing Quality and/or Productivity Measures by considering the Size of Software that has been produced. SIZE-ORIENTED METRICS - Errors / KLOC - Defect / KLOC - $ / KLOC - Page of Document / KLOC Other interesting Metrics can be computed such as:- - Errors / Person-Month - LOC / Person-Month - $ / Pages of Documentation Note: KLOC (Thousand of Lines of Code)

  19. SOFTWARE METRICS FOR PROCESS AND PROJECTS SIZE-ORIENTED METRICS The Table below lists each Software Development Project that has been completed over the past few years and corresponding Measures for that Project. REFERRING TO Project A , 12100 Lines of Code (LOC) were developed with in 24 Person- Months of Effort at a cost of $168000. The Effort and Cost recorded in the table represents all Software Engineering Activities i.e. Analysis, Design, Code, and Test) Project A also indicates that 365 Pages of Documentation were developed, 134 Errors were recorded before the Software released, and 29 Defects were encountered after release to the Customer within the first year of operation. 3 Software Engineer worked on Project A development.

  20. SOFTWARE METRICS FOR PROCESS AND PROJECTS We can calculate the following Size Oriented Metrics from the table or each Projects: e.g. for Project A - Errors / KLOC (134 / 12.1 = 11.07) - Defect / KLOC (29 / 12.1 = 2.4 ) - $ / KLOC (168000 / 12.1= 13884) - Page of Document / KLOC (365 / 12.1 = 31.7) Note: KLOC (Thousand of Lines of Code. (eg 12100 LOC = 12.1 KLOC) Other interesting Metrics can be computed such as:- - Errors / Person-Month (134 / 24 = 5.58 ) - LOC / Person-Month ( 12100 / 24 = 504 ) - $ / Pages of Documentation ( 168000 / 365 = 460.27)

  21. SOFTWARE METRICS FOR PROCESS AND PROJECTS WHY SIZE-ORIENTED METRICS ARE NOT UNIVERSALLY ACCEPTED? PROPONENTS Argues that LOC is an “Artifact” of Software Development Projects that can be easily counted. Many existing software Estimation Models use LOC or KLOC as the input and that a large body of literature and data predicted on LOC already exists OPPONENTS Argues that LOC measures are Programming Language dependent, that when Productivity is considered, they penalize well designed but shorter Programs, that they can not easily accommodate Non-procedural Languages. Thus, their use in Project Estimation require a level of detail that may be difficult to achieve. (i.e . The Project Planner must Estimate the LOC to be produced long before Analysis and Design have been completed.

  22. SOFTWARE METRICS FOR PROCESS AND PROJECTS FUNCTION-ORIENTED SOFTWARE MERTICS Function-Oriented Software Metrics use Measure of “Functionality” delivered by the Software Application as a Normalization value. The most widely used Function-oriented Metrics isFUNCTION POINT (FP) Computation of Function Point is based on characteristic of the Software’s Information Domains and the complexity F actors. The Function Point Measure is also controversial like LOC Measures.

  23. SOFTWARE METRICS FOR PROCESS AND PROJECTS The Arguments of Proponents and Opponents of Functional-Oriented metrics: POPONENTS Claim that Function Point (FP) is Programming Language independent, thus making it ideal for applications using Procedural (conventional) and non- Procedural Programming Languages. OPPONENTS Claim that the method requires some ‘’slight of hands’’ in that Function Point computation is based on subjective rather than objective data, that the counts of the Information Domain (and other dimensions) can be difficult to collect after the fact, and that FP has no direct physical meaning; It’s just a number. Function Points (FP) are derived using an Empirical Relationship.

  24. SOSOFTWARE METRICS FOR PROCESS AND PROJECTS Function Points (FP) are computed by completing the ‘’Five Information Domain Characteristics’’ that are determined and Counts are placed in a table. THE FIVE INFORMATION DOMAINS for Function Points calculation 1. Number of Inputs2. Number of Outputs 3. Number of User Enquiries 4. No. Of Files 5. No. of External Interfaces THE COMPLEXITY FACTORS of the System FP = COUNT TOTAL * [0.65 + 0.01 * ∑ ( fi )] Complexity Adjustment Factor

  25. SOFTWARE METRICS FOR PROCESS AND PROJECTS COMPLEXITY FACTOR ASSUMPTIONS (Based on the answers to the following 14 Questions) FACTORVALUE ( fi ). 1. Back-up and Recovery ? 4 2. Data Communication ? 2 3. Distributed Processing ? 0 4. Performance Critical ? 4 5. Existing Operational Environment ? 3 6. On-line Data Entry ? 4 7. Input transactions over multiple Screens? 5 8. Online Updates ? 3 9. Information Domain Values Complex ? 5 10. Internal Processing Complex? 5 11 Code Designed for reuse? 4 12. Conversion / installation in Design? 3 13. Multiple Installations? 5 14. Application Designed for change ? 5 ============================================================ ∑ (fi) (52)

  26. SOFTWARE METRICS FOR PROCESS AND PROJECTS FUNCTION-ORIENTED METRICS ERROR / FP DEFECTS / FP $ / FP PAGES / FPFP / PERSON- MONTH RELATIONSIONSHIP BETWEEN LOC AND FP The relationship between LINES OF CODE (LOC) and FUNCTION POINTS (FP) depends on Programming Language that is used to implement the Software and the Quality of the Design. The Average number of Lines of Code required to build one Function Point in various Programming Languages. Programming LanguageLOC/FP AVERAGE C 128 C++ 64 VISUAL BASIC 32 SQL 12 As you can see that one LOC of C++ provides approx. 2.4 times the Functionality as one LOC of C.

  27. SOFTWARE METRICS FOR PROCESS AND PROJECTS LOC and FP measure are often used to derive Productivity Metrics. However it is debatable to appraise the Performance of individual by using these Metrics, since many factors influence Productivity. FP and LOC based Metrics have been found to be relatively accurate Predictors (Estimates) of Software Development Effort and Cost.. In order to use LOC and FP for Estimation, a historical baseline of Information must be established.

  28. SOFTWARE METRICS FOR PROCESS AND PROJECTS Within the context of Process and Project Metrics, we are concerned with Productivity and Quality measurers of ‘’Software Development Output’’ as a Function of Effort and Time applied and measures of the ‘’Fitness For Use’’ of the Work Products that are produced. However, for the Process improvement and Project Planning purposes 0ur interest is historical. What was the Software Development Productivity on past Projects? What was the Quality of the of Software that was produced? How can the Past Productivity and Quality data extrapolated to present? How can it help us improve the Process and Plan new Projects more accurately?

  29. SOFTWARE METRICS FOR PROCESS AND PROJECTS OBJECT- ORIENTED PROJECT METRICS Conventional Software Project Metrics such as LOC and FP Metrics can be used to estimate O-O Projects However, Conventional Metrics do not provide enough granularity for the Project Schedule and Effort Adjustments that are required as we iterate through Evolutionary incremental Process Method for O-O Projects. Object-Oriented Project Metrics Set :- - No. Of Scenario Scripts - No. Of Key (Foundation) Classes - No. of Support Classes - Average No. Of Support Class / Key Class - No. Of Sub-systems

  30. SOFTWARE METRICS FOR PROCESS AND PROJECTS Number Of Scenario Scripts A Scenario Script is a detailed sequence of steps that describes the interaction between the User and the Application. The number of Scenario Scripts directly correlated to the Size of the application and to the number of Test Cases that must be developed to exercise the System once it is constructed. Number Of Key Classes (Foundation Classes) Key or Foundation Classes are highly independent Components that are defined in Object- Oriented Analysis. Because Key Classes are central to the Problem Domain , the Number of such Classes is an indicator of”: The Amount of Effort required to develop the Software - The potential Amount of Reuse to be applied during the development.

  31. SOFTWARE METRICS FOR PROCESS AND PROJECTS Number of Support Classes Support Classes are required to implement the System but are not immediately related to the Problem Domain. (e.g User Interface Classes, Database Access and Manipulation Classes , Computation Classes) In addition a Support Class can be developed for each of the Key Classes. Thus, the Number of Support classes is an indication of the amount of Effort to develop the Software and an indication of potential amount of Reuse to be applied during Development Average Number of Support Class per Key Class - Key Classes are usually known early in the Project. - Support Classes are defined during the development. If the Average number is known for a given Problem Domain, estimating would be much simpler. Lorenz and Kidd suggest that:- Applications with a GUI have between 2 and 3 times the number of Support Classes as Key Classes. Applications with Non-GUI have between 1 and 2 times the number of Support Classes as Key Classes.

  32. SOFTWARE METRICS FOR PROCESS AND PROJECTS Number of Subsystems A Sub-system is an aggregation of Classes that support a Function that is visible to the end-user of a system. Once Subsystems are identified , it is easier to lay out a reasonable Schedule in which work on Subsystems is partitioned among Project staff.

  33. SOSOFTWARE METRICS FOR PROCESS AND PROJECTS USE OF OBJECT-ORIENTED METRICS To use Metrics effectively in an Object-Oriented Software Engineering Environment, metrics must be collected along with the Project Measurers such as:- Effort Expended - Errors and Defects uncovered - Models or Document Pages produced. As the Project Database grow with Object-oriented Projects, relationships between O-O Measures and Project Measures will provide Metrics that can aid in Project Estimation.

  34. USE-CASE ORIENTED METRICS • Use-Case can be used as a Normalization Measurers similar to LOC or FP. • Like the FP Use-Case, is defined early in the Software Process allowing it to be used for Project Estimation before significant Modeling and Construction activities are initiated. • Use Cases describe User-visible functions and futures that are basic requirements for a system • Use-case is also independent of Programming Languages. • Also the Number of Use-Case is directly proportional to the Size of the Application in LOC and the Number of Test Cases that will have to be designed to fully exercise the Application. SOSOFTWARE METRICS FOR PROCESS AND PROJECTS

  35. CRITICISM ABOUT USE-CASE ORIENTED METRICS Use-case can be created at many different levels of abstraction thus, there is no standard Size for a Use-case. - Without a Standard Measure of what a Use-case is, its application as a Normalization measure (e.g. Effort expanded per Use-case) is suspect. Although a number of researchers have attempted to derive Use-case Metrics, much work remains to be done. SOSOFTWARE METRICS FOR PROCESS AND PROJECTS

  36. SOFTWARE METRICS FOR PROCESS AND PROJECTS WEB ENGINEERING PROJECT METRICS Measures and Metrics used for Traditional Software Engineering Project are difficult to translate directly to Web-Apps. Yet a Web Engineering organization will have to collect Measurers and build a Database that allow it to assess its internal Productivity and Quality over a number of Projects. Among the Measurers that can be collected for WEB Engineering Projects are: No. of Static Web Pages No. of Dynamic Web Pages No. of Internal Page Links No. of External System interfaces No. of Persistent Data Objects No. of Static Content Objects No. of Dynamic Content Objects No. of Executable Functions

  37. SOFTWARE METRICS FOR PROCESS AND PROJECTS WEB ENGINEERING PROJECT METRICS NO. OF STATIC WEB PAGES Web Pages with Static content are the most common of all Web – Applications. These Pages represent ‘’Low relative complexity’’ and generally require less effort to construct than Dynamic pages. This measure provide the overall Size of the Application and the Effort required to develop it. NO. OF DYNAMIC PAGES Are essential for e-commerce Applications an Search Engines, Financial Applications and may other WebApps. These pages represents ‘’Higher relative Complexity’’ and thus require more Effort to construct than Static pages. This measure also provide the overall Size of the Application and the Effort required to develop it.

  38. SOFTWARE METRICS FOR PROCESS AND PROJECTS NO. OF INTERNAL PAGE LINKS Are Pointers that provide a Hyperlink to some other Web pages within the WebApp. This measure provides an indication of the degree of Architectural coupling within the WebApp. As the Link pages increases, the Effort expended on designing and constructing Navigations. NO. OF EXTERNAL SYSTEMS INTERFACED WebApps must often interface with ‘’Backroom Business Applications’’. As the requirements for External interfacing grow, System complexity and development effort increases. NO. OF PERSISTENT DATA OBJECTS One or more Database files may be accessed by a WebApp. As the number of required files grow, the complexity of WebApp also grow and Effort to Implement it increases proportionally.

  39. SOFTWARE METRICS FOR PROCESS AND PROJECTS NO. OF STATIC CONTENT OBJECTS A Static content objects may contain text, graphic, video, animation and audio information. A Multiple content Objects may appear on a single Web Page increasing the complexity. NO. OF DYNAMIC CONTENT OBJECTS Dynamic Content Object are generated based on User actions and encompasses internally generated text, graphic, video, animation and audio information that are incorporated within WebApp. Multiple content Objects may appear on a single Web Page.

  40. SOFTWARE METRICS FOR PROCESS AND PROJECTS WEB ENGINEERING PROJECT METRICS NO. OF EXECUTABLE FUNCTIONS An Executable function (also called Script or Applet) provides some conceptual service to the end-user. As the number of Functions increases, Modeling and construction Effort also increases. Each of the above Measures can be determined at a relatively early stage of the Web Engineering Process. Web Application Metrics can be computed and correlated with Project Measuressuch as :- - Effort Expanded - Errors and Defects uncovered - Models or Document Pages produced. WebApp Measures and Project Measures provide Metrics that can aid in Project Estimation.

  41. SOSOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITY The overriding Goal of Software Engineering is to produce a High-quality Application System within a ‘’Time-frame that satisfy a market need. HOW TO ACHIEVE THIS GOAL, By applying effective Methods coupled with modern Development Tools within the context of a mature Software Process. Taking measures continuously to ensure high quality.

  42. SOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITY The Primary source of quality measurers at the Project-level is ‘Errors and Defects’. Metrics derived from Errors and Defects provide an indication of the effectiveness of Software Quality assurance and Control activities. Error data can also be used compute the ‘Defect Removal Efficiency (DRE)’ QUALITY METRICS that are derived from Errors / Defects - Product Errors Per Function Point - Errors uncovered per review hours - Errors uncovered per Testing hour

  43. SOSOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITY MEASURING QUALITY There are many Measures of Software Quality; But the following Four measures provide useful indicators for the Project Team. - Software Correctness - Software Maintainability - Software Integrity - Software Usability

  44. SOSOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITY 1. SOFTWARE CORRECTNESS Correctness is the degree to which the software performs its required function. Most common measures for Correctness is:- - DEFECTS / KLOC, Defects are these problems that are reported by Users after the Software has been released for general use. For Quality assessment, Defects are counted over a standard period of time, typically for one year.

  45. SOSOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITY 2. SOFTWARE MAINTAINABILITY Maintainability is the ease with which a program can be corrected when an error is encountered, adapted if its environmental changes, or enhanced if the customer desires a change in requirements. There is no way to measure Maintainability directly so we must use indirect measurements. Mean Time To Change Time-(MTTC), which is a simple Time- oriented Metrics can be used to Analyze the changes required, Design the appropriate modification, Test, Implement and distribute the changes to all users. Programs that are maintainable have a lower MTTC than the programs that are not maintainable.

  46. SOSOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITY 3. SOFTWARE INTEGRITY This attribute measures a System ability to withstand both accidental and intentional attacks to its security. Attacks can be made on all three components of a Software (i.e. Programs, Data and Documents.) Integrity has become extremely important in the age of ‘’Hackers and Firewalls’’ To measure Integrity two other attributes need to be defined.- THREAT Probability - SECURITY Probability

  47. SOFTWARE METRICS FOR PROCESS AND PROJECTS Threat Probability - that an attack of a specific type will Occur within a given time SECURITY Probability - that the attack of a specific type will be repelled. INTEGRITY = ∑ [1 – (THREAT Probability * (1 – SECURITY))] Where Threat and Security are summed Over each type of attack. Example1 :- If Threat Probability is 25% and Security (Likelihood of repelling an attack) is 95% the integrity of System is 99% Which is Very High. Example 2 If Threat Probability is 50% and the Security is 25% then the System’s Integrity is 62.5%, which is unacceptably low. Integrity = ∑ [1 - (0,50 * (1 – 0,25))] = [1 - (0,50 * (0,75))] = [1 - (0,375)] = 0,625 or 62,5 %

  48. SOSOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITY 4. SOFTWARE USABILITY Usability is an attempt to quantify User-friendliness and can be measured in terms of the following four characteristics. USABILITY CHARACTERISTICS The physical and / or intellectual skill required to learn the System. The time required to become moderately efficient in the use of the system. The net increase in productivity measured when the system is used by someone who is moderately efficient. A subjective assessment of Users’ attitudes towards the System. If a Program is a not User-friendly it is doomed to failure, even its functions are valuable.

  49. SOFTWARE METRICS FOR PROCESS AND PROJECTS METRICS FOR SOFTWARE QUALITY DEFECT REMOVAL EFFICIENCY Defect Removal Efficiency (DRE) in essence is a Measure of filtering ability of Quality Assurance and Control activities as they are applied through all Process Framework Activities. DRE is a Quality Assurance Metrics that provides benefits of both the Project and Process level. DRE = E / (E + D) Where: (E) No. of Errors before delivery to User. (D) No. of Defects found by users after delivery. The ideal DRE value is “1” or 100% - That is no Defect found in Software. Realistically (D) will be greater than 0, but the value of DRE can still approach 1. As (E) increases, it is likely that the overall Value of (D) will decrease. Example : 20 errors before delivery to users 8 Defects reported by Users after delivery DRE = 20 / (20 + 8) => 20 / 28 = 0,714 or 71,4 %

  50. SOFTWARE METRICS FOR PROCESS AND PROJECTS DEFECT REMOVAL EFFICIENCY DRE encourages a Software Project team to institute technique for finding errors before delivery. DRE can also be used within the Project to Asses a Team’s ability to find Errors before they are passed to the next Process Framework activity of Software Engineering task. For example: Errors that are not found during the Reviews of Analysis Phase are passed on to the Design Phase. When DRE is used in this context:- DREi = Ei / (Ei + E i+1) say (Ei + 1) = y DREi = Ei / (Ei + Ey) (Ei) N0. of errors found deriving Analysis Activity. Ey: No. of errors that were not discovered in Design activity. A Quality objective for a Software team is to achieve a DRE that approximates to 1.

More Related