Goal Question Metric and SoftwareQuality     Muhammad Ameer Abdul Rehman [email protected]  Muhammad [email protected] Khurram [email protected]  COMSATSINSTITUE OF INFORMATION AND TECHNOLOGYLAHORE  Abstract— Goal Question metric is designed for the improvement of SoftwareDevelopment process. GQM defines a certain goals and then refines these goalsinto questions and defines metrics that should provide the information toanswer these questions. The Goal Question Metric (GQM) approach has exhibiteditself accommodating in an assortment of mechanical settings to helpquantitative programming venture administration. This paper talksabout the utilization of the Goal Question Metric as a system for defining andinterpreting software measurement.

In software concentrated affiliations, a hierarchicalorganization won’t guarantee definitive accomplishment unless the businesstechnique can be changed over into an arrangement of operational programmingobjectives. And this paper discuss about the issues on identifying the problemsfaced in the development of software and how to resolve them properly usingGQM.Keywords—GoalQuestion Matric,Software Quality, Software Measurement, Goal Oriented, DefectLeakage.I.                   Introduction: EssentiallyGoal-Question-Metric (GQM) has been proposed by Basils and Weiss.

The rulebehind the GQM technique is that estimation ought to be objective oriented.GQMcharacterizes a specific objective, refines this objective into questions, andcharacterizes measurements that ought to give the data to answer theseinquiries. Whereas software quality refers to two related however particularideas that exist wherever quality is characterized in a business setting.Programming utilitarian quality reflects how well it follows or complies with agiven plan, in light of practical prerequisites or details.

   Similarly aswith any designing control, software improvement requires an estimationcomponent for criticism and assessment. Estimation is a component for making acorporate memory and a guide in noting an assortment of inquiries related withthe establishment of any product procedure. This implies estimation must becharacterized in a best down manner. It must be engaged, in view of objectivesand models.

A base up approach won’t work in light of the fact that there arenumerous discernible qualities in programming yet which measurements one usesand how one deciphers them it isn’t clear without the fitting models andobjectives to characterize the unique circumstance.This paper is organized asfollow: Section II describes the related work. Section III. Describes the Discussionon the GQM. Section IV describes the case study.

Section V Describes theConclusion. In the last section references are provided which helped in thecompletion of this research paper. II.

                 Related WorkAccording to Victor R.Basilithere are few organized ways to deal with software measurement have beenproduced and are utilized as a part of associations. These approaches arereferred to as “GOAL ORIENTED” approaches because they use goals, objectives,strategies, or other mechanisms to guide the choice of data to collect andanalyze in a systematic way. One well known goal-oriented approach is the GQMapproach 1.According to Norton, D. GQM givesa technique to an association or a task to characterize objectives, refinethose objectives down to determinations of information to be gathered, andafter that dissect and translate the subsequent information as for the firstobjectives.

Balanced Scorecard (BSC) 2 is an approach to linking measurementat all levels of an organization to the organization’s strategy. The”scorecard” consists of four perspectives: financial, customer, internalbusiness processes, and learning and growth. BSC does not dictate a static setof measures, but serves as a framework for choosing measures, processes, andinitiatives that are aligned with organizational strategy and higher-levelbusiness goals. According to Victor R.Basili GoalQuestion Metric (GQM) approach is based upon the assumption that for anorganization to measure in a purposeful way it must first specify the goals foritself and its projects, then it must trace those goals to the data that areintended to define those goals operationally, and finally provide a frameworkfor interpreting the data with respect to the stated goals.

Thus it isimportant to make clear; at least in general terms, what informational needsthe organization has, so that these needs for information can be quantifiedwhenever possible, and the quantified information can be analyzed to whether ornot the goals are achieved. The approach was originally defined for evaluatingdefects for a set of projects in the NASA Goddard Space Flight Centerenvironment. The application involved a set of case study experiments 4 andwas expanded to include various types of experimental approaches 3. Althoughthe approach was originally used to define and evaluate goals for a particularproject in a particular environment, its use has been expanded to a largercontext. It is used as the goal setting step in an evolutionary qualityimprovement paradigm tailored for a software development organization.

According to the US Department ofDefense Practical Software Measurement (PSM) 5 offers very detailed guidanceon software measurement, including a catalogue of specific measures, along withinformation on operationalizing them in an organization. PSM also includes aprocess for choosing appropriate measures based on the issues and objectivesrelevant to a software development project.According to Becker, S.

A. inreference 6 addresses the misalignment between strategy at the organizationaland project levels of software organizations caused by project data that doesnot address organizational goals and organizational goals that fail becausethey are not operationalized through processes and metrics at the projectlevel. Their approach is to embed a GQM structure within each of the four BSCperspectives. One advantage of this approach is that it allows more consistencyin notation and terminology surrounding goals and measures at all levels.

