Release judgment criteria・To check the product quality, first check the design quality

27/12/2017Release Judgment

We also look at product quality and process quality in release judgment

One of the four criteria that my father Gutara used to judge the release of software is product quality, which I introduced in the article before the four criteria for the release judgment . 

Product quality and process quality are important ideas when considering software quality, but what to focus on varies depending on the market and organization. For the specific content of the term product quality used by my father Gutara, I have created another classification for product quality and introduced it in detail in several articles, so please refer to that for details.

In this article, I will introduce how to judge the quality of the product at the time of release judgment based on the experience of Father Gutara.  

Product quality is divided into design quality and code quality.

Product quality can be roughly divided into the following two, so if you know the quality of these, it seems that you can judge the quality of the product.

  1. Design quality
  2. Source code quality

So how do you judge the quality of each of these two? When I start thinking about it, there are a lot of things that I have to think about again, but Father Gutara has simply decided that quality is good if there are few mistakes .

Design quality is measured by the results of design reviews

First of all, the first design quality . How can you tell if the design quality is good or bad, in other words, if there are many or few design mistakes ? Father Gutara judged the quality of the design by looking at the following three pieces of information.

  1. Design review indication density = number of indications / number of design document pages to be reviewed
  2. Design review density = design review man-hours (man-hours) / number of design document pages to be reviewed
  3. Review team competence = number of participants of design leader

The density of the first indication is an indicator of whether there are many or few design mistakes. The density of the latter two reviews and the competence of the team are supplementary information to determine if the density of indications is appropriate. Let’s look at them in order.

The number of design reviews pointed out is the number of design mistakes

What was pointed out in the design review is that there was something wrong with the design content and it was found. By the way, there are two situations where you can find design mistakes . The first is the time of design review (often called design review or DR). Design review is an activity that aims to find and point out design mistakes , so many of the design mistakes can be found here, should be found, hopefully found … real intention is we now have) to leaks design review mistake of design miss, the test in the bug can be found as. I want you to find it, no, let’s find it! !!

And any bugs you missed in design reviews and tests. .. .. Well, at the time of production operation, I pop out and ridicule us. It’s a little off topic, but design mistakes can be found in two areas: design review and testing. So if you want to find out how many design mistakes you have, you have to add both.

However, the release decision in order to determine the bad of the product quality is good in the mistake of design To determine whether less or in many cases, I think that may be the only counting only the number of mistakes that were found in the design review. In other words, you don’t have to count the number of design mistakes that are causing the bugs you find in the test, just by counting the number of design reviews pointed out . 

Of course, it 's a good idea to add to the number of design mistakes if the bug found in the test is found to be a design mistake. But does your company have analyzed the cause of the bug by the time the software is released and know the cause of the bug ?

Design mistakes found in tests are innumerable

If you have a good software development project where the debug phase just before the release goes as planned, you probably know the cause of the bugs at the time of release . But in the world of embedded software, where my father Gutara has worked, unfortunately I have little experience with such a good project. I think everyone reading this page doesn’t have much experience with such a good project. 

I think there are still many software development projects that often go through Death Valley just before its release . In such an ordinary development project , it is unlikely that the cause of the bug will be known at the time of release judgment . So, Gutara’s father gave up what he couldn’t hope for, and at the time of the release decision, he only looked at the number of indications found in the design review .

The quantity and quality of design reviews are important as well as the number of indications in determining design quality.

However, even if it is said that the quality of the design is judged by the number of indications found in the design review , how many indications were there? Even if you look only at the absolute number, you can not understand the design quality very well. Pointed out that the number pointed out that the number is large, the design quality is poor and the design quality is good less, that can not be a simple decision of the dish developed product is where annoying of software. In the first place, if you do not carry out a design review even once , the points to be pointed out will be zero as a matter of course. In addition, even if a design review is conducted, if the reviewer has little design experience, it is unlikely that another person will notice a design error, and the number of indications will decrease.

Therefore, when looking at the number of points pointed out in design reviews , it is not possible to judge whether the quality of the design is good or bad unless the amount of design reviews and the competence of the review team are also taken into consideration.

The number of points pointed out in the review is normalized according to the scale of the design and used for judgment.

And another caveat is the scale of the design . The larger the scale of the design, the greater the number of indications . It is natural that the number of indications differs between the one-page design document review and the 100-page design document review . Therefore, the amount of design reviews and the number of issues must be normalized on the scale of the design before looking at them. Since the scale of the design is vague, I used it as information to judge the quality of the design by dividing it by the number of pages of the design document to be reviewed, which is the easiest to count , and converting it into the review rate and the indication rate . ..

The ability of the review team affects the indication density, but it is difficult to judge whether it is good or bad.

This is the competence of the final review team, but it is difficult to quantify. So, the competence of the review team was judged by how many Zackli and leader class designers participated in the review. However, counting the number of leader-class designers participating in each design review in detail for each review does not make much sense at the time of release judgment, so the average number of leaders in the overall design review is large. Did classmates participate in the design review? I have a view that.

What is the standard value for judging the quality of design?

I see, I understand the three items to judge the quality of the design, so what is the good value and how bad is it? That is the last question, isn’t it? It is my father’s idea that I don’t understand this . As a matter of fact , the review density and the pointed-out density vary greatly depending on the particle size of what is counted as one case, the density of description on one page of the design document , the required description level of the design document, and the method of design review. It will end up. Therefore, it is difficult to create a standard criterion for judging good or bad based on this value .

So why did Father Gutara judge the quality of the design? And say, reviews density and pointed out density for, and software quality was reasonably good in the earlier similar development of comparison to, whether the or less this time there are many, to determine a relative comparison was based on the experience of Was there.

In short , it is a judgment that if it is the same as before, it will not be bad . Also, regarding the competence of the design review team, I would like at least one person to participate in the leader class. Well, I thought that it would be safe if there were about 1.5 to 2.0 leader-class people on average to do the design review, so I set that value as the criterion for judgment.

When the roughly collectively would, past and software development of the quality was good than if degree about the same, would be all right even if the Well released as design quality, because, pointed out density, reviews density, the average participation of the reader It means that it was judged by the number of people .

Now, regarding the next source code quality, the article has become a little longer, so I will write the continuation in the next article, so please continue reading that as well. (I’m just tired of writing, high. I think I’ll play with style.css and develop my mood …)

Next : Release judgment criteria・Check the code quality to check the product quality

Posted by Gutara Father