This course covers techniques for monitoring your projects in order to align client needs, project plans, and software production. It focuses on metrics and reviews to track and improve project progress and software quality.
5.2.3: Goal, Question, Metric (GQM)
Loading...
來自 University of Alberta 的課程
Reviews & Metrics for Software Improvements
817 個評分
從本節課中
Module 2: Done Right
Welcome to the second module! Now that you’ve learned about how to make sure you’re creating the “right product”, it’s time to explore how to ensure that product is “done right”. Here, you’ll start with review techniques, some issues surrounding project monitoring in general, and the Goal Quality Metric framework. Then, you’ll move on to desirable properties of metrics and dive into some key metrics for ensuring that you’re on track. You’ll finish off the module with defect analysis, leading you into getting your product “managed right” in the next module.
與講師見面
Kenny WongAssociate Professor
Computing Science, Faculty of Science
[MUSIC]
Welcome back.
In the last lesson,
I spoke about some of the issues that surround monitoring software projects.
These issues had a lot to do with the effectiveness of metrics and
how metrics can be misused.
In this lesson, I'm going to talk about a way of formulating metrics.
So that you can make sure that they are measuring aspects of your project
that are valuable to you and your team.
That method is called goal, question, metric.
Goal, question, metric, or GQM is a method of choosing metrics for your software
projects created by Victor Basili in the University of Maryland in 1994.
The basic idea behind GQM, according to Basili himself, is that for
an organization to measure in a purposeful way, it must first specify the goals for
itself and its projects.
Then it must trace those goals to the data that are intended to define those goals
operationally, and finally, provide a framework for
interpreting the data with respect to the stated goals.
Basically, in order to make sure that you're using the right metrics for
your project you have to know the concept that you want to measure first,
also known as your goal.
Once you know that you have to figure out what defines that goal,
also known as your question.
Then you have to find a way to calculate that definition
in a way that you can interpret to inform your progress towards the goal,
this is known as your metric.
To start at the beginning, how do you set a goal?
Well, according to Basili, goals are applied to objects.
These objects are products, processes, and resources.
Essentially, you could choose your goal to improve one of these three things.
You could choose to improve your product like your code, or your documentation.
You could choose to improve your processes, such as your testing or
elicitation processes.
You could choose to improve your resources, such as your office space,
the computers on which your development team works or the developers' effort and
salaries.
The whole idea is that you can measure anything but breaking your project goals
down into these three categories, helps you to think about how to measure them.
What is the purpose of GQM?
A, to ensure that you are building the right product.
B, to ensure that you use metrics effectively.
C, to make sure that metrics use the correct data.
Or D, to make sure that you ask the client the right questions.
The answer is B, to ensure that you use metrics effectively.
GQM is a framework for
using metrics that focuses on making sure that you use the best metrics for
answering the question you want to ask about your project.
The next thing to consider after each goal are the questions you want to ask about
the goals.
Basically, what questions do you need to ask
that will tell you whether each goal is being met.
This depends on the individual goal.
But the general idea is that your questions should be specific enough so
that the answer to the question addresses the goal.
And how do you find that answer?
That's where the metric part comes in.
A metric is a quantitative way in which data can be collective
to address the questions you're asking.
This is something that we already covered though.
This metric is exactly the same as other metric we've discussed in previous
lessons.
The only thing that's special about metrics as they exist in the GQM
is that they are made more meaningful by the planning process that proceeds them.
Metrics in the GQM are made more valuable because the questions that metrics
are designed to answer have been thought out ahead of time.
Metrics can either be subjective or objective.
If they're objective, they're based on data that does not rely on
anyone's individual viewpoint or interpretation.
For example, this could be number of product downloads, sales numbers,
processing time, or user stories completed.
Subjective metrics are those that depend on interpretation,
such as product ratings by users, developer morale, or code quality.
If you think of metrics like software,
this is a lot like what we talked about in the client needs and software requirements
course, about gathering requirements versus soliciting them.
You don't want to just start with gathering metrics with reckless abandon.
Just like it's important to elicit requirements from your client,
it's also important to specify the goals of the metric ahead of time.
Of course, once you have user stories,
you don't dive straight into building them either.
That's because you create developer tasks first.
Small actionable items that can be done in a few hours.
Questions in the GQM are the same thing.
You create small items that when added together address the entire goal.
Only when you have planned your work ahead of time with a release and iteration plan,
do you move forward to developing code.
So, only when you have defined the goals of your metrics with specific questions
ahead of time, do you move forward to actually implementing the metrics and
collecting data.
What does GQM stand for?
A, goal, question, measure.
B, gains, question, measure.
C, goal, question, metric, or D, gains, question, metric.
The answer is C, goal, question, metric.
Let's look at an example of GQM. Say,
you're developing product and you want to know whether your product is done right.
Product quality then is your goal.
Here are a few questions that could help you address this goal.
How much of my product's code is covered by unit tests?
How many defects are in my product?
Once you've asked your questions, the next step is to identify your metrics.
So, if we were to take the question of how many defects are in my product?
We could approach this in a few ways.
One metric could be the number of times a user store is rejected during
acceptance testing before it's finally accepted.
This could be represented as a percentage of rejections to acceptances across
the whole project.
You could say that a high ratio of rejections to acceptances is an indicator
that something in your process should change, so
that you can reduce the defects.
To know what a high ratio is, you might consider comparing this number
across projects that worked well versus those that didn't.
Another metric that addresses this question is the number of bugs that
are placed in your product backlog at any given time.
If you're seeing an influx of bugs in your backlog, this might indicate that you need
to review your techniques to catch defects earlier.
Of course, you could get much more complicated than that.
The idea here is just to give you an idea
of how metrics can be applied within the GQM paradigm.
