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 expains metrics that should provide the data to answer thequestions. The Goal Question Metric (GQM) approach has exhibited itselfaccommodating in an assortment of mechanical settings to help quantitativeprogramming venture administration. This paper talks about theutilization of the Goal Question Metric as a system for determine meaning andexplainingsoftware measurement. In software concentrated affiliations, ahierarchical organization won’t guarantee definitive accomplishment unless thebusiness technique can be changed over into an arrangement of operationalprogramming objectives.
And this paper discuss about the issues on identifyingthe problems faced in the development of software and how to resolve themproperly using GQM.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 someoneuses and how anyone understand dificult in them it isn’t clear without thefitting models and objectives to characterize the unique circumstance.This paper is organized asfollow: Section II describes the relivant work. Section III.
Describes thedetailed meaning on the GQM. Section IV describes the case study. Section VDescribes the Conclusion. In the last section references are provided whichhelped in the completion of this research paper. II. RelatedWorkAccording 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 GAOL ORIENTED approachesbecause they uses aims, techniques and methods to guide the choice of data tocollect and evaluate in a managed way.
One well known goal-oriented approach isthe GQM approach 1.According to Norton, D. GQM givesa technique to an association or a work 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 works at allstages of an organization to the organization’s planing. The “scorecard”consists of four perspectives: financial, customer, internal businessprocesses, and learning and growth. BSC does not dictate a fixed set ofactivities, but serves as a framework for choosing measures, processes, andability to asses that are linked with organizational plans and higher-levelbusiness aims According to Victor R.
Basili GoalQuestion Metric (GQM) approach is based upon the thinking that for anorganization to measure in a meaningfull way it must first select theobjectives for itself and its projects, then it must track those goals to thedata that are intended to define those goals on routine bases, and finallyprovide a scheme for explaining the data with respect to the specified aims andobjectives . Thus it is important to make clear; at least in simple way, whatinformation based requirements the organization has, so that these needs forinformation can be quantitatively evaluated whenever possible, and theevaluated information can be checked to whether or not the objectives areachieved. The approach was originally defined for evaluating defects for a setof projects in the NASA Goddard Space Flight Center environment. Theapplication involved a set of case study experiments 4 and was expanded toinclude various types of experimental approaches 3. Although the approach wasoriginally used to clear and check aims fora particular project in a specific environment, its use has been enlarged to alarger environment. It is used as the goal setting step in an evolutionaryquality improvement pattern fitted for a software development organization.According to the US Department ofDefense Practical Software Measurement (PSM) 5 offers very detailed advice onsoftware measurement, including a list of specific tasks, along withinformation on operationaly apply them in an organization.
PSM also includes aprocess for choosing correct measures based on the problems and aims related to a software development project.According to Becker, S.A.
inreference 6 addresses the incorrect arrangemnt between plan at theorganizational and project levels of software organizations caused by projectdata that does not address organizational aims and organizational goals thatfail because they are not operationalty related through processes and systemsat the project level. Their approach is the root of a GQM structure within eachof the four BSC perspectives. One advantage of this approach is that it allowsmore stability in signs and defining terms surrounding goals and measures atall levels.
However, the approach does not recognize or support truly differentgoals at different levels of the organization case, in addition to the style provided by the dropdown 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 structure that enclosesorganizational informations. M3P does not allow for goals at different levelsof the organization that are different but clearly linked, to allow analysis ofmeasurement data to feed back up the chain. 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) Thislevel defines the goals in which we decide that what we want to accomplishabout the desired project and what are the main problems that we can face inthe 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: Thegoals and measurement areas identified by the Motorola Quality Policy forSoftware Development (QPSD) are listed in the following. 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 be basedregarding quantitative evolution of products and process characters.
Theapplication of GQM into various projects with same organization that allows toreuse 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.