However, the approach does not recognize or support truly different goals atdifferent levels of the organization case, italic) in addition to the styleprovided by the drop down menu to differentiate the head from the text.According to Offen, R.J. andJefferey, R.

The M3P – Model, Measure, Manage Paradigm – is an extension of theQIP and GQM 7. M3P embeds GQM as a measurement definition technique within alarger framework that encompasses organizational concerns. M3P does not allowfor goals at different levels of the organization that are different butexplicitly linked, to allow analysis of measurement data to feed back up thechain. III.      Discussion:GQM is the approach to software matrices which is promoted by theVictor Basili from the University of Maryland College Park.

GQM defines ameasurement model on three different levels which are mentioned as follow:·        ConceptualLevel·        OperationalLevel·        QuantitativeLevelConceptual Level: (Goal)                              This leveldefines the goals in which we decide that what we want to accomplish about thedesired project and what are the main problems that we can face in the project. Operational Level: (Question)                            This level defines the set ofquestions is used to characterize the way the assessment/achievement of aspecific goal is going to be performed based on some characterizing model. QuantitativeLevel: (Metrics)                               This Level defines the set of data associated with every questionin order to answer it in a quantitative way.

That data can be possibly in twoways that are mentioned below:·        Objective·        Subjective Objective:                   If they depend only on the object that isbeing measured and not on the viewpoint from which they are taken; e.g., numberof versions of a document, staff hours spent on a task, size of a program. Subjective:                    If they depend on both the objectthat is being measured and the viewpoint from which they are taken; E.g.,readability of a text, level of user satisfaction. GQM Method: Goals}   They define what the organization wants toimprove. Questions}  They refine each goal to a morequantifiable way.

 Metrics}   They indicate the metrics required to answer each question  GQMRepresentation:             A GQM model is a hierarchical structure,starting with a goal that is specifying the purpose of the measurement, theobject to be measured, the issue to be measured, and the viewpoint from whichthe measure is taken.  The goal isthen refined into several questions, which usually break down the issue intoits major components. Each question is then refined into metrics — some of themobjective, some of them subjective.The samemetric can be used to answer different questions under the same goal. SeveralGQM models can also have questions and metrics in common. Here’s an example ofthe GQM approach. As the Project Manager, I would like to know the functionalquality of the current version in the production.Example:   In above example, the goal is to know the quality of thesoftware.

In order to satisfy this goal, two questions are asked. One looks forthe number of defects in the production, which is answered by having a metriccalled “defect leakage.” The other question is to identify if there has beenany improvement in the quality compared to the last release, which is answeredby having defect leakage trend and severity trend metrics. These metrics looklike logical extensions of a Project Manager’s goal. Advantages and Disadvantages:  Advantages: DISADVANTAGES Directing and monitoring process in software. GQM become difficult to apply where the impacts of methodology are not clear.

It accesses the software engineering technologies which are new. Technological support for GQM is still adequate.                                         I.       Certifying and judging the improvement activates. Detailed guidelines for establishment of GQM program in industrial environment are still limited.

It helps in achieving improvement goals. GQM has been criticized for lack of structure and guidance. It generates only those measures which are useful for goal attainment. Evaluation is no final numerous or quantitative result, which could be used for comparing two or more GIS software IV.

            Case Study Background:              Motorola was set up in 1928 by brothers Paul and JosephGalvin. The company was originally incorporated as the Galvin ManufacturingCorporation (GMC), and was headquartered in Chicago. GMC’s first product was a’battery eliminator’, which allowed radios to operate on standard householdelectric current instead of batteries.              The competition in the battery eliminator business wasintense, with manufacturers aggressively undercutting each other. Because ofthis, GMC diversified into making automobile radios, which was a relativelyunexplored business at that time.

GMC’s first car radio was launched in 1930under the name MOTOROLA. Goals:          The goals and measurement areas identified by theMotorola Quality Policy for Software Development (QPSD) are listed in thefollowing.  Goal 1: Improveproject planning. Goal 2: Increasedefect containment. Goal 3: Increasesoftware reliability. Goal 4: Decreasesoftware defect density. Goal 5: Improvecustomer service. Goal 6: Increasesoftware productivity.

 Measurement Areas: }  Delivered defects and delivered defects per size}  Total effectiveness throughout the process}  Number of open customer problems}  Software reliability  Solution:                For each goal the questions tobe asked and the corresponding metrics were also formulated. And following arethe list of the questions and matrices for each goal.  Goal 1 Questions Matrices Improve Project Planning Question 1.1 What was the accuracy of estimating the actual value of project schedule?   Metric 1.

1 : Schedule Estimation Accuracy (SEA) SEA=Actual project duration / Estimated project duration     Question 1.2: What was the accuracy of estimating the actual value of project Effort?   Metric 1.2 : Effort Estimation Accuracy (EEA) EEA= Actual project effort / Estimated project effort     Goal 2 Questions Matrices Goal 2: Increase Defect Containment   Question 2.1: What is the currently known effectiveness of the defect detection process prior to release?   Metric 2.1: Total Defect Containment Effectiveness (TDCE) TDCE = Number of prerelease defects / Number of prerelease defects + Number of post release defects     Question 2.2: What is the currently known containment effectiveness of faults introduced during each constructive phase of software development for a particular software product?   Metric 2.2: Phase Containment Effectiveness for phase i (PCEi) PCEi  = Number of phase errors / Number of phase errors + Number of phase defects     Goal 3 Questions Matrices Goal 3: Increase Software Reliability   Question 3.

1: What is the rate of software failures, and how does it change over time?   Metric 3.1: Failure Rate (FR) FR = Number of failures / Execution time     Goal 4 Questions Matrices Goal 4: Decrease Software Defect Density   Question 4.1: What is the number of in-process faults, and how does it Compare with the number of in-process defects?   Metric 4.1a: In-process Faults (IPF) IPF In-process faults caused by software development / source size Metric 4.1b: In-process Defects (IPD) IPF = In-process defects caused by software development/ source size   Goal 4: Decrease Software Defect Density   Question 4.2: What is the currently known defect content of software delivered to customers?   Metric 4.2: Total Released Defects (TRD) total TRD total Number of released defects /   source size       Goal 5 Questions Matrices Goal 5: Improve Customer Service   Question 5.

1 What is the number of new problems opened during the month?   Metric 5.1: New Open Problems (NOP) NOP = Total new post release problems opened during the month     Question 5.2 What is the total number of open problems at the end of the month?   Metric 5.

2: Total Open Problems (TOP) TOP = Total post release problems that remain open at the end of the month     Question 5.3: What is the mean age of the problems that were closed during the month?   Metric 5.4: Mean Age of Closed Problems (ACP) ACP = (Total time post release problems closed within the month were open) / (Number of open post release problems closed within the month)     Goal 6 Questions Matrices Increase Software Productivity   Question 6.1: What was the productivity of software development projects (based on source size)?   Metric 7.1: Software Productivity total (SP total) SP total = total source size / Software development effort       V.                Conclusion:                                    Software process improvement should bebased regarding quantitative evolution of products and process characteristics.The application of GQM into various projects with same organization that allowsto reuse the parts of GQM planning such as goals, sheets, abstraction, questionand metrics. The reusing of these parts may save effort and time oforganization.

The growth of GQM and its measurement plans must be based on wideknowledge on process details. Goal setting should be based on simplerepresentations and intuitive of the known difficulties of the process that arebeing studied.GQM must have clear knowledge of organization that being studiedat various levels of management.

 References1     Basili, V., Caldiera, G., and Rombach D.

“Goal,Question Metric Paradigm”, Encyclopedia of Software Engineering, vol. 1, JohnWiley and Sons, 1994a.2     Kaplan, R. and Norton, D. “The Balanced Scorecard -Measures That Drive Performance”, Harvard Business Review, January-February1992, p. 71. 3     V.R.

Basili, R.W. Selby, “Data Collection and Analysisin Software Research and Management”, Proceedings of the American StatisticalAssociation and Biomesure Society, Joint Statistical Meetings, Philadelphia,PA, August 1984.

 4     R  Basili, D.M.”A Methodology for Collecting Valid Software Engineering.” IEEE Transactionon Software Engineering, SE-10(6), 728-738(Nov. 1984b) 5     US Department of Defense and US Army (DoD), PracticalSoftware and Systems Measurement: A Foundation for Objective ProjectManagement, 6     v. 4.0c, March 2003, from www.

psmsc.com, visited inAugust 2007. 7     Becker, S.A. and Bostelman, M.L. “Aligning Strategicand Project Measurement Systems”, IEEE Software, May/June 1999, pp.

46-51. 8     Offen, R.J. and Jefferey, R. “Establishing SoftwareMeasurement Programs”, IEEE Software, Mar/Apr 1997. 9     Boehm J. R.

Brown, and M Lipow,”QuantitativeEvaluation of software Quality.”Proceedings of the Second Internationalconference on Software Engineering, pp 592-605, 1976.  

Written by

I'm Colleen!

Would you like to get a custom essay? How about receiving a customized one?

Check it out